From tim@phonefromhere.com Tue Nov 1 01:30:42 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6607521F8E74 for ; Tue, 1 Nov 2011 01:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsC1dz2qV1Lc for ; Tue, 1 Nov 2011 01:30:41 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id E8FA121F8E6B for ; Tue, 1 Nov 2011 01:30:34 -0700 (PDT) Received: from [10.182.109.135] (unknown [212.183.132.60]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id EE7AD37A902; Tue, 1 Nov 2011 08:43:10 +0000 (GMT) From: Tim Panton Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Nov 2011 08:30:21 +0000 To: rtcweb@ietf.org Message-Id: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com> Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [rtcweb] Usecases for innovation. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 08:30:42 -0000 I've repeatedly been asked for use-cases for innovative applications of = webRTC to justify my contention that we should be providing a low-level = framework, not an embedded legacy compatibility application. It's a 'when did you stop beating your wife?' question, there is no good = answer. By definition we don't know what innovative uses are yet, so we are = reduced to guessing, which sounds unconvincing. By chance, this weekend I was exposed to 2 innovative uses of = real-time-communications in a browser that _won't_ fit in the current looking-over-its-shoulder = scheme. 1) H264 implementation in Javascript http://yfrog.com/nmng0z=20 2) Kinect as an input device for a virtual receptionist in a real = reception area (Voxeo's as it happens). Neither of these are production ready - or indeed necessarily a good = idea, but the fact that neither (minor) innovation fits at all into our brand = new framework should give us pause for thought. (but given the pell-mell dash to be = compatible with last century's deskphones I don't imagine it will). Tim.= From magnus.westerlund@ericsson.com Tue Nov 1 06:24:11 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E1411E8138 for ; Tue, 1 Nov 2011 06:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 2JRXmsRoHYYG for ; Tue, 1 Nov 2011 06:24:11 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A5FEE11E816A for ; Tue, 1 Nov 2011 06:24:10 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-7a-4eaff2f7e79a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F9.2A.13753.7F2FFAE4; Tue, 1 Nov 2011 14:24:07 +0100 (CET) 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.137.0; Tue, 1 Nov 2011 14:24:07 +0100 Message-ID: <4EAFF2F5.5080703@ericsson.com> Date: Tue, 1 Nov 2011 14:24:05 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4EAC6BF4.2000604@alvestrand.no> <4EAE163C.4070603@it.aoyama.ac.jp> In-Reply-To: <4EAE163C.4070603@it.aoyama.ac.jp> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 13:24:11 -0000 On 2011-10-31 04:30, "Martin J. Dürst" wrote: > On 2011/10/30 6:11, Harald Alvestrand wrote: >> Hi, >> being in the process of scanning all the drafts with -rtcweb- in them, I >> came across these two: >> >> draft-nandakumar-rtcweb-stun-uri-00.txt >> draft-nandakumar-rtcweb-turn-uri-00.txt >> >> Just three comments: >> >> - I think it's not RTCWEB business. They should be pointed at the home >> group for STUN/ICE. Well, I think this boils down to an RTCWEB WG requirement to the W3C saying something like: The API must enable the application to configure the WebRTC stack with one or more STUN or TURN resources. This configuration will need to include security credentials for using those resources. >From my perspective I think it is W3C that needs to consider if they want to use an URI format, or have tuple providing host name/address, transport, security, and security credentials. > > For TURN, there's already > http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-bis-04. I also think the draft authors should take RFC 5928 into account here. That document defines how DNS can be used to resolve TURN resources using S-NAPTR. 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 Nov 1 07:10:48 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E3621F9421 for ; Tue, 1 Nov 2011 07:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.419 X-Spam-Level: X-Spam-Status: No, score=-106.419 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 eSQE4gu7wK0s for ; Tue, 1 Nov 2011 07:10:47 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 28F1621F941E for ; Tue, 1 Nov 2011 07:10:46 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-24-4eaffdd262b1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 36.41.13753.2DDFFAE4; Tue, 1 Nov 2011 15:10:26 +0100 (CET) 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.137.0; Tue, 1 Nov 2011 15:10:26 +0100 Message-ID: <4EAFFDD1.4000909@ericsson.com> Date: Tue, 1 Nov 2011 15:10:25 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_T=FCxen?= References: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@acmepacket.com> <8624F864-AB28-4CE7-AB8D-8A55B08AD745@lurchi.franken.de> In-Reply-To: <8624F864-AB28-4CE7-AB8D-8A55B08AD745@lurchi.franken.de> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , Randall Stewart Subject: Re: [rtcweb] Layers in draft-jesup-rtcweb-data-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 14:10:48 -0000 On 2011-10-26 22:45, Michael Tüxen wrote: > > On Oct 26, 2011, at 10:28 PM, Hadriel Kaplan wrote: >> But rather this: >> >> +------+ +------+ >> |WEBAPP| |WEBAPP| >> +------+------+------+ +------+------+------+ >> | DTLS | Audio| Video| | SCTP | Audio| Video| >> +---------------------------+ +---------------------------+ >> | STUN | SCTP |S/RTP |S/RTP | | STUN | DTLS |S/RTP |S/RTP | >> +---------------------------+ +---------------------------+ >> | Mux/Demux | | Mux/Demux | >> +---------------------------+ +---------------------------+ >> | UDP | | UDP | >> +---------------------------+ +---------------------------+ >> >> [Note: "S/RTP" = SRTP/SRTCP or RTP/RTCP, "Mux/Demux" = tiny logic to mux/demux] >> >> Because the audio/video streams may be using the same UDP port, right? >> >> And the two "S/RTP" boxes may be just one box depending on how the MMUSIC multiplexing decision turns out. >> >> So if we want to choose the left one, because we expect/want that someday the Operating System provides a SCTP/UDP stack in the kernel, and I think we do, could it do so while demuxing and letting STUN, RTP, and DTLS go up to the app layer? (i.e., given a socket/BIO/FD model) I have no idea about such things... just asking. > This is not possible today. The demultiplexing seems to be specific to this scenario. > Not sure it fits. For demuxing you use the first byte to distinguish STUN from DTLS and SRTP. > The first byte us the high order byte of the source port. Once could require > SCTP to use source ports with the high order byte > 192. That might work. > However, you would need to get the Mux/Demux into the kernel. Could be done > using a socket option. But I'm not sure it really fits. Maybe Randy has an > opinion. > Michael, I think one of the reasons there is discussion of use land implementations of SCTP is so that you can do the above stack diagrams with SCTP above UDP that is being shared for several purposes. I would also like to correct Hadriel's picture slightly: >> +------+ +------+ >> |WEBAPP| |WEBAPP| >> +------+------+------+ +------+------+------+ >> | DTLS |Audio & Video| | SCTP |Audio & Video| >> +---------------------------+ +---------------------------+ >> | STUN | SCTP | DTLS-SRTP | | STUN | DTLS | DTLS-SRTP | >> +---------------------------+ +---------------------------+ >> | Mux/Demux | | Mux/Demux | >> +---------------------------+ +---------------------------+ >> | UDP | | UDP | >> +---------------------------+ +---------------------------+ I think the above indicating that the common RTP session, potentially being a DTLS-SRTP keyed RTP session that can co-exist on the same UDP flow. To make the left one work, I think one has to have a source port where the first byte value is 192-255 as the de-multiplexing table from section 5.1.2 of RFC 5764 shows these to be the only available. Thus I think the options are: A. Left figure above. (source port must be in 49152-65535) B. Right figure above C. SCTP in its own UDP flow plus one UDP flow for each RTP session. If we would pick SCTP then I think we must have either A+C or B+C working. 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 Tue Nov 1 07:18:56 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FEC21F9852 for ; Tue, 1 Nov 2011 07:18:56 -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 zmr1HhUK0I4J for ; Tue, 1 Nov 2011 07:18: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 5951821F984B for ; Tue, 1 Nov 2011 07:18:55 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so6893848vcb.31 for ; Tue, 01 Nov 2011 07:18:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.150.212 with SMTP id z20mr2782684vcv.58.1320157131983; Tue, 01 Nov 2011 07:18:51 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Tue, 1 Nov 2011 07:18:51 -0700 (PDT) In-Reply-To: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com> References: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com> Date: Tue, 1 Nov 2011 15:18:51 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tim Panton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Usecases for innovation. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 14:18:56 -0000 2011/11/1 Tim Panton : > I've repeatedly been asked for use-cases for innovative applications of w= ebRTC > to justify my contention that we should be providing a low-level framewor= k, > not an embedded legacy compatibility application. > By chance, this weekend I was exposed to 2 innovative uses of real-time-c= ommunications > in a browser that _won't_ fit in the current looking-over-its-shoulder sc= heme. > > 1) H264 implementation in Javascript http://yfrog.com/nmng0z Interesting but, how is that related to WebRTC? IMHO the RTP stack and media manipulation (including codecs) must be built-in the browser rather than doing it at JavaScript level. > 2) Kinect as an input device for a virtual receptionist in a real recepti= on area > =C2=A0 =C2=A0 =C2=A0 =C2=A0(Voxeo's as it happens). This is cool, but IMHO it requires: 1) A system driver for the Kinect device (in the same way a webcam requires a system driver). 2) A browser specification for handling those kind of devices (indeed not all the RTC is audio and video). 3) A mechanism for passing in-the-wire the data retrieved from the device (corporal position and so). - Bullet 1 is out of the scope of WebRTC, however there are open source drivers for Kinect in most of the operating systems. - IMHO bullet 2 should be in the scope of some other (new?) Working Group, and we need it to be somehow standarized (I can't imagine a specification for handling *just* Kinect in browsers, those kind of devices should be "standarized" before carrying them to the browsers). - Bullet 3 can already be achieved in multiple ways (using HTTP polling, HTTP Commet, AJAX, WebSocket... and in theory also the WebRTC Data specification). > Neither of these are production ready - or indeed necessarily a good idea= , > but the fact that neither (minor) innovation fits at all into our brand n= ew framework > should give us pause for thought. (but given the pell-mell dash to be com= patible > with last century's deskphones I don't imagine it will). Indeed most of the discussions in this WG are about how to make ***current*** SIP devices to work with a WebRTC scenario. It's a limited vision of WebRTC in which the main interest is to make profit of this new spec within telcos business. Bad IMHO. But, where are those "innovative" and "crazy" Web folks right now? why 95% of people discussing in this ***open*** WG are telcos? So this is also their fault, the fault of people not participating here and now. In the other side, let's take into account that 99% of Web folks know absolutely nothing about RTC and/or VoIP. They live on top of HTTP and port 80/443. WebRTC is about realtime communications, we need people with RTC experience here. But indeed we need also the vision of Web folks (in contrast to so much legacy telephony vision). Anyhow I'm not so pesimist. I think that current WebRTC design is flexible enough to make possible lot of features without being constrained to follow a telco/telephony model at all. Regards. --=20 I=C3=B1aki Baz Castillo From magnus.westerlund@ericsson.com Tue Nov 1 07:34:21 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4310B11E80F9 for ; Tue, 1 Nov 2011 07:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 bPxaJTBzqICW for ; Tue, 1 Nov 2011 07:34:20 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 15AB311E809C for ; Tue, 1 Nov 2011 07:34:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-3a-4eb0036abdb2 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 60.74.13753.B6300BE4; Tue, 1 Nov 2011 15:34:19 +0100 (CET) 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.137.0; Tue, 1 Nov 2011 15:34:18 +0100 Message-ID: <4EB00369.3020908@ericsson.com> Date: Tue, 1 Nov 2011 15:34:17 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Bernard Aboba References: <3FACD0E9-449A-4897-8997-F76B5A41A34E@acmepacket.com>, <4EAA7B02.4010400@ericsson.com>, <2308DE02-0E63-4CCF-8889-F2E79204C7AF@acmepacket.com> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Security issue: consent refresh X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 14:34:21 -0000 On 2011-10-31 14:22, Bernard Aboba wrote: >> If there is a MitM physically on the path between the Browser and the > peer, such a MitM can keep the RTP flowing even if we used RTCP, >>because it could fake RTCP. (and such a MitM can keep TCP and SCTP > going too, fwiw) > > > [BA] Agree with Hadriel that forcing an IWF to "manufacture" RTCP is a > bad idea, and that the focus should be on an off-path attacker. > > Also agree that we need "continuing consent" and can't rely on a "source > quench" approach which has proven unworkable in other > contexts. There are situations where a receiver might have "gone away" > for one reason or another, or where the receiver is being > overwhelmed, where it might not have the ability or context to tell the > sender to stop. For example, if key state has been lost, > putting out a secured "Bye" may not be possible. > If we uses ICE initially then the implementation support for ICE connectivity checks must exist in the interworking gateway. So I agree that is likely the simplest, even if that code is going to be continuously executed instead of only at startup for each session. However, we still have a pretty big issue to figure out when it comes to legacy devices and that is congestion/rate control. We are going to need it, and I really wonder if we can make exceptions to this at all. And if the legacy device don't implement even basic RTCP then this is a real issue. We added some text in the new version of WebRTC's usage of RTP document. https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ 8.3. Legacy Interop Limitations Congestion control interoperability with most type of legacy devices, even using an translator could be difficult. There are numerous reasons for this: No RTCP Support: There exist legacy implementations that does not even implement RTCP at all. Thus no feedback at all is provided. RTP/AVP Minimal RTCP Interval of 5s: RTP [RFC3550] under the RTP/AVP profile specifies a recommended minimal fixed interval of 5 seconds. Sending RTCP report blocks as seldom as 5 seconds makes it very difficult for a sender to use these reports and react to any congestion event. RTP/AVP Scaled Minimal Interval: If a legacy device uses the scaled minimal RTCP compound interval, the "RECOMMENDED value for the reduced minimum in seconds is 360 divided by the session bandwidth in kilobits/second" ([RFC3550], section 6.2). The minimal interval drops below a second, still several times the RTT in almost all paths in the Internet, when the session bandwidht becomes 360 kbps. A session bandwidth of 1 Mbps still has a minimal interval of 360 ms. Thus, with the exception for rather high bandwidth sessions, getting frequent enough RTCP Report Blocks to report on the order of the RTT is very difficult as long as the legacy device uses the RTP/AVP profile. RTP/AVPF Supporting Legacy Device: If a legacy device supports RTP/ AVPF, then that enables negotation of important parameters for frequent reporting, such as the "trr-int" parameter, and the possibility that the end-point supports some useful feedback format for congestion control purpose such as TMMBR [RFC5104]. It has been suggested on the RTCWEB mailing list that if interoperating with really limited legacy devices an WebRTC end-point may not send more than 64 kbps of media streams, to avoid it causing massive congestion on most paths in the Internet when communicating with a legacy node not providing sufficient feedback for effective congestion control. This warrants further discussion as there is clearly a number of link layers that don't even provide that amount of bit-rate consistently, and that assumes no competing traffic. We need to discuss if there is a reasonable way to resolve this or if this puts as strict or even stricter requirements then to support ICE. 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 Michael.Tuexen@lurchi.franken.de Tue Nov 1 08:19:51 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD1021F8FBB for ; Tue, 1 Nov 2011 08:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tdu1IjlJSPFW for ; Tue, 1 Nov 2011 08:19:50 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 27CCB21F8F2A for ; Tue, 1 Nov 2011 08:19:49 -0700 (PDT) Received: from [192.168.1.200] (p508FC512.dip.t-dialin.net [80.143.197.18]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3A0111C0B461B; Tue, 1 Nov 2011 16:19:30 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <4EAFFDD1.4000909@ericsson.com> Date: Tue, 1 Nov 2011 16:19:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@acmepacket.com> <8624F864-AB28-4CE7-AB8D-8A55B08AD745@lurchi.franken.de> <4EAFFDD1.4000909@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" , Randall Stewart Subject: Re: [rtcweb] Layers in draft-jesup-rtcweb-data-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 15:19:51 -0000 On Nov 1, 2011, at 3:10 PM, Magnus Westerlund wrote: > On 2011-10-26 22:45, Michael T=FCxen wrote: >>=20 >> On Oct 26, 2011, at 10:28 PM, Hadriel Kaplan wrote: >=20 >>> But rather this: >>>=20 >>> +------+ +------+ >>> |WEBAPP| |WEBAPP| >>> +------+------+------+ +------+------+------+ >>> | DTLS | Audio| Video| | SCTP | Audio| Video| >>> +---------------------------+ +---------------------------+ >>> | STUN | SCTP |S/RTP |S/RTP | | STUN | DTLS |S/RTP |S/RTP | >>> +---------------------------+ +---------------------------+ >>> | Mux/Demux | | Mux/Demux | >>> +---------------------------+ +---------------------------+ >>> | UDP | | UDP | >>> +---------------------------+ +---------------------------+ >>>=20 >>> [Note: "S/RTP" =3D SRTP/SRTCP or RTP/RTCP, "Mux/Demux" =3D tiny = logic to mux/demux] >>>=20 >>> Because the audio/video streams may be using the same UDP port, = right? >>>=20 >>> And the two "S/RTP" boxes may be just one box depending on how the = MMUSIC multiplexing decision turns out. >>>=20 >>> So if we want to choose the left one, because we expect/want that = someday the Operating System provides a SCTP/UDP stack in the kernel, = and I think we do, could it do so while demuxing and letting STUN, RTP, = and DTLS go up to the app layer? (i.e., given a socket/BIO/FD model) I = have no idea about such things... just asking. >> This is not possible today. The demultiplexing seems to be specific = to this scenario. >> Not sure it fits. For demuxing you use the first byte to distinguish = STUN from DTLS and SRTP. >> The first byte us the high order byte of the source port. Once could = require >> SCTP to use source ports with the high order byte > 192. That might = work. >> However, you would need to get the Mux/Demux into the kernel. Could = be done >> using a socket option. But I'm not sure it really fits. Maybe Randy = has an >> opinion. >>=20 >=20 > Michael, >=20 > I think one of the reasons there is discussion of use land > implementations of SCTP is so that you can do the above stack diagrams > with SCTP above UDP that is being shared for several purposes. >=20 > I would also like to correct Hadriel's picture slightly: >=20 >>> +------+ +------+ >>> |WEBAPP| |WEBAPP| >>> +------+------+------+ +------+------+------+ >>> | DTLS |Audio & Video| | SCTP |Audio & Video| >>> +---------------------------+ +---------------------------+ >>> | STUN | SCTP | DTLS-SRTP | | STUN | DTLS | DTLS-SRTP | >>> +---------------------------+ +---------------------------+ >>> | Mux/Demux | | Mux/Demux | >>> +---------------------------+ +---------------------------+ >>> | UDP | | UDP | >>> +---------------------------+ +---------------------------+ >=20 > I think the above indicating that the common RTP session, potentially > being a DTLS-SRTP keyed RTP session that can co-exist on the same UDP = flow. >=20 > To make the left one work, I think one has to have a source port where > the first byte value is 192-255 as the de-multiplexing table from > section 5.1.2 of RFC 5764 shows these to be the only available. >=20 > Thus I think the options are: >=20 > A. Left figure above. (source port must be in 49152-65535) >=20 > B. Right figure above >=20 > C. SCTP in its own UDP flow plus one UDP flow for each RTP session. >=20 > If we would pick SCTP then I think we must have either A+C or B+C = working. And you want one DTLS connection for key derivation of SRTP and a separate one for SCTP? Or must they be the same? Best regards Michael >=20 > cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 From wolfgang.beck01@googlemail.com Tue Nov 1 09:02:21 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722F211E80BE for ; Tue, 1 Nov 2011 09:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.795 X-Spam-Level: X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[AWL=-0.118, 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 GtB-jJWP0CRS for ; Tue, 1 Nov 2011 09:02:21 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB1F111E80B3 for ; Tue, 1 Nov 2011 09:02:20 -0700 (PDT) Received: by qadc10 with SMTP id c10so7551398qad.31 for ; Tue, 01 Nov 2011 09:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jeC4wzNrRAsfmrnMnec75E2M3rm9fu66tAIgxiLKELs=; b=LLfBk2EhlY+xcFe4CxoDX+YyCKc3azHxD3aLf3/CJmGqCHNeOkJgC2kxBfcOUf07Vp RgUuyCFU/eA2ngRtkQjDP7hIsdYTabGsrIFaKRnbiGdV0SPOaVlihuWsRiSTzjF8G3b4 NEj1BENdwnbV9QhZgVXxy8sRtP8pIpqyRqYfs= MIME-Version: 1.0 Received: by 10.68.38.169 with SMTP id h9mr892850pbk.113.1320163340166; Tue, 01 Nov 2011 09:02:20 -0700 (PDT) Received: by 10.68.64.66 with HTTP; Tue, 1 Nov 2011 09:02:20 -0700 (PDT) In-Reply-To: References: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com> Date: Tue, 1 Nov 2011 17:02:20 +0100 Message-ID: From: Wolfgang Beck 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] Usecases for innovation. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 16:02:21 -0000 On Tue, Nov 1, 2011 at 3:18 PM, I=F1aki Baz Castillo wrote: > 2011/11/1 Tim Panton : >> I've repeatedly been asked for use-cases for innovative applications of = webRTC >> to justify my contention that we should be providing a low-level framewo= rk, >> not an embedded legacy compatibility application. [..] > Indeed most of the discussions in this WG are about how to make > ***current*** SIP devices to work with a WebRTC scenario. It's a > limited vision of WebRTC in which the main interest is to make profit > of this new spec within telcos business. Bad IMHO. But, where are > those "innovative" and "crazy" Web folks right now? why 95% of people > discussing in this ***open*** WG are telcos? So this is also their > fault, the fault of people not participating here and now. Well, I'm working for a telco. Hadriel' employer sells equipment to telcos and telephony providers. Still our proposals to avoid standardized signaling and to depart from classical telco signaling flows were not well received by the crazy web folks. The world has turned upside down.. Wolfgang Beck From igor.faynberg@alcatel-lucent.com Tue Nov 1 09:37:25 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86461F0C44 for ; Tue, 1 Nov 2011 09:37:25 -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 Sq67L3U17PtY for ; Tue, 1 Nov 2011 09:37:25 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 88DA711E80BE for ; Tue, 1 Nov 2011 09:37:20 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id pA1GbJXP018616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 1 Nov 2011 11:37:19 -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 pA1GbJLP006551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 1 Nov 2011 11:37:19 -0500 Received: from [135.244.41.165] (faynberg.lra.lucent.com [135.244.41.165]) by umail.lucent.com (8.13.8/TPES) with ESMTP id pA1GbIgB013824; Tue, 1 Nov 2011 11:37:18 -0500 (CDT) Message-ID: <4EB0203E.3060108@alcatel-lucent.com> Date: Tue, 01 Nov 2011 12:37:18 -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: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [rtcweb] Usecases for innovation. 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, 01 Nov 2011 16:37:25 -0000 ;) On 11/1/2011 12:02 PM, Wolfgang Beck wrote: > On Tue, Nov 1, 2011 at 3:18 PM, Iñaki Baz Castillo wrote: >> 2011/11/1 Tim Panton: >>> I've repeatedly been asked for use-cases for innovative applications of webRTC >>> to justify my contention that we should be providing a low-level framework, >>> not an embedded legacy compatibility application. > [..] >> Indeed most of the discussions in this WG are about how to make >> ***current*** SIP devices to work with a WebRTC scenario. It's a >> limited vision of WebRTC in which the main interest is to make profit >> of this new spec within telcos business. Bad IMHO. But, where are >> those "innovative" and "crazy" Web folks right now? why 95% of people >> discussing in this ***open*** WG are telcos? So this is also their >> fault, the fault of people not participating here and now. > Well, I'm working for a telco. Hadriel' employer sells equipment to > telcos and telephony providers. > Still our proposals to avoid standardized signaling and to depart from > classical telco signaling flows were not well > received by the crazy web folks. The world has turned upside down.. > > > Wolfgang Beck > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Tue Nov 1 10:27:41 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60EF11E80E1 for ; Tue, 1 Nov 2011 10:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, 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 5RGAs5fhXqRf for ; Tue, 1 Nov 2011 10:27: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 228BA11E80DE for ; Tue, 1 Nov 2011 10:27:41 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so5332vcb.31 for ; Tue, 01 Nov 2011 10:27:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.178.13 with SMTP id bk13mr43726vcb.23.1320168421557; Tue, 01 Nov 2011 10:27:01 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Tue, 1 Nov 2011 10:27:01 -0700 (PDT) In-Reply-To: References: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com> Date: Tue, 1 Nov 2011 18:27:01 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Wolfgang Beck Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Usecases for innovation. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 17:27:41 -0000 2011/11/1 Wolfgang Beck : > Still our proposals to avoid standardized signaling and to depart from > classical telco signaling flows were not well > received by the crazy web folks. Is this really true? If so, they don't know what they want. --=20 I=C3=B1aki Baz Castillo From randell-ietf@jesup.org Tue Nov 1 10:56:10 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCB71F0C75 for ; Tue, 1 Nov 2011 10:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 ZTta8TbZqgvk for ; Tue, 1 Nov 2011 10:56:10 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id EF5071F0C3B for ; Tue, 1 Nov 2011 10:56:09 -0700 (PDT) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RLIVx-0007q7-2n for rtcweb@ietf.org; Tue, 01 Nov 2011 12:52:45 -0500 Message-ID: <4EB031DC.5000909@jesup.org> Date: Tue, 01 Nov 2011 13:52:28 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <3FACD0E9-449A-4897-8997-F76B5A41A34E@acmepacket.com>, <4EAA7B02.4010400@ericsson.com>, <2308DE02-0E63-4CCF-8889-F2E79204C7AF@acmepacket.com> <4EB00369.3020908@ericsson.com> In-Reply-To: <4EB00369.3020908@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] Security issue: consent refresh X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 17:56:10 -0000 On 11/1/2011 10:34 AM, Magnus Westerlund wrote: > However, we still have a pretty big issue to figure out when it comes to > legacy devices and that is congestion/rate control. We are going to need > it, and I really wonder if we can make exceptions to this at all. And if > the legacy device don't implement even basic RTCP then this is a real > issue. > > We added some text in the new version of WebRTC's usage of RTP document. > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ > > 8.3. Legacy Interop Limitations > > Congestion control interoperability with most type of legacy devices, > even using an translator could be difficult. There are numerous > reasons for this: > > No RTCP Support: There exist legacy implementations that does not > even implement RTCP at all. Thus no feedback at all is provided. Typically these devices aren't using codecs that can be throttled, so lack of congestion control doesn't really matter here. (G.711, G.729, etc). In theory you could switch codecs to a supported-but-lower-bandwidth codec, of course, but there would be no way to tell them to switch. Effectively you're talking to a non-CC device; it will work or it won't. I've never seen a 2-way video endpoint that didn't support RTCP in some way (though some are broken in odd ways) - they might exist, but I haven't seen one. > RTP/AVP Minimal RTCP Interval of 5s: RTP [RFC3550] under the RTP/AVP > profile specifies a recommended minimal fixed interval of 5 > seconds. Sending RTCP report blocks as seldom as 5 seconds makes > it very difficult for a sender to use these reports and react to > any congestion event. Congestion control based on AVP RTCP reports is possible, but with a very slow convergence time and unclear fairness results. It does "work" in practice if not over-stressed. I used such algorithms in the past for interop with "standard" videophones and endpoints (while operating my device in AVPF mode). Such algorithms are likely significantly unfair in practice, though they may be fair "on average". Congestion control here is more useful as a way to provide adaptation to link bandwidth for a single application than to provide sharing of a link. > RTP/AVP Scaled Minimal Interval: If a legacy device uses the scaled > minimal RTCP compound interval, the "RECOMMENDED value for the > reduced minimum in seconds is 360 divided by the session bandwidth > in kilobits/second" ([RFC3550], section 6.2). The minimal > interval drops below a second, still several times the RTT in > almost all paths in the Internet, when the session bandwidht > becomes 360 kbps. A session bandwidth of 1 Mbps still has a > minimal interval of 360 ms. Thus, with the exception for rather > high bandwidth sessions, getting frequent enough RTCP Report > Blocks to report on the order of the RTT is very difficult as long > as the legacy device uses the RTP/AVP profile. This is in most cases much better than AVP timings, though not good. "Typical" usages might yield 300-1500ms RTCP intervals (much better than 5000ms avg.) > RTP/AVPF Supporting Legacy Device: If a legacy device supports RTP/ > AVPF, then that enables negotation of important parameters for > frequent reporting, such as the "trr-int" parameter, and the > possibility that the end-point supports some useful feedback > format for congestion control purpose such as TMMBR [RFC5104]. Even without TMMBR, a RR-based CC algorithm with a fairly fast reporting interval should be able to provide some level of fairness and quick response (though far worse delay control). > It has been suggested on the RTCWEB mailing list that if > interoperating with really limited legacy devices an WebRTC end-point > may not send more than 64 kbps of media streams, to avoid it causing > massive congestion on most paths in the Internet when communicating > with a legacy node not providing sufficient feedback for effective > congestion control. This warrants further discussion as there is > clearly a number of link layers that don't even provide that amount > of bit-rate consistently, and that assumes no competing traffic. > > We need to discuss if there is a reasonable way to resolve this or if > this puts as strict or even stricter requirements then to support ICE. -- Randell Jesup randell-ietf@jesup.org From juberti@google.com Tue Nov 1 12:39:21 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74641F0CC3 for ; Tue, 1 Nov 2011 12:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 dzVR1EYwmx0p for ; Tue, 1 Nov 2011 12:39:20 -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 9FB9C1F0C36 for ; Tue, 1 Nov 2011 12:39:20 -0700 (PDT) Received: by ywt2 with SMTP id 2so8798939ywt.31 for ; Tue, 01 Nov 2011 12:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=FXOd1+RYlRwcQUGZr7OiT+10Aau5aL996gkJYKEjPe8=; b=JHLvXzDyXbveaBCJl7+VM3dOyfHwy+AGm7GEsN9TB7vQ51JHWe1PccY+zFuaf+Kh5O 4cdzB5d8Vtfg36Sw4Wag== Received: by 10.50.36.168 with SMTP id r8mr635136igj.49.1320176248382; Tue, 01 Nov 2011 12:37:28 -0700 (PDT) Received: by 10.50.36.168 with SMTP id r8mr635096igj.49.1320176246877; Tue, 01 Nov 2011 12:37:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.34.4 with HTTP; Tue, 1 Nov 2011 12:37:05 -0700 (PDT) In-Reply-To: References: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@acmepacket.com> <8624F864-AB28-4CE7-AB8D-8A55B08AD745@lurchi.franken.de> <4EAFFDD1.4000909@ericsson.com> From: Justin Uberti Date: Tue, 1 Nov 2011 15:37:05 -0400 Message-ID: To: =?UTF-8?Q?Michael_T=C3=BCxen?= Content-Type: multipart/alternative; boundary=14dae9340a253c6cd204b0b17c6f X-System-Of-Record: true Cc: "rtcweb@ietf.org" , Randall Stewart Subject: Re: [rtcweb] Layers in draft-jesup-rtcweb-data-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 19:39:21 -0000 --14dae9340a253c6cd204b0b17c6f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think we want one DTLS session for each transport. If we have independent RTP sessions, we have N transports, and N DTLS sessions. If we multiplex RTP/SCTP sessions, we have a single transport, and the same DTLS session is used to protect SCTP traffic, as well as to get keys for SRTP traffic. On Tue, Nov 1, 2011 at 11:19 AM, Michael T=C3=BCxen < Michael.Tuexen@lurchi.franken.de> wrote: > On Nov 1, 2011, at 3:10 PM, Magnus Westerlund wrote: > > > On 2011-10-26 22:45, Michael T=C3=BCxen wrote: > >> > >> On Oct 26, 2011, at 10:28 PM, Hadriel Kaplan wrote: > > > >>> But rather this: > >>> > >>> +------+ +------+ > >>> |WEBAPP| |WEBAPP| > >>> +------+------+------+ +------+------+------+ > >>> | DTLS | Audio| Video| | SCTP | Audio| Video| > >>> +---------------------------+ +---------------------------+ > >>> | STUN | SCTP |S/RTP |S/RTP | | STUN | DTLS |S/RTP |S/RTP | > >>> +---------------------------+ +---------------------------+ > >>> | Mux/Demux | | Mux/Demux | > >>> +---------------------------+ +---------------------------+ > >>> | UDP | | UDP | > >>> +---------------------------+ +---------------------------+ > >>> > >>> [Note: "S/RTP" =3D SRTP/SRTCP or RTP/RTCP, "Mux/Demux" =3D tiny logic= to > mux/demux] > >>> > >>> Because the audio/video streams may be using the same UDP port, right= ? > >>> > >>> And the two "S/RTP" boxes may be just one box depending on how the > MMUSIC multiplexing decision turns out. > >>> > >>> So if we want to choose the left one, because we expect/want that > someday the Operating System provides a SCTP/UDP stack in the kernel, and= I > think we do, could it do so while demuxing and letting STUN, RTP, and DTL= S > go up to the app layer? (i.e., given a socket/BIO/FD model) I have no > idea about such things... just asking. > >> This is not possible today. The demultiplexing seems to be specific to > this scenario. > >> Not sure it fits. For demuxing you use the first byte to distinguish > STUN from DTLS and SRTP. > >> The first byte us the high order byte of the source port. Once could > require > >> SCTP to use source ports with the high order byte > 192. That might > work. > >> However, you would need to get the Mux/Demux into the kernel. Could be > done > >> using a socket option. But I'm not sure it really fits. Maybe Randy ha= s > an > >> opinion. > >> > > > > Michael, > > > > I think one of the reasons there is discussion of use land > > implementations of SCTP is so that you can do the above stack diagrams > > with SCTP above UDP that is being shared for several purposes. > > > > I would also like to correct Hadriel's picture slightly: > > > >>> +------+ +------+ > >>> |WEBAPP| |WEBAPP| > >>> +------+------+------+ +------+------+------+ > >>> | DTLS |Audio & Video| | SCTP |Audio & Video| > >>> +---------------------------+ +---------------------------+ > >>> | STUN | SCTP | DTLS-SRTP | | STUN | DTLS | DTLS-SRTP | > >>> +---------------------------+ +---------------------------+ > >>> | Mux/Demux | | Mux/Demux | > >>> +---------------------------+ +---------------------------+ > >>> | UDP | | UDP | > >>> +---------------------------+ +---------------------------+ > > > > I think the above indicating that the common RTP session, potentially > > being a DTLS-SRTP keyed RTP session that can co-exist on the same UDP > flow. > > > > To make the left one work, I think one has to have a source port where > > the first byte value is 192-255 as the de-multiplexing table from > > section 5.1.2 of RFC 5764 shows these to be the only available. > > > > Thus I think the options are: > > > > A. Left figure above. (source port must be in 49152-65535) > > > > B. Right figure above > > > > C. SCTP in its own UDP flow plus one UDP flow for each RTP session. > > > > If we would pick SCTP then I think we must have either A+C or B+C > working. > And you want one DTLS connection for key derivation of SRTP and a > separate one for SCTP? Or must they be the same? > > Best regards > Michael > > > > cheers > > > > Magnus Westerlund > > > > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --14dae9340a253c6cd204b0b17c6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think we want one DTLS session for each transport. If we have independent= RTP sessions, we have N transports, and N DTLS sessions. If we multiplex R= TP/SCTP sessions, we have a single transport, and the same DTLS session is = used to protect SCTP traffic, as well as to get keys for SRTP traffic.

On Tue, Nov 1, 2011 at 11:19 AM, Michael T= =C3=BCxen <Michael.Tuexen@lurchi.franken.de> wrote:
On Nov 1, 2011, at 3:10 PM, Magnus = Westerlund wrote:

> On 2011-10-26 22:45, Michael T=C3=BCxen wrote:
>>
>> On Oct 26, 2011, at 10:28 PM, Hadriel Kaplan wrote:
>
>>> But rather this:
>>>
>>> =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 |WEBAPP| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|WEBAPP|
>>> =C2=A0 =C2=A0 =C2=A0 +------+------+------+ =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+------+------+------+
>>> =C2=A0 =C2=A0 =C2=A0 | DTLS | Audio| Video| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| SCTP | Audio| Video|
>>> +---------------------------+ =C2=A0 +------------------------= ---+
>>> | STUN | SCTP |S/RTP |S/RTP | =C2=A0 | STUN | DTLS |S/RTP |S/R= TP |
>>> +---------------------------+ =C2=A0 +------------------------= ---+
>>> | =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mux/Demux =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mux/Demux =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
>>> +---------------------------+ =C2=A0 +------------------------= ---+
>>> | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0UDP =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=A0UDP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>> +---------------------------+ =C2=A0 +------------------------= ---+
>>>
>>> [Note: "S/RTP" =3D SRTP/SRTCP or RTP/RTCP, "Mux= /Demux" =3D tiny logic to mux/demux]
>>>
>>> Because the audio/video streams may be using the same UDP port= , right?
>>>
>>> And the two "S/RTP" boxes may be just one box depend= ing on how the MMUSIC multiplexing decision turns out.
>>>
>>> So if we want to choose the left one, because we expect/want t= hat someday the Operating System provides a SCTP/UDP stack in the kernel, a= nd I think we do, could it do so while demuxing and letting STUN, RTP, and = DTLS go up to the app layer? =C2=A0(i.e., given a socket/BIO/FD model) =C2= =A0I have no idea about such things... just asking.
>> This is not possible today. The demultiplexing seems to be specifi= c to this scenario.
>> Not sure it fits. For demuxing you use the first byte to distingui= sh STUN from DTLS and SRTP.
>> The first byte us the high order byte of the source port. Once cou= ld require
>> SCTP to use source ports with the high order byte > 192. That m= ight work.
>> However, you would need to get the Mux/Demux into the kernel. Coul= d be done
>> using a socket option. But I'm not sure it really fits. Maybe = Randy has an
>> opinion.
>>
>
> Michael,
>
> I think one of the reasons there is discussion of use land
> implementations of SCTP is so that you can do the above stack diagrams=
> with SCTP above UDP that is being shared for several purposes.
>
> I would also like to correct Hadriel's picture slightly:
>
>>> =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 |WEBAPP| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|WEBAPP|
>>> =C2=A0 =C2=A0 =C2=A0 +------+------+------+ =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+------+------+------+
>>> =C2=A0 =C2=A0 =C2=A0 | DTLS |Audio & Video| =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| SCTP |Audio & Video|
>>> +---------------------------+ =C2=A0 +------------------------= ---+
>>> | STUN | SCTP | DTLS-SRTP =C2=A0 | =C2=A0 | STUN | DTLS | DTLS= -SRTP =C2=A0 |
>>> +---------------------------+ =C2=A0 +------------------------= ---+
>>> | =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mux/Demux =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mux/Demux =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
>>> +---------------------------+ =C2=A0 +------------------------= ---+
>>> | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0UDP =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=A0UDP =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>> +---------------------------+ =C2=A0 +------------------------= ---+
>
> I think the above indicating that the common RTP session, potentially<= br> > being a DTLS-SRTP keyed RTP session that can co-exist on the same UDP = flow.
>
> To make the left one work, I think one has to have a source port where=
> the first byte value is 192-255 as the de-multiplexing table from
> section 5.1.2 of RFC 5764 shows these to be the only available.
>
> Thus I think the options are:
>
> A. Left figure above. (source port must be in 49152-65535)
>
> B. Right figure above
>
> C. SCTP in its own UDP flow plus one UDP flow for each RTP session. >
> If we would pick SCTP then I think we must have either A+C or B+C work= ing.
And you want one DTLS connection for key derivation of SRTP and= a
separate one for SCTP? Or must they be the same?

Best regards
Michael
>
> cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------=
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------=
> Ericsson AB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| P= hone =C2=A0+46 = 10 7148287
> F=C3=A4r=C3=B6gatan 6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0| Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------=
>
>

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

--14dae9340a253c6cd204b0b17c6f-- From randell-ietf@jesup.org Tue Nov 1 13:35:49 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BDC11E81CA for ; Tue, 1 Nov 2011 13:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 PM1ZDh5RWxhR for ; Tue, 1 Nov 2011 13:35:49 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 14BE811E8091 for ; Tue, 1 Nov 2011 13:35:48 -0700 (PDT) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RLK19-0001ny-QV for rtcweb@ietf.org; Tue, 01 Nov 2011 14:29:03 -0500 Message-ID: <4EB0486E.2040001@jesup.org> Date: Tue, 01 Nov 2011 15:28:46 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <4EAC24A2.70401@alvestrand.no> <4EADBAD3.5020804@mozilla.com> In-Reply-To: <4EADBAD3.5020804@mozilla.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] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 20:35:49 -0000 On 10/30/2011 5:00 PM, Timothy B. Terriberry wrote: >> If we support SDES, the offer also contains crypto keys. Reusing crypto >> keys for all created connections would be a huge security vulnerability. > > I'm starting to come to the opinion that we shouldn't support SDES. If > we're doing it just for interop with legacy, we'd get better interop > with fewer headaches by supporting plain RTP. We'd have a distinction > between the two that I could actually explain to users, and less chance > of (unnoticed) downgrade attacks. SDES causes all sorts of privacy and security risks, so long as we retain the threat model of not trusting the JS or server, so unless we either a) relax the threat model, or b) allow SDES only in place of no encryption for non-rtcweb/webrtc destinations - i.e. never between rtcweb clients. The downside would be a downgrade attack where the JS routes the call through a relay-and-copy server that acts as a legacy gateway. My position is no SDES unless someone convinces me there's a need for it and it doesn't add important security risks/holes. While SDES is the "most" common keying method currently (and least secure in most cases!), there are more keying mechanisms for SRTP than I can count/remember. -- Randell Jesup randell-ietf@jesup.org From petithug@acm.org Tue Nov 1 13:50:45 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9314A11E81EE; Tue, 1 Nov 2011 13:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-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 N5Xb9RXNGt8X; Tue, 1 Nov 2011 13:50:45 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 75B2911E80B0; Tue, 1 Nov 2011 13:50:34 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 95516204AD; Tue, 1 Nov 2011 20:41:39 +0000 (UTC) Message-ID: <4EB05B90.10808@acm.org> Date: Tue, 01 Nov 2011 13:50:24 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Harald Alvestrand References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> In-Reply-To: <4EB05A23.3060101@alvestrand.no> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Ned Freed , Keith Moore , "rtcweb@ietf.org" , Keith Moore , Behave WG Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 20:50:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/01/2011 01:44 PM, Harald Alvestrand wrote: > Top-posting a general principle, detailed comment at the bottom.... > > For all URI schemes, I think the URI needs to contain all the information you > need in order to make contact with the service; you can't negotiate until you've > made contact. > (the process may involve things like "resolve through a resolution mechanism > like DNS" or "get authorization tokens from somewhere else"). > > In the case of TURN, you need to distinguish between TCP, UDP and TLS, and you > need to make that determination before you send the first packet. That means the > distinguishing information between those three things belongs in the URL; I > don't think the scheme is a good place to encode it. > > On 10/31/2011 11:37 PM, "Martin J. Dürst" wrote: >> >> >> On 2011/11/01 0:33, Keith Moore wrote: >>> >>> On Oct 31, 2011, at 10:57 AM, Marc Petit-Huguenin wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Hi Martin, >>>> >>>> So I understand Roy's email as saying in fact the opposite of what Harald said, >>>> i.e. that using an "s" suffix to signify security is a good thing. >>>> >>>> What is your opinion on defining a generic scheme suffix (i.e. "+s" or "+sec") >>>> that would indicate a well defined set of security properties that could apply >>>> to any scheme, (vs the current "s" suffix where security properties has to be >>>> defined scheme by scheme)? >>> >>> >>> There is no "well defined set of security properties that could apply to any >>> scheme". Security properties necessarily vary depending on the way a >>> resource is used, the threat model, and so forth. >> >> Here I agree with Keith. >> >>> Also, the idea that there should be a "secure" bit in a URI scheme, to >>> distinguish it from the "insecure" form of a URL, doesn't make much sense. >>> You always want to use the best security that's available. >> >> You always want the best security you're willing to pay for. >> >>> You don't want that to depend on the URI scheme. >> >> Ideally not, but in actual operation, it made a lot of sense for HTTP as Roy >> has explained. > I think it made a lot of sense because the port 443 convention meant that you > had to know whether or not to use SSL had to be known before you sent the SYN > packet. > Well, same thing for TURN, as a different default port is used when TLS is used (3478 for TURN over UDP and TCP, and 5349 for TURN over TLS). - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk6wW48ACgkQ9RoMZyVa61fPKQCfTLUElFx97Pz8XwQHwkJmJNCh kiEAn3Ew6/LOxc816VpuMWk5hFfKzi5y =c0vN -----END PGP SIGNATURE----- From harald@alvestrand.no Tue Nov 1 13:54:39 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E98821F8DF6; Tue, 1 Nov 2011 13:54:39 -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 thr-M0AunLLZ; Tue, 1 Nov 2011 13:54:39 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F2C3221F8DA4; Tue, 1 Nov 2011 13:54:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1270D39E13B; Tue, 1 Nov 2011 21:44:21 +0100 (CET) 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 q8SW1uNsqm46; Tue, 1 Nov 2011 21:44:20 +0100 (CET) Received: from [172.20.78.134] (63-145-238-4.dia.static.qwest.net [63.145.238.4]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 982C039E04C; Tue, 1 Nov 2011 21:44:18 +0100 (CET) Message-ID: <4EB05A23.3060101@alvestrand.no> Date: Tue, 01 Nov 2011 13:44:19 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> In-Reply-To: <4EAF9391.5040209@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Ned Freed , Keith Moore , Keith Moore , Behave WG , "rtcweb@ietf.org" Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 20:54:39 -0000 Top-posting a general principle, detailed comment at the bottom.... For all URI schemes, I think the URI needs to contain all the information you need in order to make contact with the service; you can't negotiate until you've made contact. (the process may involve things like "resolve through a resolution mechanism like DNS" or "get authorization tokens from somewhere else"). In the case of TURN, you need to distinguish between TCP, UDP and TLS, and you need to make that determination before you send the first packet. That means the distinguishing information between those three things belongs in the URL; I don't think the scheme is a good place to encode it. On 10/31/2011 11:37 PM, "Martin J. Dürst" wrote: > > > On 2011/11/01 0:33, Keith Moore wrote: >> >> On Oct 31, 2011, at 10:57 AM, Marc Petit-Huguenin wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Hi Martin, >>> >>> So I understand Roy's email as saying in fact the opposite of what >>> Harald said, >>> i.e. that using an "s" suffix to signify security is a good thing. >>> >>> What is your opinion on defining a generic scheme suffix (i.e. "+s" >>> or "+sec") >>> that would indicate a well defined set of security properties that >>> could apply >>> to any scheme, (vs the current "s" suffix where security properties >>> has to be >>> defined scheme by scheme)? >> >> >> There is no "well defined set of security properties that could apply >> to any scheme". Security properties necessarily vary depending on >> the way a resource is used, the threat model, and so forth. > > Here I agree with Keith. > >> Also, the idea that there should be a "secure" bit in a URI scheme, >> to distinguish it from the "insecure" form of a URL, doesn't make >> much sense. You always want to use the best security that's available. > > You always want the best security you're willing to pay for. > >> You don't want that to depend on the URI scheme. > > Ideally not, but in actual operation, it made a lot of sense for HTTP > as Roy has explained. I think it made a lot of sense because the port 443 convention meant that you had to know whether or not to use SSL had to be known before you sent the SYN packet. From christer.holmberg@ericsson.com Wed Nov 2 03:52:51 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE4611E8149 for ; Wed, 2 Nov 2011 03:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.269 X-Spam-Level: X-Spam-Status: No, score=-6.269 tagged_above=-999 required=5 tests=[AWL=0.330, 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 YSgeWI2KY1kP for ; Wed, 2 Nov 2011 03:52:51 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC4E11E80D9 for ; Wed, 2 Nov 2011 03:52:50 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-73-4eb12102fcaa Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 07.D5.13753.20121BE4; Wed, 2 Nov 2011 11:52:50 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 2 Nov 2011 11:52:50 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Date: Wed, 2 Nov 2011 11:52:48 +0100 Thread-Topic: SDES and forking [was RE: RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]] Thread-Index: AcyXRuxXL0m+HvX7TS6DFejg12yLHQCBfwng Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522356F2F11@ESESSCMS0356.eemea.ericsson.se> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <4EAC24A2.70401@alvestrand.no> <4EADBAD3.5020804@mozilla.com> In-Reply-To: <4EADBAD3.5020804@mozilla.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] SDES and forking [was RE: RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 10:52:51 -0000 Hi,=20 > If we support SDES, the offer also contains crypto keys. Reusing=20 > crypto keys for all created connections would be a huge=20 > security vulnerability. If using the same keys for media assocaited with all early dialogs, one cou= ld, for each early dialog, send a new offer, with dialog-specific SDES keys= . Yes, it would require a new offer, which I have previously said I don't lik= e. But, in this case, if you don't have to change the local IP parameters/c= andidates etc, the new offer would not trigger a ICE re-start etc. Regards, Christer= From christer.holmberg@ericsson.com Wed Nov 2 03:54:27 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E17A21F9F41 for ; Wed, 2 Nov 2011 03:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 mOdmOZtA6JcA for ; Wed, 2 Nov 2011 03:54:26 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 67F8421F9F39 for ; Wed, 2 Nov 2011 03:54:26 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-cd-4eb12161b221 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6D.FE.20773.16121BE4; Wed, 2 Nov 2011 11:54:25 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 2 Nov 2011 11:54:25 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Date: Wed, 2 Nov 2011 11:54:23 +0100 Thread-Topic: SDES and forking [was RE: RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]] Thread-Index: AcyXRuxXL0m+HvX7TS6DFejg12yLHQCBfwngAAAyLnA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522356F2F14@ESESSCMS0356.eemea.ericsson.se> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com> <6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <4EAB2657.7090609@jesup.org> <4EAC24A2.70401@alvestrand.no> <4EADBAD3.5020804@mozilla.com> <7F2072F1E0DE894DA4B517B93C6A058522356F2F11@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522356F2F11@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] SDES and forking [was RE: RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 10:54:27 -0000 =20 If using the same keys for media assocaited with all early dialogs is a sec= urity vulnerability, that is. > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 2. marraskuuta 2011 12:53 > To: rtcweb@ietf.org > Subject: [rtcweb] SDES and forking [was RE: RTCWeb Forking=20 > usecase [was RE:=20 > draft-kaplan-rtcweb-sip-interworking-requirements-00]] >=20 >=20 > Hi,=20 >=20 > > If we support SDES, the offer also contains crypto keys. Reusing=20 > > crypto keys for all created connections would be a huge security=20 > > vulnerability. >=20 > If using the same keys for media assocaited with all early=20 > dialogs, one could, for each early dialog, send a new offer,=20 > with dialog-specific SDES keys. >=20 > Yes, it would require a new offer, which I have previously=20 > said I don't like. But, in this case, if you don't have to=20 > change the local IP parameters/candidates etc, the new offer=20 > would not trigger a ICE re-start etc. >=20 > Regards, >=20 > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From Michael.Tuexen@lurchi.franken.de Wed Nov 2 04:57:30 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67AE11E815C for ; Wed, 2 Nov 2011 04:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3L6QJv9ehTk for ; Wed, 2 Nov 2011 04:57:30 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id BAFDF11E816A for ; Wed, 2 Nov 2011 04:57:29 -0700 (PDT) Received: from [192.168.1.200] (p508FAFBE.dip.t-dialin.net [80.143.175.190]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9431D1C0C0BD9; Wed, 2 Nov 2011 12:57:28 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Wed, 2 Nov 2011 12:57:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@acmepacket.com> <8624F864-AB28-4CE7-AB8D-8A55B08AD745@lurchi.franken.de> <4EAFFDD1.4000909@ericsson.com> To: Justin Uberti X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" , Randall Stewart Subject: Re: [rtcweb] Layers in draft-jesup-rtcweb-data-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 11:57:31 -0000 On Nov 1, 2011, at 8:37 PM, Justin Uberti wrote: > I think we want one DTLS session for each transport. If we have = independent RTP sessions, we have N transports, and N DTLS sessions. If = we multiplex RTP/SCTP sessions, we have a single transport, and the same = DTLS session is used to protect SCTP traffic, as well as to get keys for = SRTP traffic. OK, thanks for the clarification. Best regards Michael >=20 > On Tue, Nov 1, 2011 at 11:19 AM, Michael T=FCxen = wrote: > On Nov 1, 2011, at 3:10 PM, Magnus Westerlund wrote: >=20 > > On 2011-10-26 22:45, Michael T=FCxen wrote: > >> > >> On Oct 26, 2011, at 10:28 PM, Hadriel Kaplan wrote: > > > >>> But rather this: > >>> > >>> +------+ +------+ > >>> |WEBAPP| |WEBAPP| > >>> +------+------+------+ +------+------+------+ > >>> | DTLS | Audio| Video| | SCTP | Audio| Video| > >>> +---------------------------+ +---------------------------+ > >>> | STUN | SCTP |S/RTP |S/RTP | | STUN | DTLS |S/RTP |S/RTP | > >>> +---------------------------+ +---------------------------+ > >>> | Mux/Demux | | Mux/Demux | > >>> +---------------------------+ +---------------------------+ > >>> | UDP | | UDP | > >>> +---------------------------+ +---------------------------+ > >>> > >>> [Note: "S/RTP" =3D SRTP/SRTCP or RTP/RTCP, "Mux/Demux" =3D tiny = logic to mux/demux] > >>> > >>> Because the audio/video streams may be using the same UDP port, = right? > >>> > >>> And the two "S/RTP" boxes may be just one box depending on how the = MMUSIC multiplexing decision turns out. > >>> > >>> So if we want to choose the left one, because we expect/want that = someday the Operating System provides a SCTP/UDP stack in the kernel, = and I think we do, could it do so while demuxing and letting STUN, RTP, = and DTLS go up to the app layer? (i.e., given a socket/BIO/FD model) I = have no idea about such things... just asking. > >> This is not possible today. The demultiplexing seems to be specific = to this scenario. > >> Not sure it fits. For demuxing you use the first byte to = distinguish STUN from DTLS and SRTP. > >> The first byte us the high order byte of the source port. Once = could require > >> SCTP to use source ports with the high order byte > 192. That might = work. > >> However, you would need to get the Mux/Demux into the kernel. Could = be done > >> using a socket option. But I'm not sure it really fits. Maybe Randy = has an > >> opinion. > >> > > > > Michael, > > > > I think one of the reasons there is discussion of use land > > implementations of SCTP is so that you can do the above stack = diagrams > > with SCTP above UDP that is being shared for several purposes. > > > > I would also like to correct Hadriel's picture slightly: > > > >>> +------+ +------+ > >>> |WEBAPP| |WEBAPP| > >>> +------+------+------+ +------+------+------+ > >>> | DTLS |Audio & Video| | SCTP |Audio & Video| > >>> +---------------------------+ +---------------------------+ > >>> | STUN | SCTP | DTLS-SRTP | | STUN | DTLS | DTLS-SRTP | > >>> +---------------------------+ +---------------------------+ > >>> | Mux/Demux | | Mux/Demux | > >>> +---------------------------+ +---------------------------+ > >>> | UDP | | UDP | > >>> +---------------------------+ +---------------------------+ > > > > I think the above indicating that the common RTP session, = potentially > > being a DTLS-SRTP keyed RTP session that can co-exist on the same = UDP flow. > > > > To make the left one work, I think one has to have a source port = where > > the first byte value is 192-255 as the de-multiplexing table from > > section 5.1.2 of RFC 5764 shows these to be the only available. > > > > Thus I think the options are: > > > > A. Left figure above. (source port must be in 49152-65535) > > > > B. Right figure above > > > > C. SCTP in its own UDP flow plus one UDP flow for each RTP session. > > > > If we would pick SCTP then I think we must have either A+C or B+C = working. > And you want one DTLS connection for key derivation of SRTP and a > separate one for SCTP? Or must they be the same? >=20 > Best regards > Michael > > > > 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 > > = ---------------------------------------------------------------------- > > > > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From magnus.westerlund@ericsson.com Wed Nov 2 05:44:18 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F261121F9EAC for ; Wed, 2 Nov 2011 05:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 kk3bJ0wkMswy for ; Wed, 2 Nov 2011 05:44:17 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 36D8021F9E7D for ; Wed, 2 Nov 2011 05:44:17 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-8d-4eb13b2091e7 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BB.C9.13753.02B31BE4; Wed, 2 Nov 2011 13:44:16 +0100 (CET) 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.137.0; Wed, 2 Nov 2011 13:44:16 +0100 Message-ID: <4EB13B1E.5070506@ericsson.com> Date: Wed, 2 Nov 2011 13:44:14 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Justin Uberti References: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@acmepacket.com> <8624F864-AB28-4CE7-AB8D-8A55B08AD745@lurchi.franken.de> <4EAFFDD1.4000909@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , Randall Stewart Subject: Re: [rtcweb] Layers in draft-jesup-rtcweb-data-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 12:44:18 -0000 On 2011-11-01 20:37, Justin Uberti wrote: > I think we want one DTLS session for each transport. If we have > independent RTP sessions, we have N transports, and N DTLS sessions. If > we multiplex RTP/SCTP sessions, we have a single transport, and the same > DTLS session is used to protect SCTP traffic, as well as to get keys for > SRTP traffic. Can you please expand on this argument? I think in the case where you have IP/UDP/DTLS-SRTP (where DTLS-SRTP represents both the DTLS handshakes used to establish the keys for SRTP and SRTP) and want to combine it with IP/UDP/DTLS/SCTP I think you are forced to have a single DTLS session for that UDP flow. However, what I do understand of DTLS it is possible to have both DTLS protected datagrams and DTLS-SRTP packets in the same DTLS session. However, as STUN in this case still is outside of the DTLS we anyway have a de-multiplexing. Based on that you from a feasibility point of view combined DTLS-SRTP with IP/UDP/SCTP/DTLS and have different DTLS sessions, one on the IP/UDP layer and another on the IP/UDP/SCTP layer. I also think we shouldn't forget what would occur if one has SRTP keyed in another way than DTLS as that can also proposed. Then the DTLS for SCTP doesn't interact with another DTLS at either IP/UDP or IP/UDP/SCTP. I would also like to raise the issue of DTLS resumption which to my knowledge is possible to use for any DTLS session between the same end-points after the first? 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 Wed Nov 2 06:29:01 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855491F0C52 for ; Wed, 2 Nov 2011 06:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 rFoM65K1KuEl for ; Wed, 2 Nov 2011 06:29:00 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3631F0C34 for ; Wed, 2 Nov 2011 06:29:00 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-4a-4eb1459b7ed1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 02.B1.13753.B9541BE4; Wed, 2 Nov 2011 14:28:59 +0100 (CET) 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.137.0; Wed, 2 Nov 2011 14:28:59 +0100 Message-ID: <4EB14599.5000509@ericsson.com> Date: Wed, 2 Nov 2011 14:28:57 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Summary of draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Nov 2011 13:29:01 -0000 WG, I have gone over the discussion in this thread and the "Does ROAP mandate the on-the-wire format?" thread. >From the postings in these threads I think my summary of this would be: There was strong agreement on the need for freedom in the used signaling protocol and its transport between the web-app and the servers and other web-app instances. This can be proprietary or a standardized protocol and is only up to the application what suits its needs. It is also not required to send ROAP messages end-to-end although that is intended to be possible. As a WG chair, I don't see any need to adopt draft-sipdoc-rtcweb-open-wire-protocol-00 as a WG document. I think the first agreements can most easily be documented in Overview document. Does the WG participants think it is necessary to include this in the use case and requirements document? The second piece I think the authors of the ROAP draft should take into consideration on their next update to clarify the purpose of the protocol and its relation to the API the application. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ibc@aliax.net Wed Nov 2 06:56:05 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F63821F8C0A for ; Wed, 2 Nov 2011 06:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, 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 HpiiKQ20C9B9 for ; Wed, 2 Nov 2011 06:56:05 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9EF721F8C1B for ; Wed, 2 Nov 2011 06:56:04 -0700 (PDT) Received: by vws5 with SMTP id 5so188948vws.31 for ; Wed, 02 Nov 2011 06:56:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.94.102 with SMTP id db6mr3029213vdb.118.1320242164199; Wed, 02 Nov 2011 06:56:04 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Wed, 2 Nov 2011 06:56:04 -0700 (PDT) In-Reply-To: <4EB14599.5000509@ericsson.com> References: <4EB14599.5000509@ericsson.com> Date: Wed, 2 Nov 2011 14:56:04 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Nov 2011 13:56:05 -0000 2011/11/2 Magnus Westerlund : > There was strong agreement on the need for freedom in the used signaling > protocol and its transport between the web-app and the servers and other > web-app instances. This can be proprietary or a standardized protocol > and is only up to the application what suits its needs. > > It is also not required to send ROAP messages end-to-end although that > is intended to be possible. > > As a WG chair, I don't see any need to adopt > draft-sipdoc-rtcweb-open-wire-protocol-00 as a WG document. I think the > first agreements can most easily be documented in Overview document. I agree. In fact the purpose of draft-sipdoc-rtcweb-open-wire-protocol-00 was not to become a WG document, but just to show different WebRTC use cases and how different the in-the-wire signaling should be in each scenario. We wrote the draft in order to clarify the need for freedom in the in-the-wire signaling protocol (since there were lot of discussions and threads about this subject). So if the Overview document could be more clear about the requirements in draft-sipdoc-rtcweb-open-wire-protocol-00 (those that you mention above) it's really fine for me. > Does the WG participants think it is necessary to include this in the > use case and requirements document? IMHO yes :) Thanks a lot. --=20 I=C3=B1aki Baz Castillo From ekr@rtfm.com Wed Nov 2 07:25:17 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37EF21F8BDB for ; Wed, 2 Nov 2011 07:25:17 -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 yMg66C3Y8ngr for ; Wed, 2 Nov 2011 07:25:17 -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 E9C9F21F8BB0 for ; Wed, 2 Nov 2011 07:25:16 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so220538vcb.31 for ; Wed, 02 Nov 2011 07:25:16 -0700 (PDT) Received: by 10.220.2.19 with SMTP id 19mr353535vch.161.1320243916393; Wed, 02 Nov 2011 07:25:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Wed, 2 Nov 2011 07:24:35 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4EB13B1E.5070506@ericsson.com> References: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@acmepacket.com> <8624F864-AB28-4CE7-AB8D-8A55B08AD745@lurchi.franken.de> <4EAFFDD1.4000909@ericsson.com> <4EB13B1E.5070506@ericsson.com> From: Eric Rescorla Date: Wed, 2 Nov 2011 07:24:35 -0700 Message-ID: To: Magnus Westerlund Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" , Randall Stewart Subject: Re: [rtcweb] Layers in draft-jesup-rtcweb-data-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 14:25:17 -0000 On Wed, Nov 2, 2011 at 5:44 AM, Magnus Westerlund wrote: > On 2011-11-01 20:37, Justin Uberti wrote: >> I think we want one DTLS session for each transport. If we have >> independent RTP sessions, we have N transports, and N DTLS sessions. If >> we multiplex RTP/SCTP sessions, we have a single transport, and the same >> DTLS session is used to protect SCTP traffic, as well as to get keys for >> SRTP traffic. > > Can you please expand on this argument? I think in the case where you > have IP/UDP/DTLS-SRTP (where DTLS-SRTP represents both the DTLS > handshakes used to establish the keys for SRTP and SRTP) and want to > combine it with IP/UDP/DTLS/SCTP I think you are forced to have a single > DTLS session for that UDP flow. I want to make sure I understand your question, you're talking about a call with both SCTP and SRTP carried over the same UDP host-port quartet? Yes, in that case, you would want to have a single DTLS association (session turns out to be a technical term in TLS that means something different than this) for that host-port quartet. > However, what I do understand of DTLS it > is possible to have both DTLS protected datagrams and DTLS-SRTP packets > in the same DTLS session. However, as STUN in this case still is outside > of the DTLS we anyway have a de-multiplexing. +------+ +------+ |WEBAPP| |WEBAPP| +------+------+------+ +------+------+------+ | DTLS | Audio| Video| | SCTP | Audio| Video| +---------------------------+ +---------------------------+ | STUN | SCTP |S/RTP |S/RTP | | STUN | DTLS |S/RTP |S/RTP | +---------------------------+ +---------------------------+ | Mux/Demux | | Mux/Demux | +---------------------------+ +---------------------------+ | UDP | | UDP | +---------------------------+ +---------------------------+ Assuming we're talking about the layering on the right, then there are two demux phases: 1. STUN vs. DTLS vs. SRTP, which is defined in RFC 5764; S 5.1.2 2. DTLS handshake versus SCTP data (carried as TLS application_data). This is just part of the DTLS stack. > Based on that you from a feasibility point of view combined DTLS-SRTP > with IP/UDP/SCTP/DTLS and have different DTLS sessions, one on the > IP/UDP layer and another on the IP/UDP/SCTP layer. I'm not sure how would be best to handle the case on the left (which is one reason I prefer the layering on the right). My instinct was to say that if you were going to do DTLS-SRTP you would still need to set up a IP/UDP/SCTP/DTLS channel, so you would have only one DTLS association. Of course, this still leaves you with the SCTP vs. S/RTP vs. STUN demux. > I also think we shouldn't forget what would occur if one has SRTP keyed > in another way than DTLS as that can also proposed. Then the DTLS for > SCTP doesn't interact with another DTLS at either IP/UDP or IP/UDP/SCTP. I'm not sure I get this point. > I would also like to raise the issue of DTLS resumption which to my > knowledge is possible to use for any DTLS session between the same > end-points after the first? Yes. There's some discussion of the most efficient way to handle this in Appendix B of RFC 5764. However, this should be invisible to the endpoints, as it's just a performance optimization. -Ekr From wolfgang.beck01@googlemail.com Wed Nov 2 07:33:53 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E5B11E80DA for ; Wed, 2 Nov 2011 07:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 ymTHbD0sksDb for ; Wed, 2 Nov 2011 07:33:52 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 785BD11E808A for ; Wed, 2 Nov 2011 07:33:52 -0700 (PDT) Received: by qadc10 with SMTP id c10so284910qad.31 for ; Wed, 02 Nov 2011 07:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=gb4wb8ZOJ8IGaJ5pKjLbZJ6dDIUGYHuh4FCESW8kkWI=; b=GNgw8Bq1VqQF7BCsVFJKjldSOWW/j7oU0JLLMUXsqncoCI1d68RigIQZ6xzU4LEexs OhZoScIlhTncGZDZaM411cM7/iYqwDJmsBU1+gexFRfQ7+c4mRfu+/hcVDNNwSmEGRXH D8BxU/nQoFKPZjsWzrrWVHJVBkQml579tuOng= MIME-Version: 1.0 Received: by 10.68.12.104 with SMTP id x8mr5200888pbb.79.1320244431481; Wed, 02 Nov 2011 07:33:51 -0700 (PDT) Received: by 10.68.64.66 with HTTP; Wed, 2 Nov 2011 07:33:51 -0700 (PDT) Date: Wed, 2 Nov 2011 15:33:51 +0100 Message-ID: From: Wolfgang Beck To: "" Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] draft-ietf-rtcweb-use-cases-and-requirements-06.txt, A12, monitoring quality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Nov 2011 14:33:53 -0000 Section 5.2, Browser Requirements " A12 The Web API MUST provide means for informing the web application when high loss rates occur." Wouldn't it make sense to have a more general API that provides access to RTP/RTCP performance counters? A smart JS client might analyze the counters and suggest solutions, like 'fix your fine NAT configuration'. Providers like to see that data to detect and fix problems, too. Wolfgang Beck From ted.ietf@gmail.com Wed Nov 2 09:59:38 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7944411E8131 for ; Wed, 2 Nov 2011 09:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 Zk9hKisADo3y for ; Wed, 2 Nov 2011 09:59:37 -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 8A3F511E8135 for ; Wed, 2 Nov 2011 09:59:37 -0700 (PDT) Received: by ywt2 with SMTP id 2so385184ywt.31 for ; Wed, 02 Nov 2011 09:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=cJRoVqVB68hXfboL+1eoH36MhBh/4Kmk5KvOCn0b3LQ=; b=TW96MsIRFsi0Vuk1z5R62KLP0itQ4dt7nDNe1GYpvi7579MCpM7GgFKsG0TdixvnsU jYfdfs2hXkhi+SDmeFEq3f4G0WRD2EerNKaK81E38OeQLrt82cf8WT2igPNREBhYw/ij i8SPm2kU4MilI1KYViwdfq21HiAeBf9H1tQOQ= MIME-Version: 1.0 Received: by 10.236.124.17 with SMTP id w17mr8101459yhh.126.1320253177142; Wed, 02 Nov 2011 09:59:37 -0700 (PDT) Received: by 10.236.105.169 with HTTP; Wed, 2 Nov 2011 09:59:37 -0700 (PDT) Date: Wed, 2 Nov 2011 09:59:37 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf300e4fbfa31bcc04b0c365a1 Subject: [rtcweb] Signaling discussion in Taipei X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Nov 2011 16:59:38 -0000 --20cf300e4fbfa31bcc04b0c365a1 Content-Type: text/plain; charset=ISO-8859-1 Folks, As you know, we have set aside a major block of time in our upcoming meeting for discussion of signaling. After the recent conference call and the discussion on the mailing list, Magnus and I believe that we should structure that discussion in terms of ROAP. That doesn't imply that we are calling for adoption of the current document as a WG document or that we are declaring consensus on that. But we are convinced that the working group is making the most progress with a concrete proposal in hand, and this seems to be at the level with the most support for a first-order work item. Please ensure that you've read the draft and the relevant threads, thanks, Ted Hardie --20cf300e4fbfa31bcc04b0c365a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Folks,

As you know, we have set aside a major block of time in our u= pcoming meeting for discussion of signaling.=A0 After the recent conference= call and the discussion on the mailing list, Magnus and I believe that we = should structure that discussion in terms of ROAP.=A0 That doesn't impl= y that we are calling for adoption of the current document as a WG document= or that we are declaring consensus on that.=A0 But we are convinced that t= he working group is making the most progress with a concrete proposal in ha= nd, and this seems to be at the level with the most support for a first-ord= er work item.

Please ensure that you've read the draft and the relevant threads,<= br>
thanks,

Ted Hardie
--20cf300e4fbfa31bcc04b0c365a1-- From randell-ietf@jesup.org Wed Nov 2 10:55:46 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3061F0CA0 for ; Wed, 2 Nov 2011 10:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 cFUlKvh3Hm5w for ; Wed, 2 Nov 2011 10:55:46 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id EA1961F0C4B for ; Wed, 2 Nov 2011 10:55:45 -0700 (PDT) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RLf2P-0006aA-1X for rtcweb@ietf.org; Wed, 02 Nov 2011 12:55:45 -0500 Message-ID: <4EB1840D.6070405@jesup.org> Date: Wed, 02 Nov 2011 13:55:25 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com> 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] Usecases for innovation. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Nov 2011 17:55:46 -0000 On 11/1/2011 12:02 PM, Wolfgang Beck wrote: > On Tue, Nov 1, 2011 at 3:18 PM, Iñaki Baz Castillo wrote: >> 2011/11/1 Tim Panton: >>> I've repeatedly been asked for use-cases for innovative applications of webRTC >>> to justify my contention that we should be providing a low-level framework, >>> not an embedded legacy compatibility application. > [..] >> Indeed most of the discussions in this WG are about how to make >> ***current*** SIP devices to work with a WebRTC scenario. It's a >> limited vision of WebRTC in which the main interest is to make profit >> of this new spec within telcos business. Bad IMHO. But, where are >> those "innovative" and "crazy" Web folks right now? why 95% of people >> discussing in this ***open*** WG are telcos? So this is also their >> fault, the fault of people not participating here and now. Well, the IETF's AVT group has a strong component of telephony (really VoIP/Video) people, so it's not that surprising. Most of the "web" people would be focused on the W3C side of things, and have minimal interest in the plumbing. ;-) Mostly only in how the exposed interfaces affect them, but they (generic website/app developers) haven't really seen what's proposed yet - and most of them don't even follow the W3C, which is more major site vendors and browser people I believe. I straddle both - long-term core Mozilla contributor, now employee, but in the interim spent 7 years working on videophones. But I'm no expert on website/javascript-library design. (Mozilla does have people more focused on that involved.) > Well, I'm working for a telco. Hadriel' employer sells equipment to > telcos and telephony providers. > Still our proposals to avoid standardized signaling and to depart from > classical telco signaling flows were not well > received by the crazy web folks. The world has turned upside down.. We (browser vendors) have a strong focus on getting something deployable, without unduly limiting potential innovation. We also (as has been mentioned) have concerns over complexity exposed and the resultant reliance on (rarely-if-ever-updated) JS frameworks. Quite honestly, the largest problem we have is NOT signalling; one way or another media and data channels can get open and negotiated. The biggest problem and hardest one to "solve" (it's not truly "solvable") is security and privacy and the user-interaction aspects of that. The technical issues of signalling, congestion control, and data channels are all eminently resolvable (even if there is no universally-agreed 'best' solution). Security and privacy are far harder, and the solutions less satisfying. So, if you have brain cycles to born, spend them on security, IMHO. (Note: personal opinions, not official Mozilla position, though "Mozilla" may agree with me) -- Randell Jesup randell-ietf@jesup.org From harald@alvestrand.no Wed Nov 2 14:21:47 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D7E1F0CCD for ; Wed, 2 Nov 2011 14:21:44 -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 sxS5vrMU1cVM for ; Wed, 2 Nov 2011 14:21:41 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C6E7C1F0CC3 for ; Wed, 2 Nov 2011 14:21:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DB46939E12F; Wed, 2 Nov 2011 22:21:30 +0100 (CET) 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 8aWsscBF71mT; Wed, 2 Nov 2011 22:21:29 +0100 (CET) Received: from [192.168.244.102] (unknown [207.239.83.130]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 3C15C39E089; Wed, 2 Nov 2011 22:21:27 +0100 (CET) Message-ID: <4EB1B450.5040904@alvestrand.no> Date: Wed, 02 Nov 2011 14:21:20 -0700 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Wolfgang Beck References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , "public-webrtc@w3.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-use-cases-and-requirements-06.txt, A12, monitoring quality X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "public-webrtc@w3.org" List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 21:21:47 -0000 On 11/02/2011 07:33 AM, Wolfgang Beck wrote: > Section 5.2, Browser Requirements > " A12 The Web API MUST provide means for > informing the web application when high > loss rates occur." > > Wouldn't it make sense to have a more general API that provides access > to RTP/RTCP performance counters? A smart JS client might analyze the > counters and suggest solutions, like 'fix your fine NAT > configuration'. Providers like to see that data to detect and fix > problems, too. Since this is an application API requirement, this discussion belongs in the WEBRTC WG, reply-to: set accordingly. In the discussions at the TPAC this week, it was felt that counters should be provided for things like packet loss. A regularly scheduled function that reads the lost-packet counter every few seconds and sends an alert when it's increasing "too fast" would then satisfy this requirement - a good question may be how quickly it's reasonable for the application to be informed that such a condition exists; my feeling is that "within a few seconds" is fine, but others may have other opinions. The editor team has (I believe) taken on the task of coming up with a first proposal for such a metrics interface. Harald From pravindran@sonusnet.com Wed Nov 2 16:55:51 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA25A11E8094 for ; Wed, 2 Nov 2011 16:55:51 -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.037, 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 sEoHNFn9weQO for ; Wed, 2 Nov 2011 16:55:51 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id E2FFE11E8073 for ; Wed, 2 Nov 2011 16:55:50 -0700 (PDT) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA2NuMk1008530; Wed, 2 Nov 2011 19:56:22 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 19:55:07 -0400 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 05:25:12 +0530 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.0339.001; Thu, 3 Nov 2011 05:25:11 +0530 From: Ravindran Parthasarathi To: Harald Alvestrand Thread-Topic: New usecase & requirement for media forking in browser Thread-Index: AQHMl9BWsWD0kT8xzE+tFIa2IMhSLJWWQH+AgAQBaAA= Date: Wed, 2 Nov 2011 23:55:10 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6CD0B4@inba-mail01.sonusnet.com> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <387F9047F55E8C42850AD6B3A7A03C6CB953@inba-mail01.sonusnet.com> <4EAEC609.1040707@alvestrand.no> In-Reply-To: <4EAEC609.1040707@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.53.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Nov 2011 23:55:12.0018 (UTC) FILETIME=[DBF5AF20:01CC99BA] Cc: "" Subject: Re: [rtcweb] New usecase & requirement for media forking in browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 02 Nov 2011 23:55:52 -0000 Harald, Thanks for your clarification. Some of the usecase which comes immediately = to my mind for media forking are as follows: 1) Whisper call scenario: Telemarketing Agent makes the call to the custom= er and the same call is forked to Supervisor for support/monitoring. Here, = Customer will not realize that Supervisor & Agent has side conversation. 2) Remote Recording: The call is forked towards remote peer as well as reco= rding server. This usecase is already covered in usecase document 3) Interworking SIP parallel forking with RTCWeb client:=20 Please let me know your opinion on addition of this usecase now. Thanks Partha >-----Original Message----- >From: Harald Alvestrand [mailto:harald@alvestrand.no] >Sent: Monday, October 31, 2011 9:30 PM >To: Ravindran Parthasarathi >Cc: >Subject: Re: New usecase & requirement for media forking in browser > >On 10/31/2011 06:23 AM, Ravindran Parthasarathi wrote: >> Usecase: Media forking in browser >> >> Description: User forks local stream/stream components to multiple >peers simultaneously and able to receive multiple streams from multiple >peers. >Ravindran, > >I see this as an implementation description, and not an use case. > >Could you rephrase this in terms that make it clear what the user will >be trying to do, and that this technology (forking) is the appropriate >solution for that problem? > >That will also help uncover more requirements that the use case will >imply. For instance, if the idea is that the user talks to multiple >persons simultaneously, and they are able to hear each other without a >direct connection to each other, there is an added requirement that the >user be able to mix audio from local and remote sources. > >Thank you! > > Harald Alvestrand > >> Functional requirement: F11, F12, (any new requirement has to be added >?) >> >> API requirement: The Web API MUST provide means for the web >application to initiate sending/receiving of stream/stream components to >a multiple peer simultaneously and relate each of these streams >individually by web application. >> >> Having said that, I'm not very sure whether this usecase falls under >the category of remote-recording by John. >> >> Hadriel, >> >> Thanks for the clarification on the current status and practical >usecases. >> >> Thanks >> Partha >> >> >>> -----Original Message----- >>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>> Sent: Saturday, October 29, 2011 1:58 AM >>> To: Ravindran Parthasarathi >>> Cc: Harald Alvestrand; I=F1aki Baz Castillo; >>> Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE:draft-kaplan- >>> rtcweb-sip-interworking-requirements-00] >>> >>> >>> We've debated serial and parallel forking a number of times but I >don't >>> know if there's been consensus. >>> >>> But your email is really two different questions/topics: >>> 1) Is there a use-case for forking within WebRTC? >>> 2) Does supporting SIP forking mean the Browser has to handle the >>> SDP/media behavior of it, vs. the Web-server/Interworking-function >>> handling it? >>> >>> For the first question, I can certainly envision a Web-app wanting to >>> let Alice press a single button on her Browser and end up >communicating >>> with Bob no matter where he may be, or letting her single button- >press >>> end up communicating with Bob first and then Charlie, or letting her >>> single button-press end up communicating with Bob and Charlie at the >>> same time. But I think such things can be accomplished through >clever >>> Web-app code without needing the Browser to be aware it's a forked >>> ROAP/SDP scenario. >>> [Note: though this may depend on what W3C decides the user-consent UI >>> model is relative to PeerConnections, MediaStreams and ROAP] >>> >>> With regards to the second question, there was a long email thread on >>> this which started here I think: >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01354.html >>> >>> -hadriel >>> >>> >>> On Oct 28, 2011, at 3:14 PM, Ravindran Parthasarathi wrote: >>> >>>> Harald, >>>> >>>> Thanks for the clarification. "Fedex IVR" usecase is under browser >to >>> GW/server section (sec 4.3) which is a SIP based forking requirement. >If >>> you look at carefully, "Fedex IVR non-final response" scenario could >>> have be achieved cleanly using two separate offer/answer exchange& >two >>> final responses (INVITE/200/ACK, RE-INVITE/200/ACK) : >>>> 1) customer - fedex IVR offer/answer exchange >>>> 2) fedex agent - Customer offer/answer exchange >>>> >>>> but it may be avoided in legacy for billing reasons which should not >>> be major concern for RTCWeb. In case of SIP forking, it is assumed >that >>> 2nd answer override the 1st answer in the media plane. >>>> As I mentioned earlier, SIP (serial) forking requirement shall be >met >>> by gateway signaling and no extra requirement for browser. Also, >>> switching media stream from one responder to other responder in Fedex >>> IVR usecase is not so easy because of legacy media handling (ICE, >RTCP) >>> differences as mentioned in draft-kaplan-rtcweb-sip-interworking- >>> requirements-00. >>>> ISTM, we don't have RTCWeb specific forking usecase till now. >>>> >>>> Thanks >>>> Partha >>>> >>>>> -----Original Message----- >>>>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>>>> Sent: Friday, October 28, 2011 11:58 PM >>>>> To: Ravindran Parthasarathi >>>>> Cc: I=F1aki Baz Castillo; rtcweb@ietf.org; Hadriel Kaplan >>>>> Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan- >>>>> rtcweb-sip-interworking-requirements-00] >>>>> >>>>> On 10/28/2011 10:56 AM, Ravindran Parthasarathi wrote: >>>>>> By looking at draft-ietf-rtcweb-use-cases-and-requirements-06, I >>> could >>>>> not see any specific requirement for RTCWeb forking. In case SIP >>> forking >>>>> is the only requirement for RTCWeb and also, RTCWeb does not have >any >>>>> specific forking requirement, then the gateway between RTCWeb& >SIP >>>>> shall take care of the functionality. I'm asking this question to >get >>>>> the clarity on whether SIP forking feature has to impact RTCWeb >>> client >>>>> requirement or not. >>>>> I believe the "Fedex IVR" case was specifically intended to surface >>> the >>>>> requirement for "non-final responses" (switching a media stream >from >>> the >>>>> initial responder to a next responder). >>>>> That's one form of forking ("serial fork"?) >>>>> >>>>> I haven't understood forking to be a requirement in any other use >>> case. >> From mthornbu@adobe.com Wed Nov 2 18:13:55 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F9311E80FE for ; Wed, 2 Nov 2011 18:13:55 -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 1jIdyj1duAxK for ; Wed, 2 Nov 2011 18:13:54 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 94E6011E80CB for ; Wed, 2 Nov 2011 18:13:53 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP; Wed, 02 Nov 2011 18:13:53 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1.sea.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pA31DntS023682 for ; Wed, 2 Nov 2011 18:13:50 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pA31Dm5R007013 for ; Wed, 2 Nov 2011 18:13:48 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Wed, 2 Nov 2011 18:13:48 -0700 From: Michael Thornburgh To: "rtcweb@ietf.org" Date: Wed, 2 Nov 2011 18:12:53 -0700 Thread-Topic: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt Thread-Index: AcyYRPZLIPNDx8U/RQGa2q6HeLAQ4QBch+sg Message-ID: <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> In-Reply-To: <4EAF64FF.8020101@jesup.org> 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 Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 01:13:55 -0000 comments on this draft: section 3.2: reliable streams would be fairly simple to layer on top of any= reliable and in-order datagram delivery service, not just SCTP's. section 4.1: DCCP is not a good choice when any kind of reliability is desi= red. i've seen people on this list suggest that some kind of reliability/re= transmission scheme can be layered on top of DCCP, and while that's certain= ly true, it's very un-optimal. DCCP already uses its own sequence numbers a= nd acknowledgements to detect loss events and trigger congestion response, = but that information is semantically hidden from higher-level users of DCCP= . additional application-layer sequencing AND acknowledgement information m= ust be implemented to 1) recover the original transmission order at the rec= eiver (including waiting for gaps to be repaired, if in-order delivery is d= esired); and 2) duplicate application-layer loss detection at the sender (d= riven by the application-layer acks) must be performed to re-determine whic= h segments were lost so they can be retransmitted. that sucks because, unde= r the covers, DCCP already knew exactly which segments were lost and was in= the best position to trigger (fast-) retransmission if appropriate. general comments on SCTP: Matthew and i examined SCTP when we were designing MFP (the predecessor of = RTMFP). in fact, if you look at the MFP protocol spec in the Internet Archi= ve, you might notice a suspicious similarity to SCTP's chunk scheme. :) we rejected SCTP as inappropriate for real-time communication and our other= use cases for several reasons. some of these have been at least partially = addressed since our initial dismissal of SCTP in 2004 (in particular, DTLS = in SCTP addresses the limitations of using TLS in SCTP [RFC3436], which at = the time was the only way to "secure" SCTP messages; that mechanism meant t= hat all secure messages/streams had to be fully reliable and in-order, whic= h was unacceptable for real-time communication). issues with SCTP that remain, and which i believe make it undesirable for W= ebRTC, include: o as you point out in section 5.3, running SCTP over DTLS, rather than DT= LS over SCTP, is desired so that all SCTP fields, not just the user data, a= re secured. however, this configuration is currently not defined by IETF an= d would have to be specified. o DTLS and SCTP handshakes must be performed serially (no matter which or= der they happen in), which increases the number of round-trips necessary to= establish communication. o (most important for real-time communication): each user data fragment/c= hunk is assigned an SCTP Transmission Sequence Number (TSN) at the time of = first transmission. that means even if your SCTP implementation supported s= tream prioritization somehow, the priority decision is only made at first t= ransmission time. since there's just one TSN space and the Gap Ack structur= e only talks about TSNs, it's undesirable for gaps to persist (else the Gap= Ack structure will continue to grow as more losses naturally happen). ther= efore it's desirable to repair gaps as quickly as possible. this may inappr= opriately increase the priority of a low priority fragment/chunk/stream dur= ing periods of congestion, which is exactly when priority matters (this is = a "priority inversion"). o (second most important for real-time communication): there's only one r= eceive window advertisement for all of the streams, rather than one receive= window per stream. this means there's no per-stream flow control. so if yo= u're receiving (for example) a bulk file transfer and real-time player posi= tion updates and text chat messages, and you need to suspend the file trans= fer stream for a time, that means you must also suspend the player position= updates and text chat messages. unless you spin up an entirely separate SC= TP for each flow control domain, which is lame and defeats the purpose of s= tream multiplexing. o SCTP specifies the maximum number of streams in each direction at assoc= iation startup. web applications may not know the number of streams needed = up front; in fact, the number of streams needed in any real-world non-SS7 d= ata application is very likely to evolve over the lifetime of that applicat= ion, naturally increasing and decreasing. o the semantics of unordered messages are confusing and not a good map to= WebRTC. they are semantically equivalent to an entirely separate stream lo= osely associated to the ordered stream of the same number. there's no way t= o tell (without application layer sequencing) if an unordered message has b= een lost/abandoned by the sender. at the protocol level, TSNs can be used t= o recover the queuing order of received unordered messages, but the TSNs ar= e semantically disconnected from the SCTP user. recovering the original que= uing order over a short reorder/reassembly window period is desirable in so= me real-time applications. o an SCTP receiver should be able to choose to receive stream messages in= originally-queued order or as-received-on-the-network order on a per-strea= m basis, and be able to recover the original queuing order to whatever exte= nt desired (potentially limited by real-time constraints) when receiving in= network order. SCTP's unordered message semantics are designed for "out-of= -band" messages, and are not a good fit for general "real-time" data. trans= mission order should be determined by the sender, reception order should be= determined by the receiver. o the stream sequence number being only 16 bits limits the maximum messag= e rate through high delay networks where message gaps can be reliably detec= ted at the receiver, when the sender uses limited-reliability, to 32767 mes= sages/RTT. that sounds large, but could be easily reached even today in mod= erately high bandwidth*delay paths if messages are small. specifying and implementing SCTP over DTLS over ICE over UDP is probably ne= arly as much work as specifying and implementing a new network protocol tha= t actually solves the problems cleanly and holistically. having done that b= efore a few times, i'm in favor of the clean holistic approach. :) -mike -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Randell Jesup Sent: Monday, October 31, 2011 8:18 PM A new version of I-D, draft-jesup-rtcweb-data-01.txt has been successfully submitted by Randell Jesup and posted to the IETF repository. [...] http://www.ietf.org/id/draft-jesup-rtcweb-data-01.txt [...] From pravindran@sonusnet.com Wed Nov 2 18:21:53 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF62411E8104 for ; Wed, 2 Nov 2011 18:21:52 -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.037, 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 ec34rf6B7QRB for ; Wed, 2 Nov 2011 18:21:52 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id BABE411E80FE for ; Wed, 2 Nov 2011 18:21:50 -0700 (PDT) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA31MNQX031143 for ; Wed, 2 Nov 2011 21:22:23 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 21:12:34 -0400 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 06:42:39 +0530 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.0339.001; Thu, 3 Nov 2011 06:42:38 +0530 From: Ravindran Parthasarathi To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] Usecases for innovation. Thread-Index: AQHMmHCS/LiPYOr2wEy+DsTSeMo0LJWXtUaAgAAc6gCAAbHtgIAAwcpQ Date: Thu, 3 Nov 2011 01:12:37 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6CD0F1@inba-mail01.sonusnet.com> References: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com> <4EB1840D.6070405@jesup.org> In-Reply-To: <4EB1840D.6070405@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.53.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Nov 2011 01:12:39.0346 (UTC) FILETIME=[ADFBA920:01CC99C5] Subject: Re: [rtcweb] Usecases for innovation. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 01:21:53 -0000 IMO, low level API are nothing but exposing (secured) RTP library API from = browser to web developer. Of course, it helps in case the web development f= ocused on special web-application like 1) Proprietary SDP next generation mechanism (if ROAP proposal is accepted = as default API mechanism) implementation. Of course, lot of flames on SDP a= lready and alternative proposal for the specific deployment is possible. 2) Signaling mechanism like H.245 (Media description of H.323) which does n= ot direct well fit with SDP 3) RTP specific enhancement services like adding proprietary RTCP extension= s. But I don't whether the above application will be interesting to typical we= bsite developer (not telephony or UC provider) and also, Browser vendors sp= elt out in the last meeting that it is tough to maintain these API in brows= ers. Thanks to Randell for sharing his experience and burning issue in WebRTC. I= understand that security & privacy should be the main focus of this WG.=20 I raised standard signaling issue as it is normal response in any real-time= (telephony or unified communication) development that signaling is less im= portant and let us focus on service but after couple of releases with this = mentality, signaling manageability go for toss which calls for hack & re-st= ructure in signaling layer. The proprietary signaling helps for time to mar= ket but provides the manageability & scalability issues in the long run. Lo= t of so-called SIP based mechanism works based on unsubscribed NOTIFY & INF= O mechanism. I have seen these kind of proprietary implementation wherein t= he companies struggles to move out of it because of developed service on to= p of this protocol infrastructure. I'm more skeptical about "no standardizi= ng signaling protocol" argument as the argument mostly comes from VoIP & te= lephony service providers or OEM. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Randell Jesup >Sent: Wednesday, November 02, 2011 11:25 PM >To: rtcweb@ietf.org >Subject: Re: [rtcweb] Usecases for innovation. > >On 11/1/2011 12:02 PM, Wolfgang Beck wrote: >> On Tue, Nov 1, 2011 at 3:18 PM, I=F1aki Baz Castillo >wrote: >>> 2011/11/1 Tim Panton: >>>> I've repeatedly been asked for use-cases for innovative applications >of webRTC >>>> to justify my contention that we should be providing a low-level >framework, >>>> not an embedded legacy compatibility application. >> [..] >>> Indeed most of the discussions in this WG are about how to make >>> ***current*** SIP devices to work with a WebRTC scenario. It's a >>> limited vision of WebRTC in which the main interest is to make profit >>> of this new spec within telcos business. Bad IMHO. But, where are >>> those "innovative" and "crazy" Web folks right now? why 95% of people >>> discussing in this ***open*** WG are telcos? So this is also their >>> fault, the fault of people not participating here and now. > >Well, the IETF's AVT group has a strong component of telephony (really >VoIP/Video) people, so it's not that surprising. Most of the "web" >people would be focused on the W3C side of things, and have minimal >interest in the plumbing. ;-) Mostly only in how the exposed interfaces >affect them, but they (generic website/app developers) haven't really >seen what's proposed yet - and most of them don't even follow the W3C, >which is more major site vendors and browser people I believe. > >I straddle both - long-term core Mozilla contributor, now employee, but >in the interim spent 7 years working on videophones. But I'm no expert >on website/javascript-library design. (Mozilla does have people more >focused on that involved.) > >> Well, I'm working for a telco. Hadriel' employer sells equipment to >> telcos and telephony providers. >> Still our proposals to avoid standardized signaling and to depart from >> classical telco signaling flows were not well >> received by the crazy web folks. The world has turned upside down.. > >We (browser vendors) have a strong focus on getting something >deployable, without unduly limiting potential innovation. We also (as >has been mentioned) have concerns over complexity exposed and the >resultant reliance on (rarely-if-ever-updated) JS frameworks. > >Quite honestly, the largest problem we have is NOT signalling; one way >or another media and data channels can get open and negotiated. The >biggest problem and hardest one to "solve" (it's not truly "solvable") >is security and privacy and the user-interaction aspects of that. The >technical issues of signalling, congestion control, and data channels >are all eminently resolvable (even if there is no universally-agreed >'best' solution). Security and privacy are far harder, and the >solutions less satisfying. > >So, if you have brain cycles to born, spend them on security, IMHO. > >(Note: personal opinions, not official Mozilla position, though >"Mozilla" may agree with me) > >-- >Randell Jesup >randell-ietf@jesup.org >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Wed Nov 2 21:52:29 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2888C11E80FC for ; Wed, 2 Nov 2011 21:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 rlQYpcEL2j6o for ; Wed, 2 Nov 2011 21:52: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 4CE1911E80CE for ; Wed, 2 Nov 2011 21:52:22 -0700 (PDT) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RLpHo-0005lF-UB; Wed, 02 Nov 2011 23:52:21 -0500 Message-ID: <4EB21DEF.5060606@jesup.org> Date: Thu, 03 Nov 2011 00:51:59 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> In-Reply-To: <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.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: Cc: Michael Tuexen Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 04:52:29 -0000 On 11/2/2011 9:12 PM, Michael Thornburgh wrote: > comments on this draft: > > section 3.2: reliable streams would be fairly simple to layer on top of any reliable and in-order datagram delivery service, not just SCTP's. Yes. > section 4.1: DCCP is not a good choice when any kind of reliability is desired. I agree; it was added in there by one of the authors to cover the options available. > general comments on SCTP: > > Matthew and i examined SCTP when we were designing MFP (the predecessor of RTMFP). in fact, if you look at the MFP protocol spec in the Internet Archive, you might notice a suspicious similarity to SCTP's chunk scheme. :) > > we rejected SCTP as inappropriate for real-time communication and our other use cases for several reasons. some of these have been at least partially addressed since our initial dismissal of SCTP in 2004 (in particular, DTLS in SCTP addresses the limitations of using TLS in SCTP [RFC3436], which at the time was the only way to "secure" SCTP messages; that mechanism meant that all secure messages/streams had to be fully reliable and in-order, which was unacceptable for real-time communication). Ok, that sounds like SCTP/DTLS (or at least DTLS/SCTP) is usable given your comments above. > issues with SCTP that remain, and which i believe make it undesirable for WebRTC, include: > > o as you point out in section 5.3, running SCTP over DTLS, rather than DTLS over SCTP, is desired so that all SCTP fields, not just the user data, are secured. however, this configuration is currently not defined by IETF and would have to be specified. Ok - though conceptually SCTP should be able to run over anything presenting a UDP-like interface. There are some fallouts, like no multi-homing. Can some others here (Magnus?) with better understanding of the exact RFC requirements state if it would be acceptable to reference a SCTP-over-DTLS draft, which should be fairly straightforward to create and move forward? > o DTLS and SCTP handshakes must be performed serially (no matter which order they happen in), which increases the number of round-trips necessary to establish communication. True, though since we're not sending media data over the SCTP link I don't think this is a significant problem; almost any reliable-datagram-over-DTLS would have a similar issue I think. > o (most important for real-time communication): each user data fragment/chunk is assigned an SCTP Transmission Sequence Number (TSN) at the time of first transmission. that means even if your SCTP implementation supported stream prioritization somehow, the priority decision is only made at first transmission time. since there's just one TSN space and the Gap Ack structure only talks about TSNs, it's undesirable for gaps to persist (else the Gap Ack structure will continue to grow as more losses naturally happen). therefore it's desirable to repair gaps as quickly as possible. this may inappropriately increase the priority of a low priority fragment/chunk/stream during periods of congestion, which is exactly when priority matters (this is a "priority inversion"). Priority inversion is a bad thing; though since it would only apply to the data streams the impact is limited. I'd be interested in hearing Michael Tuexen's/etc discussion of this, and how big an impact it would be. > o (second most important for real-time communication): there's only one receive window advertisement for all of the streams, rather than one receive window per stream. this means there's no per-stream flow control. so if you're receiving (for example) a bulk file transfer and real-time player position updates and text chat messages, and you need to suspend the file transfer stream for a time, that means you must also suspend the player position updates and text chat messages. unless you spin up an entirely separate SCTP for each flow control domain, which is lame and defeats the purpose of stream multiplexing. That's more concerning. Correct me if I've misunderstood: if I stop reading from the file-transfer stream, that will block the other streams? One could layer something on top of SCTP to provide per-stream queues I imagine, and ensure in the rtcweb code that the main receive window doesn't stall, but the problem with that would be providing reliability if the file-transfer stream is reliable - if it's reliable, we'd have to in theory buffer a large amount of data *or* block other channels *or* put a flow-control layer on top of the reliable channels, which hurts the overall complexity and advantage of using existing code. Perhaps I do misunderstand this issue (I hope so actually). Or we state that the JS app must service all channels expeditiously or real-time channels may be blocked, which is probably the way we'd resolve it. Definitely sub-optimal and an annoyance for the JS app writer in some cases, but probably not a major problem. > o SCTP specifies the maximum number of streams in each direction at association startup. web applications may not know the number of streams needed up front; in fact, the number of streams needed in any real-world non-SS7 data application is very likely to evolve over the lifetime of that application, naturally increasing and decreasing. I would assume we would define a maximum number of data streams, and specify that number when opening the association. Not optimal, but workable. > o the semantics of unordered messages are confusing and not a good map to WebRTC. they are semantically equivalent to an entirely separate stream loosely associated to the ordered stream of the same number. there's no way to tell (without application layer sequencing) if an unordered message has been lost/abandoned by the sender. at the protocol level, TSNs can be used to recover the queuing order of received unordered messages, but the TSNs are semantically disconnected from the SCTP user. recovering the original queuing order over a short reorder/reassembly window period is desirable in some real-time applications. Thus far we haven't required that unordered delivery be exposed to the JS app, though that capability would be handy for some uses. I have no problem with the application being required to include its own sequence number in the data if it cares and if that helps with this objection. > o an SCTP receiver should be able to choose to receive stream messages in originally-queued order or as-received-on-the-network order on a per-stream basis, and be able to recover the original queuing order to whatever extent desired (potentially limited by real-time constraints) when receiving in network order. SCTP's unordered message semantics are designed for "out-of-band" messages, and are not a good fit for general "real-time" data. transmission order should be determined by the sender, reception order should be determined by the receiver. Agreed; but the spec (and code) for SCTP exists, even if sub-optimal, and timeframe is a major constraint. > o the stream sequence number being only 16 bits limits the maximum message rate through high delay networks where message gaps can be reliably detected at the receiver, when the sender uses limited-reliability, to 32767 messages/RTT. that sounds large, but could be easily reached even today in moderately high bandwidth*delay paths if messages are small. Worst-case RTT is probably on the order of 2s (~2 satellite links each direction). Note that for most use-cases this would be an intolerably long delay, but not for all. 16K messages/second may be reachable in theory, but given the likely bandwidth of said long-latency links I don't think this is a restriction that would bother me at all (even with high bandwidth I don't think this would bother me). > specifying and implementing SCTP over DTLS over ICE over UDP is probably nearly as much work as specifying and implementing a new network protocol that actually solves the problems cleanly and holistically. having done that before a few times, i'm in favor of the clean holistic approach. :) Before I answer that: Thanks greatly for the detailed critique! In response I have to say: put a protocol proposal on the table or gather a group to do so, and do so ASAP, because if we don't get an alternative, it *will* be either SCTP/DTLS/(ICE/UDP) or pseudo-TCP/DTLS/(ICE/UDP), and I don't know what we'd do for the unreliable congestion-controlled channels (maybe DCCP). If you do put forward a proposal, do you really believe it can be done, standardized, agreed to and implemented in the timeframe required? Specifying SCTP/DTLS seems relatively straightforward compared to standardizing a new protocol... The timeframe for this is quite constrained already; one of the strongest arguments against SCTP would also be timeframe, except that SCTP gives us congestion-controlled unreliable data, which pseudo-TCP-over-DTLS doesn't - we'd have to use yet another unspecified mechanism for congestion control of the unreliable data channels. I think the hottest item you've flagged from my perspective is the receive-window blocking, followed by wanting to understand the possible priority-inversions. Michael? Randy? -- Randell Jesup randell-ietf@jesup.org From wolfgang.beck01@googlemail.com Thu Nov 3 01:18:44 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2620D11E80DC for ; Thu, 3 Nov 2011 01:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=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 G22GX99uSPLG for ; Thu, 3 Nov 2011 01:18:43 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5150A11E80C9 for ; Thu, 3 Nov 2011 01:18:43 -0700 (PDT) Received: by faas12 with SMTP id s12so1507729faa.31 for ; Thu, 03 Nov 2011 01:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HTFAXbcZWv4SlfkyfHPDpAP32lnClLuIDdzPexiRqM8=; b=dkpzHA4mX4T20yg/QNjH7XmIEi9GTDfES9DsLxEGv77jYl1NdShcIFfU2nAFwEX+Oi b21PT6hgWEjcf6XA5uzx9R8r4DQ+KxnSQe917kb7Mkd8GHicLqrX8XbO6ZzpzU659yoO zvbsxKOSwcvtn1tx/DsdaoXvaZDtAXdV1t1m4= MIME-Version: 1.0 Received: by 10.223.58.134 with SMTP id g6mr983825fah.0.1320308322254; Thu, 03 Nov 2011 01:18:42 -0700 (PDT) Received: by 10.152.18.197 with HTTP; Thu, 3 Nov 2011 01:18:41 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6CD0F1@inba-mail01.sonusnet.com> References: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com> <4EB1840D.6070405@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6CD0F1@inba-mail01.sonusnet.com> Date: Thu, 3 Nov 2011 09:18:41 +0100 Message-ID: From: Wolfgang Beck To: Ravindran Parthasarathi Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Usecases for innovation. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 08:18:44 -0000 On Thu, Nov 3, 2011 at 2:12 AM, Ravindran Parthasarathi wrote: > IMO, low level API are nothing but exposing (secured) RTP library API from browser to web developer. Of course, it helps in case the web development focused on special web-application like > > 1) Proprietary SDP next generation mechanism (if ROAP proposal is accepted as default API mechanism) implementation. Of course, lot of flames on SDP already and alternative proposal for the specific deployment is possible. > 2) Signaling mechanism like H.245 (Media description of H.323) which does not direct well fit with SDP > 3) RTP specific enhancement services like adding proprietary RTCP extensions. > The API must hit the right level. If it is too low-level, security will be hard to achieve. If it is too high-level, it can't be used for anything new. What worries me about ROAP is this protocol stack: SDP ROAP proprietary JS client protocol HTTP ... SDP+ROAP may require a complexity of the JS client protocol that is not really needed by the actual application. However, running code wins. Maybe this isn't a problem. > Thanks to Randell for sharing his experience and burning issue in WebRTC. I understand that security & privacy should > be the main focus of this WG. We have less security issues if both parties are using the same server. With trapezoid style interconnection/federation security relevant information can get lost. You can get into transit scenarios where all your signaling is routed through providers that you don't know. If Facebook or Google became big hubs to interconnect small RTCWEB providers, how would they use this signaling information? > > The proprietary signaling helps for time to market but provides the manageability & scalability issues in the long run. FYI, here's one of the presentations that motivated RTCWEB in the first place: 'The End Of Application Protocol Standardization (?)' http://www.ietf.org/proceedings/80/slides/plenaryt-5.pdf Wolfgang Beck From magnus.westerlund@ericsson.com Thu Nov 3 03:13:33 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637281F0C5F for ; Thu, 3 Nov 2011 03:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.259 X-Spam-Level: X-Spam-Status: No, score=-107.259 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_55=0.6, 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 qFti4-FNpmK2 for ; Thu, 3 Nov 2011 03:13:32 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4551F0C3C for ; Thu, 3 Nov 2011 03:13:31 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-9d-4eb2694a54d3 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 27.6B.13753.A4962BE4; Thu, 3 Nov 2011 11:13:30 +0100 (CET) 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.137.0; Thu, 3 Nov 2011 11:13:30 +0100 Message-ID: <4EB26945.40607@ericsson.com> Date: Thu, 3 Nov 2011 11:13:25 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] State of the Forking discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 10:13:33 -0000 WG, I just reviewed the last weeks Forking discussion. This includes the threads "RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]" and "Media forking solution for SIP interoperability (without a media gateway)" As far as I can tell there is not yet even a rough consensus. Therefore I will attempt to summarize what I personally believe to be the important points and alternatives in this discussion. Keep in mind that my assumptions or understanding may be unclear or have errors. So don't hesitate to challenge what I write. I think it is important that there are in fact at least two important questions here. 1. Is forking needed to be supported at all? 2. If it is supported in which form would it supported in. so lets start looking into the arguments and possibilities for these two questions. And I do hope that you will read to the end of this mail which is quite long. Lets start with the high level functionality part. Is forking needed and what usage does it have. So forking is all about sending out an invitation to a media session including an actual media configuration offer, i.e. SDP Offer, then get more than a single answer to that offer back. How you deal with these answers as they come in is the difference between serial and parallel forking. So lets define those. Parallel forking: For each answer you receive you establish a new actual media session. Thus if you receive two answers you will have to different media sessions that are potentially in use at the same time. Serial forking: The first answer is received and results the establishment of a media session. At a later point in time a second answer is received. At that point you take the decision if that second answer is going to be used to establish a new media session that replaces the first one. In other words at any given time you will only have a single media session established based on each offer. So there has been a number of different views on how one can see on forking. And I think I will have to bring in a bit reflections on how this can be done with the current PeerConnection API. A) No forking is needed: Between WebRTC end-points there is no need for forking. Instead the application can send out session invitations to the peers it wants to talk to. These are without any SDP Offer equivalent, instead end-points that want to communicate they create PeerConnections, which results in SDP Offers. Thus the communication initiating end-point becomes the ones that provides SDP answers and get one PeerConnection per remote end-point that actually want to communicate. B) We need to have some interworking with SIP: So the fundamental here is that it needs to be reasonable to interwork with SIP, independent if one uses a SIP in JS in the application running on the WebRTC enabled browser, or have signalling gateway in the webserver, or as a remote WebRTC peer. The issue is that A)'s method of initiating call doesn't work well with SIP. There is a need to send a SIP Invite with an SDP Offer and that can result in multiple answers. To resolve this one could deal with this in a couple of different ways: B1) Use Iñaki's proposal which forces the WebRTC application to create a second PeerConnection and then forces an update in the SIP domain with the second peer-connections Offer. However, it was pointed out that this doesn't work with SIP Provisional answers, as used by ICE for example, unless PRACK is supported. The level of PRACK support is reasonable but far from universal so this would limit the SIP UAs one can interwork with. However, from WebRTC perspective no forking support is needed. A single PeerConnection results in one offer and a single answer is processed. B2) Require WebRTC to handle replace Answers: So the idea here is that one changes the PeerConnection API and have underlying functionality so that at any point in time a new Answer can pushed onto a PeerConnection and that forces the media session to be reestablished if needed. So if the ICE candidate list is different an ICE restart happens. This clearly supports serial forking. It also can create some complexities in the underlying SDP handling logic if one desires to minimize the media impact. B3) Local side shared parameters in multiple PeerConnections: The idea in this proposal is that all PeerConnections generated in a browser context, like a tab will implicit share the fundamental parameters like ICE candidates etc for the number of media streams added. So if one creates a second PeerConnection with the same audio+video MediaStream object added I will get an offer that is mostly identical to the the first PeerConnection, thus I can push in the answer from the first PeerConnection Offer into the second PC object and it will still work. The downside of this is that it is implicit and it becomes difficult to determine when it works and when it will fail. It will also be highly dependent on the application performing the right process to get it to work. It also causes a sharing of the parameters when not needed or desired, which primarily is an issue from a security point of view, especially with SDES keys (see below). The positive is this likely requires no API changes. This method would also support parallel forking. B4) Cloning/Factory for PeerConnection: On the API level there will be explicit support for generating multiple PeerConnections from the same base. This could either be a factory for PeerConnections or some Object constructor that clones an existing PeerConnection but that is a W3C question. By being explicit some of the B3) issues goes away and the applications can choose when this should happen or not. This also support parallel forking as the application can deal with each media session independently. This clearly will have some impact on the API. Additional considerations: Shared SDES keys: B2 to B4 will result in that SDES keys from the Offering party to be used towards all invited parties. This is security risk as any of the invited parties can spoof the offering side towards any of the other invited parties. This threat can be resolved by having the inviter rekey immediately after having received an answer. Sharing ICE candidates: B3 and B4 and also B2 to some degree will share the ICE candidates. That has certain implications. One is the positive in that it minimizes the resource consumption as additional PeerConnections come at very little extra cost, no need for additional ICE gathering candidate phases, and also be very quick as no external communication is required. The downside of this is that the end-points candidates must always be kept alive as long as some PeerConnection instance exist. Because the browser never knows when the application may create an additional PC and expect them to have the same ICE candidates. It should also be noted that the answering WebRTC end-point will need to gather candidates for each offer. Otherwise it will become impossible to create multiple PeerConnections between the same end-points if that is desired by the application. I know the above doesn't list all of the pro and cons of the different alternatives. So please fill in additional arguments. And if I missed some proposal please add that also if relevant As you may have noted I the two questions in the above have kind of floated together. The reason for this is that I think the majority are fine with having SIP support as long as it doesn't have to high cost or complexity associated with it. Thus, the question how becomes very intertwined with forking support yes or no. So please continue the discussion 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 Thu Nov 3 03:29:58 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AEB11E80DD for ; Thu, 3 Nov 2011 03:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 5OdJXBMf4PdP for ; Thu, 3 Nov 2011 03:29:57 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 359DD11E80AC for ; Thu, 3 Nov 2011 03:29:57 -0700 (PDT) X-AuditID: c1b4fb39-b7cb2ae000001bd8-70-4eb26d23585f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EA.DF.07128.32D62BE4; Thu, 3 Nov 2011 11:29:55 +0100 (CET) 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.137.0; Thu, 3 Nov 2011 11:29:55 +0100 Message-ID: <4EB26D22.5090000@ericsson.com> Date: Thu, 3 Nov 2011 11:29:54 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 10:29:58 -0000 WG, There has been a number of posts that makes arguments based on federation and the federation protocol. This is the protocol used between the webservers, called "Signalling path" in the trappzoid picture (from draft-ietf-rtcweb-overview-02) below: +-----------+ +-----------+ | Web | | Web | | | Signalling | | | |-------------| | | Server | path | Server | | | | | +-----------+ +-----------+ / \ / \ Proprietary over / \ HTTP/Websockets / \ / Proprietary over \ / HTTP/Websockets \ / \ +-----------+ +-----------+ |JS/HTML/CSS| |JS/HTML/CSS| +-----------+ +-----------+ +-----------+ +-----------+ | | | | | | | | | Browser | ------------------------- | Browser | | | Media path | | | | | | +-----------+ +-----------+ Figure 2: Browser RTC Trapezoid Please consider that the current WG consensus is well captured in the overview draft: If the two Web servers are operated by different entities, the signalling path needs to be agreed upon, either by standardization or by other means of agreement; for example, both servers might implement SIP, and the servers would talk SIP to each other, and each would translate between the SIP protocol and their proprietary representation for sending to their application running in the browser. This part is outside the scope of the RTCWEB standars suite. So, it may be SIP, it doesn't need to be SIP. The important from the WG's perspective is that is a possible deployment model we intended to support. It is not the only deployment model. We don't define what is used on the signalling path and there is freedom here. Please consider that when writing arguments so that you don't misrepresent the current WG consensus or ignore the set of possibilities that currently are considered. If you don't like the WG consensus, then suggest to change it and see if you get support for it. 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 Thu Nov 3 03:37:27 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC3C1F0C3C for ; Thu, 3 Nov 2011 03:37:27 -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 ZohyvEF5-1PL for ; Thu, 3 Nov 2011 03:37:26 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2182E11E8088 for ; Thu, 3 Nov 2011 03:37:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0704039E0D4; Thu, 3 Nov 2011 11:37:25 +0100 (CET) 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 uD7-Qs8PIhuz; Thu, 3 Nov 2011 11:37:24 +0100 (CET) Received: from [10.0.4.98] (unknown [77.241.230.246]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 0824339E082; Thu, 3 Nov 2011 11:37:23 +0100 (CET) Message-ID: <4EB26EE5.40703@alvestrand.no> Date: Thu, 03 Nov 2011 11:37:25 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <387F9047F55E8C42850AD6B3A7A03C6CB953@inba-mail01.sonusnet.com> <4EAEC609.1040707@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6CD0B4@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6CD0B4@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [rtcweb] New usecase & requirement for media forking in browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 10:37:27 -0000 On 11/03/2011 12:55 AM, Ravindran Parthasarathi wrote: > Harald, > > Thanks for your clarification. Some of the usecase which comes immediately to my mind for media forking are as follows: > > 1) Whisper call scenario: Telemarketing Agent makes the call to the customer and the same call is forked to Supervisor for support/monitoring. Here, Customer will not realize that Supervisor& Agent has side conversation. This does not need forking. The caller (the agent) is the one setting up 2 connections. He will also have to relay media from the customer to the supervisor. > 2) Remote Recording: The call is forked towards remote peer as well as recording server. This usecase is already covered in usecase document Again, this does not need forking. The client creating 2 connections is the one deciding to do so. > 3) Interworking SIP parallel forking with RTCWeb client: "Because SIP does it" is not an use case. > Please let me know your opinion on addition of this usecase now. I still do not see an use case from this description. > Thanks > Partha >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: Monday, October 31, 2011 9:30 PM >> To: Ravindran Parthasarathi >> Cc: >> Subject: Re: New usecase& requirement for media forking in browser >> >> On 10/31/2011 06:23 AM, Ravindran Parthasarathi wrote: >>> Usecase: Media forking in browser >>> >>> Description: User forks local stream/stream components to multiple >> peers simultaneously and able to receive multiple streams from multiple >> peers. >> Ravindran, >> >> I see this as an implementation description, and not an use case. >> >> Could you rephrase this in terms that make it clear what the user will >> be trying to do, and that this technology (forking) is the appropriate >> solution for that problem? >> >> That will also help uncover more requirements that the use case will >> imply. For instance, if the idea is that the user talks to multiple >> persons simultaneously, and they are able to hear each other without a >> direct connection to each other, there is an added requirement that the >> user be able to mix audio from local and remote sources. >> >> Thank you! >> >> Harald Alvestrand >> >>> Functional requirement: F11, F12, (any new requirement has to be added >> ?) >>> API requirement: The Web API MUST provide means for the web >> application to initiate sending/receiving of stream/stream components to >> a multiple peer simultaneously and relate each of these streams >> individually by web application. >>> Having said that, I'm not very sure whether this usecase falls under >> the category of remote-recording by John. >>> Hadriel, >>> >>> Thanks for the clarification on the current status and practical >> usecases. >>> Thanks >>> Partha >>> >>> >>>> -----Original Message----- >>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>> Sent: Saturday, October 29, 2011 1:58 AM >>>> To: Ravindran Parthasarathi >>>> Cc: Harald Alvestrand; Iñaki Baz Castillo; >>>> Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE:draft-kaplan- >>>> rtcweb-sip-interworking-requirements-00] >>>> >>>> >>>> We've debated serial and parallel forking a number of times but I >> don't >>>> know if there's been consensus. >>>> >>>> But your email is really two different questions/topics: >>>> 1) Is there a use-case for forking within WebRTC? >>>> 2) Does supporting SIP forking mean the Browser has to handle the >>>> SDP/media behavior of it, vs. the Web-server/Interworking-function >>>> handling it? >>>> >>>> For the first question, I can certainly envision a Web-app wanting to >>>> let Alice press a single button on her Browser and end up >> communicating >>>> with Bob no matter where he may be, or letting her single button- >> press >>>> end up communicating with Bob first and then Charlie, or letting her >>>> single button-press end up communicating with Bob and Charlie at the >>>> same time. But I think such things can be accomplished through >> clever >>>> Web-app code without needing the Browser to be aware it's a forked >>>> ROAP/SDP scenario. >>>> [Note: though this may depend on what W3C decides the user-consent UI >>>> model is relative to PeerConnections, MediaStreams and ROAP] >>>> >>>> With regards to the second question, there was a long email thread on >>>> this which started here I think: >>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01354.html >>>> >>>> -hadriel >>>> >>>> >>>> On Oct 28, 2011, at 3:14 PM, Ravindran Parthasarathi wrote: >>>> >>>>> Harald, >>>>> >>>>> Thanks for the clarification. "Fedex IVR" usecase is under browser >> to >>>> GW/server section (sec 4.3) which is a SIP based forking requirement. >> If >>>> you look at carefully, "Fedex IVR non-final response" scenario could >>>> have be achieved cleanly using two separate offer/answer exchange& >> two >>>> final responses (INVITE/200/ACK, RE-INVITE/200/ACK) : >>>>> 1) customer - fedex IVR offer/answer exchange >>>>> 2) fedex agent - Customer offer/answer exchange >>>>> >>>>> but it may be avoided in legacy for billing reasons which should not >>>> be major concern for RTCWeb. In case of SIP forking, it is assumed >> that >>>> 2nd answer override the 1st answer in the media plane. >>>>> As I mentioned earlier, SIP (serial) forking requirement shall be >> met >>>> by gateway signaling and no extra requirement for browser. Also, >>>> switching media stream from one responder to other responder in Fedex >>>> IVR usecase is not so easy because of legacy media handling (ICE, >> RTCP) >>>> differences as mentioned in draft-kaplan-rtcweb-sip-interworking- >>>> requirements-00. >>>>> ISTM, we don't have RTCWeb specific forking usecase till now. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>>> -----Original Message----- >>>>>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>>>>> Sent: Friday, October 28, 2011 11:58 PM >>>>>> To: Ravindran Parthasarathi >>>>>> Cc: Iñaki Baz Castillo; rtcweb@ietf.org; Hadriel Kaplan >>>>>> Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan- >>>>>> rtcweb-sip-interworking-requirements-00] >>>>>> >>>>>> On 10/28/2011 10:56 AM, Ravindran Parthasarathi wrote: >>>>>>> By looking at draft-ietf-rtcweb-use-cases-and-requirements-06, I >>>> could >>>>>> not see any specific requirement for RTCWeb forking. In case SIP >>>> forking >>>>>> is the only requirement for RTCWeb and also, RTCWeb does not have >> any >>>>>> specific forking requirement, then the gateway between RTCWeb& >> SIP >>>>>> shall take care of the functionality. I'm asking this question to >> get >>>>>> the clarity on whether SIP forking feature has to impact RTCWeb >>>> client >>>>>> requirement or not. >>>>>> I believe the "Fedex IVR" case was specifically intended to surface >>>> the >>>>>> requirement for "non-final responses" (switching a media stream >> from >>>> the >>>>>> initial responder to a next responder). >>>>>> That's one form of forking ("serial fork"?) >>>>>> >>>>>> I haven't understood forking to be a requirement in any other use >>>> case. > From ibc@aliax.net Thu Nov 3 04:23:05 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F328511E80AC for ; Thu, 3 Nov 2011 04:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, 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 Sc5RKYI2BWOB for ; Thu, 3 Nov 2011 04:23: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 6ABBF11E8088 for ; Thu, 3 Nov 2011 04:23:04 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so1145865vcb.31 for ; Thu, 03 Nov 2011 04:23:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.115.208 with SMTP id j16mr680859vcq.33.1320319381329; Thu, 03 Nov 2011 04:23:01 -0700 (PDT) Received: by 10.220.107.206 with HTTP; Thu, 3 Nov 2011 04:23:01 -0700 (PDT) In-Reply-To: <4EB26D22.5090000@ericsson.com> References: <4EB26D22.5090000@ericsson.com> Date: Thu, 3 Nov 2011 12:23:01 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 11:23:05 -0000 2011/11/3 Magnus Westerlund : > Please consider that the current WG consensus is well captured in the > overview draft: > > =C2=A0 If the two Web servers are operated by different entities, the > =C2=A0 signalling path needs to be agreed upon, either by standardization= or > =C2=A0 by other means of agreement; for example, both servers might > =C2=A0 implement SIP, and the servers would talk SIP to each other, and e= ach > =C2=A0 would translate between the SIP protocol and their proprietary > =C2=A0 representation for sending to their application running in the > =C2=A0 browser. =C2=A0This part is outside the scope of the RTCWEB standa= rs > =C2=A0 suite. > > So, it may be SIP, it doesn't need to be SIP. The important from the > WG's perspective is that is a possible deployment model we intended to > support. It is not the only deployment model. We don't define what is > used on the signalling path and there is freedom here. I strongly agree with these conclusions: Freedom in-the-wire and let the Web to decide. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Thu Nov 3 04:53:43 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE9C11E80E8 for ; Thu, 3 Nov 2011 04:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.987 X-Spam-Level: X-Spam-Status: No, score=-6.987 tagged_above=-999 required=5 tests=[AWL=1.012, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kvdNEJPiKc0 for ; Thu, 3 Nov 2011 04:53:42 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 342E211E8088 for ; Thu, 3 Nov 2011 04:53:42 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-91-4eb280c5decf Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 49.ED.13753.5C082BE4; Thu, 3 Nov 2011 12:53:41 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 3 Nov 2011 12:53:40 +0100 From: Christer Holmberg To: Magnus Westerlund , "rtcweb@ietf.org" Date: Thu, 3 Nov 2011 12:53:39 +0100 Thread-Topic: [rtcweb] State of the Forking discussion Thread-Index: AcyaET/UQS0OLGexRSeTGvjWAriroQADHEGA Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522359626A5@ESESSCMS0356.eemea.ericsson.se> References: <4EB26945.40607@ericsson.com> In-Reply-To: <4EB26945.40607@ericsson.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] State of the Forking discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 11:53:43 -0000 Hi Magnus, Question #1: Is forking needed to be supported at all? Answer: Yes Question #2: If it is supported in which form would it supported in? Answer: Serial (ie one "active" media session at any given time) forking i= s enough. Solution B2, B3 or B4 - whatever is possible and least complex from a Pee= rConnection perspective :) Regards, Christer =09 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund > Sent: 3. marraskuuta 2011 12:13 > To: rtcweb@ietf.org > Subject: [rtcweb] State of the Forking discussion >=20 > WG, >=20 > I just reviewed the last weeks Forking discussion. This=20 > includes the threads "RTCWeb Forking usecase [was RE: > draft-kaplan-rtcweb-sip-interworking-requirements-00]" and=20 > "Media forking solution for SIP interoperability (without a=20 > media gateway)" >=20 > As far as I can tell there is not yet even a rough consensus.=20 > Therefore I will attempt to summarize what I personally=20 > believe to be the important points and alternatives in this=20 > discussion. Keep in mind that my assumptions or understanding=20 > may be unclear or have errors. So don't hesitate to challenge=20 > what I write. >=20 > I think it is important that there are in fact at least two=20 > important questions here. >=20 > 1. Is forking needed to be supported at all? >=20 > 2. If it is supported in which form would it supported in. >=20 > so lets start looking into the arguments and possibilities=20 > for these two questions. And I do hope that you will read to=20 > the end of this mail which is quite long. >=20 > Lets start with the high level functionality part. Is forking=20 > needed and what usage does it have. So forking is all about=20 > sending out an invitation to a media session including an=20 > actual media configuration offer, i.e. SDP Offer, then get=20 > more than a single answer to that offer back. How you deal=20 > with these answers as they come in is the difference between=20 > serial and parallel forking. So lets define those. >=20 > Parallel forking: For each answer you receive you establish a=20 > new actual media session. Thus if you receive two answers you=20 > will have to different media sessions that are potentially in=20 > use at the same time. >=20 > Serial forking: The first answer is received and results the=20 > establishment of a media session. At a later point in time a=20 > second answer is received. At that point you take the=20 > decision if that second answer is going to be used to=20 > establish a new media session that replaces the first one. In=20 > other words at any given time you will only have a single=20 > media session established based on each offer. >=20 > So there has been a number of different views on how one can=20 > see on forking. And I think I will have to bring in a bit=20 > reflections on how this can be done with the current=20 > PeerConnection API. >=20 > A) No forking is needed: Between WebRTC end-points there is=20 > no need for forking. Instead the application can send out=20 > session invitations to the peers it wants to talk to. These=20 > are without any SDP Offer equivalent, instead end-points that=20 > want to communicate they create PeerConnections, which=20 > results in SDP Offers. Thus the communication initiating=20 > end-point becomes the ones that provides SDP answers and get=20 > one PeerConnection per remote end-point that actually want to=20 > communicate. >=20 > B) We need to have some interworking with SIP: So the=20 > fundamental here is that it needs to be reasonable to=20 > interwork with SIP, independent if one uses a SIP in JS in=20 > the application running on the WebRTC enabled browser, or=20 > have signalling gateway in the webserver, or as a remote=20 > WebRTC peer. The issue is that A)'s method of initiating call=20 > doesn't work well with SIP. There is a need to send a SIP=20 > Invite with an SDP Offer and that can result in multiple answers. >=20 > To resolve this one could deal with this in a couple of=20 > different ways: >=20 > B1) Use I=F1aki's proposal which forces the WebRTC application=20 > to create a second PeerConnection and then forces an update=20 > in the SIP domain with the second peer-connections Offer.=20 > However, it was pointed out that this doesn't work with SIP=20 > Provisional answers, as used by ICE for example, unless PRACK=20 > is supported. The level of PRACK support is reasonable but=20 > far from universal so this would limit the SIP UAs one can=20 > interwork with. However, from WebRTC perspective no forking=20 > support is needed. A single PeerConnection results in one=20 > offer and a single answer is processed. >=20 > B2) Require WebRTC to handle replace Answers: So the idea=20 > here is that one changes the PeerConnection API and have=20 > underlying functionality so that at any point in time a new=20 > Answer can pushed onto a PeerConnection and that forces the=20 > media session to be reestablished if needed. So if the ICE=20 > candidate list is different an ICE restart happens. This=20 > clearly supports serial forking. It also can create some=20 > complexities in the underlying SDP handling logic if one=20 > desires to minimize the media impact. >=20 > B3) Local side shared parameters in multiple PeerConnections:=20 > The idea in this proposal is that all PeerConnections=20 > generated in a browser context, like a tab will implicit=20 > share the fundamental parameters like ICE candidates etc for=20 > the number of media streams added. So if one creates a second=20 > PeerConnection with the same audio+video MediaStream object=20 > added I will get an offer that is mostly identical to the the=20 > first PeerConnection, thus I can push in the answer from the=20 > first PeerConnection Offer into the second PC object and it=20 > will still work. > The downside of this is that it is implicit and it becomes=20 > difficult to determine when it works and when it will fail.=20 > It will also be highly dependent on the application=20 > performing the right process to get it to work. It also=20 > causes a sharing of the parameters when not needed or=20 > desired, which primarily is an issue from a security point of=20 > view, especially with SDES keys (see below). The positive is=20 > this likely requires no API changes. This method would also=20 > support parallel forking. >=20 > B4) Cloning/Factory for PeerConnection: On the API level=20 > there will be explicit support for generating multiple=20 > PeerConnections from the same base. This could either be a=20 > factory for PeerConnections or some Object constructor that=20 > clones an existing PeerConnection but that is a W3C question.=20 > By being explicit some of the B3) issues goes away and the=20 > applications can choose when this should happen or not. This=20 > also support parallel forking as the application can deal=20 > with each media session independently. This clearly will have=20 > some impact on the API. >=20 >=20 > Additional considerations: >=20 > Shared SDES keys: B2 to B4 will result in that SDES keys from=20 > the Offering party to be used towards all invited parties.=20 > This is security risk as any of the invited parties can spoof=20 > the offering side towards any of the other invited parties.=20 > This threat can be resolved by having the inviter rekey=20 > immediately after having received an answer. >=20 > Sharing ICE candidates: B3 and B4 and also B2 to some degree=20 > will share the ICE candidates. That has certain implications.=20 > One is the positive in that it minimizes the resource=20 > consumption as additional PeerConnections come at very little=20 > extra cost, no need for additional ICE gathering candidate=20 > phases, and also be very quick as no external communication=20 > is required. The downside of this is that the end-points=20 > candidates must always be kept alive as long as some=20 > PeerConnection instance exist. Because the browser never=20 > knows when the application may create an additional PC and=20 > expect them to have the same ICE candidates. > It should also be noted that the answering WebRTC end-point=20 > will need to gather candidates for each offer. Otherwise it=20 > will become impossible to create multiple PeerConnections=20 > between the same end-points if that is desired by the application. >=20 >=20 > I know the above doesn't list all of the pro and cons of the=20 > different alternatives. So please fill in additional=20 > arguments. And if I missed some proposal please add that also=20 > if relevant >=20 > As you may have noted I the two questions in the above have=20 > kind of floated together. The reason for this is that I think=20 > the majority are fine with having SIP support as long as it=20 > doesn't have to high cost or complexity associated with it.=20 > Thus, the question how becomes very intertwined with forking=20 > support yes or no. >=20 > So please continue the discussion >=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 pravindran@sonusnet.com Thu Nov 3 04:54:56 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E12411E80E8 for ; Thu, 3 Nov 2011 04:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=-0.036, 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 pMGHoC3nxn04 for ; Thu, 3 Nov 2011 04:54:55 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id C484A11E80D2 for ; Thu, 3 Nov 2011 04:54:55 -0700 (PDT) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA3BtRXf021771; Thu, 3 Nov 2011 07:55:28 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 07:48:42 -0400 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 17:18:46 +0530 Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by inba-hub01.sonusnet.com (10.70.51.86) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 3 Nov 2011 17:18:46 +0530 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.0339.001; Thu, 3 Nov 2011 17:18:44 +0530 From: Ravindran Parthasarathi To: Magnus Westerlund , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Regarding Federation Arguments Thread-Index: AQHMmhOSpaBQnqnn3Ea06PkOYAyRWJWbBmeQ Date: Thu, 3 Nov 2011 11:48:46 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6CD2FA@inba-mail01.sonusnet.com> References: <4EB26D22.5090000@ericsson.com> In-Reply-To: <4EB26D22.5090000@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Nov 2011 11:48:46.0940 (UTC) FILETIME=[8BA451C0:01CC9A1E] Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 11:54:56 -0000 I agree with the consensus that there is no need to mandate any signaling p= rotocol as Federation protocol for WebRTC. Let Federation protocol be SIP o= r Jingle or any signaling protocol for that matter.=20 I'm interested in asking the folks whether WG will be interested to see the= "informational" draft on mapping with WebRTC signaling (ROAP + other mecha= nism) to standard federation protocol like SIP, Jingle. draft-kaplan-rtcweb= -sip-interworking-requirements-00 focus on the interworking with deployed S= IP devices. My proposal is to extend the draft to accommodate other standa= rd federation protocol and also consider the possible other deployment scen= ario. The intention of the draft is to provide the implementation guideline= s for the WebRTC Federation. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Magnus Westerlund >Sent: Thursday, November 03, 2011 4:00 PM >To: rtcweb@ietf.org >Subject: [rtcweb] Regarding Federation Arguments > >WG, > >There has been a number of posts that makes arguments based on >federation and the federation protocol. This is the protocol used >between the webservers, called "Signalling path" in the trappzoid >picture (from draft-ietf-rtcweb-overview-02) below: > > +-----------+ +-----------+ > | Web | | Web | > | | Signalling | | > | |-------------| | > | Server | path | Server | > | | | | > +-----------+ +-----------+ > / \ > / \ Proprietary over > / \ HTTP/Websockets > / \ > / Proprietary over \ > / HTTP/Websockets \ > / \ > +-----------+ +-----------+ > |JS/HTML/CSS| |JS/HTML/CSS| > +-----------+ +-----------+ > +-----------+ +-----------+ > | | | | > | | | | > | Browser | ------------------------- | Browser | > | | Media path | | > | | | | > +-----------+ +-----------+ > > Figure 2: Browser RTC Trapezoid > > >Please consider that the current WG consensus is well captured in the >overview draft: > > If the two Web servers are operated by different entities, the > signalling path needs to be agreed upon, either by standardization or > by other means of agreement; for example, both servers might > implement SIP, and the servers would talk SIP to each other, and each > would translate between the SIP protocol and their proprietary > representation for sending to their application running in the > browser. This part is outside the scope of the RTCWEB standars > suite. > >So, it may be SIP, it doesn't need to be SIP. The important from the >WG's perspective is that is a possible deployment model we intended to >support. It is not the only deployment model. We don't define what is >used on the signalling path and there is freedom here. > >Please consider that when writing arguments so that you don't >misrepresent the current WG consensus or ignore the set of possibilities >that currently are considered. > >If you don't like the WG consensus, then suggest to change it and see if >you get support for it. > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Thu Nov 3 04:56:28 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1C311E80F9 for ; Thu, 3 Nov 2011 04:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 7ppl8ogitFTt for ; Thu, 3 Nov 2011 04:56:27 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id EF42711E8088 for ; Thu, 3 Nov 2011 04:56:26 -0700 (PDT) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA3Bv0dB022725; Thu, 3 Nov 2011 07:57:00 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 07:55:57 -0400 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 17:26:01 +0530 Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by inba-hub01.sonusnet.com (10.70.51.86) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 3 Nov 2011 17:26:01 +0530 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.0339.001; Thu, 3 Nov 2011 17:25:59 +0530 From: Ravindran Parthasarathi To: Harald Alvestrand Thread-Topic: New usecase & requirement for media forking in browser Thread-Index: AQHMl9BWsWD0kT8xzE+tFIa2IMhSLJWWQH+AgAQBaACAAFtrgIAAYp8g Date: Thu, 3 Nov 2011 11:56:00 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6CD31E@inba-mail01.sonusnet.com> References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <387F9047F55E8C42850AD6B3A7A03C6CB953@inba-mail01.sonusnet.com> <4EAEC609.1040707@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6CD0B4@inba-mail01.sonusnet.com> <4EB26EE5.40703@alvestrand.no> In-Reply-To: <4EB26EE5.40703@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Nov 2011 11:56:01.0503 (UTC) FILETIME=[8EA95EF0:01CC9A1F] Cc: "" Subject: Re: [rtcweb] New usecase & requirement for media forking in browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 11:56:28 -0000 Harald, Please read inline. Thanks Partha >-----Original Message----- >From: Harald Alvestrand [mailto:harald@alvestrand.no] >Sent: Thursday, November 03, 2011 4:07 PM >To: Ravindran Parthasarathi >Cc: >Subject: Re: New usecase & requirement for media forking in browser > >On 11/03/2011 12:55 AM, Ravindran Parthasarathi wrote: >> Harald, >> >> Thanks for your clarification. Some of the usecase which comes >immediately to my mind for media forking are as follows: >> >> 1) Whisper call scenario: Telemarketing Agent makes the call to the >customer and the same call is forked to Supervisor for >support/monitoring. Here, Customer will not realize that Supervisor& >Agent has side conversation. >This does not need forking. The caller (the agent) is the one setting up >2 connections. >He will also have to relay media from the customer to the supervisor. >> 2) Remote Recording: The call is forked towards remote peer as well as >recording server. This usecase is already covered in usecase document >Again, this does not need forking. The client creating 2 connections is >the one deciding to do so. I'll take this usecase because it is very common usecase. Client (= browser) is not required to create two connection in this scenario if recor= ding request is going as metadata and WebRTC Server forks the request to re= mote peer and recorder. Please note that client is not required to know the= recorder destination till get the answer. >> 3) Interworking SIP parallel forking with RTCWeb client: >"Because SIP does it" is not an use case. Agree with you as RTCWeb client is not the only way to solve this = interworking usecase. Interworking itself could be the usecase for RTCWeb b= ut it is not as we interested in Freedom world. The point to be noted is th= at SIP parallel forking (media) infrastructure helps for the above two usec= ases as well. >> Please let me know your opinion on addition of this usecase now. >I still do not see an use case from this description. >> Thanks >> Partha >>> -----Original Message----- >>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>> Sent: Monday, October 31, 2011 9:30 PM >>> To: Ravindran Parthasarathi >>> Cc: >>> Subject: Re: New usecase& requirement for media forking in browser >>> >>> On 10/31/2011 06:23 AM, Ravindran Parthasarathi wrote: >>>> Usecase: Media forking in browser >>>> >>>> Description: User forks local stream/stream components to multiple >>> peers simultaneously and able to receive multiple streams from >multiple >>> peers. >>> Ravindran, >>> >>> I see this as an implementation description, and not an use case. >>> >>> Could you rephrase this in terms that make it clear what the user >will >>> be trying to do, and that this technology (forking) is the >appropriate >>> solution for that problem? >>> >>> That will also help uncover more requirements that the use case will >>> imply. For instance, if the idea is that the user talks to multiple >>> persons simultaneously, and they are able to hear each other without >a >>> direct connection to each other, there is an added requirement that >the >>> user be able to mix audio from local and remote sources. >>> >>> Thank you! >>> >>> Harald Alvestrand >>> >>>> Functional requirement: F11, F12, (any new requirement has to be >added >>> ?) >>>> API requirement: The Web API MUST provide means for the web >>> application to initiate sending/receiving of stream/stream components >to >>> a multiple peer simultaneously and relate each of these streams >>> individually by web application. >>>> Having said that, I'm not very sure whether this usecase falls under >>> the category of remote-recording by John. >>>> Hadriel, >>>> >>>> Thanks for the clarification on the current status and practical >>> usecases. >>>> Thanks >>>> Partha >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >>>>> Sent: Saturday, October 29, 2011 1:58 AM >>>>> To: Ravindran Parthasarathi >>>>> Cc: Harald Alvestrand; I=F1aki Baz Castillo; >>>>> Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE:draft-kaplan- >>>>> rtcweb-sip-interworking-requirements-00] >>>>> >>>>> >>>>> We've debated serial and parallel forking a number of times but I >>> don't >>>>> know if there's been consensus. >>>>> >>>>> But your email is really two different questions/topics: >>>>> 1) Is there a use-case for forking within WebRTC? >>>>> 2) Does supporting SIP forking mean the Browser has to handle the >>>>> SDP/media behavior of it, vs. the Web-server/Interworking-function >>>>> handling it? >>>>> >>>>> For the first question, I can certainly envision a Web-app wanting >to >>>>> let Alice press a single button on her Browser and end up >>> communicating >>>>> with Bob no matter where he may be, or letting her single button- >>> press >>>>> end up communicating with Bob first and then Charlie, or letting >her >>>>> single button-press end up communicating with Bob and Charlie at >the >>>>> same time. But I think such things can be accomplished through >>> clever >>>>> Web-app code without needing the Browser to be aware it's a forked >>>>> ROAP/SDP scenario. >>>>> [Note: though this may depend on what W3C decides the user-consent >UI >>>>> model is relative to PeerConnections, MediaStreams and ROAP] >>>>> >>>>> With regards to the second question, there was a long email thread >on >>>>> this which started here I think: >>>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01354.html >>>>> >>>>> -hadriel >>>>> >>>>> >>>>> On Oct 28, 2011, at 3:14 PM, Ravindran Parthasarathi wrote: >>>>> >>>>>> Harald, >>>>>> >>>>>> Thanks for the clarification. "Fedex IVR" usecase is under browser >>> to >>>>> GW/server section (sec 4.3) which is a SIP based forking >requirement. >>> If >>>>> you look at carefully, "Fedex IVR non-final response" scenario >could >>>>> have be achieved cleanly using two separate offer/answer exchange& >>> two >>>>> final responses (INVITE/200/ACK, RE-INVITE/200/ACK) : >>>>>> 1) customer - fedex IVR offer/answer exchange >>>>>> 2) fedex agent - Customer offer/answer exchange >>>>>> >>>>>> but it may be avoided in legacy for billing reasons which should >not >>>>> be major concern for RTCWeb. In case of SIP forking, it is assumed >>> that >>>>> 2nd answer override the 1st answer in the media plane. >>>>>> As I mentioned earlier, SIP (serial) forking requirement shall be >>> met >>>>> by gateway signaling and no extra requirement for browser. Also, >>>>> switching media stream from one responder to other responder in >Fedex >>>>> IVR usecase is not so easy because of legacy media handling (ICE, >>> RTCP) >>>>> differences as mentioned in draft-kaplan-rtcweb-sip-interworking- >>>>> requirements-00. >>>>>> ISTM, we don't have RTCWeb specific forking usecase till now. >>>>>> >>>>>> Thanks >>>>>> Partha >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>>>>>> Sent: Friday, October 28, 2011 11:58 PM >>>>>>> To: Ravindran Parthasarathi >>>>>>> Cc: I=F1aki Baz Castillo; rtcweb@ietf.org; Hadriel Kaplan >>>>>>> Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft- >kaplan- >>>>>>> rtcweb-sip-interworking-requirements-00] >>>>>>> >>>>>>> On 10/28/2011 10:56 AM, Ravindran Parthasarathi wrote: >>>>>>>> By looking at draft-ietf-rtcweb-use-cases-and-requirements-06, I >>>>> could >>>>>>> not see any specific requirement for RTCWeb forking. In case SIP >>>>> forking >>>>>>> is the only requirement for RTCWeb and also, RTCWeb does not have >>> any >>>>>>> specific forking requirement, then the gateway between RTCWeb& >>> SIP >>>>>>> shall take care of the functionality. I'm asking this question to >>> get >>>>>>> the clarity on whether SIP forking feature has to impact RTCWeb >>>>> client >>>>>>> requirement or not. >>>>>>> I believe the "Fedex IVR" case was specifically intended to >surface >>>>> the >>>>>>> requirement for "non-final responses" (switching a media stream >>> from >>>>> the >>>>>>> initial responder to a next responder). >>>>>>> That's one form of forking ("serial fork"?) >>>>>>> >>>>>>> I haven't understood forking to be a requirement in any other use >>>>> case. >> From pravindran@sonusnet.com Thu Nov 3 05:13:29 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC5D1F0C94 for ; Thu, 3 Nov 2011 05:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.334 X-Spam-Level: X-Spam-Status: No, score=-3.334 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_55=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 zG-3UbjLbBJ8 for ; Thu, 3 Nov 2011 05:13:28 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id B80001F0C78 for ; Thu, 3 Nov 2011 05:13:27 -0700 (PDT) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA3CE10K000829; Thu, 3 Nov 2011 08:14:01 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 08:07:30 -0400 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 17:37:35 +0530 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.0339.001; Thu, 3 Nov 2011 17:37:34 +0530 From: Ravindran Parthasarathi To: Christer Holmberg , Magnus Westerlund , "rtcweb@ietf.org" Thread-Topic: [rtcweb] State of the Forking discussion Thread-Index: AQHMmhFGM+ZWxST1zUmltmCZMyiJ6ZWarh2AgABdTYA= Date: Thu, 3 Nov 2011 12:07:34 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6CD335@inba-mail01.sonusnet.com> References: <4EB26945.40607@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A058522359626A5@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522359626A5@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Nov 2011 12:07:35.0143 (UTC) FILETIME=[2C1A6F70:01CC9A21] Subject: Re: [rtcweb] State of the Forking discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 12:13:29 -0000 Hi Magnus, Question #1: Is forking needed to be supported at all? Answer: Yes Question #2: If it is supported in which form would it supported in? I support for B3 or B4 as it covers both serial & parallel for= king. I'm interested in parallel forking because serial forking support is= partial support of forking in terms of SIP (RFC 3261) which may leads to i= nterop issue and also, it is always possible to get 2 18x response with dif= ferent to-tag and different SDP answers while interworking with SIP (2 dial= ogs with 2 different offer/answer pair at this stage) and 200 may came any = one of the remote (first or second). Also, WebRTC forking infrastructure sh= all be used for other services as mentioned in http://www.ietf.org/mail-arc= hive/web/rtcweb/current/msg02516.html.=20 =20 Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Christer Holmberg >Sent: Thursday, November 03, 2011 5:24 PM >To: Magnus Westerlund; rtcweb@ietf.org >Subject: Re: [rtcweb] State of the Forking discussion > > >Hi Magnus, > > > >Question #1: Is forking needed to be supported at all? > >Answer: Yes > > >Question #2: If it is supported in which form would it supported in? > >Answer: Serial (ie one "active" media session at any given time) >forking is enough. > > Solution B2, B3 or B4 - whatever is possible and least >complex from a PeerConnection perspective :) > > >Regards, > >Christer > > > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Magnus Westerlund >> Sent: 3. marraskuuta 2011 12:13 >> To: rtcweb@ietf.org >> Subject: [rtcweb] State of the Forking discussion >> >> WG, >> >> I just reviewed the last weeks Forking discussion. This >> includes the threads "RTCWeb Forking usecase [was RE: >> draft-kaplan-rtcweb-sip-interworking-requirements-00]" and >> "Media forking solution for SIP interoperability (without a >> media gateway)" >> >> As far as I can tell there is not yet even a rough consensus. >> Therefore I will attempt to summarize what I personally >> believe to be the important points and alternatives in this >> discussion. Keep in mind that my assumptions or understanding >> may be unclear or have errors. So don't hesitate to challenge >> what I write. >> >> I think it is important that there are in fact at least two >> important questions here. >> >> 1. Is forking needed to be supported at all? >> >> 2. If it is supported in which form would it supported in. >> >> so lets start looking into the arguments and possibilities >> for these two questions. And I do hope that you will read to >> the end of this mail which is quite long. >> >> Lets start with the high level functionality part. Is forking >> needed and what usage does it have. So forking is all about >> sending out an invitation to a media session including an >> actual media configuration offer, i.e. SDP Offer, then get >> more than a single answer to that offer back. How you deal >> with these answers as they come in is the difference between >> serial and parallel forking. So lets define those. >> >> Parallel forking: For each answer you receive you establish a >> new actual media session. Thus if you receive two answers you >> will have to different media sessions that are potentially in >> use at the same time. >> >> Serial forking: The first answer is received and results the >> establishment of a media session. At a later point in time a >> second answer is received. At that point you take the >> decision if that second answer is going to be used to >> establish a new media session that replaces the first one. In >> other words at any given time you will only have a single >> media session established based on each offer. >> >> So there has been a number of different views on how one can >> see on forking. And I think I will have to bring in a bit >> reflections on how this can be done with the current >> PeerConnection API. >> >> A) No forking is needed: Between WebRTC end-points there is >> no need for forking. Instead the application can send out >> session invitations to the peers it wants to talk to. These >> are without any SDP Offer equivalent, instead end-points that >> want to communicate they create PeerConnections, which >> results in SDP Offers. Thus the communication initiating >> end-point becomes the ones that provides SDP answers and get >> one PeerConnection per remote end-point that actually want to >> communicate. >> >> B) We need to have some interworking with SIP: So the >> fundamental here is that it needs to be reasonable to >> interwork with SIP, independent if one uses a SIP in JS in >> the application running on the WebRTC enabled browser, or >> have signalling gateway in the webserver, or as a remote >> WebRTC peer. The issue is that A)'s method of initiating call >> doesn't work well with SIP. There is a need to send a SIP >> Invite with an SDP Offer and that can result in multiple answers. >> >> To resolve this one could deal with this in a couple of >> different ways: >> >> B1) Use I=F1aki's proposal which forces the WebRTC application >> to create a second PeerConnection and then forces an update >> in the SIP domain with the second peer-connections Offer. >> However, it was pointed out that this doesn't work with SIP >> Provisional answers, as used by ICE for example, unless PRACK >> is supported. The level of PRACK support is reasonable but >> far from universal so this would limit the SIP UAs one can >> interwork with. However, from WebRTC perspective no forking >> support is needed. A single PeerConnection results in one >> offer and a single answer is processed. >> >> B2) Require WebRTC to handle replace Answers: So the idea >> here is that one changes the PeerConnection API and have >> underlying functionality so that at any point in time a new >> Answer can pushed onto a PeerConnection and that forces the >> media session to be reestablished if needed. So if the ICE >> candidate list is different an ICE restart happens. This >> clearly supports serial forking. It also can create some >> complexities in the underlying SDP handling logic if one >> desires to minimize the media impact. >> >> B3) Local side shared parameters in multiple PeerConnections: >> The idea in this proposal is that all PeerConnections >> generated in a browser context, like a tab will implicit >> share the fundamental parameters like ICE candidates etc for >> the number of media streams added. So if one creates a second >> PeerConnection with the same audio+video MediaStream object >> added I will get an offer that is mostly identical to the the >> first PeerConnection, thus I can push in the answer from the >> first PeerConnection Offer into the second PC object and it >> will still work. >> The downside of this is that it is implicit and it becomes >> difficult to determine when it works and when it will fail. >> It will also be highly dependent on the application >> performing the right process to get it to work. It also >> causes a sharing of the parameters when not needed or >> desired, which primarily is an issue from a security point of >> view, especially with SDES keys (see below). The positive is >> this likely requires no API changes. This method would also >> support parallel forking. >> >> B4) Cloning/Factory for PeerConnection: On the API level >> there will be explicit support for generating multiple >> PeerConnections from the same base. This could either be a >> factory for PeerConnections or some Object constructor that >> clones an existing PeerConnection but that is a W3C question. >> By being explicit some of the B3) issues goes away and the >> applications can choose when this should happen or not. This >> also support parallel forking as the application can deal >> with each media session independently. This clearly will have >> some impact on the API. >> >> >> Additional considerations: >> >> Shared SDES keys: B2 to B4 will result in that SDES keys from >> the Offering party to be used towards all invited parties. >> This is security risk as any of the invited parties can spoof >> the offering side towards any of the other invited parties. >> This threat can be resolved by having the inviter rekey >> immediately after having received an answer. >> >> Sharing ICE candidates: B3 and B4 and also B2 to some degree >> will share the ICE candidates. That has certain implications. >> One is the positive in that it minimizes the resource >> consumption as additional PeerConnections come at very little >> extra cost, no need for additional ICE gathering candidate >> phases, and also be very quick as no external communication >> is required. The downside of this is that the end-points >> candidates must always be kept alive as long as some >> PeerConnection instance exist. Because the browser never >> knows when the application may create an additional PC and >> expect them to have the same ICE candidates. >> It should also be noted that the answering WebRTC end-point >> will need to gather candidates for each offer. Otherwise it >> will become impossible to create multiple PeerConnections >> between the same end-points if that is desired by the application. >> >> >> I know the above doesn't list all of the pro and cons of the >> different alternatives. So please fill in additional >> arguments. And if I missed some proposal please add that also >> if relevant >> >> As you may have noted I the two questions in the above have >> kind of floated together. The reason for this is that I think >> the majority are fine with having SIP support as long as it >> doesn't have to high cost or complexity associated with it. >> Thus, the question how becomes very intertwined with forking >> support yes or no. >> >> So please continue the discussion >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Thu Nov 3 05:27:42 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891991F0C61 for ; Thu, 3 Nov 2011 05:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, 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 Nax3uXOIJr1X for ; Thu, 3 Nov 2011 05:27: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 DB0111F0C5F for ; Thu, 3 Nov 2011 05:27:41 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so1210547vcb.31 for ; Thu, 03 Nov 2011 05:27:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.205.198 with SMTP id fr6mr692719vcb.138.1320323259488; Thu, 03 Nov 2011 05:27:39 -0700 (PDT) Received: by 10.220.107.206 with HTTP; Thu, 3 Nov 2011 05:27:39 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6CD335@inba-mail01.sonusnet.com> References: <4EB26945.40607@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A058522359626A5@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6CD335@inba-mail01.sonusnet.com> Date: Thu, 3 Nov 2011 13:27:39 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Ravindran Parthasarathi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] State of the Forking discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 12:27:42 -0000 2011/11/3 Ravindran Parthasarathi : > Question #2: If it is supported in which form would it supported in? > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I support for B3 or B4 as it co= vers both serial & parallel forking. >=C2=A0I'm interested in parallel forking because serial forking support is= partial support of forking in terms of SIP (RFC 3261) which may leads to i= nterop issue and also, it is always possible to get 2 18x response with dif= ferent to-tag and different SDP answers while interworking with SIP (2 dial= ogs with 2 different offer/answer pair at this stage) Right. But note however that most of the SIP devices just choose a single media session and render that to the human (regardless there could be N sessions due to multiple 18X with different Totag and SDPs). So I don't consider this a very important limitation as the very same occurs in 99% of SIP phones. > and 200 may came any one of the remote (first or second). Yes, but that is not parallel forking, it's serial forking. For this last case we don't require WebRTC to support media parallel forking, but just the hability to *replace* the media information of the remote peer with a new one (the SDP in 200) by reusing the same local PeerConnection. So this is case B2 above, and not B3 or B4. > Also, WebRTC forking infrastructure shall be used for other services as m= entioned in http://www.ietf.org/mail-archive/web/rtcweb/current/msg02516.ht= ml. You already received a reply in that thread. The use cases you describe there don't require media-forking. Instead they require N media streams from different PeerConnections in local side. Then we can discuss about the need (or not) for mixing different streams in the browser (like a 3-Way-Call in legacy telephony), but that is not about media forking at all. Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Thu Nov 3 05:28:37 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8901F0C70 for ; Thu, 3 Nov 2011 05:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, 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 fl5s9DWz+5LE for ; Thu, 3 Nov 2011 05:28:37 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CE6061F0C61 for ; Thu, 3 Nov 2011 05:28:36 -0700 (PDT) Received: by vws5 with SMTP id 5so1229875vws.31 for ; Thu, 03 Nov 2011 05:28:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.34.100 with SMTP id y4mr9366762vdi.66.1320323316392; Thu, 03 Nov 2011 05:28:36 -0700 (PDT) Received: by 10.220.107.206 with HTTP; Thu, 3 Nov 2011 05:28:36 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6CD2FA@inba-mail01.sonusnet.com> References: <4EB26D22.5090000@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6CD2FA@inba-mail01.sonusnet.com> Date: Thu, 3 Nov 2011 13:28:36 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Ravindran Parthasarathi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 12:28:37 -0000 2011/11/3 Ravindran Parthasarathi : > I agree with the consensus that there is no need to mandate any signaling= protocol as Federation protocol for WebRTC. Do you? I could find ~100 mails from you (including a draft and slides) in which you advocate for the opposite, and not just about the federation protocol, but also about mandating the in-the-wire protocol in browser to server communication. So I celebrate you agree now with the consensus :) > Let Federation protocol be SIP or Jingle or any signaling protocol for th= at matter. > > I'm interested in asking the folks whether WG will be interested to see t= he "informational" draft on mapping with WebRTC signaling (ROAP + other mec= hanism) to standard federation protocol like SIP, Jingle. draft-kaplan-rtcw= eb-sip-interworking-requirements-00 focus on the interworking with deployed= SIP devices. My proposal is to extend the draft to =C2=A0accommodate other= standard federation protocol and also consider the possible other deployme= nt scenario. The intention of the draft is to provide the implementation gu= idelines for the WebRTC Federation. IMHO given that the consensus is not to define browser-to-server nor server-to-server protocols, we should focus on remaining items rather than spending time in informational topics. Or at least, I would wait until remaining items are more defined (it could help in the document you have in mind). Of course you are free to write it whenever you want. Regards. --=20 I=C3=B1aki Baz Castillo From randell-ietf@jesup.org Thu Nov 3 05:52:36 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0325C11E8105 for ; Thu, 3 Nov 2011 05:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 YqSa5p8qex7u for ; Thu, 3 Nov 2011 05:52:34 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB5D11E80FC for ; Thu, 3 Nov 2011 05:52:34 -0700 (PDT) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RLwmX-00010Q-5R for rtcweb@ietf.org; Thu, 03 Nov 2011 07:52:33 -0500 Message-ID: <4EB28E7B.7020004@jesup.org> Date: Thu, 03 Nov 2011 08:52:11 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com> <4EB1840D.6070405@jesup.org> <387F9047F55E8C42850AD6B3A7A03C6CD0F1@inba-mail01.sonusnet.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] Usecases for innovation. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 12:52:36 -0000 On 11/3/2011 4:18 AM, Wolfgang Beck wrote: > On Thu, Nov 3, 2011 at 2:12 AM, Ravindran Parthasarathi >> Thanks to Randell for sharing his experience and burning issue in WebRTC. I understand that security& privacy should >> be the main focus of this WG. > We have less security issues if both parties are using the same > server. With trapezoid style interconnection/federation security > relevant information can get lost. You can get into transit scenarios > where all your signaling is routed through providers that you don't > know. If Facebook or Google became big hubs to interconnect small > RTCWEB providers, how would they use this signaling information? The security and privacy issues I was referring to were mostly regarding the user interface and evil JS apps, not trapezoid security "plumbing" issues. -- Randell Jesup randell-ietf@jesup.org From HKaplan@acmepacket.com Thu Nov 3 06:03:23 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C547211E80D2 for ; Thu, 3 Nov 2011 06:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YD5yKRfdq0y4 for ; Thu, 3 Nov 2011 06:03:23 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4483211E808E for ; Thu, 3 Nov 2011 06:03:22 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 3 Nov 2011 09:03:21 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 3 Nov 2011 09:03:21 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] State of the Forking discussion Thread-Index: AQHMmij22NouMyfKS02Wa+lc/LFVrA== Date: Thu, 3 Nov 2011 13:03:20 +0000 Message-ID: References: <4EB26945.40607@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A058522359626A5@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6CD335@inba-mail01.sonusnet.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="iso-8859-1" Content-ID: <8BD4A6E21FCDFF4492D96950E6C4E5B9@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] State of the Forking discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 13:03:23 -0000 On Nov 3, 2011, at 8:27 AM, I=F1aki Baz Castillo wrote: > Right. But note however that most of the SIP devices just choose a > single media session and render that to the human (regardless there > could be N sessions due to multiple 18X with different Totag and > SDPs). So I don't consider this a very important limitation as the > very same occurs in 99% of SIP phones. >=20 Yes but what's cool is that browsers are a platform type that could actuall= y render two streams at the same time: per the current requirements, the br= owser can mix incoming audio streams and display separate videos, and send = out the same audio/video to multiple peers - so parallel forking could actu= ally really work well for in WebRTC as compared to SIP. :) But anyway as we keep saying, we don't need native forking ability in the b= rowser for WebRTC's sake, since it can all be done with app code - the main= benefit to having it is to federate/interop with SIP more easily/sanely. How hard is it to put in the browsers? Has W3C given any input on this? -hadriel From christer.holmberg@ericsson.com Thu Nov 3 06:07:51 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A992211E80AC for ; Thu, 3 Nov 2011 06:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.154 X-Spam-Level: X-Spam-Status: No, score=-6.154 tagged_above=-999 required=5 tests=[AWL=0.145, 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 yItJiYFM-Da4 for ; Thu, 3 Nov 2011 06:07:51 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E5B5321F913C for ; Thu, 3 Nov 2011 06:07:50 -0700 (PDT) X-AuditID: c1b4fb39-b7cb2ae000001bd8-1e-4eb29213abdc Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D7.60.07128.31292BE4; Thu, 3 Nov 2011 14:07:31 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 3 Nov 2011 14:07:13 +0100 From: Christer Holmberg To: Hadriel Kaplan , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Thu, 3 Nov 2011 14:07:11 +0100 Thread-Topic: [rtcweb] State of the Forking discussion Thread-Index: AQHMmij22NouMyfKS02Wa+lc/LFVrJWbHmug Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852235962787@ESESSCMS0356.eemea.ericsson.se> References: <4EB26945.40607@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A058522359626A5@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6CD335@inba-mail01.sonusnet.com> 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== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] State of the Forking discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 13:07:51 -0000 I thought we were asked to answer Magnus's questions - not to argue each ot= hers answers :) Regards, Christer=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 3. marraskuuta 2011 15:03 > To: I=F1aki Baz Castillo > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] State of the Forking discussion >=20 >=20 > On Nov 3, 2011, at 8:27 AM, I=F1aki Baz Castillo wrote: >=20 > > Right. But note however that most of the SIP devices just choose a=20 > > single media session and render that to the human (regardless there=20 > > could be N sessions due to multiple 18X with different Totag and=20 > > SDPs). So I don't consider this a very important limitation as the=20 > > very same occurs in 99% of SIP phones. > >=20 >=20 > Yes but what's cool is that browsers are a platform type that=20 > could actually render two streams at the same time: per the=20 > current requirements, the browser can mix incoming audio=20 > streams and display separate videos, and send out the same=20 > audio/video to multiple peers - so parallel forking could=20 > actually really work well for in WebRTC as compared to SIP. :) >=20 > But anyway as we keep saying, we don't need native forking=20 > ability in the browser for WebRTC's sake, since it can all be=20 > done with app code - the main benefit to having it is to=20 > federate/interop with SIP more easily/sanely. >=20 > How hard is it to put in the browsers? Has W3C given any=20 > input on this? >=20 > -hadriel >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From magnus.westerlund@ericsson.com Thu Nov 3 06:09:35 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA91211E80F4 for ; Thu, 3 Nov 2011 06:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 RqJFeNND1bTk for ; Thu, 3 Nov 2011 06:09:34 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5A36D11E80AC for ; Thu, 3 Nov 2011 06:09:34 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-ba-4eb2928afe30 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7E.DA.13753.A8292BE4; Thu, 3 Nov 2011 14:09:30 +0100 (CET) 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.137.0; Thu, 3 Nov 2011 14:09:10 +0100 Message-ID: <4EB29275.8000204@ericsson.com> Date: Thu, 3 Nov 2011 14:09:09 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Randell Jesup References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> <4EB21DEF.5060606@jesup.org> In-Reply-To: <4EB21DEF.5060606@jesup.org> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Michael Tuexen , "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 13:09:35 -0000 On 2011-11-03 05:51, Randell Jesup wrote: > On 11/2/2011 9:12 PM, Michael Thornburgh wrote: >> o as you point out in section 5.3, running SCTP over DTLS, rather >> than DTLS over SCTP, is desired so that all SCTP fields, not just >> the user data, are secured. however, this configuration is >> currently not defined by IETF and would have to be specified. > > > Ok - though conceptually SCTP should be able to run over anything > presenting a UDP-like interface. There are some fallouts, like no > multi-homing. Can some others here (Magnus?) with better > understanding of the exact RFC requirements state if it would be > acceptable to reference a SCTP-over-DTLS draft, which should be > fairly straightforward to create and move forward? It is fine for this WG to request publication of a document with normative references to internet drafts. What really happens is two things. First we WG chairs + AD needs to determine if it is reasonable to request publication without the normative reference being ready. That depends on how clean the separation is. Secondly even if IESG approves our document, the RFC can't be published until that draft also is approved and ready to be published. This is fairly common and if you look at the RFC-editors home page they have this clusters for documents that await publication due to the normative reference not being ready. When it comes to the actual usage of either of IP/UDP/SCTP/DTLS and IP/UDP/DTLS/SCTP we have the same two dependencies on other WGs. First we need a SCTP over foo document, which is TSVWG. The SCTP over UDP is already an WG document and making some progress. For SCTP over DTLS there would be need for a new document, or possibly get that defined in the same as SCTP over UDP directly. Secondly if one uses SDP one needs a definition of how one expresses this on the media description line. That includes the "proto" identifier itself and any additional information, like direction for establishing the connection which would be similar to what COMEDIA defines for TCP (RFC 4145). >From a time perspective IP/UDP/SCTP/DTLS is the quicker road as the SCTP over UDP is already in progress and DTLS over SCTP is defined. So what exist here is really: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ https://datatracker.ietf.org/doc/rfc6083/ (DTLS over SCTP) https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps/ > > In response I have to say: put a protocol proposal on the table or > gather a group to do so, and do so ASAP, because if we don't get an > alternative, it *will* be either SCTP/DTLS/(ICE/UDP) or > pseudo-TCP/DTLS/(ICE/UDP), and I don't know what we'd do for the > unreliable congestion-controlled channels (maybe DCCP). Personally view: I think the choice will be between either DTLS/SCTP/UDP or SCTP/DTLS/UDP and TCP/UDP + DCCP/UDP > > If you do put forward a proposal, do you really believe it can be > done, standardized, agreed to and implemented in the timeframe > required? Specifying SCTP/DTLS seems relatively straightforward > compared to standardizing a new protocol... The timeframe for this > is quite constrained already; one of the strongest arguments against > SCTP would also be timeframe, except that SCTP gives us > congestion-controlled unreliable data, which pseudo-TCP-over-DTLS > doesn't - we'd have to use yet another unspecified mechanism for > congestion control of the unreliable data channels. > I personally don't think think this can be done in short time frames within the IETF. The reason is that IETF will have to do the following to get this going and in the end produce an RFC: 1. Write a Charter proposal for a WG in TSV. 2. Have a BOF on the need for creating a new transport protocol 3. Take in all the additional views from other proponents of transport protocol evolution. I think that means combing Structure Streams with SCTP + DCCP to build a new swiss army knife of a protocol 4. Agree on the new charter 5. Send it to IESG for approval 6. Have the IETF last call and deal with the comments. 7. Finally having a WG 8. Do a requirements phase 9. Design the new protocol in a committee 10. Have the new protocol receive wide review from OPS, Sec etc. 11. Improve spec by having N meeting cycles go by. 12. WG last call 13. IETF last call 14. IESG approval 15. RFC editor 16. RFC publication Just the required process steps in the above is on the order of 3 months. My guess is that even if interest in this holds it is 3-4 years before IETF can conclude on a new transport protocol. 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 randell-ietf@jesup.org Thu Nov 3 07:31:01 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D92111E80B4 for ; Thu, 3 Nov 2011 07:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 GvPWawM0J-Tt for ; Thu, 3 Nov 2011 07:31:00 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id D201F11E80A4 for ; Thu, 3 Nov 2011 07:31:00 -0700 (PDT) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RLyJo-0004JB-Em for rtcweb@ietf.org; Thu, 03 Nov 2011 09:31:00 -0500 Message-ID: <4EB2A58E.1040000@jesup.org> Date: Thu, 03 Nov 2011 10:30:38 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4EB26945.40607@ericsson.com> In-Reply-To: <4EB26945.40607@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] State of the Forking discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 14:31:01 -0000 On 11/3/2011 6:13 AM, Magnus Westerlund wrote: > I think it is important that there are in fact at least two important > questions here. > > 1. Is forking needed to be supported at all? Yes. > 2. If it is supported in which form would it supported in. B4, but I disagree with the assertion that the driving force should be SIP interop (though that's a positive aspect). I've mentioned before non-SIP uses of WebRTC that require forking, and where parallel forking would be preferable (see, Wolfgang/Hadriel/Michael - non-SIP-related reasons!) ;-) 1) mesh conference You send an offer to the server (say to invite my-work-group to chat). The server forwards the OFFER to each member of my-work-group. Each member who answers both accepts your offer, and sends their own offer to the server to be mirrored to the other members of my-work-group. Note that in this case the app (interacting with the server) is cognizant of the mesh conference state, which active offers are from members of the mesh, etc. Without forking this would require many more offers to be generated. I think parallel forking would make it faster and easier for an application developer to implement architectures like this. Also (IMPORTANT): would generation of "new" offers require separate user consent for security? How would rtcweb distinguish between that and a totally different call to another destination? 2) games In games (or virtual "3d space" conferences where locality comes into play) you might have a "hanging" offer with the server used to connect you to another player when the radio you, or come close to you, etc. Again the speed and consent issues come into play, plus the ease of use for the application writer. There are more, I'm just recounting some I'd already mentioned. > Additional considerations: > > Shared SDES keys: B2 to B4 will result in that SDES keys from the > Offering party to be used towards all invited parties. This is security > risk as any of the invited parties can spoof the offering side towards > any of the other invited parties. This threat can be resolved by having > the inviter rekey immediately after having received an answer. I'm on record as seriously disliking SDES, but if it's used that would be a way to resolve it before media is allowed to flow. -- Randell Jesup randell-ietf@jesup.org From wolfgang.beck01@googlemail.com Thu Nov 3 08:38:32 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93AF11E80D2 for ; Thu, 3 Nov 2011 08:38:32 -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.102, 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 W+SNOxgJSdAE for ; Thu, 3 Nov 2011 08:38:31 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD1311E80CD for ; Thu, 3 Nov 2011 08:38:31 -0700 (PDT) Received: by faas12 with SMTP id s12so2022658faa.31 for ; Thu, 03 Nov 2011 08:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n2gKFdLXcKy2JHXUOsVV6EgcABM/OalShhMi4ywBmXk=; b=QXnC7g0EuyPwI4zlc92TMUhlDsVBZ0MGZ6FS5fUjRSKSCVu/CKOWEr7sCp7GZw4+oj J4ijOt+57UfkY5wB3fTaBWIJLdL7QiACDbS0Wlvq0BG+FYYqcdRtRgLVKfZEJvDdPNuz 0uB5cTHMEAjNSK7LsjoxYvKNz+lO7rr3upArc= MIME-Version: 1.0 Received: by 10.223.63.206 with SMTP id c14mr16911014fai.3.1320334528643; Thu, 03 Nov 2011 08:35:28 -0700 (PDT) Received: by 10.152.18.197 with HTTP; Thu, 3 Nov 2011 08:35:28 -0700 (PDT) In-Reply-To: References: <4EB26D22.5090000@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6CD2FA@inba-mail01.sonusnet.com> Date: Thu, 3 Nov 2011 16:35:28 +0100 Message-ID: From: Wolfgang Beck To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 15:38:32 -0000 The trapezoid federation model has important drawbacks: - The server-to-server protocol can be too simple: if it doesn't cover you requirements, you have to wait for standardization. If your requirement is too specific, it will never be standardized. - The server-to-server protocol can be too complex: your application may not need feature x of the protocol (eg forking, early media), but your software still has to support the complexities associated with it. The server-to-server protocol determines the complexity of the server or JS client. You can let the server translate the server-to-server protocol into something simpler or let the JS client deal with it. But you can't escape the protocol's complexity. - The server-to-server protocol can even be too simple *and* too complex at the same time: you don't need feature x's complexities, but you desperately need feature z. Which is not covered by the standard. - If there are many providers, the number of server-to-server relationships -- which are trust relationships -- become unmanageable. It's quite possible that hubs will emerge to which smaller providers connect. The hub needs to see all signaling traffic. We're not talking about a tightly controlled hub in a walled garden, but about Internet giants who have a commercial interest in profiling user behavior. Of course, identity providers in the model described in draft-beck-rtcweb-alt-ic-00 can profile their users, too. They get less information, though. With client certificates, only the called RTCWEB provider knows about a call. Wolfgang Beck From randell-ietf@jesup.org Thu Nov 3 08:41:43 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F6011E80D4 for ; Thu, 3 Nov 2011 08:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 eo0g2l6-BU5E for ; Thu, 3 Nov 2011 08:41:40 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 1376011E80D2 for ; Thu, 3 Nov 2011 08:41:40 -0700 (PDT) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RLzQB-0005NA-NO for rtcweb@ietf.org; Thu, 03 Nov 2011 10:41:39 -0500 Message-ID: <4EB2B61D.1010000@jesup.org> Date: Thu, 03 Nov 2011 11:41:17 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> <4EB21DEF.5060606@jesup.org> <4EB29275.8000204@ericsson.com> In-Reply-To: <4EB29275.8000204@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] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 15:41:43 -0000 On 11/3/2011 9:09 AM, Magnus Westerlund wrote: > When it comes to the actual usage of either of IP/UDP/SCTP/DTLS and > IP/UDP/DTLS/SCTP we have the same two dependencies on other WGs. > > First we need a SCTP over foo document, which is TSVWG. The SCTP over > UDP is already an WG document and making some progress. For SCTP over > DTLS there would be need for a new document, or possibly get that > defined in the same as SCTP over UDP directly. > > Secondly if one uses SDP one needs a definition of how one expresses > this on the media description line. That includes the "proto" identifier > itself and any additional information, like direction for establishing > the connection which would be similar to what COMEDIA defines for TCP > (RFC 4145). We probably need to do these in any case (SCTP or not). >> From a time perspective IP/UDP/SCTP/DTLS is the quicker road as the SCTP > over UDP is already in progress and DTLS over SCTP is defined. Right, but that also means we'd need to define reliable stream-like layers on top of DTLS-over-SCTP, deal with large message fragmentation, etc. Perhaps someone with more DTLS-over-SCTP knowledge (Michael, Randy) could detail what the impact would be. (I'll also start reviewing the DTLS-over-SCTP draft.) > So what exist here is really: > > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ > https://datatracker.ietf.org/doc/rfc6083/ (DTLS over SCTP) > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps/ > > >> >> In response I have to say: put a protocol proposal on the table or >> gather a group to do so, and do so ASAP, because if we don't get an >> alternative, it *will* be either SCTP/DTLS/(ICE/UDP) or >> pseudo-TCP/DTLS/(ICE/UDP), and I don't know what we'd do for the >> unreliable congestion-controlled channels (maybe DCCP). > > Personally view: > > I think the choice will be between either > > DTLS/SCTP/UDP or SCTP/DTLS/UDP > > and > > TCP/UDP + DCCP/UDP I agree that this is the fundamental choice, barring some surprise. There is one other option, though I would vote against it and I doubt anyone really wants it: drop internal data streams and require use of websockets for data (and that means no unreliable streams, which severely crimps real-time data use). Sometimes it seems like it would be easier to rubber-stamp (document if you prefer) an existing protocol design done outside the standards process than to develop one inside of it, which is a problem, but not one we'll solve here. Realize that if we don't find a solution that works within the standards process, the vendors in question will be forced to implement something that gives the desired functionality in the timeframe required, and then it would turn into a case of a defacto standard in need of documentation. Obviously I think all here would prefer to avoid that scenario. >> If you do put forward a proposal, do you really believe it can be >> done, standardized, agreed to and implemented in the timeframe >> required? Specifying SCTP/DTLS seems relatively straightforward >> compared to standardizing a new protocol... The timeframe for this >> is quite constrained already; one of the strongest arguments against >> SCTP would also be timeframe, except that SCTP gives us >> congestion-controlled unreliable data, which pseudo-TCP-over-DTLS >> doesn't - we'd have to use yet another unspecified mechanism for >> congestion control of the unreliable data channels. >> > > I personally don't think think this can be done in short time frames > within the IETF. The reason is that IETF will have to do the following > to get this going and in the end produce an RFC: [snip 16 steps] > Just the required process steps in the above is on the order of 3 > months. My guess is that even if interest in this holds it is 3-4 years > before IETF can conclude on a new transport protocol. Even getting to the point where we have a complete enough draft within the IETF is probably a minimum of 2 years (witness OPUS/codec). -- Randell Jesup randell-ietf@jesup.org From saul@ag-projects.com Thu Nov 3 09:27:13 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F205111E809D for ; Thu, 3 Nov 2011 09:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrkiPH83iyKX for ; Thu, 3 Nov 2011 09:27:13 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 79F1A11E8099 for ; Thu, 3 Nov 2011 09:27:13 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 68ECDB01B1; Thu, 3 Nov 2011 17:27:10 +0100 (CET) Received: from [192.168.88.47] (unknown [200.76.96.109]) by mail.sipthor.net (Postfix) with ESMTPSA id 97522B017D; Thu, 3 Nov 2011 17:27:09 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Saul Ibarra Corretge In-Reply-To: <4EB14599.5000509@ericsson.com> Date: Thu, 3 Nov 2011 17:27:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EB14599.5000509@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 16:27:14 -0000 On Nov 2, 2011, at 2:28 PM, Magnus Westerlund wrote: > WG, >=20 > I have gone over the discussion in this thread and the "Does ROAP > mandate the on-the-wire format?" thread. >=20 > =46rom the postings in these threads I think my summary of this would = be: >=20 > There was strong agreement on the need for freedom in the used = signaling > protocol and its transport between the web-app and the servers and = other > web-app instances. This can be proprietary or a standardized protocol > and is only up to the application what suits its needs. >=20 > It is also not required to send ROAP messages end-to-end although that > is intended to be possible. >=20 > As a WG chair, I don't see any need to adopt > draft-sipdoc-rtcweb-open-wire-protocol-00 as a WG document. I think = the > first agreements can most easily be documented in Overview document. >=20 +1. > Does the WG participants think it is necessary to include this in the > use case and requirements document? >=20 I think it would be good, given all the confusion that some terms = created at some point. Cheers, --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From moore@network-heretics.com Sat Oct 29 21:44:26 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6695E21F8487; Sat, 29 Oct 2011 21:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.276 X-Spam-Level: X-Spam-Status: No, score=-3.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 5Y93jmFs3Tj7; Sat, 29 Oct 2011 21:44:25 -0700 (PDT) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 649D721F8486; Sat, 29 Oct 2011 21:44:25 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1E0BA20A70; Sun, 30 Oct 2011 00:44:24 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 30 Oct 2011 00:44:24 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=T0INK1107QFmAjFeBiycaoP3OOs=; b=Dk zNGoC2CH0wBrzNYW/vqJnze8g+YmMKHPd9Z8ttAwiKkPo4DT+58V+XrBBCpM9TdA wBqu0gnGgA1d4KawMimjkQcpbTouY2Oym16//q5Kplq/xNyq7SLvJ5a6/co9LeFV +HyhuyFQ2prE2e5OqAvdp8ts5Ijh3oD7pQHAqJTHY= X-Sasl-enc: Bncb10QD0JjKA1yCoLVL11zmCKxfgGcoXnVksA2Odtzm 1319949863 Received: from [192.168.1.16] (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 900C58E0FB3; Sun, 30 Oct 2011 00:44:22 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Keith Moore In-Reply-To: <4EACD558.1050003@alvestrand.no> Date: Sun, 30 Oct 2011 00:44:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8E6C5B0D-2161-4D14-9BEE-7B41998CDB7E@network-heretics.com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 03 Nov 2011 11:44:02 -0700 Cc: Ned Freed , Keith Moore , "rtcweb@ietf.org" , Behave WG Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 04:44:26 -0000 On Oct 30, 2011, at 12:40 AM, Harald Alvestrand wrote: > On 10/29/2011 04:23 PM, Marc Petit-Huguenin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> On 10/29/2011 03:36 PM, I=F1aki Baz Castillo wrote: >>> 2011/10/29 Harald Alvestrand: >>>> - I do not think it's appropriate to use "turn" and "turns" for = indicating >>>> transport. Polluting the URI namespace with more configuration = parameters in >>>> the form of trailing "s" is a Bad Thing. >>> But there should be some way to indicate that a TURN server listens = in >>> TLS, right? >>>=20 >> We should continue this discussion in BEHAVE, but I would like to ask = the OP to >> send a pointer on the RFC or discussion that says that using a = trailing "s" to >> indicate security is a bad thing. > I'll have to forward this question to the apps ADs of a few years ago = about whether there's documentation for it. It does not seem to have = been captured in an RFC that I can find; discussion was in the = ~2000-2005 timeframe. >=20 > The short version, from memory: Doing "s" locks you into one and = exactly one security scheme, and prevents you from saying anything about = the requisite parameters for that scheme, while using AUTH parameters = such as POP or in-band negotiation such as IMAP are much more flexible = approaches. Security schemes change over time as new (presumably better) ones = appear, and vulnerabilities are discovered in old ones. There's = nothing inherently wrong with having a URI scheme end in "s". But it's = a Bad Idea to promote the notion that "s" means "security". Keith From moore@network-heretics.com Mon Oct 31 08:33:37 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF1C21F8CCC; Mon, 31 Oct 2011 08:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv5cnjfPNlkg; Mon, 31 Oct 2011 08:33:36 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id B730121F8CC5; Mon, 31 Oct 2011 08:33:36 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6A398204D7; Mon, 31 Oct 2011 11:33:35 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 31 Oct 2011 11:33:35 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=itF 7j72tstHdMFqPsNEHQk2QR1I=; b=azttSUmT1R5QWOUeOXU+jslierKy3VvbflY 95pOv2tGjTTdMrfNcgyywgI6BusS3JzqKLp3V5dYE/M41yKWNEeT+8XVHrZlDae0 Lf14wo6EodQwzangsz3a4+bpDOlfSRrwS9GgwqJjK4QT7Xn/7M3tkz8Kx6IGMYzf XL2b1ujo= X-Sasl-enc: 5Pbm0ts8nT6g6zyZoQRs/TQZWuNTTrH/y3AKdafZ+X3z 1320075215 Received: from rlmartin.hq.corp.pbs.org (unknown [149.48.225.2]) by mail.messagingengine.com (Postfix) with ESMTPA id 040F8483432; Mon, 31 Oct 2011 11:33:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-32-318113624 From: Keith Moore In-Reply-To: <4EAEB76B.9090304@acm.org> Date: Mon, 31 Oct 2011 11:33:33 -0400 Message-Id: <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 03 Nov 2011 11:44:02 -0700 Cc: Ned Freed , Keith Moore , Behave WG , "rtcweb@ietf.org" Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 15:33:37 -0000 --Apple-Mail-32-318113624 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 31, 2011, at 10:57 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi Martin, >=20 > So I understand Roy's email as saying in fact the opposite of what = Harald said, > i.e. that using an "s" suffix to signify security is a good thing. >=20 > What is your opinion on defining a generic scheme suffix (i.e. "+s" or = "+sec") > that would indicate a well defined set of security properties that = could apply > to any scheme, (vs the current "s" suffix where security properties = has to be > defined scheme by scheme)? There is no "well defined set of security properties that could apply to = any scheme". Security properties necessarily vary depending on the way = a resource is used, the threat model, and so forth.=20 Also, the idea that there should be a "secure" bit in a URI scheme, to = distinguish it from the "insecure" form of a URL, doesn't make much = sense. You always want to use the best security that's available. You = don't want that to depend on the URI scheme. =20 The "s" convention was a hack to distinguish "x over SSL" from "x" for = all of the URIs that existed before SSL was well-established, because = those protocols didn't (then) have a way to negotiate security in-band. = It made sense as a short term hack, but not as an architectural = feature. It's not something that we want to propagate to new URI = types, neither in the form of an "s" suffix, nor as any other syntactic = convention. Keith --Apple-Mail-32-318113624 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
-----BEGIN PGP SIGNED MESSAGE-----
Hash: = SHA1

Hi Martin,

So I understand Roy's email as saying in = fact the opposite of what Harald said,
i.e. that using an "s" suffix = to signify security is a good thing.

What is your opinion on = defining a generic scheme suffix (i.e. "+s" or "+sec")
that would = indicate a well defined set of security properties that could = apply
to any scheme, (vs the current "s" suffix where security = properties has to be
defined scheme by = scheme)?

There is no = "well defined set of security properties that could apply to any = scheme".   Security properties necessarily vary depending on the = way a resource is used, the threat model, and so = forth. 

Also, the idea that there should = be a "secure" bit in a URI scheme, to distinguish it from the "insecure" = form of a URL, doesn't make much sense.  You always want to = use the best security that's available.  You don't want that to = depend on the URI scheme.  

The "s" = convention was a hack to distinguish "x over SSL" from "x" for all of = the URIs that existed before SSL was well-established, because those = protocols didn't (then) have a way to negotiate security in-band.   = It made sense as a short term hack, but not as an architectural feature. =   It's not something that we want to propagate to new URI types, = neither in the form of an "s" suffix, nor as any other syntactic = convention.

Keith

= --Apple-Mail-32-318113624-- From Cary.Bran@plantronics.com Mon Oct 31 15:23:08 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832A021F8C97 for ; Mon, 31 Oct 2011 15:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_VISITOURSITE=2, 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 pwDUQ9RN8Ezr for ; Mon, 31 Oct 2011 15:23:07 -0700 (PDT) Received: from mail4.plantronics.com (mail4.plantronics.com [12.151.41.50]) by ietfa.amsl.com (Postfix) with ESMTP id 223B321F8BBA for ; Mon, 31 Oct 2011 15:23:06 -0700 (PDT) Received: from usscch03.plt.plantronics.com (usscch03.plt.plantronics.com [10.1.3.26]) by mail4.plantronics.com (8.13.8/8.13.8) with ESMTP id p9VMMs9t010211; Mon, 31 Oct 2011 15:23:06 -0700 Received: from USSCMB03.plt.plantronics.com ([fe80::5824:67c8:930e:7c1e]) by USSCCH03.plt.plantronics.com ([::1]) with mapi id 14.01.0270.001; Mon, 31 Oct 2011 15:23:04 -0700 From: "Bran, Cary" To: "rtcweb-chairs@tools.ietf.org" Thread-Topic: NAT Draft Thread-Index: AcyYGqZu6twKL2kCQ/a6isFMafVCpg== Date: Mon, 31 Oct 2011 22:23:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.1.18] Content-Type: multipart/alternative; boundary="_000_E37C139C5CB78244A781E9E7B721527B54858DUSSCMB03pltplantr_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.67 on 10.63.1.50 X-Mailman-Approved-At: Thu, 03 Nov 2011 11:44:02 -0700 Cc: "rtcweb@ietf.org" Subject: [rtcweb] NAT 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, 31 Oct 2011 22:26:41 -0000 --_000_E37C139C5CB78244A781E9E7B721527B54858DUSSCMB03pltplantr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello WebRTC chairs, I have updated and submitted a 02 version of the WebRTC NAT draft: http://t= ools.ietf.org/id/draft-cbran-rtcweb-nat-02.txt I believe that this draft is representative of areas where the working grou= p has achieved consensus and at this time I would like to ask that the 02 d= raft be adopted as a working group document. I look forward to your feedback. Regards, Cary Bran Senior Director Advanced Software Technology and Architecture Office: +1 831-458-7737 Cell: +1 206-661-2398 Plantronics Simply Smarter Communications(tm) 345 Encinal St., Santa Cruz, CA 95060 ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, p= lease DO NOT disclose the contents to another person, store or copy the inf= ormation in any medium, or use any of the information contained in or attac= hed to this transmission for any purpose. If you have received this transmi= ssion in error, please immediately notify the sender by reply email or at p= rivacy@plantronics.com, and destroy the original transmission and its attac= hments without reading or saving in any manner. For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com. --_000_E37C139C5CB78244A781E9E7B721527B54858DUSSCMB03pltplantr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello WebRTC chairs,

 

I have updated and submitted a 02 version of the Web= RTC NAT draft: http://t= ools.ietf.org/id/draft-cbran-rtcweb-nat-02.txt

 

I believe that this draft is representative of areas= where the working group has achieved consensus and at this time I would li= ke to ask that the 02 draft be adopted as a working group document.

 

I look forward to your feedback.

 

Regards,

 

Cary Bran

Senior Director Advanced Software Technology and A= rchitecture

Office:  +1 831-458-7737   = ;  Cell: +1 206-661-2398

Plantronics  Simply Smarter Commu= nications™

345 Encinal St., Santa Cruz, CA 95060

 



CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the conten= ts to another person, store or copy the information in any medium, or use a= ny of the information contained in or attached to this transmission for any= purpose. If you have received this transmission in error, please immediately notify the sender by reply email= or at privacy@plantronics.com, and destroy the original transmission and i= ts attachments without reading or saving in any manner.

For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com.
 --_000_E37C139C5CB78244A781E9E7B721527B54858DUSSCMB03pltplantr_-- From Cary.Bran@plantronics.com Mon Oct 31 15:26:59 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAD71F0D11 for ; Mon, 31 Oct 2011 15:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.007 X-Spam-Level: X-Spam-Status: No, score=0.007 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, GB_VISITOURSITE=2, 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 t1rpaD1ZJVui for ; Mon, 31 Oct 2011 15:26:55 -0700 (PDT) Received: from mail4.plantronics.com (mail4.plantronics.com [12.151.41.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8D36C1F0D05 for ; Mon, 31 Oct 2011 15:26:55 -0700 (PDT) Received: from usscch03.plt.plantronics.com (usscch03.plt.plantronics.com [10.1.3.26]) by mail4.plantronics.com (8.13.8/8.13.8) with ESMTP id p9VMQto3010916; Mon, 31 Oct 2011 15:26:55 -0700 Received: from USSCMB03.plt.plantronics.com ([fe80::5824:67c8:930e:7c1e]) by USSCCH03.plt.plantronics.com ([::1]) with mapi id 14.01.0270.001; Mon, 31 Oct 2011 15:25:50 -0700 From: "Bran, Cary" To: "rtcweb-chairs@tools.ietf.org" Thread-Topic: Codec Draft Thread-Index: AcyYG7T52+iin6+9RSSZxK1D9q2OmQ== Date: Mon, 31 Oct 2011 22:25:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.1.18] Content-Type: multipart/alternative; boundary="_000_E37C139C5CB78244A781E9E7B721527B5485F6USSCMB03pltplantr_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.67 on 10.63.1.50 X-Mailman-Approved-At: Thu, 03 Nov 2011 11:44:02 -0700 Cc: "rtcweb@ietf.org" Subject: [rtcweb] Codec 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, 31 Oct 2011 22:26:59 -0000 --_000_E37C139C5CB78244A781E9E7B721527B5485F6USSCMB03pltplantr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello WebRTC chairs, I have updated and submitted a 02 version of the WebRTC Codec draft: http:/= /tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt I believe that this draft is representative of areas where the working grou= p has achieved consensus and at this time I would like to ask that the 01 d= raft be adopted as a working group document. I look forward to your feedback. Regards, Cary Bran Senior Director Advanced Software Technology and Architecture Office: +1 831-458-7737 Cell: +1 206-661-2398 Plantronics Simply Smarter Communications(tm) 345 Encinal St., Santa Cruz, CA 95060 ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, p= lease DO NOT disclose the contents to another person, store or copy the inf= ormation in any medium, or use any of the information contained in or attac= hed to this transmission for any purpose. If you have received this transmi= ssion in error, please immediately notify the sender by reply email or at p= rivacy@plantronics.com, and destroy the original transmission and its attac= hments without reading or saving in any manner. For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com. --_000_E37C139C5CB78244A781E9E7B721527B5485F6USSCMB03pltplantr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello WebRTC chairs,

 

I have updated and submitted a 02 version of the Web= RTC Codec draft: http:/= /tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt

 

I believe that this draft is representative of areas= where the working group has achieved consensus and at this time I would li= ke to ask that the 01 draft be adopted as a working group document.

 

I look forward to your feedback.

 

Regards,

 

 

Cary Bran

Senior Director Advanced Software Technology and A= rchitecture

Office:  +1 831-458-7737   = ;  Cell: +1 206-661-2398

Plantronics  Simply Smarter Commu= nications™

345 Encinal St., Santa Cruz, CA 95060

 



CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the conten= ts to another person, store or copy the information in any medium, or use a= ny of the information contained in or attached to this transmission for any= purpose. If you have received this transmission in error, please immediately notify the sender by reply email= or at privacy@plantronics.com, and destroy the original transmission and i= ts attachments without reading or saving in any manner.

For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com.
 --_000_E37C139C5CB78244A781E9E7B721527B5485F6USSCMB03pltplantr_-- From moore@network-heretics.com Tue Nov 1 05:05:37 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9A821F910E; Tue, 1 Nov 2011 05:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.829 X-Spam-Level: X-Spam-Status: No, score=-2.829 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jg3HDksGjLcr; Tue, 1 Nov 2011 05:05:36 -0700 (PDT) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by ietfa.amsl.com (Postfix) with ESMTP id D047921F8C84; Tue, 1 Nov 2011 05:05:36 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 242CA20CC1; Tue, 1 Nov 2011 08:05:30 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute5.internal (MEProxy); Tue, 01 Nov 2011 08:05:30 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=QJpD/cqe2AqoVU846CZIyKUtP9k=; b=Uk dZBL4I3mL3frA5NZ/uFeCQ9Bv2nIKSg5OHuUZd4B2mX0KcQEIVmY2Pquy9k7+xdQ WueYKPs6FKR5dchDQZaJOxCDqUaw5LZD8cBi7hZIyDRZeHd8XOXWJr8+gGj58LDx JeTiUlq6W4G45FgBJKPIaU4H5AE/wOpSxyuGP7qmM= X-Sasl-enc: QunLAAOFjBxZ3TvGL/TWmzHDttDScq/4XPsDjY9Zbreq 1320149129 Received: from [10.59.1.8] (static-71-166-174-114.washdc.east.verizon.net [71.166.174.114]) by mail.messagingengine.com (Postfix) with ESMTPA id 634254834EC; Tue, 1 Nov 2011 08:05:29 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: <4EAF9391.5040209@it.aoyama.ac.jp> Date: Tue, 1 Nov 2011 08:05:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5B7AE760-DBD1-46F9-89D9-E8F7CA56F111@network-heretics.com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Thu, 03 Nov 2011 11:44:02 -0700 Cc: Ned Freed , "rtcweb@ietf.org" , Keith Moore , Behave WG Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 12:05:37 -0000 >> The "s" convention was a hack to distinguish "x over SSL" from "x" = for all of the URIs that existed before SSL was well-established, = because those protocols didn't (then) have a way to negotiate security = in-band. It made sense as a short term hack, >=20 > Yes. It also makes sense in current-day operation. >=20 >> but not as an architectural feature. It's not something that we = want to propagate to new URI types, neither in the form of an "s" = suffix, nor as any other syntactic convention. >=20 > In most cases probably not. But there may be cases similar to HTTP/S = where it makes sense. Each case has to be analyzed independently. agree. I just don't think it's a good idea to establish a new = _convention_. regards, Keith From thp@westhawk.co.uk Thu Oct 27 06:55:36 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B383221F8593 for ; Thu, 27 Oct 2011 06:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em8F6JJklx-J for ; Thu, 27 Oct 2011 06:55:35 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id B71B121F84B6 for ; Thu, 27 Oct 2011 06:55:35 -0700 (PDT) Received: from [10.12.78.125] (64-58-7-107.sta.mho.net [64.58.7.107]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 02CDD37A91E; Thu, 27 Oct 2011 15:08:18 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: Date: Thu, 27 Oct 2011 07:55:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Thu, 03 Nov 2011 11:46:49 -0700 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 13:55:36 -0000 On 27 Oct 2011, at 02:55, I=F1aki Baz Castillo wrote: > 2011/10/25 I=F1aki Baz Castillo : >> A new I-D draft-sipdoc-rtcweb-open-wire-protocol-00.txt has been >> successfully submitted by I=F1aki Baz Castillo, Sa=FAl Ibarra = Corretg=E9 >> and Jos=E9 Luis Mill=E1n Villegas, and posted to the IETF repository. >>=20 >> Filename: draft-sipdoc-rtcweb-open-wire-protocolRevision: >> 00Title: Open In-The-Wire Protocol for RTC-WebCreation >> date: 2011-10-25WG ID: Individual SubmissionNumber of >> pages: 22 >>=20 >>=20 >> http://tools.ietf.org/html/draft-sipdoc-rtcweb-open-wire-protocol-00 >> http://www.ietf.org/id/draft-sipdoc-rtcweb-open-wire-protocol-00.txt >>=20 >>=20 >> Abstract: RTC-Web clients communicate with a server in order to >> request or manage realtime communications with other users. This >> document exposes four hypothetical and different RTC-Web scenarios >> and analyzes the requirements of the in-the-wire protocol in each of >> them. >> The aim of this document is to make RTC-Web properly fit in the >> nature of the Web. >=20 >=20 > Hi, just wondering if somebody has read this informational draft. I'd > would really appreciate if folks agree with the conclusiones and > requirements exposed in the document or want to discuss about them. > The draft tries to clarify the scope of RTC-Web, and IMHO that's an > important milestone before we can move on. >=20 > Thanks a lot. Thank you for writing this up - before I had to ;-) I agree with almost all of it, but I wonder if you could add a derived = requirement: " 4. It MUST be possible for a website developer to make his RTC-Web scenario to interoperate with a pure SIP or XMPP/Jingle network without requiring a signaling protocol gateway (by using SIP over WebSocket [I-D.ibc-rtcweb-sip-websocket] or XMPP over WebSocket [I-D.moffitt-xmpp-over-websocket]). 5. It must be possible for a website developer to make his RTC-Web scenario to interoperate without adding new infrastructure unless = they wish to interop with the wider world - i.e. if the=20 mysite.com example wished to operate as an 'island' they would not need to add additional telephony or expertise=20 servers, as all the neccessary server side work could be done in = php by his existing web programmers. " I think this is implied by your document, but I feel it is critically = important=20 so worth explicitly stating it.=20 Tim. From thp@westhawk.co.uk Thu Oct 27 06:59:37 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C19821F8AF7 for ; Thu, 27 Oct 2011 06:59:37 -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.000, BAYES_00=-2.599, MANGLED_FROM=2.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 7A7LwwV6yvx0 for ; Thu, 27 Oct 2011 06:59:36 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7C821F8ACE for ; Thu, 27 Oct 2011 06:59:36 -0700 (PDT) Received: from [10.12.78.125] (64-58-7-107.sta.mho.net [64.58.7.107]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 685D737A91E; Thu, 27 Oct 2011 15:12:22 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <1D1CC4EE-0002-4638-B42F-760C2D6F29B8@cisco.com> Date: Thu, 27 Oct 2011 07:59:31 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <57C8FC58-879A-49B7-9755-0357A79E8DD1@westhawk.co.uk> References: <1D1CC4EE-0002-4638-B42F-760C2D6F29B8@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Thu, 03 Nov 2011 11:46:49 -0700 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Relationship of ROAP and PeerConnection? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 13:59:37 -0000 On 26 Oct 2011, at 08:41, Cullen Jennings wrote: >=20 > Right now the W3C API and ROAP are way out of sync so it makes it = particularly hard to do the mapping in ones head. Eventually we will = need to sort out which spec defines the JSON object as the string form = of that is the ROAP protocol and also would be passed across the RTCWeb = API. There are arguments either way but I'm sure that we want it defined = one place and the other place to point at it. I think as we get this all = sorted out, it will become relatively clear which document to put the = text in. Right now, I'm just trying to focus on does the idea look like = it is on the right path regardless of which document it is in. The fact = the various specs are so out of sync makes it hard to get ones head = around the whole idea. In the meantime, the ROAP JSON object is = primarily about a concrete instantiation of the abstract RFC 3264 = Offer/Answer protocol and is key to the over the wire ROAP protocol to a = signaling gateway so I think it fairly reasonable to be driving the = discussion fr > om and IETF document vs a W3C one. =46rom W3C API point of view, it is = more of an opaque contain of information used for IETF protocols.=20 Agreed, with the exception that we need the W3C to help specify an API = for the 'Hints' and 'Properties' interfaces that we agreed were required in the last call. Tim. =20= From ekr@rtfm.com Thu Nov 3 12:00:07 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379E911E8132; Thu, 3 Nov 2011 12:00:07 -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 KLpj8djo82ED; Thu, 3 Nov 2011 12:00:06 -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 1B31311E811A; Thu, 3 Nov 2011 12:00:06 -0700 (PDT) Received: by gye5 with SMTP id 5so1881890gye.31 for ; Thu, 03 Nov 2011 12:00:05 -0700 (PDT) Received: by 10.146.124.10 with SMTP id w10mr2115061yac.13.1320346779246; Thu, 03 Nov 2011 11:59:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.232.12 with HTTP; Thu, 3 Nov 2011 11:58:57 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <5B7AE760-DBD1-46F9-89D9-E8F7CA56F111@network-heretics.com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <5B7AE760-DBD1-46F9-89D9-E8F7CA56F111@network-heretics.com> From: Eric Rescorla Date: Thu, 3 Nov 2011 11:58:57 -0700 Message-ID: To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Keith Moore , "rtcweb@ietf.org" , Ned Freed , Behave WG Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 19:00:07 -0000 On Tue, Nov 1, 2011 at 5:05 AM, Keith Moore wr= ote: >> In most cases probably not. But there may be cases similar to HTTP/S whe= re it makes sense. Each case has to be analyzed independently. > > agree. =A0I just don't think it's a good idea to establish a new _convent= ion_. i don't really understand what you're arguing here. The relevant issue is that we want to have a reference that Bob can provide to Alice that guarantees that when it's dereferenced it provides a minimum set of security properties. Let's imagine some hypothetical new protocol which is like HTTP but not HTT= P, say HTTQ. It runs over TCP so you can use it directly or over TLS (i.e., HTTP/TCP or HTTP/TLS/TCP). We're planning to define a new URI for it, httq://.../. How do you propose to provide the above security property? -Ekr From christer.holmberg@ericsson.com Thu Nov 3 12:03:40 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4801F0CBF for ; Thu, 3 Nov 2011 12:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.31 X-Spam-Level: X-Spam-Status: No, score=-5.31 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599, GB_VISITOURSITE=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 SvCGYCQe7fcz for ; Thu, 3 Nov 2011 12:03:40 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1901C1F0CC0 for ; Thu, 3 Nov 2011 12:03:39 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-6e-4eb2e58a97df Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 64.CB.13753.A85E2BE4; Thu, 3 Nov 2011 20:03:38 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 3 Nov 2011 20:03:38 +0100 From: Christer Holmberg To: "'Bran, Cary'" , "rtcweb-chairs@tools.ietf.org" Date: Thu, 3 Nov 2011 20:03:37 +0100 Thread-Topic: NAT Draft Thread-Index: AcyYGqZu6twKL2kCQ/a6isFMafVCpgCPzrzQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852235789600@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] NAT 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: Thu, 03 Nov 2011 19:03:41 -0000 Hi, =20 A couple of questions for clarification. =20 In section 3.3, what does "RTC-Web clients MUST support IPv4 to IPv6 transi= tion." really mean? I think you need to clarify. In section 4.1, can we put requirements on gateways? Maybe we should rather= say that RTCWeb clients shall accept cases where the remote ICE client sup= ports ICE lite, or something like that. Because, there might not even be a = gateway, but a legacy UA that actually supports ICE :) Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Bran, Cary Sent: 1. marraskuuta 2011 0:23 To: rtcweb-chairs@tools.ietf.org Cc: rtcweb@ietf.org Subject: [rtcweb] NAT Draft Hello WebRTC chairs, =20 I have updated and submitted a 02 version of the WebRTC NAT draft: http://t= ools.ietf.org/id/draft-cbran-rtcweb-nat-02.txt =20 I believe that this draft is representative of areas where the working grou= p has achieved consensus and at this time I would like to ask that the 02 d= raft be adopted as a working group document. =20 I look forward to your feedback. =20 Regards, =20 Cary Bran=20 Senior Director Advanced Software Technology and Architecture Office: +1 831-458-7737 Cell: +1 206-661-2398 Plantronics Simply Smarter Communications(tm) 345 Encinal St., Santa Cruz, CA 95060 =20 ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, p= lease DO NOT disclose the contents to another person, store or copy the inf= ormation in any medium, or use any of the information contained in or attac= hed to this transmission for any purpose. If you have received this transmi= ssion in error, please immediately notify the sender by reply email or at p= rivacy@plantronics.com, and destroy the original transmission and its attac= hments without reading or saving in any manner. For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com. From ekr@rtfm.com Thu Nov 3 12:05:17 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148981F0CC9; Thu, 3 Nov 2011 12:05:17 -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 YaurtazNu9Y6; Thu, 3 Nov 2011 12:05:16 -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 6BAD31F0CC6; Thu, 3 Nov 2011 12:05:16 -0700 (PDT) Received: by mail-yw0-f44.google.com with SMTP id 2so1894100ywt.31 for ; Thu, 03 Nov 2011 12:05:16 -0700 (PDT) Received: by 10.100.5.19 with SMTP id 19mr2513483ane.60.1320347110925; Thu, 03 Nov 2011 12:05:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.232.12 with HTTP; Thu, 3 Nov 2011 11:54:13 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <8E6C5B0D-2161-4D14-9BEE-7B41998CDB7E@network-heretics.com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <8E6C5B0D-2161-4D14-9BEE-7B41998CDB7E@network-heretics.com> From: Eric Rescorla Date: Thu, 3 Nov 2011 11:54:13 -0700 Message-ID: To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Keith Moore , Ned Freed , Behave WG , "rtcweb@ietf.org" Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 19:05:17 -0000 On Sat, Oct 29, 2011 at 9:44 PM, Keith Moore w= rote: > > On Oct 30, 2011, at 12:40 AM, Harald Alvestrand wrote: > >> On 10/29/2011 04:23 PM, Marc Petit-Huguenin wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 10/29/2011 03:36 PM, I=F1aki Baz Castillo wrote: >>>> 2011/10/29 Harald Alvestrand: >>>>> - I do not think it's appropriate to use "turn" and "turns" for indic= ating >>>>> transport. Polluting the URI namespace with more configuration parame= ters in >>>>> the form of trailing "s" is a Bad Thing. >>>> But there should be some way to indicate that a TURN server listens in >>>> TLS, right? >>>> >>> We should continue this discussion in BEHAVE, but I would like to ask t= he OP to >>> send a pointer on the RFC or discussion that says that using a trailing= "s" to >>> indicate security is a bad thing. >> I'll have to forward this question to the apps ADs of a few years ago ab= out whether there's documentation for it. It does not seem to have been cap= tured in an RFC that I can find; discussion was in the ~2000-2005 timeframe= . >> >> The short version, from memory: Doing "s" locks you into one and exactly= one security scheme, and prevents you from saying anything about the requi= site parameters for that scheme, while using AUTH parameters such as POP or= in-band negotiation such as IMAP =A0are much more flexible approaches. > > Security schemes change over time as new (presumably better) ones appear,= and vulnerabilities are discovered in old ones. =A0 There's nothing inhere= ntly wrong with having a URI scheme end in "s". =A0But it's a Bad Idea to p= romote the notion that "s" means "security". What the "s" means is "Connect via TLS and check the server cert". People are free to infer whatever they want about the level of "security" provided. -Ekr From christer.holmberg@ericsson.com Thu Nov 3 12:15:41 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06181F0CAF for ; Thu, 3 Nov 2011 12:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 cIbLCfxd2ddO for ; Thu, 3 Nov 2011 12:15:41 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id DA40B1F0CB9 for ; Thu, 3 Nov 2011 12:15:40 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-87-4eb2e858d49e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6B.8C.13753.858E2BE4; Thu, 3 Nov 2011 20:15:36 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 3 Nov 2011 20:15:36 +0100 From: Christer Holmberg To: Christer Holmberg , Cullen Jennings , "rtcweb@ietf.org" , "public-webrtc@w3.org" Date: Thu, 3 Nov 2011 20:15:36 +0100 Thread-Topic: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - seq/sessionId vs sess-version/sess-id (Section 5.2.1 and 5.2.2) Thread-Index: AcyK59ZYlpyUDRxNTFOtHnNrwuQvpADcv2WAAwB6FzA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852235789601@ESESSCMS0356.eemea.ericsson.se> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058522341F4A8B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341F4A8B@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Jonathan Rosenberg Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - seq/sessionId vs sess-version/sess-id (Section 5.2.1 and 5.2.2) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 19:15:41 -0000 Hi Cullen, I am not sure I receied a reply from you (or anyone else) to the questions = below. Regards, Christer=20 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 19. lokakuuta 2011 15:50 To: Cullen Jennings; rtcweb@ietf.org; public-webrtc@w3.org Cc: Jonathan Rosenberg Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - se= q/sessionId vs sess-version/sess-id (Section 5.2.1 and 5.2.2) =20 Hi, What is the relation between the seq/sessionId values and the SDP sess-vers= ion/sess-id values (part of the SDP o=3D line), and why do we need seq/sess= ionId in the first place? AFAIK, the only reason for having the seq/sessionId values is when sending = an OK message, since there will be no SDP (and therefor no SDP sess-version= /sessionId). Or, are there any other reasons? I think the draft should say something about the correlation. And, IF we need seq/sessionId, should we say that the SDP sess-version/sess= -id values must be identical - or, at least saying that they must be set an= d incremented according to the SDP rules? I think that would help in SIP/SD= P interworking cases. Otherwise the interworking gateway will have to check= , keep track of, and possibly modify, the sess-version/sess-id values. Regards, Christer > -----Original Message----- > From: rtcweb-bounces@ietf.org > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: 15. lokakuuta 2011 6:09 > To: rtcweb@ietf.org; public-webrtc@w3.org > Cc: Jonathan Rosenberg > Subject: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling >=20 >=20 > Jonathan and I submitted a new draft on setting up media based on the=20 > SDP Offer/Answer model. The ASCII flows are a bit hard to read so=20 > until I update them, I recommend reading the PDF version at >=20 > http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf >=20 > Clearly the draft is an early stage but we plan to revise it before=20 > the deadline for the IETF 82. Love to get input - particularly on if=20 > this looks like generally the right direction to go. >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Thu Nov 3 12:33:57 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FC61F0CAB for ; Thu, 3 Nov 2011 12:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.305 X-Spam-Level: X-Spam-Status: No, score=-6.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 pvL3SraLHyx1 for ; Thu, 3 Nov 2011 12:33:56 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3535B1F0C3B for ; Thu, 3 Nov 2011 12:33:56 -0700 (PDT) X-AuditID: c1b4fb39-b7cb2ae000001bd8-00-4eb2eca25aa3 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8F.77.07128.2ACE2BE4; Thu, 3 Nov 2011 20:33:55 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 3 Nov 2011 20:33:54 +0100 From: Christer Holmberg To: 'Cullen Jennings' Date: Thu, 3 Nov 2011 20:33:54 +0100 Thread-Topic: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - More-coming and final answer (Section 5.2.3) Thread-Index: AcyOwQK8yjsjgFbmTVywWcPfVlw13QLnF5kg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852235789602@ESESSCMS0356.eemea.ericsson.se> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058522341F4AB9@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Jonathan Rosenberg , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - More-coming and final answer (Section 5.2.3) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 19:33:57 -0000 Hi,=20 >> Q2. Are there restrictions when it comes to changing information in a no= n-final=20 >> answer and a final answer? Or, can the final answer be completely differ= ent from=20 >> previously sent non-final ANSWERS? In "legacy" O/A there are restriction= s. > > Any answer has to be a valid answer for the offer but other than that, no= restrictions,=20 > so the final answer can change everything from an earlier one.=20 Is there a reason/use-case/requirement why we need to allow that? As far as= I know, the reason behind this is ICE. Regards, Christer >> -----Original Message----- >> From: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings >> Sent: 15. lokakuuta 2011 6:09 >> To: rtcweb@ietf.org; public-webrtc@w3.org >> Cc: Jonathan Rosenberg >> Subject: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling >>=20 >>=20 >> Jonathan and I submitted a new draft on setting up media based on the=20 >> SDP Offer/Answer model. The ASCII flows are a bit hard to read so=20 >> until I update them, I recommend reading the PDF version at >>=20 >> http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf >>=20 >> Clearly the draft is an early stage but we plan to revise it before=20 >> the deadline for the IETF 82. Love to get input - particularly on if=20 >> this looks like generally the right direction to go. >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Thu Nov 3 12:54:06 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF3011E80AE; Thu, 3 Nov 2011 12:54:06 -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=[AWL=-0.000, 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 d5haqR-opkEd; Thu, 3 Nov 2011 12:54:05 -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 5927321F843B; Thu, 3 Nov 2011 12:54:05 -0700 (PDT) Received: by ywt2 with SMTP id 2so1942922ywt.31 for ; Thu, 03 Nov 2011 12:54:05 -0700 (PDT) Received: by 10.146.137.34 with SMTP id k34mr2671990yad.26.1320349431235; Thu, 03 Nov 2011 12:43:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.232.12 with HTTP; Thu, 3 Nov 2011 12:43:10 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <5B7AE760-DBD1-46F9-89D9-E8F7CA56F111@network-heretics.com> From: Eric Rescorla Date: Thu, 3 Nov 2011 12:43:10 -0700 Message-ID: To: Keith Moore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Keith Moore , "rtcweb@ietf.org" , Ned Freed , Behave WG Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 19:54:06 -0000 On Thu, Nov 3, 2011 at 12:29 PM, Keith Moore w= rote: > > On Nov 3, 2011, at 2:58 PM, Eric Rescorla wrote: > >> On Tue, Nov 1, 2011 at 5:05 AM, Keith Moore = wrote: >>>> In most cases probably not. But there may be cases similar to HTTP/S w= here it makes sense. Each case has to be analyzed independently. >>> >>> agree. =A0I just don't think it's a good idea to establish a new _conve= ntion_. >> >> i don't really understand what you're arguing here. >> >> The relevant issue is that we want to have a reference that Bob can prov= ide >> to Alice that guarantees that when it's dereferenced it provides a minim= um >> set of security properties. >> >> Let's imagine some hypothetical new protocol which is like HTTP but not = HTTP, >> say HTTQ. It runs over TCP so you can use it directly or over TLS (i.e., >> HTTP/TCP or HTTP/TLS/TCP). We're planning to define a new URI for it, >> httq://.../. How do you propose to provide the above security property? > > If you're going to define a new protocol, it should always use TLS (or it= should always provide a minimum set of security properties). =A0Then you d= efine a single URI type for the new protocol, and it doesn't need the secur= ity flag. OK. I agree with this. > It's only when you're trying to retro-fit security into an existing proto= col that is already widely used, doesn't inherently provide a reasonable le= vel of security for that application, and the security isn't securely negot= iated in-band, that you need a security flag in the URI. Sure. > More generally, the right place to set the minimum security level is in t= he application, not in the name of the resource. =A0The reason you need htt= ps vs. http is that the two are really different protocols, and the client = has to know a priori whether to send "GET..." or to negotiate the TLS layer= after the TCP open completes. I don't agree with this, however. The reason you need https: versus http: is that it's the server providing the reference and it's the only one that knows whether the resource is to be accessed over TLS or not. As a point of historical trivia, the initial use of this general convention wasn't https:// but rather shttp://, and the intent of the originator, Allan Schiffman, was to make it impossible for a non-Secure HTTP capable client to accidentally reference via HTTP a resource which should be secure. -Ekr From stewe@stewe.org Thu Nov 3 13:28:43 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D7211E80DA for ; Thu, 3 Nov 2011 13:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.546 X-Spam-Level: X-Spam-Status: No, score=-0.546 tagged_above=-999 required=5 tests=[AWL=-1.344, BAYES_00=-2.599, GB_VISITOURSITE=2, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6qCUYLhCtZY for ; Thu, 3 Nov 2011 13:28:41 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8FD11E80AE for ; Thu, 3 Nov 2011 13:28:40 -0700 (PDT) Received: from [192.168.1.63] (unverified [71.202.147.60]) by stewe.org (SurgeMail 3.9e) with ESMTP id 56237-1743317 for multiple; Thu, 03 Nov 2011 21:28:39 +0100 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Thu, 03 Nov 2011 13:28:28 -0700 From: Stephan Wenger To: "Bran, Cary" , "rtcweb@ietf.org" Message-ID: Thread-Topic: [rtcweb] Codec Draft In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3403171718_7852514" X-Originating-IP: 71.202.147.60 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.147.60) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [rtcweb] Codec 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: Thu, 03 Nov 2011 20:28:43 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3403171718_7852514 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Cary, WG, Cary, how did you come to your conclusion that the WG has achieved consensu= s on a subject like this: If the MPEG-LA issues an intent to offer H.264 baseline profile on a royalty free basis for use in browsers before March 15, 2012, then the REQUIRED video codecs will be H.264 baseline. If this does not happen by that the date, then the REQUIRED video codec will be VP8 [I-D.webm]. Or this WebRTC clients are REQUIRED to implement the following audio codecs. [=8A] o Opus [draft-ietf-codec-opus] I may have missed it in the flood of emails on this reflector, but I do not recall having seen any discussion whatsoever towards a decision between the two video codecs mentioned, let alone a decision made on commercial constraints and an attached timeline. Please note that I could most likely agree to the video codec issues as drafted, with the exception of the timeline, which is IMO overly and unnecessarily ambitious. Similarly, I do not recall a sufficiently in-depth discussion about audio codecs (though there has been a bit more discussion on the reflector in thi= s regard). I find it strange that we consider making an declared-as-royalty-bearing audio codec mandatory, without even having the slightest idea of the licensing terms beyond the RAND terms offered. Strangely, we are not providing the right holder with a timeline similar as the one used for H.264. Perhaps we should work with the Qualcomm guys to see whether they would be willing to provide an RF license with a field of use restriction to webrtc. As the very minimum, I would request the opus codec being profiled such that most obvious matches between patent claims offered under royalty bearing RAND terms and opus encoder and decoder as to be used in webrtc be eliminated. To summarize, without having those (and perhaps a few more) points discusse= d in public on the reflector, I believe that it is too early to adopt your draft as a WG draft. Stephan From: "Bran, Cary" Date: Mon, 31 Oct 2011 22:25:48 +0000 To: "rtcweb-chairs@tools.ietf.org" Cc: "rtcweb@ietf.org" Subject: [rtcweb] Codec Draft Hello WebRTC chairs, =20 I have updated and submitted a 02 version of the WebRTC Codec draft: http://tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt =20 I believe that this draft is representative of areas where the working grou= p has achieved consensus and at this time I would like to ask that the 01 draft be adopted as a working group document. =20 I look forward to your feedback. =20 Regards, =20 =20 Cary Bran Senior Director Advanced Software Technology and Architecture Office: +1 831-458-7737 Cell: +1 206-661-2398 Plantronics Simply Smarter Communications=81 345 Encinal St., Santa Cruz, CA 95060 =20 CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain information that is confidential and/or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the contents to another person, store or copy the information in any medium, or use any of the information contained in or attached to this transmission for any purpose. If you have received this transmission in error, please immediately notify the sender by reply email or at privacy@plantronics.com, and destroy the original transmission and its attachments without reading or saving in any manner. For further information about Plantronics - the Company, its products, brands, partners, please visit our website www.plantronics.com. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --B_3403171718_7852514 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Cary, WG,

<= /div>
Cary, how did you come to your conclusion that the WG has achieved= consensus on a subject like this:
   If the MPEG-LA issues an intent to offer =
H.264 baseline profile on a
   royalty free basis for use in browsers before March 15, 2012, then
   the REQUIRED video codecs will be H.264 baseline.  If this does not
   happen by that the date, then the REQUIRED video codec will be VP8
   [I-D.webm].

Or this

= 
  =
 WebRTC clients are REQUIRED to implement the following audio codecs.

    […]

   o  Opus [draft-ietf-codec-opus]

I = may have missed it in the flood of emails on this reflector, but I do not re= call having seen any discussion whatsoever towards a decision between the tw= o video codecs mentioned, let alone a decision made on commercial constraint= s and an attached timeline.  Please note that I could most likely agree= to the video codec issues as drafted, with the exception of the timeline, w= hich is IMO overly and unnecessarily ambitious.  

<= div>Similarly, I do not recall a sufficiently in-depth discussion about audi= o codecs (though there has been a bit more discussion on the reflector in th= is regard).  I find it strange that we consider making an declared-as-r= oyalty-bearing audio codec mandatory, without even having the slightest idea= of the licensing terms beyond the RAND terms offered.  Strangely, we a= re not providing the right holder with a timeline similar as the one used fo= r H.264.  Perhaps we should work with the Qualcomm guys to see whether = they would be willing to provide an RF license with a field of use restricti= on to webrtc.  As the very minimum, I would request the opus codec bein= g profiled such that most obvious matches between patent claims offered unde= r royalty bearing RAND terms and opus encoder and decoder as to be used in w= ebrtc be eliminated.  

To summarize, without h= aving those (and perhaps a few more) points discussed in public on the refle= ctor, I believe that it is too early to adopt your draft as a WG draft.

Stephan

From: "Bran, Cary" <C= ary.Bran@plantronics.com>
Date: Mon, 31 Oct 2011 22:25:48 +0000
To: <= /span> "rtcweb-chairs@tools.ie= tf.org" <rtcweb-chairs@= tools.ietf.org>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: = [rtcweb] Codec Draft

Hello WebRTC chairs,

 =

I have updated and submitted a 02 version of the We= bRTC Codec draft: http://t= ools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt

 

I believe that this draft is representative = of areas where the working group has achieved consensus and at this time I w= ould like to ask that the 01 draft be adopted as a working group document.

 

I look forward to your= feedback.

 

Regards,

 

 

Cary Bran<= /span>

Senior Director Advanced Software Technology and= Architecture

Office:  +1 831-458-7737 = ;    Cell: +1 206-661-2398

Plantronics  Simply Smarter Communi= cations™

345 Encinal St., Santa Cruz, CA 9= 5060

 



CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is = confidential and/or legally privileged. If you are not the intended recipien= t, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the conten= ts to another person, store or copy the information in any medium, or use an= y of the information contained in or attached to this transmission for any p= urpose. If you have received this transmission in error, please immediately notify the sender by reply email= or at privacy@plantronics.com,= and destroy the original transmission and its attachments without reading o= r saving in any manner.

For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com.
=
_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org= /mailman/listinfo/rtcweb --B_3403171718_7852514-- From Cary.Bran@plantronics.com Thu Nov 3 14:02:06 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B321F0C35 for ; Thu, 3 Nov 2011 14:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, GB_VISITOURSITE=2, 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 tB4oxQHpZwsb for ; Thu, 3 Nov 2011 14:02:03 -0700 (PDT) Received: from mail4.plantronics.com (mail4.plantronics.com [12.151.41.50]) by ietfa.amsl.com (Postfix) with ESMTP id 46DC81F0C6F for ; Thu, 3 Nov 2011 14:02:03 -0700 (PDT) Received: from usscch03.plt.plantronics.com (usscch03.plt.plantronics.com [10.1.3.26]) by mail4.plantronics.com (8.13.8/8.13.8) with ESMTP id pA3L22t6000321; Thu, 3 Nov 2011 14:02:02 -0700 Received: from USSCMB03.plt.plantronics.com ([fe80::5824:67c8:930e:7c1e]) by USSCCH03.plt.plantronics.com ([::1]) with mapi id 14.01.0270.001; Thu, 3 Nov 2011 14:02:01 -0700 From: "Bran, Cary" To: Stephan Wenger Thread-Topic: [rtcweb] Codec Draft Thread-Index: AcyYG7T52+iin6+9RSSZxK1D9q2OmQChhxkAAA3DBBA= Date: Thu, 3 Nov 2011 21:02:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.1.18] Content-Type: multipart/alternative; boundary="_000_E37C139C5CB78244A781E9E7B721527B54B5D9USSCMB03pltplantr_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.67 on 10.63.1.50 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Codec 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: Thu, 03 Nov 2011 21:02:06 -0000 --_000_E37C139C5CB78244A781E9E7B721527B54B5D9USSCMB03pltplantr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good points Stephan. I agree that more discussion is needed and all I am proposing here is a doc= ument to capture the groups collective thinking. I will defer to the chair= s to decide on timing. Cheers, -Cary From: Stephan Wenger [mailto:stewe@stewe.org] Sent: Thursday, November 03, 2011 1:28 PM To: Bran, Cary; rtcweb@ietf.org Subject: Re: [rtcweb] Codec Draft Hi Cary, WG, Cary, how did you come to your conclusion that the WG has achieved consensu= s on a subject like this: If the MPEG-LA issues an intent to offer H.264 baseline profile on a royalty free basis for use in browsers before March 15, 2012, then the REQUIRED video codecs will be H.264 baseline. If this does not happen by that the date, then the REQUIRED video codec will be VP8 [I-D.webm]. Or this WebRTC clients are REQUIRED to implement the following audio codecs. [...] o Opus [draft-ietf-codec-opus] I may have missed it in the flood of emails on this reflector, but I do not= recall having seen any discussion whatsoever towards a decision between th= e two video codecs mentioned, let alone a decision made on commercial const= raints and an attached timeline. Please note that I could most likely agre= e to the video codec issues as drafted, with the exception of the timeline,= which is IMO overly and unnecessarily ambitious. Similarly, I do not recall a sufficiently in-depth discussion about audio c= odecs (though there has been a bit more discussion on the reflector in this= regard). I find it strange that we consider making an declared-as-royalty= -bearing audio codec mandatory, without even having the slightest idea of t= he licensing terms beyond the RAND terms offered. Strangely, we are not pr= oviding the right holder with a timeline similar as the one used for H.264.= Perhaps we should work with the Qualcomm guys to see whether they would b= e willing to provide an RF license with a field of use restriction to webrt= c. As the very minimum, I would request the opus codec being profiled such= that most obvious matches between patent claims offered under royalty bear= ing RAND terms and opus encoder and decoder as to be used in webrtc be elim= inated. To summarize, without having those (and perhaps a few more) points discusse= d in public on the reflector, I believe that it is too early to adopt your = draft as a WG draft. Stephan From: "Bran, Cary" > Date: Mon, 31 Oct 2011 22:25:48 +0000 To: "rtcweb-chairs@tools.ietf.org" > Cc: "rtcweb@ietf.org" > Subject: [rtcweb] Codec Draft Hello WebRTC chairs, I have updated and submitted a 02 version of the WebRTC Codec draft: http:/= /tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt I believe that this draft is representative of areas where the working grou= p has achieved consensus and at this time I would like to ask that the 01 d= raft be adopted as a working group document. I look forward to your feedback. Regards, Cary Bran Senior Director Advanced Software Technology and Architecture Office: +1 831-458-7737 Cell: +1 206-661-2398 Plantronics Simply Smarter Communications(tm) 345 Encinal St., Santa Cruz, CA 95060 ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, p= lease DO NOT disclose the contents to another person, store or copy the inf= ormation in any medium, or use any of the information contained in or attac= hed to this transmission for any purpose. If you have received this transmi= ssion in error, please immediately notify the sender by reply email or at p= rivacy@plantronics.com, and destroy the ori= ginal transmission and its attachments without reading or saving in any man= ner. For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com. _______________________________________________ rtcweb mailing list rtcweb@= ietf.org https://www.ietf.org/mailman/listinfo/rtcw= eb ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, p= lease DO NOT disclose the contents to another person, store or copy the inf= ormation in any medium, or use any of the information contained in or attac= hed to this transmission for any purpose. If you have received this transmi= ssion in error, please immediately notify the sender by reply email or at p= rivacy@plantronics.com, and destroy the original transmission and its attac= hments without reading or saving in any manner. For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com. --_000_E37C139C5CB78244A781E9E7B721527B54B5D9USSCMB03pltplantr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good points Stephan.

 

I agree that more disc= ussion is needed and all I am proposing here is a document to capture the g= roups collective thinking.  I will defer to the chairs to decide on ti= ming.

 

Cheers,

 

-Cary

 

From: Stepha= n Wenger [mailto:stewe@stewe.org]
Sent: Thursday, November 03, 2011 1:28 PM
To: Bran, Cary; rtcweb@ietf.org
Subject: Re: [rtcweb] Codec Draft

 

Hi Car= y, WG,

 =

Cary, = how did you come to your conclusion that the WG has achieved consensus on a= subject like this:

   If the MPEG-LA issues an intent to offer H.264 base=
line profile on a
   royalty free basis for use in=
 browsers before March 15, 2012, then
   the REQUIRED video codecs wil=
l be H.264 baseline.  If this does not
   happen by that the date, then=
 the REQUIRED video codec will be VP8
   [I-D.webm].

 =

Or thi= s

 = 

   WebRTC clients are REQUIRED to implement the follow=
ing audio codecs.
 
    […]
 
   o  Opus [draft-ietf-code=
c-opus]

 =

I may = have missed it in the flood of emails on this reflector, but I do not recal= l having seen any discussion whatsoever towards a decision between the two = video codecs mentioned, let alone a decision made on commercial constraints and an attached timeline.  Pl= ease note that I could most likely agree to the video codec issues as draft= ed, with the exception of the timeline, which is IMO overly and unnecessari= ly ambitious.  

 =

Simila= rly, I do not recall a sufficiently in-depth discussion about audio codecs = (though there has been a bit more discussion on the reflector in this regar= d).  I find it strange that we consider making an declared-as-royalty-bearing audio codec mandatory, without even = having the slightest idea of the licensing terms beyond the RAND terms offe= red.  Strangely, we are not providing the right holder with a timeline= similar as the one used for H.264.  Perhaps we should work with the Qualcomm guys to see whether they would be willing= to provide an RF license with a field of use restriction to webrtc.  = As the very minimum, I would request the opus codec being profiled such tha= t most obvious matches between patent claims offered under royalty bearing RAND terms and opus encoder and decod= er as to be used in webrtc be eliminated.  

 =

To sum= marize, without having those (and perhaps a few more) points discussed in p= ublic on the reflector, I believe that it is too early to adopt your draft = as a WG draft.

 =

Stepha= n

 =

From: "Bran, Cary" <Cary.Bran@plantronics.com>
Date: Mon, 31 Oct 2011 22:25:48 +0000
To: "rtcweb-cha= irs@tools.ietf.org" <rtcweb-chairs@tools.ietf.org>
Cc: "rtcweb@ietf.org&quo= t; <rtcweb@ietf.org>
Subject: [rtcweb] Codec Draft

 =

Hello WebRTC chairs,

 

I have updated and submi= tted a 02 version of the WebRTC Codec draft: http:/= /tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt

 

I believe that this draf= t is representative of areas where the working group has achieved consensus= and at this time I would like to ask that the 01 draft be adopted as a wor= king group document.

 

I look forward to your f= eedback.

 

Regards,

 

 

Cary Bran

Senior Director Advanced Software Technology and A= rchitecture

Office:  +1 831-458-7737   = ;  Cell: +1 206-661-2398

Plantronics  Simply Smarter Commu= nications™

345 Encinal St., Santa Cruz, CA 95060

 

 =


CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the conten= ts to another person, store or copy the information in any medium, or use a= ny of the information contained in or attached to this transmission for any= purpose. If you have received this transmission in error, please immediately notify the sender by reply email= or at privacy@plantronics.com, and= destroy the original transmission and its attachments without reading or s= aving in any manner.

For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com.

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



CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the conten= ts to another person, store or copy the information in any medium, or use a= ny of the information contained in or attached to this transmission for any= purpose. If you have received this transmission in error, please immediately notify the sender by reply email= or at privacy@plantronics.com, and destroy the original transmission and i= ts attachments without reading or saving in any manner.

For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com.
 --_000_E37C139C5CB78244A781E9E7B721527B54B5D9USSCMB03pltplantr_-- From cb.list6@gmail.com Thu Nov 3 14:17:10 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5741F0CB6 for ; Thu, 3 Nov 2011 14:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, GB_VISITOURSITE=2, 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 5OoQ8iQBoU2R for ; Thu, 3 Nov 2011 14:17:09 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFCC1F0CBB for ; Thu, 3 Nov 2011 14:17:09 -0700 (PDT) Received: by qyk32 with SMTP id 32so569053qyk.10 for ; Thu, 03 Nov 2011 14:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m+ylJQ1ppCedmulTI7h2cC9Cp5AaEElpIQEI6/qP6+I=; b=abTAQuBIMThyVTGIJHQwn/GkyV4p13q5/hdXlMv7h9IdI2KOXpa64GIp/Q1ZTJPovc 4VhoCdIej58OPlztWsKvYiRtJJb34pBjNMswET22aGYQrNKgL8jiWrdzG35Yj9f8LOx9 1lnAfGc88ii5PlwcIEts25Qmg8yNuVsCZkWf8= MIME-Version: 1.0 Received: by 10.50.169.97 with SMTP id ad1mr6921276igc.35.1320355028395; Thu, 03 Nov 2011 14:17:08 -0700 (PDT) Received: by 10.142.230.8 with HTTP; Thu, 3 Nov 2011 14:17:08 -0700 (PDT) Received: by 10.142.230.8 with HTTP; Thu, 3 Nov 2011 14:17:08 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852235789600@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852235789600@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 3 Nov 2011 14:17:08 -0700 Message-ID: From: Cameron Byrne To: Christer Holmberg Content-Type: multipart/alternative; boundary=e89a8f2359a971e52404b0db1cbe Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" , "Bran, Cary" Subject: Re: [rtcweb] NAT 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: Thu, 03 Nov 2011 21:17:10 -0000 --e89a8f2359a971e52404b0db1cbe Content-Type: text/plain; charset=ISO-8859-1 On Nov 3, 2011 12:03 PM, "Christer Holmberg" wrote: > > Hi, > > A couple of questions for clarification. > > In section 3.3, what does "RTC-Web clients MUST support IPv4 to IPv6 transition." really mean? I think you need to clarify. > Hopefully nat64 rfc 6146 Cb > In section 4.1, can we put requirements on gateways? Maybe we should rather say that RTCWeb clients shall accept cases where the remote ICE client supports ICE lite, or something like that. Because, there might not even be a gateway, but a legacy UA that actually supports ICE :) > > Regards, > > Christer > > > > > > > > ________________________________ > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bran, Cary > Sent: 1. marraskuuta 2011 0:23 > To: rtcweb-chairs@tools.ietf.org > Cc: rtcweb@ietf.org > Subject: [rtcweb] NAT Draft > > > > Hello WebRTC chairs, > > > > I have updated and submitted a 02 version of the WebRTC NAT draft: http://tools.ietf.org/id/draft-cbran-rtcweb-nat-02.txt > > > > I believe that this draft is representative of areas where the working group has achieved consensus and at this time I would like to ask that the 02 draft be adopted as a working group document. > > > > I look forward to your feedback. > > > > Regards, > > > > Cary Bran > > Senior Director Advanced Software Technology and Architecture > > Office: +1 831-458-7737 Cell: +1 206-661-2398 > > Plantronics Simply Smarter Communications(tm) > > 345 Encinal St., Santa Cruz, CA 95060 > > > > > ________________________________ > > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain information that is confidential and/or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the contents to another person, store or copy the information in any medium, or use any of the information contained in or attached to this transmission for any purpose. If you have received this transmission in error, please immediately notify the sender by reply email or at privacy@plantronics.com, and destroy the original transmission and its attachments without reading or saving in any manner. > > For further information about Plantronics - the Company, its products, brands, partners, please visit our website www.plantronics.com. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --e89a8f2359a971e52404b0db1cbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 3, 2011 12:03 PM, "Christer Holmberg" <christer.holmberg@ericsson.com> wr= ote:
>
> Hi,
>
> A couple of questions for clarification.
>
> In section 3.3, what does "RTC-Web clients MUST support IPv4 to I= Pv6 transition." really mean? I think you need to clarify.
>

Hopefully nat64 rfc 6146

Cb
> In section 4.1, can we put requirements on gateways? Maybe we should r= ather say that RTCWeb clients shall accept cases where the remote ICE clien= t supports ICE lite, or something like that. Because, there might not even = be a gateway, but a legacy UA that actually supports ICE :)
>
> Regards,
>
> Christer
>
>
>
>
>
>
>
> ________________________________
>
> From: rtcweb-bounces@ietf.o= rg [mailto:rtcweb-bounces@ie= tf.org] On Behalf Of Bran, Cary
> Sent: 1. marraskuuta 2011 0:23
> To: rtcweb-chairs@tool= s.ietf.org
> Cc: rtcweb@ietf.org
> Subject: [rtcweb] NAT Draft
>
>
>
> Hello WebRTC chairs,
>
>
>
> I have updated and submitted a 02 version of the WebRTC NAT draft: http://tool= s.ietf.org/id/draft-cbran-rtcweb-nat-02.txt
>
>
>
> I believe that this draft is representative of areas where the working= group has achieved consensus and at this time I would like to ask that the= 02 draft be adopted as a working group document.
>
>
>
> I look forward to your feedback.
>
>
>
> Regards,
>
>
>
> Cary Bran
>
> Senior Director Advanced Software Technology and Architecture
>
> Office: =A0+1 831-458-7737 =A0 =A0 Cell: +1 206-661-2398
>
> Plantronics =A0Simply Smarter Communications(tm)
>
> 345 Encinal St., Santa Cruz, CA 95060
>
>
>
>
> ________________________________
>
>
> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, f= iles or previous e-mail messages attached to it, may contain information th= at is confidential and/or legally privileged. If you are not the intended r= ecipient, or a person responsible for delivering it to the intended recipie= nt, please DO NOT disclose the contents to another person, store or copy th= e information in any medium, or use any of the information contained in or = attached to this transmission for any purpose. If you have received this tr= ansmission in error, please immediately notify the sender by reply email or= at privacy@plantronics.com,= and destroy the original transmission and its attachments without reading = or saving in any manner.
>
> For further information about Plantronics - the Company, its products,= brands, partners, please visit our website www.plantronics.com.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--e89a8f2359a971e52404b0db1cbe-- From Cary.Bran@plantronics.com Thu Nov 3 15:00:33 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9133811E80A2 for ; Thu, 3 Nov 2011 15:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.295 X-Spam-Level: X-Spam-Status: No, score=-0.295 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, GB_VISITOURSITE=2, 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 aNXzFiGoU+uZ for ; Thu, 3 Nov 2011 15:00:29 -0700 (PDT) Received: from mail3.plantronics.com (mail3.plantronics.com [12.151.41.49]) by ietfa.amsl.com (Postfix) with ESMTP id DE49D11E80BC for ; Thu, 3 Nov 2011 15:00:29 -0700 (PDT) Received: from usscch03.plt.plantronics.com (usscch03.plt.plantronics.com [10.1.3.26]) by mail3.plantronics.com (8.13.8/8.13.8) with ESMTP id pA3M0Q11004327; Thu, 3 Nov 2011 15:00:27 -0700 Received: from USSCMB03.plt.plantronics.com ([fe80::5824:67c8:930e:7c1e]) by USSCCH03.plt.plantronics.com ([::1]) with mapi id 14.01.0270.001; Thu, 3 Nov 2011 15:00:26 -0700 From: "Bran, Cary" To: Stephan Wenger Thread-Topic: [rtcweb] Codec Draft Thread-Index: AcyYG7T52+iin6+9RSSZxK1D9q2OmQChhxkAAA3DBBAAGTwBMA== Date: Thu, 3 Nov 2011 22:00:26 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.1.18] Content-Type: multipart/alternative; boundary="_000_E37C139C5CB78244A781E9E7B721527B54B778USSCMB03pltplantr_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.67 on 10.63.1.49 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Codec 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: Thu, 03 Nov 2011 22:00:33 -0000 --_000_E37C139C5CB78244A781E9E7B721527B54B778USSCMB03pltplantr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After further review, I think I get your point, my apologies if I caused an= y confusion. What I meant to say was that I believe we have captured areas where we have= consensus in the draft. Obviously at this time there is no consensus as t= o which audio/video codecs will be mandatory to implement yet. To be cl= ear here, in the draft we put in a proposal for a mandatory to implement co= dec and we should have qualified it as an open issue, where we have no cons= ensus. Stephan, if you or anyone else, has a proposal as to what to add to the lis= t, we would be more than happy to add it to the document and correctly labe= l the areas where we have no consensus in an attempt to facilitate the disc= ussion. Regards, -Cary From: Bran, Cary Sent: Thursday, November 03, 2011 2:02 PM To: 'Stephan Wenger' Cc: rtcweb@ietf.org Subject: RE: [rtcweb] Codec Draft Good points Stephan. I agree that more discussion is needed and all I am proposing here is a doc= ument to capture the groups collective thinking. I will defer to the chair= s to decide on timing. Cheers, -Cary From: Stephan Wenger [mailto:stewe@stewe.org] Sent: Thursday, November 03, 2011 1:28 PM To: Bran, Cary; rtcweb@ietf.org Subject: Re: [rtcweb] Codec Draft Hi Cary, WG, Cary, how did you come to your conclusion that the WG has achieved consensu= s on a subject like this: If the MPEG-LA issues an intent to offer H.264 baseline profile on a royalty free basis for use in browsers before March 15, 2012, then the REQUIRED video codecs will be H.264 baseline. If this does not happen by that the date, then the REQUIRED video codec will be VP8 [I-D.webm]. Or this WebRTC clients are REQUIRED to implement the following audio codecs. [...] o Opus [draft-ietf-codec-opus] I may have missed it in the flood of emails on this reflector, but I do not= recall having seen any discussion whatsoever towards a decision between th= e two video codecs mentioned, let alone a decision made on commercial const= raints and an attached timeline. Please note that I could most likely agre= e to the video codec issues as drafted, with the exception of the timeline,= which is IMO overly and unnecessarily ambitious. Similarly, I do not recall a sufficiently in-depth discussion about audio c= odecs (though there has been a bit more discussion on the reflector in this= regard). I find it strange that we consider making an declared-as-royalty= -bearing audio codec mandatory, without even having the slightest idea of t= he licensing terms beyond the RAND terms offered. Strangely, we are not pr= oviding the right holder with a timeline similar as the one used for H.264.= Perhaps we should work with the Qualcomm guys to see whether they would b= e willing to provide an RF license with a field of use restriction to webrt= c. As the very minimum, I would request the opus codec being profiled such= that most obvious matches between patent claims offered under royalty bear= ing RAND terms and opus encoder and decoder as to be used in webrtc be elim= inated. To summarize, without having those (and perhaps a few more) points discusse= d in public on the reflector, I believe that it is too early to adopt your = draft as a WG draft. Stephan From: "Bran, Cary" > Date: Mon, 31 Oct 2011 22:25:48 +0000 To: "rtcweb-chairs@tools.ietf.org" > Cc: "rtcweb@ietf.org" > Subject: [rtcweb] Codec Draft Hello WebRTC chairs, I have updated and submitted a 02 version of the WebRTC Codec draft: http:/= /tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt I believe that this draft is representative of areas where the working grou= p has achieved consensus and at this time I would like to ask that the 01 d= raft be adopted as a working group document. I look forward to your feedback. Regards, Cary Bran Senior Director Advanced Software Technology and Architecture Office: +1 831-458-7737 Cell: +1 206-661-2398 Plantronics Simply Smarter Communications(tm) 345 Encinal St., Santa Cruz, CA 95060 ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, p= lease DO NOT disclose the contents to another person, store or copy the inf= ormation in any medium, or use any of the information contained in or attac= hed to this transmission for any purpose. If you have received this transmi= ssion in error, please immediately notify the sender by reply email or at p= rivacy@plantronics.com, and destroy the ori= ginal transmission and its attachments without reading or saving in any man= ner. For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com. _______________________________________________ rtcweb mailing list rtcweb@= ietf.org https://www.ietf.org/mailman/listinfo/rtcw= eb ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, p= lease DO NOT disclose the contents to another person, store or copy the inf= ormation in any medium, or use any of the information contained in or attac= hed to this transmission for any purpose. If you have received this transmi= ssion in error, please immediately notify the sender by reply email or at p= rivacy@plantronics.com, and destroy the original transmission and its attac= hments without reading or saving in any manner. For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com. --_000_E37C139C5CB78244A781E9E7B721527B54B778USSCMB03pltplantr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

After further review, = I think I get your point, my apologies if I caused any confusion.

 

What I meant to say wa= s that I believe we have captured areas where we have consensus in the draf= t.  Obviously at this time there is no consensus as to which audio/vid= eo codecs will be mandatory to implement yet.     To be clear here, in the draft we put in a pr= oposal for a mandatory to implement codec and we should have qualified it a= s an open issue, where we have no consensus. 

 

Stephan, if you or any= one else, has a proposal as to what to add to the list, we would be more th= an happy to add it to the document and correctly label the areas where we h= ave no consensus in an attempt to facilitate the discussion.

 

Regards,

 

-Cary

 

 

 

From: Bran, = Cary
Sent: Thursday, November 03, 2011 2:02 PM
To: 'Stephan Wenger'
Cc: rtcweb@ietf.org
Subject: RE: [rtcweb] Codec Draft

 

Good points Stephan.

 

I agree that more disc= ussion is needed and all I am proposing here is a document to capture the g= roups collective thinking.  I will defer to the chairs to decide on ti= ming.

 

Cheers,

 

-Cary

 

 

From: Stepha= n Wenger [mailto:stewe@stewe.org]
Sent: Thursday, November 03, 2011 1:28 PM
To: Bran, Cary; rtcweb@ietf.org
Subject: Re: [rtcweb] Codec Draft

 

Hi Car= y, WG,

 =

Cary, = how did you come to your conclusion that the WG has achieved consensus on a= subject like this:

   If the MPEG-LA issues an intent to offer H.264 base=
line profile on a
   royalty free basis for use in=
 browsers before March 15, 2012, then
   the REQUIRED video codecs wil=
l be H.264 baseline.  If this does not
   happen by that the date, then=
 the REQUIRED video codec will be VP8
   [I-D.webm].

 =

Or thi= s

 = 

   WebRTC clients are REQUIRED to implement the follow=
ing audio codecs.
 
    […]
 
   o  Opus [draft-ietf-code=
c-opus]

 =

I may = have missed it in the flood of emails on this reflector, but I do not recal= l having seen any discussion whatsoever towards a decision between the two = video codecs mentioned, let alone a decision made on commercial constraints and an attached timeline.  Pl= ease note that I could most likely agree to the video codec issues as draft= ed, with the exception of the timeline, which is IMO overly and unnecessari= ly ambitious.  

 =

Simila= rly, I do not recall a sufficiently in-depth discussion about audio codecs = (though there has been a bit more discussion on the reflector in this regar= d).  I find it strange that we consider making an declared-as-royalty-bearing audio codec mandatory, without even = having the slightest idea of the licensing terms beyond the RAND terms offe= red.  Strangely, we are not providing the right holder with a timeline= similar as the one used for H.264.  Perhaps we should work with the Qualcomm guys to see whether they would be willing= to provide an RF license with a field of use restriction to webrtc.  = As the very minimum, I would request the opus codec being profiled such tha= t most obvious matches between patent claims offered under royalty bearing RAND terms and opus encoder and decod= er as to be used in webrtc be eliminated.  

 =

To sum= marize, without having those (and perhaps a few more) points discussed in p= ublic on the reflector, I believe that it is too early to adopt your draft = as a WG draft.

 =

Stepha= n

 =

From: "Bran, Cary" <Cary.Bran@plantronics.com>
Date: Mon, 31 Oct 2011 22:25:48 +0000
To: "rtcweb-cha= irs@tools.ietf.org" <rtcweb-chairs@tools.ietf.org>
Cc: "rtcweb@ietf.org&quo= t; <rtcweb@ietf.org>
Subject: [rtcweb] Codec Draft

 =

Hello WebRTC chairs,

 

I have updated and submi= tted a 02 version of the WebRTC Codec draft: http:/= /tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt

 

I believe that this draf= t is representative of areas where the working group has achieved consensus= and at this time I would like to ask that the 01 draft be adopted as a wor= king group document.

 

I look forward to your f= eedback.

 

Regards,

 

 

Cary Bran

Senior Director Advanced Software Technology and A= rchitecture

Office:  +1 831-458-7737   = ;  Cell: +1 206-661-2398

Plantronics  Simply Smarter Commu= nications™

345 Encinal St., Santa Cruz, CA 95060

 

 =


CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the conten= ts to another person, store or copy the information in any medium, or use a= ny of the information contained in or attached to this transmission for any= purpose. If you have received this transmission in error, please immediately notify the sender by reply email= or at privacy@plantronics.com, and= destroy the original transmission and its attachments without reading or s= aving in any manner.

For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com.

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



CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the conten= ts to another person, store or copy the information in any medium, or use a= ny of the information contained in or attached to this transmission for any= purpose. If you have received this transmission in error, please immediately notify the sender by reply email= or at privacy@plantronics.com, and destroy the original transmission and i= ts attachments without reading or saving in any manner.

For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com.
 --_000_E37C139C5CB78244A781E9E7B721527B54B778USSCMB03pltplantr_-- From giles@thaumas.net Thu Nov 3 17:10:38 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D53811E8089 for ; Thu, 3 Nov 2011 17:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 vLAo4Zn6pdUn for ; Thu, 3 Nov 2011 17:10:36 -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 0979711E80F0 for ; Thu, 3 Nov 2011 17:09:59 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so1918111vcb.31 for ; Thu, 03 Nov 2011 17:09:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.14 with SMTP id h14mr12041529vdg.132.1320365398026; Thu, 03 Nov 2011 17:09:58 -0700 (PDT) Received: by 10.220.182.139 with HTTP; Thu, 3 Nov 2011 17:09:57 -0700 (PDT) X-Originating-IP: [66.183.19.247] In-Reply-To: References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> Date: Thu, 3 Nov 2011 17:09:57 -0700 Message-ID: From: Ralph Giles To: rtcweb@ietf.org Content-Type: multipart/mixed; boundary=20cf307cffa685ead504b0dd860a Subject: [rtcweb] Fwd: New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 00:10:38 -0000 --20cf307cffa685ead504b0dd860a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Oops, forgot to cc the list. -r ---------- Forwarded message ---------- From: Ralph Giles Date: 3 November 2011 17:09 Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt To: Randell Jesup On 31 October 2011 20:18, Randell Jesup wrote: > A new version of I-D, draft-jesup-rtcweb-data-01.txt has been successfull= y > submitted by Randell Jesup and posted to the IETF repository. Some feedback on the draft, more editorial than technical. Please see the attached patch for a number of formatting, spelling, grammar and wording improvements. I don't think any of these change meaning, but if you want a more granular report, you can pull my edit history from http://thaumas.net/~giles/git/draft-foo.git. Or ask and I can send separate patches. Note that there are two 'Req. 10's. I didn't fix that because renumbering makes it harder to discuss the draft, that they should be updated before publishing another. More content-oriented comments: In Req. 1, the wording is a little unclear. Is it the media streams, data streams, or both which MUST be able to change at any time? In Req. 7 and 10 (the first one), I worry that referring specifically to javascript may end up dated and/or too browser-centric. Can we just refer to application or webapp? There are places where the distinction between the user-agent and the content which is requesting the call is important, but I'm not sure javascript's ubiquity as a vehicle for the later is relevant. For example: [Req. 7] Data streams MUST provide message fragmentation support such that IP-layer fragmentation does not occur no matter how large a message or buffer the application passes to the Browser for transmission. [Req. 10] The data stream packet format/encoding MUST be such that it is impossible for a malicious applications to generate a crafted message which would be interpreted as another native protocol over UDP - such as UPnP, RTP, SNMP, STUN, etc. In the "User Space vs Kernel implementation" section, you talk about deployability, but not about the relative difficulty of implementing SCTP-on-DTLS vs DTLS-on-SCTP with current kernel stacks. At least a reference to the discussion lower down (section 5.2) would be helpful here, I think. In turn, that section, "User Space vs Kernel implementation," rather assumes the solution. That might be fine, but instead of saying it must be possible to implement SCTP and DTLS in user space, you could rather say, "It MUST be possible to implement the data protocol without increasing the footprint for system-level calls, i.e. using UDP sockets." Since browser vendors support a small handful of platforms, but that's a poorly defined notion, I suggest this actually be a SHOULD. E.g. do we know if other browsers currently have sufficient access to UDP to implement even RTP? We can get the meaning across with less rigid language. Thanks for putting the draft together, =C2=A0-r --20cf307cffa685ead504b0dd860a Content-Type: application/octet-stream; name="giles-fixes-draft-01a.diff" Content-Disposition: attachment; filename="giles-fixes-draft-01a.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_guker44q0 ZGlmZiAtLWdpdCBhL2RyYWZ0LWplc3VwLXJ0Y3dlYi1kYXRhLnhtbCBiL2RyYWZ0LWplc3VwLXJ0 Y3dlYi1kYXRhLnhtbAppbmRleCBmYWUxYWM4Li40NTFkYzk2IDEwMDY0NAotLS0gYS9kcmFmdC1q ZXN1cC1ydGN3ZWItZGF0YS54bWwKKysrIGIvZHJhZnQtamVzdXAtcnRjd2ViLWRhdGEueG1sCkBA IC01LDggKzUsOCBAQAogPD9yZmMgY29tcGFjdD0ieWVzIiA/PgogPD9yZmMgc29ydHJlZnM9Im5v IiA/PgogCi08cmZjIGlwcj0idHJ1c3QyMDA5MDIiCi0gICAgIGRvY05hbWU9ImRyYWZ0LWplc3Vw LXJ0Y3dlYi1kYXRhLTAxLnR4dCIgY2F0ZWdvcnk9J2luZm8nPgorPHJmYyBpcHI9InRydXN0MjAw OTAyIiBjYXRlZ29yeT0naW5mbycKKyAgICAgZG9jTmFtZT0iZHJhZnQtamVzdXAtcnRjd2ViLWRh dGEtMDEiPgogPGZyb250PgogICAgIDx0aXRsZSBhYmJyZXY9ImRhdGEgUDJQIGluIFJUQ1dFQiI+ CiAgICAgICAgUlRDV2ViIERhdGFncmFtIENvbm5lY3Rpb24KQEAgLTE2LDQyICsxNiw0MiBAQAog ICAgIDxhdXRob3IgaW5pdGlhbHM9IlIuIiBzdXJuYW1lPSJKZXN1cCIgZnVsbG5hbWU9IlJhbmRl bGwgSmVzdXAiPgogICAgICAgPG9yZ2FuaXphdGlvbj5Nb3ppbGxhPC9vcmdhbml6YXRpb24+CiAg ICAgICA8YWRkcmVzcz4KLQk8cG9zdGFsPgorICAgICAgICA8cG9zdGFsPgogICAgICAgICAgIDxz dHJlZXQ+PC9zdHJlZXQ+Ci0JICA8Y29kZT48L2NvZGU+IAotCSAgPGNpdHk+PC9jaXR5PiAKLQkg IDxjb3VudHJ5PjwvY291bnRyeT4KLSAJPC9wb3N0YWw+Ci0JPGVtYWlsPnJhbmRlbGwtaWV0ZkBq ZXN1cC5vcmc8L2VtYWlsPgorICAgICAgICAgIDxjb2RlPjwvY29kZT4KKyAgICAgICAgICA8Y2l0 eT48L2NpdHk+CisgICAgICAgICAgPGNvdW50cnk+PC9jb3VudHJ5PgorICAgICAgICA8L3Bvc3Rh bD4KKyAgICAgICAgPGVtYWlsPnJhbmRlbGwtaWV0ZkBqZXN1cC5vcmc8L2VtYWlsPgogICAgICAg PC9hZGRyZXNzPgogICAgIDwvYXV0aG9yPgogCiAKIAotICAgPGF1dGhvciBpbml0aWFscz0iUy4i IHN1cm5hbWU9IkxvcmV0byIgZnVsbG5hbWU9IlNhbHZhdG9yZSBMb3JldG8iPgotICAgIDxvcmdh bml6YXRpb24+RXJpY3Nzb248L29yZ2FuaXphdGlvbj4KLSAgICA8YWRkcmVzcz4KLSAgICAJPHBv c3RhbD4KLSAgICAgICAgPHN0cmVldD5IaXJzYWxhbnRpZSAxMTwvc3RyZWV0PgotICAgICAgICA8 Y29kZT4wMjQyMDwvY29kZT4gCi0gICAgIAkgIDxjaXR5PkpvcnZhczwvY2l0eT4gCi0gICAgCSAg PGNvdW50cnk+RmlubGFuZDwvY291bnRyeT4KLSAgICAgCTwvcG9zdGFsPgotICAgIAk8ZW1haWw+ c2FsdmF0b3JlLmxvcmV0b0Blcmljc3Nvbi5jb208L2VtYWlsPgotICAgIDwvYWRkcmVzcz4KLSAg PC9hdXRob3I+CisgICAgPGF1dGhvciBpbml0aWFscz0iUy4iIHN1cm5hbWU9IkxvcmV0byIgZnVs bG5hbWU9IlNhbHZhdG9yZSBMb3JldG8iPgorICAgICAgPG9yZ2FuaXphdGlvbj5Fcmljc3Nvbjwv b3JnYW5pemF0aW9uPgorICAgICAgPGFkZHJlc3M+CisgICAgICAgIDxwb3N0YWw+CisgICAgICAg ICAgPHN0cmVldD5IaXJzYWxhbnRpZSAxMTwvc3RyZWV0PgorICAgICAgICAgIDxjb2RlPjAyNDIw PC9jb2RlPgorICAgICAgICAgIDxjaXR5PkpvcnZhczwvY2l0eT4KKyAgICAgICAgICA8Y291bnRy eT5GaW5sYW5kPC9jb3VudHJ5PgorICAgICAgICA8L3Bvc3RhbD4KKyAgICAgICAgPGVtYWlsPnNh bHZhdG9yZS5sb3JldG9AZXJpY3Nzb24uY29tPC9lbWFpbD4KKyAgICAgIDwvYWRkcmVzcz4KKyAg ICA8L2F1dGhvcj4KIAogCiAgICAgPGF1dGhvciBpbml0aWFscz0iTS4iIHN1cm5hbWU9IlR1ZXhl biIgZnVsbG5hbWU9Ik1pY2hhZWwgVHVleGVuIj4KICAgICAgIDxvcmdhbml6YXRpb24+TXVlbnN0 ZXIgVW5pdmVyc2l0eSBvZiBBcHBsaWVkIFNjaWVuY2VzPC9vcmdhbml6YXRpb24+CiAgICAgICA8 YWRkcmVzcz4KLQk8cG9zdGFsPgorICAgICAgICA8cG9zdGFsPgogICAgICAgICAgIDxzdHJlZXQ+ U3RlZ2Vyd2FsZHN0cmFzc2UgMzk8L3N0cmVldD4KLQkgIDxjb2RlPjQ4NTY1PC9jb2RlPiAKLQkg IDxjaXR5PiBTdGVpbmZ1cnQ8L2NpdHk+IAotCSAgPGNvdW50cnk+R2VybWFueTwvY291bnRyeT4K LSAJPC9wb3N0YWw+Ci0JPGVtYWlsPnR1ZXhlbkBmaC1tdWVuc3Rlci5kZTwvZW1haWw+CisgICAg ICAgICAgPGNvZGU+NDg1NjU8L2NvZGU+CisgICAgICAgICAgPGNpdHk+IFN0ZWluZnVydDwvY2l0 eT4KKyAgICAgICAgICA8Y291bnRyeT5HZXJtYW55PC9jb3VudHJ5PgorICAgICAgICA8L3Bvc3Rh bD4KKyAgICAgICAgPGVtYWlsPnR1ZXhlbkBmaC1tdWVuc3Rlci5kZTwvZW1haWw+CiAgICAgICA8 L2FkZHJlc3M+CiAgICAgPC9hdXRob3I+CiAKQEAgLTY1LDEyICs2NSw5IEBACiAgICAgPGFic3Ry YWN0PgogICAgIDx0PgogVGhpcyBkb2N1bWVudCBpbnZlc3RpZ2F0ZXMgdGhlIHBvc3NpYmlsaXRp ZXMgZm9yIGRlc2lnbmluZyBhIGdlbmVyaWMgdHJhbnNwb3J0Ci1zZXJ2aWNlIHRoYXQgYWxsb3dz IFdlYiBCcm93c2VyIHRvIGV4Y2hhbmdlIGdlbmVyaWMgZGF0YSBpbiBhIHBlZXIgdG8gcGVlciB3 YXkuCi1TZXZlcmFsLCBhbHJlYWR5IHN0YW5kYXJkaXplZCBieSBJRVRGLCB0cmFuc3BvcnQgcHJv dG9jb2xzIGFuZCB0aGVpciBwcm9wZXJ0aWVzIGFyZSBpbnZlc3RpZ2F0ZWQgaW4gb3JkZXIKLXRv IGlkZW50aWZ5IHRoZSBtb3N0IGFwcHJvcHJpYXRlIG9uZS4KLSAgICA8L3Q+Ci0gICAgPHQ+Ci0K K3NlcnZpY2UgdGhhdCBhbGxvd3MgV2ViIEJyb3dzZXJzIHRvIGV4Y2hhbmdlIGdlbmVyaWMgZGF0 YSBpbiBhIHBlZXItdG8tcGVlcgord2F5LiBTZXZlcmFsIHRyYW5zcG9ydCBwcm90b2NvbHMgYWxy ZWFkeSBzdGFuZGFyZGl6ZWQgYnkgdGhlIElFVEYgYXJlCitpbnZlc3RpZ2F0ZWQgaW4gb3JkZXIg dG8gaWRlbnRpZnkgdGhlIG1vc3QgYXBwcm9wcmlhdGUgb25lLgogICAgIDwvdD4KIAogICAgIDwv YWJzdHJhY3Q+CkBAIC03OSwxOSArNzYsMTkgQEAgdG8gaWRlbnRpZnkgdGhlIG1vc3QgYXBwcm9w cmlhdGUgb25lLgogCiA8c2VjdGlvbiB0aXRsZT0iSW50cm9kdWN0aW9uIj4KIDx0PlRoZSBpc3N1 ZSBvZiBob3cgYmVzdCB0byBoYW5kbGUgbm9uLW1lZGlhIGRhdGEgdHlwZXMgaW4gdGhlIGNvbnRl eHQgb2YgUlRDV0VCIGlzIHN0aWxsIHVuZGVyIGRpc2N1c3Npb24KLWluIHRoZSBtYWlsaW5nIGxp c3Q7IHRoZXJlIGhhdmUgYmVlbiBzZXZlcmFsIHByb3Bvc2FscyBvbiBob3cgdG8gYWRkcmVzcyB0 aGlzIHByb2JsZW0sIGJ1dCB0aGVyZSBpcyBub3QgeWV0IGEgY2xlYXIgY29uc2Vuc3VzIAotb24g dGhlIGFjdHVhbCBzb2x1dGlvbi48L3Q+CitvbiB0aGUgbWFpbGluZyBsaXN0OyB0aGVyZSBoYXZl IGJlZW4gc2V2ZXJhbCBwcm9wb3NhbHMgb24gaG93IHRvIGFkZHJlc3MgdGhpcyBwcm9ibGVtLCBi dXQgdGhlcmUgaXMgbm90IHlldCBhIGNsZWFyIGNvbnNlbnN1cworb24gYSBzb2x1dGlvbi48L3Q+ CiAKLTx0Pkhvd2V2ZXIgaXQgc2VlbXMgdG8gYmUgYSBnZW5lcmFsIGFncmVlbWVudCB0aGF0IGZv ciBOQVQgdHJhdmVyc2FsIHB1cnBvc2UgaXQgaGFzIHRvIGJlOjwvdD4KKzx0Pkhvd2V2ZXIsIGl0 IHNlZW1zIHRvIGJlIGEgZ2VuZXJhbCBhZ3JlZW1lbnQgdGhhdCBmb3IgTkFUIHRyYXZlcnNhbCBw dXJwb3NlIGl0IGhhcyB0byBiZTo8L3Q+CiA8dD5GT08vVURQL0lQPC90PgotPHQ+b3IgbW9zdCBs aWtlbHk6PC90PiAKKzx0Pm9yIG1vc3QgbGlrZWx5OjwvdD4KIDx0PkZPTy9EVExTL1VEUC9JUCAo Zm9yIGNvbmZpZGVudGlhbGl0eSwgc291cmNlIGF1dGhlbnRpY2F0ZWQsIGludGVncml0eSBwcm90 ZWN0ZWQgdHJhbnNmZXJzKTwvdD4KIDx0PndoZXJlIEZPTyBpcyBhIHByb3RvY29sIHRoYXQgaXMg c3VwcG9zZWQgdG8gcHJvdmlkZSBjb25nZXN0aW9uIGNvbnRyb2wgYW5kIHBvc3NpYmxlIHNvbWUg dHlwZSBvZiBmcmFtaW5nIG9yIHN0cmVhbSBjb25jZXB0LjwvdD4KIAotPHQ+TW9yZW92ZXIgdGhl cmUgaGFzIGJlZW4gYSBjbGVhciBpbnRlcmVzdCBmb3IgYm90aCBhbiB1bnJlbGlhYmxlIGFuZCBh IHJlbGlhYmxlIHBlZXIgdG8gcGVlciBkYXRhZ3JhbSBiYXNlZCBjaGFubmVsLjwvdD4KKzx0Pk1v cmVvdmVyLCB0aGVyZSBoYXMgYmVlbiBhIGNsZWFyIGludGVyZXN0IGZvciBib3RoIGFuIHVucmVs aWFibGUgYW5kIGEgcmVsaWFibGUgcGVlci10by1wZWVyIGRhdGFncmFtIGJhc2VkIGNoYW5uZWwu PC90PgogCi08dD5UaGlzIGRvY3VtZW50IHByb3ZpZGVzIFJlcXVpcmVtZW50IGFuZCB1c2UgY2Fz ZXMgZm9yIGJvdGggdW5yZWxpYWJsZSBhbmQgcmVsaWFibGUgcGVlciB0byBwZWVyIGRhdGFncmFt IGJhc2UgY2hhbm5lbCwKLXByb3ZpZGUgYW4gb3ZlcnZpZXcgb2YgdGhlIHBybyBhbmQgY29ucyBv ZiB0aGUgZGlmZmVyZW50IHByb3Bvc2VkIHNvbHV0aW9ucywgYW5kIGZpbmFsbHkgYW5hbHl6ZSBp biBtb3JlIGRldGFpbCB0aGUgU0NUUAorPHQ+VGhpcyBkb2N1bWVudCBwcm92aWRlcyBSZXF1aXJl bWVudHMgYW5kIHVzZSBjYXNlcyBmb3IgYm90aCB1bnJlbGlhYmxlIGFuZCByZWxpYWJsZSBwZWVy LXRvLXBlZXIgZGF0YWdyYW0gYmFzZSBjaGFubmVscywKK3Byb3ZpZGVzIGFuIG92ZXJ2aWV3IG9m IHRoZSBwcm9zIGFuZCBjb25zIG9mIHRoZSBkaWZmZXJlbnQgcHJvcG9zZWQgc29sdXRpb25zLCBh bmQgZmluYWxseSBhbmFseXplcyBpbiBtb3JlIGRldGFpbCB0aGUgU0NUUAogYmFzZWQgc29sdXRp b24uPC90PgogCiAKQEAgLTExNiwzMiArMTEzLDMyIEBAIFRoaXMgc2VjdGlvbiBsaXN0cyB0aGUg cmVxdWlyZW1lbnRzIGZvciBQMlAgZGF0YSBjb25uZWN0aW9ucyBiZXR3ZWVuIHR3byBicm93c2Vy CiAgICAgIG1lZGlhIHN0cmVhbXMsIGFuZCB0aGF0IHRoZSBydGN3ZWIgUGVlckNvbm5lY3Rpb24g YXMgYSB3aG9sZSBpcwogICAgICBmYWlyIHdpdGggY29tcGV0aW5nIHN0cmVhbXMgc3VjaCBhcyBU Q1AuPC90Pjx0PjwvdD4KIAotICAgPHQgaGFuZ1RleHQ9IlJlcS4gNCI+VGhlIGFwcGxpY2F0aW9u IHNob3VsZCBiZSBhYmxlIHRvIHByb3ZpZGUgZ3VpZGFuY2UgYXMgdG8gdGhlIAorICAgPHQgaGFu Z1RleHQ9IlJlcS4gNCI+VGhlIGFwcGxpY2F0aW9uIHNob3VsZCBiZSBhYmxlIHRvIHByb3ZpZGUg Z3VpZGFuY2UgYXMgdG8gdGhlCiAgICAgIHJlbGF0aXZlIHByaW9yaXR5IG9mIGVhY2ggZGF0YWdy YW0gc3RyZWFtIHJlbGF0aXZlIHRvIGVhY2ggb3RoZXIsCiAgICAgIGFuZCByZWxhdGl2ZSB0byB0 aGUgbWVkaWEgc3RyZWFtcy4gWyBUQkQ6IGhvdyB0aGlzIGlzIGVuY29kZWQgYW5kCiAgICAgIHdo YXQgdGhlIGltcGFjdCBvZiB0aGlzIGlzLiBdICBUaGlzIHdpbGwgaW50ZXJhY3Qgd2l0aCB0aGUK ICAgICAgY29uZ2VzdGlvbiBjb250cm9sLjwvdD48dD48L3Q+CiAKLSAgIDx0IGhhbmdUZXh0PSJS ZXEuIDUiPkRhdGFncmFtIHN0cmVhbXMgbXVzdCBiZSBlbmNyeXB0ZWQ7IGFsbG93aW5nIGZvciBj b25maWRlbnRpYWxpdHksIAorICAgPHQgaGFuZ1RleHQ9IlJlcS4gNSI+RGF0YWdyYW0gc3RyZWFt cyBtdXN0IGJlIGVuY3J5cHRlZDsgYWxsb3dpbmcgZm9yIGNvbmZpZGVudGlhbGl0eSwKICAgICAg aW50ZWdyaXR5IGFuZCBzb3VyY2UgYXV0aGVudGljYXRpb24uIFNlZSB0aGUgc2VjdXJpdHkgc3Bl YyBbeHh4XSBmb3IgZGV0YWlsZWQgaW5mby48L3Q+PHQ+PC90PgogCiAKLSAgIDx0IGhhbmdUZXh0 PSJSZXEuIDYiPkNvbnNlbnQgYW5kIE5BVCB0cmF2ZXJzYWwgbWVjaGFuaXNtOiAgVGhlc2UgYXJl IGhhbmRsZWQgYnkgdGhlIAorICAgPHQgaGFuZ1RleHQ9IlJlcS4gNiI+Q29uc2VudCBhbmQgTkFU IHRyYXZlcnNhbCBtZWNoYW5pc206ICBUaGVzZSBhcmUgaGFuZGxlZCBieSB0aGUKICAgICAgUGVl ckNvbm5lY3Rpb24ncyBJQ0UgPHhyZWYgdGFyZ2V0PSJSRkM1MjQ1Ii8+IGNvbm5lY3Rpdml0eSBj aGVja3MgYW5kCiAgICAgIG9wdGlvbmFsIFRVUk4gc2VydmVycy48L3Q+PHQ+PC90PgogCi0gICA8 dCBoYW5nVGV4dD0iUmVxLiA3Ij4gRGF0YSBzdHJlYW1zIE1VU1QgcHJvdmlkZSBtZXNzYWdlIGZy YWdtZW50YXRpb24gc3VwcG9ydCBzdWNoIHRoYXQgSVAtbGF5ZXIgZnJhZ21lbnRhdGlvbiBkb2Vz IG5vdCBvY2N1ciBubyBtYXR0ZXIgaG93IGxhcmdlIGEgbWVzc2FnZS9idWZmZXIgdGhlIEphdmFz Y3JpcHQgYXBwbGljYXRpb24gcGFzc2VzIGRvd24gdG8gdGhlIEJyb3dzZXIgdG8gYmUgc2VudCBv dXQuPC90Pjx0PjwvdD4KKyAgIDx0IGhhbmdUZXh0PSJSZXEuIDciPiBEYXRhIHN0cmVhbXMgTVVT VCBwcm92aWRlIG1lc3NhZ2UgZnJhZ21lbnRhdGlvbiBzdXBwb3J0IHN1Y2ggdGhhdCBJUC1sYXll ciBmcmFnbWVudGF0aW9uIGRvZXMgbm90IG9jY3VyIG5vIG1hdHRlciBob3cgbGFyZ2UgYSBtZXNz YWdlL2J1ZmZlciB0aGUgSmF2YVNjcmlwdCBhcHBsaWNhdGlvbiBwYXNzZXMgZG93biB0byB0aGUg QnJvd3NlciB0byBiZSBzZW50IG91dC48L3Q+PHQ+PC90PgogCiAgICA8dCBoYW5nVGV4dD0iUmVj LiA4Ij4gVGhlIGRhdGEgc3RyZWFtIHRyYW5zcG9ydCBwcm90b2NvbCBNVVNUIE5PVCBlbmNvZGUg bG9jYWwgSVAgYWRkcmVzc2VzIGluc2lkZSBpdHMgcHJvdG9jb2wgZmllbGRzOyBkb2luZyBzbyBy ZXZlYWxzIHBvdGVudGlhbGx5IHByaXZhdGUgaW5mb3JtYXRpb24sIGFuZCBsZWFkcyB0byBmYWls dXJlIGlmIHRoZSBhZGRyZXNzIGlzIGRlcGVuZGVkIHVwb24uIDwvdD48dD48L3Q+CiAKICAgIDx0 IGhhbmdUZXh0PSJSZXEuIDkiPiBUaGUgZGF0YSBzdHJlYW0gcHJvdG9jb2wgU0hPVUxEIHN1cHBv cnQgdW5ib3VuZGVkLWxlbmd0aCAibWVzc2FnZXMiIChpLmUuLCBhIHZpcnR1YWwgc29ja2V0IHN0 cmVhbSkgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyLCBmb3Igc3VjaCB0aGluZ3MgYXMgaW1hZ2Ut ZmlsZS10cmFuc2Zlcjsgb3IgZWxzZSBpdCBNVVNUIHN1cHBvcnQgYXQgbGVhc3QgYSBtYXhpbXVt IGFwcGxpY2F0aW9uLWxheWVyIG1lc3NhZ2Ugc2l6ZSBvZiA0R0IuPC90Pjx0PjwvdD4KIAotICAg PHQgaGFuZ1RleHQ9IlJlcS4gMTAiPiBUaGUgZGF0YSBzdHJlYW0gcGFja2V0IGZvcm1hdC9lbmNv ZGluZyBNVVNUIGJlIHN1Y2ggdGhhdCBpdCBpcyBpbXBvc3NpYmxlIGZvciBhIG1hbGljaW91cyBK YXZhc2NyaXB0IHRvIGdlbmVyYXRlIGFuIGFwcGxpY2F0aW9uIG1lc3NhZ2UgY3JhZnRlZCBzdWNo IHRoYXQgaXQgY291bGQgYmUgaW50ZXJwcmV0ZWQgYXMgYSBuYXRpdmUgcHJvdG9jb2wgb3ZlciBV RFAgLSBzdWNoIGFzIFVQblAsIFJUUCwgU05NUCwgU1RVTiwgZXRjLiA8L3Q+PHQ+PC90PgorICAg PHQgaGFuZ1RleHQ9IlJlcS4gMTAiPiBUaGUgZGF0YSBzdHJlYW0gcGFja2V0IGZvcm1hdC9lbmNv ZGluZyBNVVNUIGJlIHN1Y2ggdGhhdCBpdCBpcyBpbXBvc3NpYmxlIGZvciBhIG1hbGljaW91cyBK YXZhU2NyaXB0IHRvIGdlbmVyYXRlIGFuIGFwcGxpY2F0aW9uIG1lc3NhZ2UgY3JhZnRlZCBzdWNo IHRoYXQgaXQgY291bGQgYmUgaW50ZXJwcmV0ZWQgYXMgYSBuYXRpdmUgcHJvdG9jb2wgb3ZlciBV RFAgLSBzdWNoIGFzIFVQblAsIFJUUCwgU05NUCwgU1RVTiwgZXRjLiA8L3Q+PHQ+PC90PgogCiAg ICA8dCBoYW5nVGV4dD0iUmVxLiAxMCI+IFRoZSBkYXRhIHN0cmVhbSB0cmFuc3BvcnQgcHJvdG9j b2wgTVVTVCBzdGFydCB3aXRoIHRoZSBhc3N1bXB0aW9uCiAgICBvZiBhIFBNVFUgb2YgMTI4MCBb ICoqKiBuZWVkIGp1c3RpZmljYXRpb24gKioqXSBieXRlcyB1bnRpbCBtZWFzdXJlZCBvdGhlcndp c2UuIDwvdD48dD48L3Q+CiAKLSAgIDx0IGhhbmdUZXh0PSJSZXEuIDExIj4gVGhlIGRhdGEgc3Ry ZWFtIHRyYW5zcG9ydCBwcm90b2NvbCBNVVNUIE5PVCByZWx5IG9uIElDTVAgYmVpbmcgZ2VuZXJh dGVkIAorICAgPHQgaGFuZ1RleHQ9IlJlcS4gMTEiPiBUaGUgZGF0YSBzdHJlYW0gdHJhbnNwb3J0 IHByb3RvY29sIE1VU1QgTk9UIHJlbHkgb24gSUNNUCBiZWluZyBnZW5lcmF0ZWQKICAgIG9yIGJl aW5nIHBhc3NlZCBiYWNrLCBzdWNoIGFzIGZvciBQTVRVIGRpc2NvdmVyeS4gPC90Pjx0PjwvdD4K IAogCkBAIC0xNTgsOCArMTU1LDggQEAgVGhpcyBzZWN0aW9uIGxpc3RzIHRoZSByZXF1aXJlbWVu dHMgZm9yIFAyUCBkYXRhIGNvbm5lY3Rpb25zIGJldHdlZW4gdHdvIGJyb3dzZXIKIAogICAgPHQg aGFuZ1RleHQ9IlUtQyAxIj5BIHJlYWwtdGltZSBnYW1lIHdoZXJlIHBvc2l0aW9uIGFuZCBvYmpl Y3Qgc3RhdGUgaW5mb3JtYXRpb24gaXMKICAgIHNlbnQgdmlhIG9uZSBvciBtb3JlIHVucmVsaWFi bGUgZGF0YSBjaGFubmVscy4gIE5vdGUgdGhhdCBhdCBhbnkgdGltZSB0aGVyZSBtYXkgYmUgbm8g bWVkaWEgY2hhbm5lbHMsIG9yIGFsbCBtZWRpYSBjaGFubmVscyBtYXkgYmUgaW5hY3RpdmUuPC90 Pjx0PjwvdD4KLQkKLSAgIDx0IGhhbmdUZXh0PSJVLUMgMiI+Tm9uLWNyaXRpY2FsIHN0YXRlIHVw ZGF0ZXMgYWJvdXQgYSB1c2VyIGluIGEgdmlkZW8gY2hhdCBvciAKKworICAgPHQgaGFuZ1RleHQ9 IlUtQyAyIj5Ob24tY3JpdGljYWwgc3RhdGUgdXBkYXRlcyBhYm91dCBhIHVzZXIgaW4gYSB2aWRl byBjaGF0IG9yCiAgICBjb25mZXJlbmNlLCBzdWNoIGFzIE11dGUgc3RhdGUuPC90Pjx0PjwvdD4K IAogPC9saXN0PjwvdD4KQEAgLTE3NywxMCArMTc0LDEwIEBAIFRoaXMgc2VjdGlvbiBsaXN0cyB0 aGUgcmVxdWlyZW1lbnRzIGZvciBQMlAgZGF0YSBjb25uZWN0aW9ucyBiZXR3ZWVuIHR3byBicm93 c2VyCiAgICB0cmFuc2ZlcnJlZCwgc3VjaCBhcyBjb250cm9sIGluZm9ybWF0aW9uLiAgVHlwaWNh bGx5IHRoaXMgd291bGQgYmUgZGF0YWdyYW1zLiAgU3VjaCBhIGdhbWUgbWF5CiAgICBoYXZlIG5v IG1lZGlhIGNoYW5uZWxzLCBvciB0aGV5IG1heSBiZSBpbmFjdGl2ZSBhdCBhbnkgZ2l2ZW4gdGlt ZSwgb3IgbWF5IG9ubHkgYmUgYWRkZWQKICAgIGR1ZSB0byBpbi1nYW1lIGFjdGlvbnMuPC90Pjx0 PjwvdD4KLQkKKwogICAgPHQgaGFuZ1RleHQ9IlUtQyA0Ij5Ob24tcmVhbHRpbWUgZmlsZSB0cmFu c2ZlcnMgYmV0d2VlbiBwZW9wbGUgY2hhdHRpbmcuICBUaGlzIGNvdWxkIGJlIGRhdGFncmFtcyBv ciBzdHJlYW1pbmc7IHN0cmVhbWluZyBtaWdodCBiZSBhbiBlYXNpZXIgZml0PC90Pjx0PjwvdD4K IAotICAgPHQgaGFuZ1RleHQ9IlUtQyA1Ij5SZWFsdGltZSB0ZXh0IGNoYXQgd2hpbGUgdGFsa2lu ZyB3aXRoIGFuIGluZGl2aWR1YWwgb3Igd2l0aCBtdWx0aXBsZSBwZW9wbGUgaW4gYSAKKyAgIDx0 IGhhbmdUZXh0PSJVLUMgNSI+UmVhbHRpbWUgdGV4dCBjaGF0IHdoaWxlIHRhbGtpbmcgd2l0aCBh biBpbmRpdmlkdWFsIG9yIHdpdGggbXVsdGlwbGUgcGVvcGxlIGluIGEKICAgIGNvbmZlcmVuY2Uu ICBUeXBpY2FsbHkgdGhpcyB3b3VsZCBiZSBkYXRhZ3JhbXMuPC90Pjx0PjwvdD4KIAogICAgPHQg aGFuZ1RleHQ9IlUtQyA2Ij5SZW5lZ290aWF0aW9uIG9mIHRoZSBzZXQgb2YgbWVkaWEgc3RyZWFt cyBpbiB0aGUgUGVlckNvbm5lY3Rpb24uICBUeXBpY2FsbHkgdGhpcyB3b3VsZCBiZSBkYXRhZ3Jh bXM8L3Q+PHQ+PC90PgpAQCAtMjA4LDEwICsyMDUsMTAgQEAgVGhpcyBzZWN0aW9uIGxpc3RzIHRo ZSByZXF1aXJlbWVudHMgZm9yIFAyUCBkYXRhIGNvbm5lY3Rpb25zIGJldHdlZW4gdHdvIGJyb3dz ZXIKICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICB8IFNUVU4gfCBEQ0NQIHwK ICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsKLSAgICAgICAgICB8ICAgIElDRSAgICAgIHwgCi0g ICAgICAgICAgKy0tLS0tLS0tLS0tLS0rIAorICAgICAgICAgIHwgICAgSUNFICAgICAgfAorICAg ICAgICAgICstLS0tLS0tLS0tLS0tKwogICAgICAgICAgIHwgVURQMSB8IFVEUDIgfC4uLgotICAg ICAgICAgICstLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgCisgICAgICAgICAgKy0tLS0tLS0t LS0tLS0rCiAgICAgXV0+CiAgICAgICAgIDwvYXJ0d29yaz48L2ZpZ3VyZT4KIApAQCAtMjM0LDgg KzIzMSw4IEBAIHRocm91Z2ggdGhlIGV4Y2hhbmdlIG9mIGZlYXR1cmUgbmVnb3RpYXRpb24gb3B0 aW9ucyBpbiBEQ0NQIGhlYWRlcnMuPC90Pgogb3ZlciB0aGUgbG9uZyB0ZXJtIGNvbnNpc3RlbnQg d2l0aCB0aGUgdXNlIG9mIGVuZC10by1lbmQgY29uZ2VzdGlvbiBjb250cm9sIGJ1dCByZWR1Y2Vz IHRoZSBjb25nZXN0aW9uIHdpbmRvdyBieSBoYWxmIHVwb24gY29uZ2VzdGlvbiBkZXRlY3Rpb24u CiBBcHBsaWNhdGlvbnMgdGhhdCBwcmVmZXIgYSBsYXJnZSBhbW91bnQgb2YgYmFuZHdpZHRoIGFz IGZlYXNpYmxlIG92ZXIgdGhlIGxvbmdlciB0ZXJtcyBzaG91bGQgdXNlIENDSUQyLiA8L3Q+CiAK LTx0PkNDSUQgMyA8eHJlZiB0YXJnZXQ9IlJGQzQzNDIiLz4sIFRDUCBmcmllbmRseSByYXRlIGNv bnRyb2wgbWVjaGFuaXNtKFRGUkMpLCBkZW5vdGVzIGFuIGVxdWF0aW9uLWJhc2VkIGFuZCByYXRl IGNvbnRyb2xsZWQgY29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbXMgZGVzaWduZWQgCi10byBi ZSByZWFzb25hYmx5IGZhaXIgd2hlbiBjb21wZXRpbmcgZm9yIGJhbmR3aWR0aCB3aXRoIFRDUCBs aWtlIGZsb3dzLiBJdCBzaG93cyBtdWNoIGxvd2VyIHZhcmlhdGlvbiBvZiB0aHJvdWdocHV0IG92 ZXIgdGltZSBjb21wYXJlZCB3aXRoIFRDUCB0aGF0IG1ha2VzIENDSUQgMyAKKzx0PkNDSUQgMyA8 eHJlZiB0YXJnZXQ9IlJGQzQzNDIiLz4sIFRDUCBmcmllbmRseSByYXRlIGNvbnRyb2wgbWVjaGFu aXNtKFRGUkMpLCBkZW5vdGVzIGFuIGVxdWF0aW9uLWJhc2VkIGFuZCByYXRlIGNvbnRyb2xsZWQg Y29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbXMgZGVzaWduZWQKK3RvIGJlIHJlYXNvbmFibHkg ZmFpciB3aGVuIGNvbXBldGluZyBmb3IgYmFuZHdpZHRoIHdpdGggVENQIGxpa2UgZmxvd3MuIEl0 IHNob3dzIG11Y2ggbG93ZXIgdmFyaWF0aW9uIG9mIHRocm91Z2hwdXQgb3ZlciB0aW1lIGNvbXBh cmVkIHdpdGggVENQIHRoYXQgbWFrZXMgQ0NJRCAzCiBtb3JlIHN1aXRhYmxlIHRoYW4gQ0NJRCAy IGZvciBhcHBsaWNhdGlvbnMgc3VjaCBhcyBzdHJlYW1pbmcgbWVkaWEgY29udGVudCB0aGF0IHBy ZWZlcnMgdG8gbWluaW1pemUgYWJydXB0IGNoYW5nZXMgaW4gdGhlIHNlbmRpbmcgcmF0ZS4gPC90 PgogCiA8dD5DQ0lEIDQgPHhyZWYgdGFyZ2V0PSJSRkM1NjIyIi8+IGlzIGEgbW9kaWZpZWQgdmVy c2lvbiBvZiBDQ0lEIDMgYW5kIGRlc2lnbmVkIGZvciBhcHBsaWNhdGlvbnMgdGhhdCB1c2UgYSBz bWFsbCBmaXhlZCBzZWdtZW50IHNpemUsIG9yIGNoYW5nZSB0aGVpciBzZW5kaW5nIHJhdGUgYnkg dmFyeWluZyB0aGUgc2VnbWVudCBzaXplLgpAQCAtMjU5LDE3ICsyNTYsMTcgQEAgYmV0d2VlbiBk YXRhIHBhY2tldHMgcmVnYXJkbGVzcyBvZiB0aGUgYWxsb3dlZCB0cmFuc21pdCByYXRlLjwvdD4K ICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICB8IFNUVU4gfCBEVExTIHwKICAg ICAgICAgICArLS0tLS0tLS0tLS0tLSsKLSAgICAgICAgICB8ICAgIElDRSAgICAgIHwgCi0gICAg ICAgICAgKy0tLS0tLS0tLS0tLS0rIAorICAgICAgICAgIHwgICAgSUNFICAgICAgfAorICAgICAg ICAgICstLS0tLS0tLS0tLS0tKwogICAgICAgICAgIHwgVURQMSB8IFVEUDIgfC4uLgotICAgICAg ICAgICstLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgCisgICAgICAgICAgKy0tLS0tLS0tLS0t LS0rCiAgICAgXV0+CiAgICAgICAgIDwvYXJ0d29yaz48L2ZpZ3VyZT4KIAotPHQ+QW4gU0NUUCA8 eHJlZiB0YXJnZXQ9IlJGQzQ5NjAiLz4gYmFzZWQgc29sdXRpb24gd2lsbCBwcm92aWRlIHNldmVy YWwgaW50ZXJlc3RpbmcgZmVhdHVyZXMgYW1vbmcgdGhlIG90aGVyczogTXVsdGlzdHJlYW1pbmcs IE9yZGVyZWQgYW5kIFVub3JkZXJlZCBkZWxpdmVyeSwKKzx0PkFuIFNDVFAgPHhyZWYgdGFyZ2V0 PSJSRkM0OTYwIi8+IGJhc2VkIHNvbHV0aW9uIHdpbGwgcHJvdmlkZSBzZXZlcmFsIGludGVyZXN0 aW5nIGZlYXR1cmVzIGFtb25nIHRoZSBvdGhlcnM6IE11bHRpLXN0cmVhbWluZywgT3JkZXJlZCBh bmQgVW5vcmRlcmVkIGRlbGl2ZXJ5LAogUmVsaWFiaWxpdHkgYW5kIHBhcnRpYWwtUmVsaWFiaWxp dHkgPHhyZWYgdGFyZ2V0PSJSRkMzNzU4Ii8+LCBhbmQgRHluYW1pYyBBZGRyZXNzIFJlY29uZmln dXJhdGlvbiA8eHJlZiB0YXJnZXQ9IlJGQzUwNjEiLz4uPC90PgogCi08dD5Nb3Jlb3ZlciBTQ1RQ IHByb3ZpZGVzIHRoZSBwb3NzaWJpbGl0eSB0byB0cmFuc3BvcnQgZGlmZmVyZW50ICJwcm90b2Nv bHMiIG92ZXIgbXVsdGlwbGUgc3RyZWFtcyBhbmQgYXNzb2NpYXRpb25zIHVzaW5nIHRoZSBwcGlk IChQYXlsb2FkIFByb3RvY29sIElkZW50aWZpZXIpLiAKKzx0Pk1vcmVvdmVyIFNDVFAgcHJvdmlk ZXMgdGhlIHBvc3NpYmlsaXR5IHRvIHRyYW5zcG9ydCBkaWZmZXJlbnQgInByb3RvY29scyIgb3Zl ciBtdWx0aXBsZSBzdHJlYW1zIGFuZCBhc3NvY2lhdGlvbnMgdXNpbmcgdGhlIHBwaWQgKFBheWxv YWQgUHJvdG9jb2wgSWRlbnRpZmllcikuCiBBbiBhcHBsaWNhdGlvbiBjYW4gc2V0IGEgIGRpZmZl cmVudCBQUElEIHdpdGggZWFjaCBzZW5kIGNhbGwuIFRoaXMgYWxsb3dzIHRoZSByZWNlaXZpbmcg YXBwbGljYXRpb24gdG8gbG9vayBhdCB0aGlzIGluZm9ybWF0aW9uIChhcyB3ZWxsIGFzIHRoZSBz dHJlYW0gaWQvc2VxKSBvbiByZWNlaXZpbmcKIHRvIGtub3cgd2hhdCB0eXBlIG9mIHByb3RvY29s IHRoZSBkYXRhIHBheWxvYWQgaGFzLjwvdD4KIApAQCAtMjk4LDEwICsyOTUsMTAgQEAgb2YgdGhl IHBsYWluIFVEUC48L3Q+CiAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgfCBT VFVOIHwgRFRMUyB8CiAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rCi0gICAgICAgICAgfCAgICBJ Q0UgICAgICB8IAotICAgICAgICAgICstLS0tLS0tLS0tLS0tKyAKKyAgICAgICAgICB8ICAgIElD RSAgICAgIHwKKyAgICAgICAgICArLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICB8IFVEUDEgfCBV RFAyIHwuLi4KLSAgICAgICAgICArLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgIAorICAgICAg ICAgICstLS0tLS0tLS0tLS0tKwogICAgIF1dPgogICAgICAgICA8L2FydHdvcms+PC9maWd1cmU+ CiAKQEAgLTMxNSwyNiArMzEyLDI2IEBAIG9mIHRoZSBwbGFpbiBVRFAuPC90PgogICAgICAgICAg ICAgICAgICAgICArLS0tLS0tKwogICAgICAgICAgICAgICAgICAgICB8V0VCQVBQfAogICAgICAg ICAgICAgICAgICAgICArLS0tLS0tKwotICAgICAgICAgICAgICAgICAgICB8RlJBTUUgfCAKKyAg ICAgICAgICAgICAgICAgICAgfEZSQU1FIHwKICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLSsK ICAgICAgICAgICAgICAgICAgICAgfCBUQ1AgIHwKICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LSsKICAgICAgICAgICAgICB8IFNUVU4gfCBEVExTIHwKICAgICAgICAgICAgICArLS0tLS0tLS0t LS0tLSsKLSAgICAgICAgICAgICB8ICAgIElDRSAgICAgIHwgCi0gICAgICAgICAgICAgKy0tLS0t LS0tLS0tLS0rIAorICAgICAgICAgICAgIHwgICAgSUNFICAgICAgfAorICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tKwogICAgICAgICAgICAgIHwgVURQMSB8IFVEUDIgfC4uLgogICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tKwogICAgIF1dPgogICAgICAgICA8L2FydHdvcms+PC9maWd1cmU+ CiAKLTx0PkxheWVyaW5nIFRDUCBhdG9wIERUTFMgb3IgVURQIGlzIGFuIGFwcHJvYWNoIHRoYXQg aGFzIGJlZW4gc3VnZ2VzdGVkIHNldmVyYWwgdGltZXMgaW4gdGhlIHBhc3QsIGluY2x1ZGluZyBU Q1Atb3Zlci1VRFAgCis8dD5MYXllcmluZyBUQ1AgYXRvcCBEVExTIG9yIFVEUCBpcyBhbiBhcHBy b2FjaCB0aGF0IGhhcyBiZWVuIHN1Z2dlc3RlZCBzZXZlcmFsIHRpbWVzIGluIHRoZSBwYXN0LCBp bmNsdWRpbmcgVENQLW92ZXItVURQCiA8eHJlZiB0YXJnZXQ9J0ktRC5iYXNldC10c3Z3Zy10Y3At b3Zlci11ZHAnLz4gYW5kIFVEUC1FbmNhcHN1bGF0ZWQgVHJhbnNwb3J0IFByb3RvY29scyA8eHJl ZiB0YXJnZXQ9J0ktRC5kZW5pcy11ZHAtdHJhbnNwb3J0Jy8+LjwvdD4KIAotPHQ+QSBzaW1pbGFy IG1lY2hhbmlzbSBoYXMgYWxzbyBiZWVuIHVzZWQgZm9yIEdvb2dsZSBUYWxrJ3MgcGVlci10by1w ZWVyIGZpbGUgdHJhbnNmZXIgcHJvdG9jb2wsIGltcGxlbWVudGVkIGluIHRoZSBsaWJqaW5nbGUg bGlicmFyeSBhcyAiUHNldWRvVGNwIiAKLVtodHRwOi8vY29kZS5nb29nbGUuY29tL3AvbGliamlu Z2xlL3NvdXJjZS9icm93c2UvdHJ1bmsvdGFsay9wMnAvYmFzZS9wc2V1ZG90Y3AuY2NdLiAKLUlu IHRoaXMgaW1wbGVtZW50YXRpb24sIGEgbGlnaHR3ZWlnaHQgdXNlcnNwYWNlIFRDUCBzdGFjayBo YXMgYmVlbiBkZXZlbG9wZWQgd2l0aCBzdXBwb3J0IGZvciBhIGZhaXJseSBtaW5pbWFsIHNldCBv ZiBUQ1Agb3B0aW9ucywgbmFtZWx5IGRlbGF5ZWQgYWNrbm93bGVkZ2VtZW50cywgCi1OYWdsZSwg ZmFzdCByZXRyYW5zbWl0LCBmYXN0IHJlY292ZXJ5IChOZXdSZW5vKSwgdGltZXN0YW1wcywgYW5k IHdpbmRvdyBzY2FsaW5nLiBTb21lIGZlYXR1cmVzIGhhdmUgYmVlbiByZW1vdmVkLCBzdWNoIGFz IHVyZ2VudCBkYXRhLiAKKzx0PkEgc2ltaWxhciBtZWNoYW5pc20gaGFzIGFsc28gYmVlbiB1c2Vk IGZvciBHb29nbGUgVGFsaydzIHBlZXItdG8tcGVlciBmaWxlIHRyYW5zZmVyIHByb3RvY29sLCBp bXBsZW1lbnRlZCBpbiB0aGUgbGliamluZ2xlIGxpYnJhcnkgYXMgIlBzZXVkb1RjcCIKK1todHRw Oi8vY29kZS5nb29nbGUuY29tL3AvbGliamluZ2xlL3NvdXJjZS9icm93c2UvdHJ1bmsvdGFsay9w MnAvYmFzZS9wc2V1ZG90Y3AuY2NdLgorSW4gdGhpcyBpbXBsZW1lbnRhdGlvbiwgYSBsaWdodHdl aWdodCB1c2Vyc3BhY2UgVENQIHN0YWNrIGhhcyBiZWVuIGRldmVsb3BlZCB3aXRoIHN1cHBvcnQg Zm9yIGEgZmFpcmx5IG1pbmltYWwgc2V0IG9mIFRDUCBvcHRpb25zLCBuYW1lbHkgZGVsYXllZCBh Y2tub3dsZWRnZW1lbnRzLAorTmFnbGUsIGZhc3QgcmV0cmFuc21pdCwgZmFzdCByZWNvdmVyeSAo TmV3UmVubyksIHRpbWVzdGFtcHMsIGFuZCB3aW5kb3cgc2NhbGluZy4gU29tZSBmZWF0dXJlcyBo YXZlIGJlZW4gcmVtb3ZlZCwgc3VjaCBhcyB1cmdlbnQgZGF0YS4KIEFuZCBhcyBpbiB0aGUgYWZv cmVtZW50aW9uZWQgZHJhZnRzLCB0aGUgVENQIGhlYWRlciBoYXMgYmVlbiB0d2Vha2VkIHNsaWdo dGx5IHRvIHJlbW92ZSBmaWVsZHMgcmVkdW5kYW50IHdpdGggdGhlIFVEUCBoZWFkZXIsIG5hbWVs eSBzb3VyY2UvZGVzdGluYXRpb24gcG9ydCBhbmQgY2hlY2tzdW0uPC90PgogCiA8dD5UaGUgYWR2 YW50YWdlIG9mIHRoaXMgYXBwcm9hY2ggaXMgY2xlYXI7IFRDUCBpcyB3ZWxsLWtub3duIGFuZCB1 bmRlcnN0b29kLCBhbmQgaXRzIGNvbmdlc3Rpb24gY29udHJvbCBpcyBieSBkZWZpbml0aW9uIFRD UC1mYWlyLiBVc2VyLXNwYWNlIGltcGxlbWVudGF0aW9ucyBvZiBUQ1AgZXhpc3QsIGUuZy4gYXMg UHNldWRvVGNwLCB3aGljaCBoYXMgY29uc2lkZXJhYmxlIGRlcGxveW1lbnQgZXhwZXJpZW5jZS4g SXQgaXMgYWxzbyBwb3NzaWJsZSB0byBzdXBwb3J0IG11bHRpcGxleGluZyBvZiBkYXRhZ3JhbSBm bG93cyB3aXRoIHRoaXMgYXBwcm9hY2gsIGVpdGhlciBieSBhZGRpbmcgYSBzdHJlYW0gaWRlbnRp ZmllciB0byB0aGUgVENQIGhlYWRlciAoaW4gcGxhY2Ugb2YgdGhlIHBvcnQgbnVtYmVycywgcGVy aGFwcyksIG9yIGRvaW5nIHRoZSBzYW1lIGluIGEgaGlnaGVyLWxldmVsIGZyYW1pbmcgbGF5ZXIu PC90PgpAQCAtMzU0LDggKzM1MSw4IEBAIEFuZCBhcyBpbiB0aGUgYWZvcmVtZW50aW9uZWQgZHJh ZnRzLCB0aGUgVENQIGhlYWRlciBoYXMgYmVlbiB0d2Vha2VkIHNsaWdodGx5IHRvCiAgICAgICAg ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgfFNUVU58RFRMU3wgU1JUUCB8 CiAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rCi0gICAgICAgICAgICAgfCAgICAgIElD RSAgICAgICB8IAotICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tKyAKKyAgICAgICAgICAg ICB8ICAgICAgSUNFICAgICAgIHwKKyAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsKICAg ICAgICAgICAgICB8IFVEUDEgfCBVRFAyIHwuLi4KICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LS0tLSsKICAgICBdXT4KQEAgLTM2Myw3ICszNjAsNyBAQCBBbmQgYXMgaW4gdGhlIGFmb3JlbWVu dGlvbmVkIGRyYWZ0cywgdGhlIFRDUCBoZWFkZXIgaGFzIGJlZW4gdHdlYWtlZCBzbGlnaHRseSB0 bwogCiA8dD5XaGVuIHNlbmRpbmcgUlRQIHdpdGggRFRMUywgcmF0aGVyIHRoYW4gZW5jYXBzdWxh dGluZyBSVFAgaW4gRFRMUywgU1JUUCBrZXlzIGFyZSBleHRyYWN0ZWQgZnJvbSB0aGUgRFRMUyBr ZXkgbWF0ZXJpYWwsIGFsbG93aW5nIHVzZSBvZiBTUlRQJ3MgbW9yZSBlZmZpY2llbnQgZm9ybWF0 LiBUaGlzIHNhbWUgYXBwcm9hY2ggY291bGQgYmUgZXh0ZW5kZWQgZm9yIHNlbmRpbmcgb2YgYXBw bGljYXRpb24gZGF0YSBhcyBhIFJUUCBwYXlsb2FkLjwvdD4KIAotPHQ+VGhlIGJlbmVmaXRzIG9m IHRoaXMgYXBwcm9hY2ggYXJlIGNlbnRlcmVkIGFyb3VuZCB0aGUgYWJpbGl0eSB0byByZXVzZSB0 aGUgZXhpc3RpbmcgbWVjaGFuaXNtcyBmb3IgYXVkaW8vdmlkZW8gZGF0YSBmb3IgYXBwbGljYXRp b24gZGF0YSwgYW5kIHRoZSByZXN1bHRhbnQgc2ltcGxpZmljYXRpb24gdGhhdCBvY2N1cnMuIElm IGV2ZXJ5dGhpbmcgZW5kcyB1cCBSVFAsIGFuZCBSVFAgcHJvdmlkZXMgaW5mb3JtYXRpb24gYWJv dXQgbG9zcyBhbmQgdGltaW5nLCB3ZSBjYW4gaGF2ZSBjb21tb24gZW5jcnlwdGlvbiwgY29uZ2Vz dGlvbiBjb250cm9sLCBhbmQgbXVsdGlwbGV4aW5nIG1lY2hhbmlzbXMgZm9yIGFsbCB0eXBlcyBv ZiBkYXRhLiBGb3IgZXhhbXBsZSwgd2UgY291bGQgdXNlIFJUUCBTU1JDIHRvIGRlbXV4IGRpZmZl cmVudCBhcHBsaWNhdGlvbiBkYXRhIHN0cmVhbXMsIGFuZCBSVENQIE5BQ0sgdG8gZmFjaWxpYXRl IHJlbGlhYmxlIGRlbGl2ZXJ5LjwvdD4KKzx0PlRoZSBiZW5lZml0cyBvZiB0aGlzIGFwcHJvYWNo IGFyZSBjZW50ZXJlZCBhcm91bmQgdGhlIGFiaWxpdHkgdG8gcmV1c2UgdGhlIGV4aXN0aW5nIG1l Y2hhbmlzbXMgZm9yIGF1ZGlvL3ZpZGVvIGRhdGEgZm9yIGFwcGxpY2F0aW9uIGRhdGEsIGFuZCB0 aGUgcmVzdWx0YW50IHNpbXBsaWZpY2F0aW9uIHRoYXQgb2NjdXJzLiBJZiBldmVyeXRoaW5nIGVu ZHMgdXAgUlRQLCBhbmQgUlRQIHByb3ZpZGVzIGluZm9ybWF0aW9uIGFib3V0IGxvc3MgYW5kIHRp bWluZywgd2UgY2FuIGhhdmUgY29tbW9uIGVuY3J5cHRpb24sIGNvbmdlc3Rpb24gY29udHJvbCwg YW5kIG11bHRpcGxleGluZyBtZWNoYW5pc21zIGZvciBhbGwgdHlwZXMgb2YgZGF0YS4gRm9yIGV4 YW1wbGUsIHdlIGNvdWxkIHVzZSBSVFAgU1NSQyB0byBkZW11eCBkaWZmZXJlbnQgYXBwbGljYXRp b24gZGF0YSBzdHJlYW1zLCBhbmQgUlRDUCBOQUNLIHRvIGZhY2lsaXRhdGUgcmVsaWFibGUgZGVs aXZlcnkuPC90PgogCiA8dD5PbiB0aGUgb3RoZXIgaGFuZCwgUlRQIGhhcyBhIG51bWJlciBvZiBz ZW1hbnRpY3MgYXNzb2NpYXRlZCB3aXRoIGl0IHRoYXQgYXJlbid0IG5lY2Vzc2FyaWx5IGEgZ29v ZCBmaXQgZm9yIGFyYml0cmFyeSBhcHBsaWNhdGlvbiBkYXRhLiBXaGlsZSB0aGUgUlRQIHRpbWVz dGFtcCwgc2VxdWVuY2UgbnVtYmVyIGFuZCBTU1JDIGZpZWxkcyBhcmUgbWVhbmluZ2Z1bCwgdGhl cmUgYXJlIGEgbnVtYmVyIG9mIG90aGVyIGhlYWRlciBmaWVsZHMgdGhhdCBtYXkgbm90IG1ha2Ug c2Vuc2UsIGFuZCB0aGUgYXBwbGljYWJpbGl0eSBvZiBSVFAncyBub3Rpb25zIG9mIHRpbWluZywg bWVkaWEgcGxheW91dCwgYW5kIGNvbnRyb2wgZmVlZGJhY2sgaXMgdW5jbGVhci48L3Q+CiA8L3Nl Y3Rpb24+CkBAIC0zNzksMjEgKzM3NiwyMSBAQCBBbmQgYXMgaW4gdGhlIGFmb3JlbWVudGlvbmVk IGRyYWZ0cywgdGhlIFRDUCBoZWFkZXIgaGFzIGJlZW4gdHdlYWtlZCBzbGlnaHRseSB0bwogCiAK IDxzZWN0aW9uIHRpdGxlPSJVc2VyIFNwYWNlIHZzIEtlcm5lbCBpbXBsZW1lbnRhdGlvbi4iIGFu Y2hvcj0ic2VjLXNjdHAtMSI+Ci08dD5FdmVuIGtlcm5lbCBpbXBsZW1lbnRhdGlvbiBvZiBTQ1RQ IGFyZSBhbHJlYWR5IGF2YWlsYWJsZSBmb3IgYWxsIHRoZSBkaWZmZXJlbnQgcGxhdGZvcm1zIChz ZWUgPHhyZWYgdGFyZ2V0PSdzZWMtcC1hLTInLz4gKSwKLXRoZXJlIGFyZSBjb21wZWxsaW5nIHJl YXNvbnMgdGhhdCBpbmNsaW5lIHRvd2FyZHMgZm9yIGEgU0NUUCBzdGFjayB0aGF0IHdvcmtzIHdl bGwgaW4gdXNlciBsYW5kLjwvdD4KKzx0PldoaWxlIGtlcm5lbCBpbXBsZW1lbnRhdGlvbnMgb2Yg U0NUUCBhcmUgbm93IGF2YWlsYWJsZSBmb3IgYWxsIG1ham9yIHBsYXRmb3JtcyAoc2VlIDx4cmVm IHRhcmdldD0nc2VjLXAtYS0yJy8+ICksCit0aGVyZSBhcmUgY29tcGVsbGluZyByZWFzb25zIHRv IHVzZSBhbiBTQ1RQIHN0YWNrIHRoYXQgd29ya3Mgd2VsbCBpbiB1c2VyIGxhbmQuPC90PgogCiA8 dD5UaGUgbWFpbiByZWFzb24gaXMgZGVwbG95YWJpbGl0eS48L3Q+CiAKLTx0PlRoZXJlIGFyZSBt YW55IGFwcGxpY2F0aW9ucyB0b2RheSB0aGF0IGFyZSBleHBlY3RlZCB0byBydW4gb24gYSB3aWRl IHJhbmdlIG9mIG9sZCBhbmQgbmV3IG9wZXJhdGluZyBzeXN0ZW1zLiAKLVdlYiBicm93c2VycyBh cmUgYW4gZXhjZWxsZW50IGV4YW1wbGUuIFRoZXkgc3VwcG9ydCBvcGVyYXRpbmcgc3lzdGVtcyAx MCB5ZWFycyBvbGQgb3IgbW9yZSwgdGhleSBydW4gb24gbW9iaWxlIGFuZCBkZXNrdG9wIG9wZXJh dGluZyBzeXN0ZW1zLCAKLWFuZCB0aGV5IGFyZSBoaWdobHkgcG9ydGFibGUgdG8gbmV3IG9wZXJh dGluZyBzeXN0ZW1zLiBUaGlzIGlzIGFjaGlldmVkIGJ5IGhhdmluZyBhIGZhaXJseSBuYXJyb3cg cG9ydGFiaWxpdHkgbGF5ZXIgdG8gbWluaW1pemUgd2hhdCBuZWVkcyAKLXRvIGJlIHN1cHBvcnRl ZCBvbiBvbGQgb3BlcmF0aW5nIHN5c3RlbXMgYW5kIHBvcnRlZCB0byBuZXcgb25lcy4gVGhpcyBj cmVhdGVzIGEgc3Ryb25nIGRlc2lyZSB0byBpbXBsZW1lbnRlZCBhcyBtdWNoIGZ1bmN0aW9uYWxp dHkgYXMgcG9zc2libGUgCis8dD5UaGVyZSBhcmUgbWFueSBhcHBsaWNhdGlvbnMgdG9kYXkgdGhh dCBhcmUgZXhwZWN0ZWQgdG8gcnVuIG9uIGEgd2lkZSByYW5nZSBvZiBvbGQgYW5kIG5ldyBvcGVy YXRpbmcgc3lzdGVtcy4KK1dlYiBicm93c2VycyBhcmUgYW4gZXhjZWxsZW50IGV4YW1wbGUuIFRo ZXkgc3VwcG9ydCBvcGVyYXRpbmcgc3lzdGVtcyAxMCB5ZWFycyBvbGQgb3IgbW9yZSwgdGhleSBy dW4gb24gbW9iaWxlIGFuZCBkZXNrdG9wIG9wZXJhdGluZyBzeXN0ZW1zLAorYW5kIHRoZXkgYXJl IGhpZ2hseSBwb3J0YWJsZSB0byBuZXcgb3BlcmF0aW5nIHN5c3RlbXMuIFRoaXMgaXMgYWNoaWV2 ZWQgYnkgaGF2aW5nIGEgZmFpcmx5IG5hcnJvdyBwb3J0YWJpbGl0eSBsYXllciB0byBtaW5pbWl6 ZSB3aGF0IG5lZWRzCit0byBiZSBzdXBwb3J0ZWQgb24gb2xkIG9wZXJhdGluZyBzeXN0ZW1zIGFu ZCBwb3J0ZWQgdG8gbmV3IG9uZXMuIFRoaXMgY3JlYXRlcyBhIHN0cm9uZyBkZXNpcmUgdG8gaW1w bGVtZW50ZWQgYXMgbXVjaCBmdW5jdGlvbmFsaXR5IGFzIHBvc3NpYmxlCiBpbnNpZGUgdGhlIGFw cGxpY2F0aW9uIGluc3RlYWQgb2YgcmVseWluZyBvbiB0aGUgb3BlcmF0aW5nIHN5c3RlbSBmb3Ig aXQuPC90PgogCi08dD5UaGlzIGxlYWRzIHRvIGEgc2l0dWF0aW9uIHdoZXJlIHRoZXJlIGlzIGEg ZGVzaXJlIGZvciB0aGUgU0NUUCBzdGFjayB0byBiZSBpbXBsZW1lbnRlZCBpbiB0aGUgdXNlciBz cGFjZSBpbnN0ZWFkIG9mIHRoZSBrZXJuZWwgc3BhY2UuIAotRm9yIG1hbnkgYXBwbGljYXRpb25z IHRoYXQgcmVxdWlyZSBzdXBwb3J0IG9mIG9wZXJhdGluZyBzeXN0ZW1zIHdpdGhvdXQgU0NUUCAo aW5zZXJ0IHdoYXRldmVyIHN0YWNrIG9yZGVyIGlzIC0gVURQLCBEVExTIC0gd2hhdGV2ZXIpLCAK LXRoZXJlIGlzIG5vIHdheSB0byBkZXBsb3kgdGhpcyB1bmxlc3MgaXQgY2FuIGJlIGltcGxlbWVu dGVkIGluIHRoZSBhcHBsaWNhdGlvbi4gIAotVGhlIHRyYWRpdGlvbmFsIHJlYXNvbnMgZm9yIGtl cm5lbCBpbXBsZW1lbnRhdGlvbnMsIHN1Y2ggYXMgbXV4IG9mIG1hbnkgYXBwbGljYXRpb24gdXNp bmcgdHJhbnNwb3J0IHBvcnQgbnVtYmVycywgZG9lcyBub3QgcGFydGljdWxhcmx5IGFwcGx5IGhl cmUgCis8dD5UaGlzIGxlYWRzIHRvIGEgc2l0dWF0aW9uIHdoZXJlIHRoZXJlIGlzIGEgZGVzaXJl IGZvciB0aGUgU0NUUCBzdGFjayB0byBiZSBpbXBsZW1lbnRlZCBpbiB0aGUgdXNlciBzcGFjZSBp bnN0ZWFkIG9mIHRoZSBrZXJuZWwgc3BhY2UuCitGb3IgbWFueSBhcHBsaWNhdGlvbnMgdGhhdCBy ZXF1aXJlIHN1cHBvcnQgb2Ygb3BlcmF0aW5nIHN5c3RlbXMgd2l0aG91dCBTQ1RQIChpbnNlcnQg d2hhdGV2ZXIgc3RhY2sgb3JkZXIgaXMgLSBVRFAsIERUTFMgLSB3aGF0ZXZlciksCit0aGVyZSBp cyBubyB3YXkgdG8gZGVwbG95IHRoaXMgdW5sZXNzIGl0IGNhbiBiZSBpbXBsZW1lbnRlZCBpbiB0 aGUgYXBwbGljYXRpb24uCitUaGUgdHJhZGl0aW9uYWwgcmVhc29ucyBmb3Iga2VybmVsIGltcGxl bWVudGF0aW9ucywgc3VjaCBhcyBtdXggb2YgbWFueSBhcHBsaWNhdGlvbiB1c2luZyB0cmFuc3Bv cnQgcG9ydCBudW1iZXJzLCBkb2VzIG5vdCBwYXJ0aWN1bGFybHkgYXBwbHkgaGVyZQogd2hlcmUg dGhhdCBsZXZlbCBvZiBtdWx0aXBsZXhpbmcgYmV0d2VlbiBhcHBsaWNhdGlvbiB3YXMgcHJvdmlk ZWQgYnkgdGhlIHVuZGVybGluZyBVRFAgdGhhdCBpcyB0dW5uZWxlZCBvdmVyLiBUaGUgcmVxdWly ZW1lbnQgaXM6PC90PgogCiA8dD5JdCBNVVNUIGJlIHBvc3NpYmxlIHRvIGltcGxlbWVudCB0aGUg U0NUUCBhbmQgRFRMUyBwb3J0aW9uIG9mIHRoZSBzdGFjayBpbiB0aGUgdXNlciBhcHBsaWNhdGlv biBzcGFjZS48L3Q+CkBAIC00MTIsOSArNDA5LDkgQEAgd2hlcmUgdGhhdCBsZXZlbCBvZiBtdWx0 aXBsZXhpbmcgYmV0d2VlbiBhcHBsaWNhdGlvbiB3YXMgcHJvdmlkZWQgYnkgdGhlIHVuZGVybGkK ICAgIDx0IGhhbmdUZXh0PSItIj50aGUgcmVsaWFibGUgb3IgcGFydGlhbCByZWxpYWJpbGl0eSBz dXBwb3J0LjwvdD4KIDwvbGlzdD48L3Q+CiAKLTx0Pk11bHRpIHN0cmVhbWluZyBpcyBwcm9iYWJs eSBhbHNvIG9mIGludGVyZXN0LjwvdD4KKzx0Pk11bHRpLXN0cmVhbWluZyBpcyBwcm9iYWJseSBh bHNvIG9mIGludGVyZXN0LjwvdD4KIAotPHQ+TXVsdGlob21pbmcgd2lsbCBub3QgYmUgdXNlZCBp biB0aGlzIHNjZW5hcmlvLiBUaGUgU0NUUCBsYXllciB3b3VsZCBzaW1wbHkgYWN0IGFzIGlmIGl0 IHdlcmUgcnVubmluZyBvbiBhIHNpbmdsZS1ob21lZCBob3N0LCAKKzx0Pk11bHRpLWhvbWluZyB3 aWxsIG5vdCBiZSB1c2VkIGluIHRoaXMgc2NlbmFyaW8uIFRoZSBTQ1RQIGxheWVyIHdvdWxkIHNp bXBseSBhY3QgYXMgaWYgaXQgd2VyZSBydW5uaW5nIG9uIGEgc2luZ2xlLWhvbWVkIGhvc3QsCiBz aW5jZSB0aGF0IGlzIHRoZSBhYnN0cmFjdGlvbiB0aGF0IHRoZSBsb3dlciBsYXllcnMgKGUuZy4g VURQKSB3b3VsZCBleHBvc2UuPC90PgogCiA8L3NlY3Rpb24+CkBAIC00NDQsMTEgKzQ0MSwxMSBA QCBzaG93biBvbiB0aGUgbGVmdCBoYW5kIHNpZGUgb2YgPHhyZWYgdGFyZ2V0PSdmaWctc2N0cC1s YXllcmluZycvPgogaXMgc3BlY2lmaWVkIGluIDx4cmVmIHRhcmdldD0nSS1ELmlldGYtdHN2d2ct c2N0cC11ZHAtZW5jYXBzJy8+IGFuZCB0aGUKIHVzYWdlIG9mIERUTFMgb3ZlciBTQ1RQIGlzIHNw ZWNpZmllZCBpbiA8eHJlZiB0YXJnZXQ9J1JGQzYwODMnLz4uCiBVc2luZyB0aGUgVURQIGVuY2Fw c3VsYXRpb24gb2YgU0NUUCBhbGxvd3MgU0NUUCBpbXBsZW1lbnRhdGlvbnMKLXRvIHJ1biBpbiB1 c2VyLWxhbmQgd2l0aG91dCBhbnkgc3BlY2lhbCBwcml2aWxlZ2VzLCBidXQgc3RpbGwgYWxsb3dz Ci10aGUgc3VwcG9ydCBvZiBTQ1RQIGtlcm5lbCBpbXBsZW1lbnRhdGlvbnMuCit0byBydW4gaW4g dXNlci1sYW5kIHdpdGhvdXQgYW55IHNwZWNpYWwgcHJpdmlsZWdlcywgYnV0IHN0aWxsCit3b3Jr cyB3aXRoIFNDVFAga2VybmVsIGltcGxlbWVudGF0aW9ucy4KIFRoaXMgYWxzbyByZXF1aXJlcyBu byBTQ1RQIHNwZWNpZmljIHN1cHBvcnQgaW4gbWlkZGxlYm94ZXMgbGlrZSBmaXJld2FsbHMgYW5k Ci1OQVRzLiAgTXVsdGlob21pbmcgYW5kIGZhaWxvdmVyIHN1cHBvcnQgaXMgaW1wbGVtZW50ZWQg dmlhIHRoZSBJQ0UgbGF5ZXIsIAotYW5kIFNDVFAgYXNzb2NpYXRpb25zIGFyZSBzaW5nbGUtaG9t ZWQgYXQgdGhlIFNSVFAgbGF5ZXIuIAorTkFUcy4gIE11bHRpaG9taW5nIGFuZCBmYWlsb3ZlciBz dXBwb3J0IGlzIGltcGxlbWVudGVkIHZpYSB0aGUgSUNFIGxheWVyLAorYW5kIFNDVFAgYXNzb2Np YXRpb25zIGFyZSBzaW5nbGUtaG9tZWQuCiBUaGUgU0NUUCBwYXlsb2FkIGlzIHByb3RlY3RlZCBi eSBEVExTLCB3aGljaAogcHJvdmlkZXMgY29uZmlkZW50aWFsaXR5LCBpbnRlZ3JpdHkgYW5kIHNv dXJjZSBhdXRoZW50aWNhdGlvbi4gU0NUUC1BVVRIIGFzCiBzcGVjaWZpZWQgaW4gPHhyZWYgdGFy Z2V0PSdSRkM0ODk1Jy8+IGlzIHVzZWQgdG8gcHJvdmlkZSBpbnRlZ3JpdHkgb2YKQEAgLTQ3Myw3 ICs0NzAsNyBAQCBsYXllciwgc2luY2UgdGhlcmUgaXMgbm8gd2F5IHRvIGlkZW50aWZ5IHRoZSBj b3JyZXNwb25kaW5nIGFzc29jaWF0aW9uLgogVGhlcmVmb3JlIHRoZSBudW1iZXIgb2YgU0NUUCBh c3NvY2lhdGlvbnMgc2hvdWxkIGJlIGxpbWl0ZWQgdG8gb25lIG9yIElDTVAgYW5kCiBJQ01QdjYg bWVzc2FnZXMgc2hvdWxkIGJlIGlnbm9yZWQuCiBJbiBnZW5lcmFsLCB0aGUgbG93ZXIgbGF5ZXIg aW50ZXJmYWNlIG9mIGFuIFNDVFAgaW1wbGVtZW50YXRpb24gaGFzIHRvIGJlCi1hZG9wdGVkIHRv IGFkZHJlc3MgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gSVB2NCBvciBJUHY2IChiZWluZyBjb25u ZWN0aW9uLWxlc3MpCithZGFwdGVkIHRvIGFkZHJlc3MgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4g SVB2NCBvciBJUHY2IChiZWluZyBjb25uZWN0aW9uLWxlc3MpCiBvciBEVExTIChiZWluZyBjb25u ZWN0aW9uLW9yaWVudGVkKS4KIFdoZW4gdGhpcyBzdGFjayBpcyB1c2VkLCBEVExTIHByb3RlY3Rz IHRoZSBjb21wbGV0ZSBTQ1RQIHBhY2tldCwgc28gaXQKIHByb3ZpZGVzIGNvbmZpZGVudGlhbGl0 eSwgaW50ZWdyaXR5IGFuZCBzb3VyY2UgYXV0aGVudGljYXRpb24KQEAgLTUwNSwxMyArNTAyLDE2 IEBAIHRoZSBTQ1RQIGNvbmdlc3Rpb24gY29udHJvbC48L3Q+CiAKIDx0PiBUQkQgaWYgd2UgbmVl ZCBhbHNvIHRvIGRlc2lnbiBhIGZyYW1pbmcgb3Igbm90LjwvdD4KIAotPHQ+IEF0IHRpbWUgb2Yg d3JpdGluZyBub2JvZHkgaGFzIGlkZW50aWZpZWQgYSByZWFsIG5lZWQgZm9yIG1hc2tpbmcgb2Yg VURQLAorPHQ+IEluIGRpc2N1c3Npb25zIHNvIGZhciwgbm8gb25lIGhhcyBpZGVudGlmaWVkIGEg cmVhbCBuZWVkIGZvciBtYXNraW5nIG9mIFVEUCwKIGFuZCBEVExTIGlzIGEgbXVjaC1wcmVmZXJy ZWQgc29sdXRpb24gZm9yIGVuY3J5cHRpb24vYXV0aGVudGljYXRpb24uPC90PgogCi08dD5Nb3Jl IFNDVFAgYWxyZWFkeSBwcm92aWRlcyBzZXF1ZW5jZSBudW1iZXIgaW5mb3JtYXRpb24gKGUuZy4g c3RyZWFtIHNlcXVlbmNlIG51bWJlcnMpLgotSG93ZXZlciB0aGVyZSBjb3VsZCBiZSBhIG5lZWQg dG8gc3VwcG9ydCBkaWZmZXJlbnQga2luZCBvZiBtZXNzYWdlIChsaW5rIGluIFdlYlNvY2tldCB3 aGVyZSB0aGVyZSBpcyBzdXBwb3J0Ci10byBkaXN0aW5ndWlzaCBiZXR3ZWVuIFVuaWNvZGUgdGV4 dCBhbmQgYmluYXJ5IGZyYW1lcyksIHNpbmNlIGZvciBTQ1RQIHRoZXkgYXJlIGFsbCB1c2VyIG1l c3NhZ2UuCi1JbiB0aGUgY2FzZSB0aGVyZSBpcyB0aGlzIG5lZWQgYSBwb3NzaWJpbGl0eSBpcyB0 byBtYXAgdHlwZXMgdG8gc3RyZWFtcy48L3Q+Cis8dD5TQ1RQIGFscmVhZHkgcHJvdmlkZXMgc2Vx dWVuY2UgbnVtYmVyIGluZm9ybWF0aW9uIChlLmcuIHN0cmVhbSBzZXF1ZW5jZSBudW1iZXJzKS4K K0hvd2V2ZXIgdGhlcmUgY291bGQgYmUgYSBuZWVkIHRvIHN1cHBvcnQgZGlmZmVyZW50IGtpbmRz IG9mIG1lc3NhZ2VzLAorc2luY2UgZm9yIFNDVFAgdGhleSBhcmUgYWxsIHVzZXIgbWVzc2FnZS4K KyhlLmcuIGluIFdlYlNvY2tldCB0aGVyZSBpcyBhIGRpc3RpbmN0aW9uIGJldHdlZW4gVW5pY29k ZSB0ZXh0CithbmQgYmluYXJ5IGZyYW1lcykKK0lmIHRoaXMgZG9lcyBiZWNvbWUgYSByZXF1aXJl bWVudCwgb25lIHBvc3NpYmlsaXR5IGlzIHRvIG1hcAorbWVzc2FnZSB0eXBlcyB0byBzdHJlYW1z LjwvdD4KIAogCiA8L3NlY3Rpb24+CkBAIC01NDEsMjAgKzU0MSwyMCBAQCBSYW5kYWxsIFN0ZXdh cnQgYW5kIEp1c3RpbiBVYmVydGkuPC90PgogCiA8YmFjaz4KIDxyZWZlcmVuY2VzIHRpdGxlPSJJ bmZvcm1hdGlvbmFsIFJlZmVyZW5jZXMiPgotCTw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5SRkMu Mzc1OCI/PgotCTw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5SRkMuNDM0MCI/PgotCTw/cmZjIGlu Y2x1ZGU9InJlZmVyZW5jZS5SRkMuNDM0MSI/PgotCTw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5S RkMuNDM0MiI/PgotCTw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5SRkMuNTYyMiI/PgotCTw/cmZj IGluY2x1ZGU9InJlZmVyZW5jZS5SRkMuNDg5NSI/PgotCTw/cmZjIGluY2x1ZGU9InJlZmVyZW5j ZS5SRkMuNDk2MCI/PgotCTw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5SRkMuNTA2MSI/PgotCTw/ cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5SRkMuNTI0NSI/PgotCTw/cmZjIGluY2x1ZGU9InJlZmVy ZW5jZS5SRkMuNTM4OSI/PgotCTw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5SRkMuNTQwNSI/Pgot CTw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5SRkMuNjA4MyI/PgotCTw/cmZjIGluY2x1ZGU9InJl ZmVyZW5jZS5JLUQuaWV0Zi10bHMtcmZjNDM0Ny1iaXMiPz4KLQk8P3JmYyBpbmNsdWRlPSJyZWZl cmVuY2UuSS1ELmlldGYtdHN2d2ctc2N0cC11ZHAtZW5jYXBzIj8+CisgICAgICAgIDw/cmZjIGlu Y2x1ZGU9InJlZmVyZW5jZS5SRkMuMzc1OCI/PgorICAgICAgICA8P3JmYyBpbmNsdWRlPSJyZWZl cmVuY2UuUkZDLjQzNDAiPz4KKyAgICAgICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy40 MzQxIj8+CisgICAgICAgIDw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5SRkMuNDM0MiI/PgorICAg ICAgICA8P3JmYyBpbmNsdWRlPSJyZWZlcmVuY2UuUkZDLjU2MjIiPz4KKyAgICAgICAgPD9yZmMg aW5jbHVkZT0icmVmZXJlbmNlLlJGQy40ODk1Ij8+CisgICAgICAgIDw/cmZjIGluY2x1ZGU9InJl ZmVyZW5jZS5SRkMuNDk2MCI/PgorICAgICAgICA8P3JmYyBpbmNsdWRlPSJyZWZlcmVuY2UuUkZD LjUwNjEiPz4KKyAgICAgICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy41MjQ1Ij8+Cisg ICAgICAgIDw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5SRkMuNTM4OSI/PgorICAgICAgICA8P3Jm YyBpbmNsdWRlPSJyZWZlcmVuY2UuUkZDLjU0MDUiPz4KKyAgICAgICAgPD9yZmMgaW5jbHVkZT0i cmVmZXJlbmNlLlJGQy42MDgzIj8+CisgICAgICAgIDw/cmZjIGluY2x1ZGU9InJlZmVyZW5jZS5J LUQuaWV0Zi10bHMtcmZjNDM0Ny1iaXMiPz4KKyAgICAgICAgPD9yZmMgaW5jbHVkZT0icmVmZXJl bmNlLkktRC5pZXRmLXRzdndnLXNjdHAtdWRwLWVuY2FwcyI/PgogPD9yZmMgaW5jbHVkZT0icmVm ZXJlbmNlLkktRC5iYXNldC10c3Z3Zy10Y3Atb3Zlci11ZHAiPz4KIDw/cmZjIGluY2x1ZGU9InJl ZmVyZW5jZS5JLUQuZGVuaXMtdWRwLXRyYW5zcG9ydCI/PgogCkBAIC01NjMsNyArNTYzLDcgQEAg UmFuZGFsbCBTdGV3YXJ0IGFuZCBKdXN0aW4gVWJlcnRpLjwvdD4KIAogPC9yZmM+CiAKLTwhLS0g Q2hhbmdlIGxvZyAKKzwhLS0gQ2hhbmdlIGxvZwogCiAKIC0tPgo= --20cf307cffa685ead504b0dd860a-- From HKaplan@acmepacket.com Thu Nov 3 18:59:19 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE4A11E80AE for ; Thu, 3 Nov 2011 18:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=-0.872, BAYES_00=-2.599, GB_VISITOURSITE=2, 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 DGLyiMIXtbdj for ; Thu, 3 Nov 2011 18:59:18 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFFB11E8089 for ; Thu, 3 Nov 2011 18:59:18 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 3 Nov 2011 21:59:16 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 3 Nov 2011 21:59:15 -0400 From: Hadriel Kaplan To: "Bran, Cary" Thread-Topic: [rtcweb] NAT Draft Thread-Index: AQHMmpVay12ir971zEWuAtTil5VTkA== Date: Fri, 4 Nov 2011 01:59:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: multipart/alternative; boundary="_000_F0ED21943C0044099B11116419AEA5D3acmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] NAT 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: Fri, 04 Nov 2011 01:59:19 -0000 --_000_F0ED21943C0044099B11116419AEA5D3acmepacketcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Howdy, I've read the draft and I do think some consensus has been reached with reg= ard to some of it. Having said that, though, I don't think this needs to be a WG document beca= use that implies we would be publishing this as an RFC eventually... and I = don't see a need to do that. We should instead incorporate any requirements we reach WG consensus on int= o the draft-ietf-rtcweb-use-cases-and-requirements WG document; or if we fe= el that that document is meant for high-level requirements only, then we sh= ould create a new WG document that covers all the specific requirements. Having separate individual drafts is ok for now, but having a separate WG d= oc and RFC for every requirement sub-category seems unnecessary to me, and = likely to cause confusion. It's not like we would expect to only satisfy t= he requirements of RFC X but not Y, is it? [note: We might have separate RFCs if we plan a phase-1 and phase-2 approac= h for W3C and browsers, but this NAT one isn't in that type of situation. = And we might have a separate RFC for requirements for new protocol work, su= ch as a data-transport one if we need the Transport Area to create a new tr= ansport, but this NAT one isn't that type of situation either.] -hadriel On Oct 31, 2011, at 6:23 PM, Bran, Cary wrote: Hello WebRTC chairs, I have updated and submitted a 02 version of the WebRTC NAT draft: http://t= ools.ietf.org/id/draft-cbran-rtcweb-nat-02.txt I believe that this draft is representative of areas where the working grou= p has achieved consensus and at this time I would like to ask that the 02 d= raft be adopted as a working group document. I look forward to your feedback. Regards, Cary Bran Senior Director Advanced Software Technology and Architecture Office: +1 831-458-7737 Cell: +1 206-661-2398 Plantronics Simply Smarter Communications=99 345 Encinal St., Santa Cruz, CA 95060 ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, p= lease DO NOT disclose the contents to another person, store or copy the inf= ormation in any medium, or use any of the information contained in or attac= hed to this transmission for any purpose. If you have received this transmi= ssion in error, please immediately notify the sender by reply email or at p= rivacy@plantronics.com, and destroy the ori= ginal transmission and its attachments without reading or saving in any man= ner. For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_F0ED21943C0044099B11116419AEA5D3acmepacketcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5600D8E785482D4680AAB9192F5D61B1@acmepacket.com> Content-Transfer-Encoding: quoted-printable

Howdy,
I've read the draft and I do think some consensus has been reached wit= h regard to some of it.

Having said that, though, I don't think this needs to be a WG document= because that implies we would be publishing this as an RFC eventually... a= nd I don't see a need to do that.  

We should instead incorporate any requirements we reach WG consensus o= n into the draft-ietf-rtcweb-use-cases-and-requirements WG document; o= r if we feel that that document is meant for high-level requirements only, = then we should create a new WG document that covers all the specific requirements.  

Having separate individual drafts is ok for now, but having a sep= arate WG doc and RFC for every requirement sub-category seems unnecessary t= o me, and likely to cause confusion.  It's not like we would expect to= only satisfy the requirements of RFC X but not Y, is it?  

[note: We might have separate RFCs if we plan a phase-1 and phase-2 ap= proach for W3C and browsers, but this NAT one isn't in that type of situati= on.  And we might have a separate RFC for requirements for new protoco= l work, such as a data-transport one if we need the Transport Area to create a new transport, but this NAT one = isn't that type of situation either.]

-hadriel

On Oct 31, 2011, at 6:23 PM, Bran, Cary wrote:

Hello WebRTC chairs,

 

I have updated and submitted a 02 version of the WebRTC NAT draft: http://tools.ietf.org/id/draft-cbran-rtcweb-nat-02.txt

 

I believe that this draft is representative of areas where the working grou= p has achieved consensus and at this time I would like to ask that the 02 d= raft be adopted as a working group document.

 

I look forward to your feedback.

 

Regards,

 

Cary Bran<= /div>
Senior Directo= r Advanced Software Technology and Architecture
Office:  = +1 831-458-7737     Cell: +1 206-661-2398<= /span>

Plantronics  Simply Smarter Communications=99

345 Encinal St= ., Santa Cruz, CA 95060

 



CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the conten= ts to another person, store or copy the information in any medium, or use a= ny of the information contained in or attached to this transmission for any= purpose. If you have received this transmission in error, please immediately notify the sender by reply email= or at  www.plantronics.com.
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtc= web

--_000_F0ED21943C0044099B11116419AEA5D3acmepacketcom_-- From magnus.westerlund@ericsson.com Fri Nov 4 02:08:03 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502A021F8AB8 for ; Fri, 4 Nov 2011 02:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.58 X-Spam-Level: X-Spam-Status: No, score=-105.58 tagged_above=-999 required=5 tests=[AWL=-0.981, BAYES_00=-2.599, GB_VISITOURSITE=2, 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 wSu6xSd66qrZ for ; Fri, 4 Nov 2011 02:08:02 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8E76621F8B24 for ; Fri, 4 Nov 2011 02:08:01 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-56-4eb3ab7000e3 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 58.DB.13753.07BA3BE4; Fri, 4 Nov 2011 10:08:00 +0100 (CET) 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.137.0; Fri, 4 Nov 2011 10:07:56 +0100 Message-ID: <4EB3AB64.40400@ericsson.com> Date: Fri, 4 Nov 2011 10:07:48 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Bran, Cary" References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [rtcweb] Codec 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: Fri, 04 Nov 2011 09:08:03 -0000 WG, Cary has tried to clarify his statement below, but for clarity: There is no WG consensus on this document. The WG chairs have made no decision yet to even call for adoption. We will have 30 minutes in Taipei to discuss Codecs and Codec selection for WebRTC. Please consider this draft one proposal for a starting point in this selection. The other individual document that provides any views on the codecs are: https://datatracker.ietf.org/doc/draft-wenger-rtcweb-layered-codec/ So please review both in preparation for the discussion. We WG chairs encourage discussion on the mailing list and feedback to the authors of the documents. Cheers Magnus On 2011-10-31 23:25, Bran, Cary wrote: > Hello WebRTC chairs, > > > > I have updated and submitted a 02 version of the WebRTC Codec draft: > http://tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt > > > > I believe that this draft is representative of areas where the working > group has achieved consensus and at this time I would like to ask that > the 01 draft be adopted as a working group document. > > > > I look forward to your feedback. > > > > Regards, > > > > > > *Cary Bran* > > Senior Director Advanced Software Technology and Architecture > > Office: +1 831-458-7737 Cell: +1 206-661-2398 > > *Plantronics* Simply Smarter Communications™ > > 345 Encinal St., Santa Cruz, CA 95060 > > > > > ------------------------------------------------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, > files or previous e-mail messages attached to it, may contain > information that is confidential and/or legally privileged. If you are > not the intended recipient, or a person responsible for delivering it to > the intended recipient, please DO NOT disclose the contents to another > person, store or copy the information in any medium, or use any of the > information contained in or attached to this transmission for any > purpose. If you have received this transmission in error, please > immediately notify the sender by reply email or at > privacy@plantronics.com, and destroy the original transmission and its > attachments without reading or saving in any manner. > > For further information about Plantronics - the Company, its products, > brands, partners, please visit our website www.plantronics.com. -- 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 Fri Nov 4 02:20:56 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CBB21F8C34 for ; Fri, 4 Nov 2011 02:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 j56utGuEJyZP for ; Fri, 4 Nov 2011 02:20:55 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id CB0F021F8BF0 for ; Fri, 4 Nov 2011 02:20:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-59-4eb3ae707902 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1B.0E.13753.07EA3BE4; Fri, 4 Nov 2011 10:20:48 +0100 (CET) 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.137.0; Fri, 4 Nov 2011 10:20:29 +0100 Message-ID: <4EB3AE5B.4090401@ericsson.com> Date: Fri, 4 Nov 2011 10:20:27 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , "Bran, Cary" Subject: Re: [rtcweb] NAT 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: Fri, 04 Nov 2011 09:20:56 -0000 On 2011-11-04 02:59, Hadriel Kaplan wrote: > > Howdy, > I've read the draft and I do think some consensus has been reached with > regard to some of it. > > Having said that, though, I don't think this needs to be a WG document > because that implies we would be publishing this as an RFC eventually... > and I don't see a need to do that. > > We should instead incorporate any requirements we reach WG consensus on > into the draft-ietf-rtcweb-use-cases-and-requirements WG document; or if > we feel that that document is meant for high-level requirements only, > then we should create a new WG document that covers all the specific > requirements. > > Having separate individual drafts is ok for now, but having a separate > WG doc and RFC for every requirement sub-category seems unnecessary to > me, and likely to cause confusion. It's not like we would expect to > only satisfy the requirements of RFC X but not Y, is it? Hadriel, I think a document of this type should and will eventually be published as its own RFC. The reason for this I think is that the document should evolve from requirements to actually specify how the Peer to Peer transport flow establishment layer for WebRTC works. As that layer will be used by both the RTP based media transport and the Data Transport having a document only containing that functionality will make it simpler to reference. In addition I think it is good from specification maintenance perspective. If we have bugs in a functionality block we don't need to republish other functionality blocks just to update, in this case the NAT traversal functionality. Given that a NAT traversal document will specify how WebRTC establish the transport flows do you think that really should be part of the use-cases and requirements? My personal input to draft-cbran-rtcweb-nat is to stop using requirements as the word for what an end-point shall implement and which specifications they should follow. Instead call it specification. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Nov 4 05:33:23 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617E621F8BDC for ; Fri, 4 Nov 2011 05:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 eMPUZNsnlL9m for ; Fri, 4 Nov 2011 05:33:23 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8E021F8BDB for ; Fri, 4 Nov 2011 05:33:22 -0700 (PDT) X-AuditID: c1b4fb39-b7b3eae00000252a-01-4eb3db91c771 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 54.EF.09514.19BD3BE4; Fri, 4 Nov 2011 13:33:21 +0100 (CET) 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.137.0; Fri, 4 Nov 2011 13:33:20 +0100 Message-ID: <4EB3DB8F.5030902@ericsson.com> Date: Fri, 4 Nov 2011 13:33:19 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Discussing Multiple Media Types in an RTP session and Multiple RTP sessions over single transport X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 12:33:23 -0000 WG, As chairs of both AVTCORE and RTCWEB I would like to remind the RTCWEB WG that discussion of any details around the following drafts all related to the WebRTC RTP session usage should happen in the AVTCORE WG for RTP related details and MMUSIC for siganlling: AVTCORE: https://datatracker.ietf.org/doc/draft-lennox-rtcweb-rtp-media-type-mux/ https://datatracker.ietf.org/doc/draft-westerlund-avtcore-transport-multiplexing/ https://datatracker.ietf.org/doc/draft-westerlund-avtcore-multiplex-architecture/ MMUSIC: https://datatracker.ietf.org/doc/draft-holmberg-mmusic-sdp-bundle-negotiation/ 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 xavier.marjou@gmail.com Fri Nov 4 07:06:05 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B149B21F8C54 for ; Fri, 4 Nov 2011 07:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.976 X-Spam-Level: X-Spam-Status: No, score=-0.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_VISITOURSITE=2, 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 qx0xozGBPOjT for ; Fri, 4 Nov 2011 07:06:05 -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 CDDCD21F8C4F for ; Fri, 4 Nov 2011 07:06:04 -0700 (PDT) Received: by ywt2 with SMTP id 2so2906788ywt.31 for ; Fri, 04 Nov 2011 07:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=S6xi8HnA4oFSHKCyUgsd3q917YK7PRPl9A5k/qqx/7g=; b=SFc2REAmu6zMNk5hxbGJNatSrT/VPQBE4naCDFuKDDiJjCU6RvbYMq/twHX+yTiG3m IM1at3pzlG+8ByDMX26Gt70+euSBr5wXCsNinQoicAUjY9I/Vz3sVlKIt1f1U2SKNoh/ BUIFE9xAgus2bfsJO+mMdIxxKalXx2iQyxS3A= MIME-Version: 1.0 Received: by 10.236.200.201 with SMTP id z49mr20770353yhn.20.1320415564233; Fri, 04 Nov 2011 07:06:04 -0700 (PDT) Sender: xavier.marjou@gmail.com Received: by 10.236.157.73 with HTTP; Fri, 4 Nov 2011 07:06:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Nov 2011 15:06:04 +0100 X-Google-Sender-Auth: BarRfxoCKpIk2dYS__eEzPhqikQ Message-ID: From: Xavier Marjou To: "Bran, Cary" , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=20cf305b09fea97cc704b0e93466 Subject: Re: [rtcweb] Codec 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: Fri, 04 Nov 2011 14:06:05 -0000 --20cf305b09fea97cc704b0e93466 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I don't think there is a consensus on codec requirements. There are other individual drafts also discussing the rtcweb codecs : First, this old draft http://tools.ietf.org/html/draft-marjou-dispatch-rtcweb-sip-rtp-interwk-req= s-00, and also this draft http://tools.ietf.org/html/draft-kaplan-rtcweb-sip-interworking-requirement= s-00 that I fully support by the way. Cheers, Xavier On Mon, Oct 31, 2011 at 11:25 PM, Bran, Cary wro= te: > Hello WebRTC chairs, > > > > I have updated and submitted a 02 version of the WebRTC Codec draft: > http://tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt > > > > I believe that this draft is representative of areas where the working > group has achieved consensus and at this time I would like to ask that th= e > 01 draft be adopted as a working group document. > > > > I look forward to your feedback. > > > > Regards, > > > > > > *Cary Bran* > > Senior Director Advanced Software Technology and Architecture > > Office: +1 831-458-7737 Cell: +1 206-661-2398 > > *Plantronics* Simply Smarter Communications=99 > > 345 Encinal St., Santa Cruz, CA 95060 > > > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, file= s > or previous e-mail messages attached to it, may contain information that = is > confidential and/or legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, please DO NOT disclose the contents to another person, store o= r > copy the information in any medium, or use any of the information contain= ed > in or attached to this transmission for any purpose. If you have received > this transmission in error, please immediately notify the sender by reply > email or at privacy@plantronics.com, and destroy the original > transmission and its attachments without reading or saving in any manner. > > For further information about Plantronics - the Company, its products, > brands, partners, please visit our website www.plantronics.com. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --20cf305b09fea97cc704b0e93466 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,

I don't think there is a consensus on codec requ= irements.=A0There are other individual drafts also discussing the rtcweb co= decs :

Cheers,
Xavier

On Mon, Oct 31, 2011 at 11:25 PM, Bran, Cary <Cary.Bran@plantr= onics.com> wrote:

Hello WebRTC chairs,

=A0

I have updated and submitted a 02 version of the Web= RTC Codec draft: http://tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt

=A0

I believe that this draft is representative of areas= where the working group has achieved consensus and at this time I would li= ke to ask that the 01 draft be adopted as a working group document.

=A0

I look forward to your feedback.

=A0

Regards,

=A0

=A0

Cary Bran

Senior Director Advanced Software Technology and Ar= chitecture

Office:=A0 +1 831-458-7737=A0=A0=A0=A0 Cell:= =A0+1 206-661-2398

Plantronics=A0 Simply Smarter Commun= ications=99

345 Encinal St., Santa Cruz, CA 95060

=A0



CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the conten= ts to another person, store or copy the information in any medium, or use a= ny of the information contained in or attached to this transmission for any= purpose. If you have received this transmission in error, please immediately notify the sender by reply email= or at privacy= @plantronics.com, and destroy the original transmission and its attachm= ents without reading or saving in any manner.

For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com.

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


--20cf305b09fea97cc704b0e93466-- From xavier.marjou@gmail.com Fri Nov 4 07:20:19 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413A221F8C50 for ; Fri, 4 Nov 2011 07:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.976 X-Spam-Level: X-Spam-Status: No, score=-0.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_VISITOURSITE=2, 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 WJh+BJcNwYI9 for ; Fri, 4 Nov 2011 07:20:18 -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 65DB521F8C00 for ; Fri, 4 Nov 2011 07:20:18 -0700 (PDT) Received: by ywt2 with SMTP id 2so2922447ywt.31 for ; Fri, 04 Nov 2011 07:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=ncaacZURnFUDdO+vKe49WdGB6r2Iw09X9q4FxNmpLTI=; b=TapCLX71sL6fHKlo9sSIbN2iSfTV7JdQXidJ0p0riwH1sJoxnShopC33pEgi0HrD7/ rLsjwwwfxe8c+eAtJZs18F9Z+6ZDTDSfBxr2zEQ5Lbi3OBc4GVYPYkdQMwFE1qxBtG0r Vb+scImHIBcQivCmrJZP0plV7W5vAR40aYIEY= MIME-Version: 1.0 Received: by 10.236.129.238 with SMTP id h74mr16837173yhi.3.1320416417910; Fri, 04 Nov 2011 07:20:17 -0700 (PDT) Sender: xavier.marjou@gmail.com Received: by 10.236.157.73 with HTTP; Fri, 4 Nov 2011 07:20:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Nov 2011 15:20:17 +0100 X-Google-Sender-Auth: 1KBXhN423UE2fj1M2H8Jdc1ACeo Message-ID: From: Xavier Marjou To: "Bran, Cary" , "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=20cf300e50b38b911a04b0e96778 Subject: Re: [rtcweb] Codec 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: Fri, 04 Nov 2011 14:20:19 -0000 --20cf300e50b38b911a04b0e96778 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Regarding WebRTC codec requirements, there are also other individual drafts with different views on the wanted codecs : first, this old draft http://tools.ietf.org/html/draft-marjou-dispatch-rtcweb-sip-rtp-interwk-req= s-00, and also http://tools.ietf.org/html/draft-kaplan-rtcweb-sip-interworking-requirement= s-00, which I fully support by the way. Cheers, Xavier > > On Mon, Oct 31, 2011 at 11:25 PM, Bran, Cary w= rote: > >> Hello WebRTC chairs, >> >> >> >> I have updated and submitted a 02 version of the WebRTC Codec draft: >> http://tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt >> >> >> >> I believe that this draft is representative of areas where the working >> group has achieved consensus and at this time I would like to ask that t= he >> 01 draft be adopted as a working group document. >> >> >> >> I look forward to your feedback. >> >> >> >> Regards, >> >> >> >> >> >> *Cary Bran* >> >> Senior Director Advanced Software Technology and Architecture >> >> Office: +1 831-458-7737 Cell: +1 206-661-2398 >> >> *Plantronics* Simply Smarter Communications=99 >> >> 345 Encinal St., Santa Cruz, CA 95060 >> >> >> >> ------------------------------ >> >> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, >> files or previous e-mail messages attached to it, may contain informatio= n >> that is confidential and/or legally privileged. If you are not the inten= ded >> recipient, or a person responsible for delivering it to the intended >> recipient, please DO NOT disclose the contents to another person, store = or >> copy the information in any medium, or use any of the information contai= ned >> in or attached to this transmission for any purpose. If you have receive= d >> this transmission in error, please immediately notify the sender by repl= y >> email or at privacy@plantronics.com, and destroy the original >> transmission and its attachments without reading or saving in any manner= . >> >> For further information about Plantronics - the Company, its products, >> brands, partners, please visit our website www.plantronics.com. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --20cf300e50b38b911a04b0e96778 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,

Regarding WebRTC codec requirements, there a= re also other individual drafts with different views on the wanted codecs := first, this old draft=A0http://tools.ietf.org/html/draft-marjou-dispatch-rtcweb-sip= -rtp-interwk-reqs-00,=A0and also http://tools.ietf.org/html/draft-kaplan-rtcweb-= sip-interworking-requirements-00,=A0which I fully support by the way.

Cheers,
Xavier



On Mon, Oct 31, 2011 at 11:25 PM, Bran, Cary <Car= y.Bran@plantronics.com> wrote:

Hello WebRTC chairs,

=A0

I have updated and submitted a 02 version of the Web= RTC Codec draft: http://tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt

=A0

I believe that this draft is representative of areas= where the working group has achieved consensus and at this time I would li= ke to ask that the 01 draft be adopted as a working group document.

=A0

I look forward to your feedback.

=A0

Regards,

=A0

=A0

Cary Bran

Senior Director Advanced Software Technology and Ar= chitecture

Office:=A0 +1 831-458-7737=A0=A0=A0=A0 Cell:= =A0+1 206-661-2398

Plantronics=A0 Simply Smarter Commun= ications=99

345 Encinal St., Santa Cruz, CA 95060

=A0



CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the conten= ts to another person, store or copy the information in any medium, or use a= ny of the information contained in or attached to this transmission for any= purpose. If you have received this transmission in error, please immediately notify the sender by reply email= or at privacy= @plantronics.com, and destroy the original transmission and its attachm= ents without reading or saving in any manner.

For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com.

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



--20cf300e50b38b911a04b0e96778-- From wolfgang.beck01@googlemail.com Fri Nov 4 07:21:51 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0F221F8AC3 for ; Fri, 4 Nov 2011 07:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.925 X-Spam-Level: X-Spam-Status: No, score=-2.925 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 xSzlM6lb72J7 for ; Fri, 4 Nov 2011 07:21:51 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8B021F88A0 for ; Fri, 4 Nov 2011 07:21:50 -0700 (PDT) Received: by faas12 with SMTP id s12so3210444faa.31 for ; Fri, 04 Nov 2011 07:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VdDKuQ7+tVOYhCdBFIIq0nCgrt1WJYTHyhnRCPblTAs=; b=EOdkdZwrh5aqYTt45vUAs2mAasdJ1+PsJAcaZLD/zbtajv71xmXH3MVIv95D9Y2bry SHZFmP9HcTtEBPeGAx8+1Zsv2NCGn8hk1Y8K7xATsFj02EOiqWvarplK4wEF79t78y4l hK+p+ymqr8ekJhD/C0Vv9qL2K6cwVP+ruL6so= MIME-Version: 1.0 Received: by 10.152.106.115 with SMTP id gt19mr969558lab.27.1320416510121; Fri, 04 Nov 2011 07:21:50 -0700 (PDT) Received: by 10.152.18.197 with HTTP; Fri, 4 Nov 2011 07:21:49 -0700 (PDT) In-Reply-To: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@acmepacket.com> References: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@acmepacket.com> Date: Fri, 4 Nov 2011 15:21:49 +0100 Message-ID: From: Wolfgang Beck To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Layers in draft-jesup-rtcweb-data-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 14:21:51 -0000 On Wed, Oct 26, 2011 at 10:28 PM, Hadriel Kaplan w= rote: .. > > =A0 =A0 =A0 =A0+------+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+-= -----+ > =A0 =A0 =A0 =A0|WEBAPP| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|W= EBAPP| > =A0 =A0 =A0 =A0+------+------+------+ =A0 =A0 =A0 =A0 =A0+------+------+-= -----+ > =A0 =A0 =A0 =A0| DTLS | Audio| Video| =A0 =A0 =A0 =A0 =A0| SCTP | Audio| = Video| > =A0+---------------------------+ =A0 +---------------------------+ > =A0| STUN | SCTP |S/RTP |S/RTP | =A0 | STUN | DTLS |S/RTP |S/RTP | > =A0+---------------------------+ =A0 +---------------------------+ > =A0| =A0 =A0 =A0 =A0 Mux/Demux =A0 =A0 =A0 =A0 | =A0 | =A0 =A0 =A0 =A0 Mu= x/Demux =A0 =A0 =A0 =A0 | > =A0+---------------------------+ =A0 +---------------------------+ > =A0| =A0 =A0 =A0 =A0 =A0 =A0UDP =A0 =A0 =A0 =A0 =A0 =A0| =A0 | =A0 =A0 = =A0 =A0 =A0 =A0UDP =A0 =A0 =A0 =A0 =A0 =A0| > =A0+---------------------------+ =A0 +---------------------------+ > Has somebody tried to map the relevant combinations into SDP? We can exclude Audio, Video[/DTLS]/SCTP, right? Do we have to express the contents of the generic data in a similar way we are describing the contents -- codecs and parameters -- for RTP streams? Wolfgang Beck From fluffy@cisco.com Fri Nov 4 08:43:54 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F09C21F8C19 for ; Fri, 4 Nov 2011 08:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.394 X-Spam-Level: X-Spam-Status: No, score=-106.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 v4mFwKJaxwPn for ; Fri, 4 Nov 2011 08:43:53 -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 9AAFC21F8C16 for ; Fri, 4 Nov 2011 08:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1263; q=dns/txt; s=iport; t=1320421433; x=1321631033; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=sX91iLZls5JpynCZawjOIaug7G2LH3PHbHSjhvYadmw=; b=YV1E1WpMFyEYWAhGw+T6pdY2Z4uym/IRUGk36+La/VG3aCqzQE0ouq2F X5MimDrVAdSGGohSKSuixl8Yd0fNoUaadgb98vF/Bq7v2E82K5cjtKvjX clhhiubp9X9dOTf/rqj+8OLnqQiToj+kPu4KGqgUTBjH4mRMNz/OtVQX6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAC0HtE6rRDoG/2dsb2JhbABEqgOBBYFyAQEBAwESAWYQCzsLVwY1h2CWeAGeZIhIYwSICowSkgY X-IronPort-AV: E=Sophos;i="4.69,456,1315180800"; d="scan'208";a="12346318" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 04 Nov 2011 15:43:53 +0000 Received: from [IPv6:::1] (ssh-sjc-2.cisco.com [171.68.46.188]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA4FhrUv003575; Fri, 4 Nov 2011 15:43:53 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852235789602@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 4 Nov 2011 08:43:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <088367F5-90D3-45B5-939E-904411CF2D7B@cisco.com> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058522341F4AB9@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852235789602@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1251.1) Cc: Jonathan Rosenberg , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - More-coming and final answer (Section 5.2.3) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Nov 2011 15:43:54 -0000 On Nov 3, 2011, at 12:33 , Christer Holmberg wrote: >=20 > Hi,=20 >=20 >>> Q2. Are there restrictions when it comes to changing information in = a non-final=20 >>> answer and a final answer? Or, can the final answer be completely = different from=20 >>> previously sent non-final ANSWERS? In "legacy" O/A there are = restrictions. >>=20 >> Any answer has to be a valid answer for the offer but other than = that, no restrictions,=20 >> so the final answer can change everything from an earlier one.=20 >=20 > Is there a reason/use-case/requirement why we need to allow that? As = far as I know, the reason behind this is ICE. >=20 >=20 There a bunch of use cases but to mention two: In the browser to browser = case, imagine that you start sending audio in the first answer but need = to wait for user feedback to find out if video can be added or not in = the final answer. In a browser to SIP use case, the early media for = 1-800-go-fedex. Cullen PS - Sorry for slow replies but we had the week before the -00 drafts, = then the week before the -01 drafts, now I am at the W3C TPAC meeting = for a week, then reading drafts weeks, then IETF so I suspect a bunch of = this I won't really get to till after IETF but =85. From moore@network-heretics.com Thu Nov 3 12:29:29 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7861F0CAB; Thu, 3 Nov 2011 12:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=0.621, 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 2DsyfF0iiMZq; Thu, 3 Nov 2011 12:29:28 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id A1CBE1F0CB6; Thu, 3 Nov 2011 12:29:28 -0700 (PDT) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 35DA920A74; Thu, 3 Nov 2011 15:29:27 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 03 Nov 2011 15:29:27 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=oY+zzfrkNq8DL6JrAJJ9F05oL8Y=; b=Gk L1wcw8MLB2QsMu8hHg6u06Pw37yJT1tNSeTQIsbrMfAiApIZLKN+7+KNNyHhbvhb jq9IljEZj3+cY2Wn60iyCeFnSwekD/xX1rjVWYJlq0eoLvOBbADtJPH8UvdZSrp2 DCCK1tIagj8dz7wJ4cuPj1ofNV7U5Sa+dquasTgws= X-Sasl-enc: NkDtGeB2cZwLgDA7TAhiJfVtigovcopaL4XnYFrirMcv 1320348567 Received: from rlmartin.hq.corp.pbs.org (unknown [149.48.225.2]) by mail.messagingengine.com (Postfix) with ESMTPA id EBF928E0FB9; Thu, 3 Nov 2011 15:29:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Thu, 3 Nov 2011 15:29:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <5B7AE760-DBD1-46F9-89D9-E8F7CA56F111@network-heretics.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Fri, 04 Nov 2011 08:52:42 -0700 Cc: Keith Moore , "rtcweb@ietf.org" , Ned Freed , Behave WG Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 19:29:29 -0000 On Nov 3, 2011, at 2:58 PM, Eric Rescorla wrote: > On Tue, Nov 1, 2011 at 5:05 AM, Keith Moore = wrote: >>> In most cases probably not. But there may be cases similar to HTTP/S = where it makes sense. Each case has to be analyzed independently. >>=20 >> agree. I just don't think it's a good idea to establish a new = _convention_. >=20 > i don't really understand what you're arguing here. >=20 > The relevant issue is that we want to have a reference that Bob can = provide > to Alice that guarantees that when it's dereferenced it provides a = minimum > set of security properties. >=20 > Let's imagine some hypothetical new protocol which is like HTTP but = not HTTP, > say HTTQ. It runs over TCP so you can use it directly or over TLS = (i.e., > HTTP/TCP or HTTP/TLS/TCP). We're planning to define a new URI for it, > httq://.../. How do you propose to provide the above security = property? If you're going to define a new protocol, it should always use TLS (or = it should always provide a minimum set of security properties). Then = you define a single URI type for the new protocol, and it doesn't need = the security flag. It's only when you're trying to retro-fit security into an existing = protocol that is already widely used, doesn't inherently provide a = reasonable level of security for that application, and the security = isn't securely negotiated in-band, that you need a security flag in the = URI. More generally, the right place to set the minimum security level is in = the application, not in the name of the resource. The reason you need = https vs. http is that the two are really different protocols, and the = client has to know a priori whether to send "GET..." or to negotiate the = TLS layer after the TCP open completes. =20 Keith From moore@network-heretics.com Thu Nov 3 13:04:25 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3DB1F0C44; Thu, 3 Nov 2011 13:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 DZ9hqxfYr-1J; Thu, 3 Nov 2011 13:04:24 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8B58E1F0C35; Thu, 3 Nov 2011 13:04:18 -0700 (PDT) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 287D320CB9; Thu, 3 Nov 2011 16:04:18 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 03 Nov 2011 16:04:18 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=Yuvge/hhlTYGTb3ZJHlhQc9wFoU=; b=iu VpANkHw+taNa1E+H8+XRx4UsrPtrr9mmQXo6ASGKVCkXD+LGpqfEsp++TQDKpPr6 lyZ1QxHOQ7dO8/njoxmt+7JOiwvP8roGFAknnfzfgqjiFpDbMm9PvuTUx6vw/fIt s6qe8qGQ63jyTzcxnC6hoTD9hyWNCJyxv9eeFWqLA= X-Sasl-enc: +fm0sdn4wbjRC/p3pzC5SmorQpFZE9Sh5UB+lgUaUK5b 1320350657 Received: from rlmartin.hq.corp.pbs.org (unknown [149.48.225.2]) by mail.messagingengine.com (Postfix) with ESMTPA id B7C658E102B; Thu, 3 Nov 2011 16:04:17 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Keith Moore In-Reply-To: Date: Thu, 3 Nov 2011 16:04:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <5B7AE760-DBD1-46F9-89D9-E8F7CA56F111@network-heretics.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Fri, 04 Nov 2011 08:52:42 -0700 Cc: Keith Moore , "rtcweb@ietf.org" , Ned Freed , Behave WG Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Nov 2011 20:04:25 -0000 On Nov 3, 2011, at 3:43 PM, Eric Rescorla wrote: >> More generally, the right place to set the minimum security level is = in the application, not in the name of the resource. The reason you = need https vs. http is that the two are really different protocols, and = the client has to know a priori whether to send "GET..." or to negotiate = the TLS layer after the TCP open completes. >=20 > I don't agree with this, however. The reason you need https: versus > http: is that it's the server providing the reference and it's the > only one that knows whether the resource is to be accessed over TLS or > not. Right, but it has to communicate that information to the client somehow, = and the URI is really the only place to do it. =20 > As a point of historical trivia, the initial use of this general > convention wasn't https:// but rather shttp://, and the intent of the > originator, Allan Schiffman, was to make it impossible for a > non-Secure HTTP capable client to accidentally reference via HTTP a > resource which should be secure. I wasn't aware of the originator's name, but certainly agree with the = intent. =20 There's a huge problem with in-band negotiation of security if either = (a) it's feasible for an attacker to get the client to downgrade to = insufficient security, or (b) it's so much work for the client to = negotiate good security that clients tend to be lazy and not bother to = even try.=20 One thing I find fairly annoying about URIs in that we'd really like to = be able to attach attributes and/or constraints to a URI (like what the = minimum security requirements should be) for the purpose of things like = bookmarks, but we don't have a uniform URI syntax that lets us define = such attributes and/or constraints while still being able to easily = separate them from the name of the resource being referred to. Keith From ned.freed@mrochek.com Fri Nov 4 08:36:31 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E23721F8A71; Fri, 4 Nov 2011 08:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 Uf0RaQaiQio2; Fri, 4 Nov 2011 08:36:30 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C4CC421F8A70; Fri, 4 Nov 2011 08:36:30 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O80L7PEC340183VD@mauve.mrochek.com>; Fri, 4 Nov 2011 08:33:43 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O7ZO5R0F0G00RCTX@mauve.mrochek.com>; Fri, 4 Nov 2011 08:33:40 -0700 (PDT) Message-id: <01O80L7NM7N000RCTX@mauve.mrochek.com> Date: Fri, 04 Nov 2011 08:31:20 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 01 Nov 2011 13:44:19 -0700" <4EB05A23.3060101@alvestrand.no> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> To: Harald Alvestrand X-Mailman-Approved-At: Fri, 04 Nov 2011 08:52:42 -0700 Cc: Ned Freed , Keith Moore , Keith Moore , "rtcweb@ietf.org" , Behave WG Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Nov 2011 15:36:31 -0000 > Top-posting a general principle, detailed comment at the bottom.... > For all URI schemes, I think the URI needs to contain all the > information you need in order to make contact with the service; you > can't negotiate until you've made contact. > (the process may involve things like "resolve through a resolution > mechanism like DNS" or "get authorization tokens from somewhere else"). > In the case of TURN, you need to distinguish between TCP, UDP and TLS, > and you need to make that determination before you send the first > packet. That means the distinguishing information between those three > things belongs in the URL; I don't think the scheme is a good place to > encode it. I'm in complete agreement with Harald on all of these points. And while it would have been nice if URL syntax was less messy and more general, making it easier to do these sorts of things in a consistent way, it quite simply isn't and we have to make do with what we have. Ned From ekr@rtfm.com Fri Nov 4 08:56:58 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61F321F8B7B; Fri, 4 Nov 2011 08:56:58 -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 qZ3CsaOzw8rw; Fri, 4 Nov 2011 08:56:58 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F22A421F8B49; Fri, 4 Nov 2011 08:56:57 -0700 (PDT) Received: by vws5 with SMTP id 5so220460vws.31 for ; Fri, 04 Nov 2011 08:56:54 -0700 (PDT) Received: by 10.52.65.14 with SMTP id t14mr13419980vds.47.1320422214081; Fri, 04 Nov 2011 08:56:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Fri, 4 Nov 2011 08:56:13 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <01O80L7NM7N000RCTX@mauve.mrochek.com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> From: Eric Rescorla Date: Fri, 4 Nov 2011 08:56:13 -0700 Message-ID: To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 Cc: Keith Moore , Keith Moore , Behave WG , "rtcweb@ietf.org" Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Nov 2011 15:56:58 -0000 On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed wrote: >> Top-posting a general principle, detailed comment at the bottom.... > >> For all URI schemes, I think the URI needs to contain all the >> information you need in order to make contact with the service; you >> can't negotiate until you've made contact. >> (the process may involve things like "resolve through a resolution >> mechanism like DNS" or "get authorization tokens from somewhere else"). > >> In the case of TURN, you need to distinguish between TCP, UDP and TLS, >> and you need to make that determination before you send the first >> packet. That means the distinguishing information between those three >> things belongs in the URL; I don't think the scheme is a good place to >> encode it. > > I'm in complete agreement with Harald on all of these points. And while it > would have been nice if URL syntax was less messy and more general, making > it easier to do these sorts of things in a consistent way, it quite simply > isn't and we have to make do with what we have. I don't have any commitment to the scheme. What's the best place? -Ekr From dwing@cisco.com Fri Nov 4 09:06:20 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD2C21F8CA1; Fri, 4 Nov 2011 09:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.578 X-Spam-Level: X-Spam-Status: No, score=-105.578 tagged_above=-999 required=5 tests=[AWL=1.021, 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 dewo4gp7akOA; Fri, 4 Nov 2011 09:06:19 -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 2E0F421F8C9E; Fri, 4 Nov 2011 09:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1860; q=dns/txt; s=iport; t=1320422779; x=1321632379; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=9m+Vvi+nxuAvN6Wd+QzSkVe5onXVhRKd5pV73Wmdcuk=; b=ZGqrHYxB6kl/vM6ueQp83jvjLMpKP258aE6R55v16VQzLc9PbiVwbrJQ Oikmxc8fX46AFQrAl+Db3T6JVGHnDwrwtu3HxIaCojWaLyECINEOJ7TWh G0StqggpZ/4YhC9gFVB3989jOHK4R2tpXCBBYFqn1cUqfX7tC7T4wGQrE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskAAE8NtE6rRDoJ/2dsb2JhbABEmhCBa4xogSCBBYFyAQEBBAEBAQUKARcQNAsMAQMCCQ4BAgQBAQEnBxkOFQoJCAEBBAESCxeHaJZ5AZ5ciSsEiAqeGA X-IronPort-AV: E=Sophos;i="4.69,456,1315180800"; d="scan'208";a="12370910" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 04 Nov 2011 16:06:07 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA4G67gs000440; Fri, 4 Nov 2011 16:06:07 GMT From: "Dan Wing" To: "'Eric Rescorla'" , "'Ned Freed'" References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> In-Reply-To: Date: Fri, 4 Nov 2011 09:06:07 -0700 Message-ID: <02a901cc9b0b$a9638940$fc2a9bc0$@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: AcybCmTMk2kTkttER/CHovfDIrg3zwAAQ4Zw Content-Language: en-us Cc: 'Behave WG' , 'Keith Moore' , 'Keith Moore' , rtcweb@ietf.org Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Nov 2011 16:06:20 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Eric Rescorla > Sent: Friday, November 04, 2011 8:56 AM > To: Ned Freed > Cc: Keith Moore; Keith Moore; Behave WG; rtcweb@ietf.org > Subject: Re: [rtcweb] URI schemes for TURN and STUN > > On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed > wrote: > >> Top-posting a general principle, detailed comment at the bottom.... > > > >> For all URI schemes, I think the URI needs to contain all the > >> information you need in order to make contact with the service; you > >> can't negotiate until you've made contact. > >> (the process may involve things like "resolve through a resolution > >> mechanism like DNS" or "get authorization tokens from somewhere > else"). > > > >> In the case of TURN, you need to distinguish between TCP, UDP and > TLS, > >> and you need to make that determination before you send the first > >> packet. That means the distinguishing information between those > three > >> things belongs in the URL; I don't think the scheme is a good place > to > >> encode it. > > > > I'm in complete agreement with Harald on all of these points. And > while it > > would have been nice if URL syntax was less messy and more general, > making > > it easier to do these sorts of things in a consistent way, it quite > simply > > isn't and we have to make do with what we have. > > I don't have any commitment to the scheme. What's the best place? http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-bis-05 uses "?transport=", for example: turn://example.com?transport=tcp turns://example.com?transport=udp -d > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From petithug@acm.org Fri Nov 4 09:17:33 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE5F21F8C1E; Fri, 4 Nov 2011 09:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.721 X-Spam-Level: X-Spam-Status: No, score=-102.721 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, NO_RELAYS=-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 v5HDOoI-sG3F; Fri, 4 Nov 2011 09:17:32 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 6017521F8C34; Fri, 4 Nov 2011 09:17:32 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 3FE3220595; Fri, 4 Nov 2011 16:08:30 +0000 (UTC) Message-ID: <4EB41016.7080205@acm.org> Date: Fri, 04 Nov 2011 09:17:26 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Dan Wing References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <02a901cc9b0b$a9638940$fc2a9bc0$@com> In-Reply-To: <02a901cc9b0b$a9638940$fc2a9bc0$@com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'Behave WG' , 'Keith Moore' , 'Keith Moore' , 'Ned Freed' , rtcweb@ietf.org Subject: Re: [rtcweb] [BEHAVE] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Nov 2011 16:17:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/04/2011 09:06 AM, Dan Wing wrote: >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Eric Rescorla >> Sent: Friday, November 04, 2011 8:56 AM >> To: Ned Freed >> Cc: Keith Moore; Keith Moore; Behave WG; rtcweb@ietf.org >> Subject: Re: [rtcweb] URI schemes for TURN and STUN >> >> On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed >> wrote: >>>> Top-posting a general principle, detailed comment at the bottom.... >>> >>>> For all URI schemes, I think the URI needs to contain all the >>>> information you need in order to make contact with the service; you >>>> can't negotiate until you've made contact. >>>> (the process may involve things like "resolve through a resolution >>>> mechanism like DNS" or "get authorization tokens from somewhere >> else"). >>> >>>> In the case of TURN, you need to distinguish between TCP, UDP and >> TLS, >>>> and you need to make that determination before you send the first >>>> packet. That means the distinguishing information between those >> three >>>> things belongs in the URL; I don't think the scheme is a good place >> to >>>> encode it. >>> >>> I'm in complete agreement with Harald on all of these points. And >> while it >>> would have been nice if URL syntax was less messy and more general, >> making >>> it easier to do these sorts of things in a consistent way, it quite >> simply >>> isn't and we have to make do with what we have. >> >> I don't have any commitment to the scheme. What's the best place? > > http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-bis-05 > uses "?transport=", for example: > > turn://example.com?transport=tcp > turns://example.com?transport=udp The document uses opaque URI (there was a long discussion at the time about this), so it is in fact: turn:example.com?transport=tcp turns:example.com?transport=udp - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk60EBIACgkQ9RoMZyVa61fG4wCeLR4SnIoXerj7ONxM6QeKgjZh rmoAmwbBUDmL6YOlnfH1sWsC6a6R+4Bz =Iqfa -----END PGP SIGNATURE----- From ibc@aliax.net Fri Nov 4 09:31:21 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AB421F85B8 for ; Fri, 4 Nov 2011 09:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.033, 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 DLhvFuA5lCwz for ; Fri, 4 Nov 2011 09:31:21 -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 D155021F8C53 for ; Fri, 4 Nov 2011 09:31:19 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so2628594vcb.31 for ; Fri, 04 Nov 2011 09:31:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.113.227 with SMTP id jb3mr15534848vdb.15.1320424279319; Fri, 04 Nov 2011 09:31:19 -0700 (PDT) Received: by 10.220.107.206 with HTTP; Fri, 4 Nov 2011 09:31:19 -0700 (PDT) Received: by 10.220.107.206 with HTTP; Fri, 4 Nov 2011 09:31:19 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Nov 2011 17:31:19 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Xavier Marjou Content-Type: multipart/alternative; boundary=bcaec548a6831f25fd04b0eb3c32 Cc: "rtcweb@ietf.org" , "Bran, Cary" Subject: Re: [rtcweb] Codec 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: Fri, 04 Nov 2011 16:31:21 -0000 --bcaec548a6831f25fd04b0eb3c32 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El 04/11/2011 15:20, "Xavier Marjou" escribi=C3= =B3: > > http://tools.ietf.org/html/draft-kaplan-rtcweb-sip-interworking-requirement= s-00, which I fully support by the way. Xavier, such draft does not propose that Webrtc must implement all the requirements in the draft. It just lists all the requirements needed in order to fully interoperate with current SIP deployments and opens the door for discussion about it. So if you "fully support" this draft it means that you are just interested in making Webrtc to work with current SIP, regardless security requirements in the Web. So let me know: do you support that browsers must implement g729? Do you support that webrtc requires not security at all in the media plane (like legacy SIP)? If so, I dont think you care about Webrtc for the Web, but just for telcos. Behaviors like this one makes this WG to seem a telco party rather than a WG working for the Web. WebRTC means RTC for the Web, rather than Web for telcos, or that is what I hope. Regards. --bcaec548a6831f25fd04b0eb3c32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

El 04/11/2011 15:20, "Xavier Marjou" <xavier.marjou@orange.com> escribi=C3=B3:
>
> http://tools.ietf.org/html/draft-kaplan-rtcweb-sip-in= terworking-requirements-00,=C2=A0which I fully support by the way.

Xavier, such draft does not propose that Webrtc must implement all the r= equirements in the draft. It just lists all the requirements needed in orde= r to fully interoperate with current SIP deployments and opens the door for= discussion about it.

So if you "fully support" this draft it means that you are jus= t interested in making Webrtc to work with current SIP, regardless security= requirements in the Web.

So let me know: do you support that browsers must implement g729? Do you= support that webrtc requires not security at all in the media plane (like = legacy SIP)?

If so, I dont think you care about Webrtc for the Web, but just for telc= os. Behaviors like this one makes this WG to seem a telco party rather than= a WG working for the Web. WebRTC means RTC for the Web, rather than Web fo= r telcos, or that is what I hope.

Regards.

--bcaec548a6831f25fd04b0eb3c32-- From dwing@cisco.com Fri Nov 4 09:40:06 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB14821F8B94; Fri, 4 Nov 2011 09:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.596 X-Spam-Level: X-Spam-Status: No, score=-105.596 tagged_above=-999 required=5 tests=[AWL=1.003, 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 AbbuJGXFTloa; Fri, 4 Nov 2011 09:40:06 -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 292EF21F8B8C; Fri, 4 Nov 2011 09:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2916; q=dns/txt; s=iport; t=1320424806; x=1321634406; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=3FFzVr98U5iKNxQRdySfKo7z7wk+XmW1xyA0wTBuqm8=; b=Ky+/EwIDsoseEhF/uq0n/FiMHQNvn/1FeOOqaCEVVw61eIHjzCTaR4O9 PZEO9VknNSxdo/reIRRvvYfpJ0+s9/xbbCIFs2MBKj8sMV7Cz8vlWRwAd q8jVowI5gVemaJYJlVdcsZPcPoM9UUGm3q5axBXCL1jqhcXWbYCUNcjoq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskAAEEVtE6rRDoH/2dsb2JhbABEhHqVFoFrjGiBIIEFgXIBAQEECAoBEAdPDAEDAgkPAgQBAQECAiMDAgIZIwoJCAEBBBMLF4dolxoBjEuSDYEwhmWBFgSICp4Y X-IronPort-AV: E=Sophos;i="4.69,456,1315180800"; d="scan'208";a="12392035" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 04 Nov 2011 16:40:05 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA4Ge5Qx011233; Fri, 4 Nov 2011 16:40:05 GMT From: "Dan Wing" To: "'Marc Petit-Huguenin'" References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <02a901cc9b0b$a9638940$fc2a9bc0$@com> <4EB41016.7080205@acm.org> In-Reply-To: <4EB41016.7080205@acm.org> Date: Fri, 4 Nov 2011 09:40:05 -0700 Message-ID: <02be01cc9b10$6816f9e0$3844eda0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcybDUFWu8RSTTcyS+O+hnVed8FuKwAAxdIw Content-Language: en-us Cc: 'Behave WG' , 'Keith Moore' , 'Keith Moore' , 'Ned Freed' , rtcweb@ietf.org Subject: Re: [rtcweb] [BEHAVE] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Nov 2011 16:40:07 -0000 > -----Original Message----- > From: Marc Petit-Huguenin [mailto:petithug@acm.org] > Sent: Friday, November 04, 2011 9:17 AM > To: Dan Wing > Cc: 'Eric Rescorla'; 'Ned Freed'; 'Behave WG'; 'Keith Moore'; 'Keith > Moore'; rtcweb@ietf.org > Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/04/2011 09:06 AM, Dan Wing wrote: > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of Eric Rescorla > >> Sent: Friday, November 04, 2011 8:56 AM > >> To: Ned Freed > >> Cc: Keith Moore; Keith Moore; Behave WG; rtcweb@ietf.org > >> Subject: Re: [rtcweb] URI schemes for TURN and STUN > >> > >> On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed > >> wrote: > >>>> Top-posting a general principle, detailed comment at the > bottom.... > >>> > >>>> For all URI schemes, I think the URI needs to contain all the > >>>> information you need in order to make contact with the service; > you > >>>> can't negotiate until you've made contact. > >>>> (the process may involve things like "resolve through a resolution > >>>> mechanism like DNS" or "get authorization tokens from somewhere > >> else"). > >>> > >>>> In the case of TURN, you need to distinguish between TCP, UDP and > >> TLS, > >>>> and you need to make that determination before you send the first > >>>> packet. That means the distinguishing information between those > >> three > >>>> things belongs in the URL; I don't think the scheme is a good > place > >> to > >>>> encode it. > >>> > >>> I'm in complete agreement with Harald on all of these points. And > >> while it > >>> would have been nice if URL syntax was less messy and more general, > >> making > >>> it easier to do these sorts of things in a consistent way, it quite > >> simply > >>> isn't and we have to make do with what we have. > >> > >> I don't have any commitment to the scheme. What's the best place? > > > > http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-bis-05 > > uses "?transport=", for example: > > > > turn://example.com?transport=tcp > > turns://example.com?transport=udp > > The document uses opaque URI (there was a long discussion at the time > about > this), so it is in fact: > > turn:example.com?transport=tcp > turns:example.com?transport=udp Thanks for the correction. (some examples in the I-D would be useful, to avoid mistakes like mine.) -d > - -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk60EBIACgkQ9RoMZyVa61fG4wCeLR4SnIoXerj7ONxM6QeKgjZh > rmoAmwbBUDmL6YOlnfH1sWsC6a6R+4Bz > =Iqfa > -----END PGP SIGNATURE----- From ekr@rtfm.com Fri Nov 4 09:43:18 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FD411E8086; Fri, 4 Nov 2011 09:43:18 -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 XneiaqgoENNT; Fri, 4 Nov 2011 09:43:17 -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 B845411E8082; Fri, 4 Nov 2011 09:43:17 -0700 (PDT) Received: by gye5 with SMTP id 5so3070057gye.31 for ; Fri, 04 Nov 2011 09:43:16 -0700 (PDT) Received: by 10.150.190.10 with SMTP id n10mr15665085ybf.70.1320424996087; Fri, 04 Nov 2011 09:43:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.232.12 with HTTP; Fri, 4 Nov 2011 09:42:35 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <02a901cc9b0b$a9638940$fc2a9bc0$@com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <02a901cc9b0b$a9638940$fc2a9bc0$@com> From: Eric Rescorla Date: Fri, 4 Nov 2011 09:42:35 -0700 Message-ID: To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Keith Moore , Ned Freed , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Nov 2011 16:43:18 -0000 On Fri, Nov 4, 2011 at 9:06 AM, Dan Wing wrote: >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Eric Rescorla >> Sent: Friday, November 04, 2011 8:56 AM >> To: Ned Freed >> Cc: Keith Moore; Keith Moore; Behave WG; rtcweb@ietf.org >> Subject: Re: [rtcweb] URI schemes for TURN and STUN >> >> On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed >> wrote: >> >> Top-posting a general principle, detailed comment at the bottom.... >> > >> >> For all URI schemes, I think the URI needs to contain all the >> >> information you need in order to make contact with the service; you >> >> can't negotiate until you've made contact. >> >> (the process may involve things like "resolve through a resolution >> >> mechanism like DNS" or "get authorization tokens from somewhere >> else"). >> > >> >> In the case of TURN, you need to distinguish between TCP, UDP and >> TLS, >> >> and you need to make that determination before you send the first >> >> packet. That means the distinguishing information between those >> three >> >> things belongs in the URL; I don't think the scheme is a good place >> to >> >> encode it. >> > >> > I'm in complete agreement with Harald on all of these points. And >> while it >> > would have been nice if URL syntax was less messy and more general, >> making >> > it easier to do these sorts of things in a consistent way, it quite >> simply >> > isn't and we have to make do with what we have. >> >> I don't have any commitment to the scheme. What's the best place? > > http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-bis-05 > uses "?transport=3D", for example: > > =A0turn://example.com?transport=3Dtcp > =A0turns://example.com?transport=3Dudp I'm confused. I thought the idea was to distinguish TLS from non-TLS, but you seem to be doing that in the scheme. -Ekr From petithug@acm.org Fri Nov 4 09:49:37 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC74A11E8082; Fri, 4 Nov 2011 09:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.706 X-Spam-Level: X-Spam-Status: No, score=-102.706 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, NO_RELAYS=-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 C5WgsAgstQpQ; Fri, 4 Nov 2011 09:49:37 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id DD34111E8081; Fri, 4 Nov 2011 09:49:36 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id A19BD20595; Fri, 4 Nov 2011 16:40:35 +0000 (UTC) Message-ID: <4EB4179C.9050703@acm.org> Date: Fri, 04 Nov 2011 09:49:32 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Dan Wing References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <02a901cc9b0b$a9638940$fc2a9bc0$@com> <4EB41016.7080205@acm.org> <02be01cc9b10$6816f9e0$3844eda0$@com> In-Reply-To: <02be01cc9b10$6816f9e0$3844eda0$@com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'Behave WG' , 'Keith Moore' , 'Keith Moore' , 'Ned Freed' , rtcweb@ietf.org Subject: Re: [rtcweb] [BEHAVE] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Nov 2011 16:49:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/04/2011 09:40 AM, Dan Wing wrote: >> -----Original Message----- >> From: Marc Petit-Huguenin [mailto:petithug@acm.org] >> Sent: Friday, November 04, 2011 9:17 AM >> To: Dan Wing >> Cc: 'Eric Rescorla'; 'Ned Freed'; 'Behave WG'; 'Keith Moore'; 'Keith >> Moore'; rtcweb@ietf.org >> Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN >> > On 11/04/2011 09:06 AM, Dan Wing wrote: >>>>> -----Original Message----- >>>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>>> Behalf Of Eric Rescorla >>>>> Sent: Friday, November 04, 2011 8:56 AM >>>>> To: Ned Freed >>>>> Cc: Keith Moore; Keith Moore; Behave WG; rtcweb@ietf.org >>>>> Subject: Re: [rtcweb] URI schemes for TURN and STUN >>>>> >>>>> On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed >>>>> wrote: >>>>>>> Top-posting a general principle, detailed comment at the > bottom.... >>>>>> >>>>>>> For all URI schemes, I think the URI needs to contain all the >>>>>>> information you need in order to make contact with the service; > you >>>>>>> can't negotiate until you've made contact. >>>>>>> (the process may involve things like "resolve through a resolution >>>>>>> mechanism like DNS" or "get authorization tokens from somewhere >>>>> else"). >>>>>> >>>>>>> In the case of TURN, you need to distinguish between TCP, UDP and >>>>> TLS, >>>>>>> and you need to make that determination before you send the first >>>>>>> packet. That means the distinguishing information between those >>>>> three >>>>>>> things belongs in the URL; I don't think the scheme is a good > place >>>>> to >>>>>>> encode it. >>>>>> >>>>>> I'm in complete agreement with Harald on all of these points. And >>>>> while it >>>>>> would have been nice if URL syntax was less messy and more general, >>>>> making >>>>>> it easier to do these sorts of things in a consistent way, it quite >>>>> simply >>>>>> isn't and we have to make do with what we have. >>>>> >>>>> I don't have any commitment to the scheme. What's the best place? >>>> >>>> http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-bis-05 >>>> uses "?transport=", for example: >>>> >>>> turn://example.com?transport=tcp >>>> turns://example.com?transport=udp > > The document uses opaque URI (there was a long discussion at the time > about > this), so it is in fact: > > turn:example.com?transport=tcp > turns:example.com?transport=udp > >> Thanks for the correction. > >> (some examples in the I-D would be useful, to avoid mistakes like mine.) Will do. Thanks. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk60F5oACgkQ9RoMZyVa61ccqQCePrkokWQlZIpgRImOVnUngs9Q w34An2U9EgwpFclj98m6MJl68GAkziIz =qrda -----END PGP SIGNATURE----- From dwing@cisco.com Fri Nov 4 09:53:44 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF8121F8B84; Fri, 4 Nov 2011 09:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.614 X-Spam-Level: X-Spam-Status: No, score=-105.614 tagged_above=-999 required=5 tests=[AWL=0.985, 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 6ukHfcYv5LD5; Fri, 4 Nov 2011 09:53:44 -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 04FF721F8B7A; Fri, 4 Nov 2011 09:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2605; q=dns/txt; s=iport; t=1320425623; x=1321635223; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=keQN27SFU7jMNb+nq99Nz52/d2Dm5ac/t1hImCdFXEk=; b=Thc+xil7v7PXBxtTIHX0fojyJzYtF+Dt4nUgV1Bgpe5pAVZWq9+fEScJ RKAsK5wgjNS4cA1vMK+ZGasSQ8nCZcBE9lzm+5rKCrWuxfyDdhOoFNGCA ZNKCVGA3T5HfI6U2shJuPhXdVl6k6yVS0Bey3WEuy2IWfgSumaPe0udRT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskAAPEXtE6rRDoI/2dsb2JhbABEmhCBa4xogSCBBYFyAQEBAwEICgEXTwwBAwIJDgECBAEBAScHGSMKCQgBAQQTCxeHYAiXIwGeU4krBIdZMZ4Y X-IronPort-AV: E=Sophos;i="4.69,456,1315180800"; d="scan'208";a="10977601" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 04 Nov 2011 16:53:43 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA4GrfBK011647; Fri, 4 Nov 2011 16:53:42 GMT From: "Dan Wing" To: "'Eric Rescorla'" References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <02a901cc9b0b$a9638940$fc2a9bc0$@com> In-Reply-To: Date: Fri, 4 Nov 2011 09:53:41 -0700 Message-ID: <02d801cc9b12$4ef4bb80$ecde3280$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcybENwFGD02H39KSmeHmaD54VpzsgAAKUXg Content-Language: en-us Cc: 'Keith Moore' , 'Ned Freed' , 'Keith Moore' , 'Behave WG' , rtcweb@ietf.org Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 04 Nov 2011 16:53:44 -0000 > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: Friday, November 04, 2011 9:43 AM > To: Dan Wing > Cc: Ned Freed; Keith Moore; Keith Moore; Behave WG; rtcweb@ietf.org > Subject: Re: [rtcweb] URI schemes for TURN and STUN >=20 > On Fri, Nov 4, 2011 at 9:06 AM, Dan Wing wrote: > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of Eric Rescorla > >> Sent: Friday, November 04, 2011 8:56 AM > >> To: Ned Freed > >> Cc: Keith Moore; Keith Moore; Behave WG; rtcweb@ietf.org > >> Subject: Re: [rtcweb] URI schemes for TURN and STUN > >> > >> On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed > >> wrote: > >> >> Top-posting a general principle, detailed comment at the > bottom.... > >> > > >> >> For all URI schemes, I think the URI needs to contain all the > >> >> information you need in order to make contact with the service; > you=09 > >> >> can't negotiate until you've made contact. > >> >> (the process may involve things like "resolve through a > resolution > >> >> mechanism like DNS" or "get authorization tokens from somewhere > >> else"). > >> > > >> >> In the case of TURN, you need to distinguish between TCP, UDP = and > >> TLS, > >> >> and you need to make that determination before you send the = first > >> >> packet. That means the distinguishing information between those > >> three > >> >> things belongs in the URL; I don't think the scheme is a good > place > >> to > >> >> encode it. > >> > > >> > I'm in complete agreement with Harald on all of these points. And > >> while it > >> > would have been nice if URL syntax was less messy and more > general, > >> making > >> > it easier to do these sorts of things in a consistent way, it > quite > >> simply > >> > isn't and we have to make do with what we have. > >> > >> I don't have any commitment to the scheme. What's the best place? > > > > = http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uri-bis-05 > > uses "?transport=3D", for example: > > > > =A0turn://example.com?transport=3Dtcp > > =A0turns://example.com?transport=3Dudp >=20 > I'm confused. I thought the idea was to distinguish TLS from non-TLS, > but you seem to be doing that in the scheme. Harald said: URI needs to contain all the information you need in order to make contact with the service; you can't negotiate until you've made contact. Keith has never liked using "S" in HTTPS (or other URIs). *shrug*. I think that ship sailed. -d From Cary.Bran@plantronics.com Fri Nov 4 10:07:27 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6B61F0C34 for ; Fri, 4 Nov 2011 10:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.206 X-Spam-Level: X-Spam-Status: No, score=-0.206 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, GB_VISITOURSITE=2, 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 pmEWnYNdZNLG for ; Fri, 4 Nov 2011 10:07:26 -0700 (PDT) Received: from mail4.plantronics.com (mail4.plantronics.com [12.151.41.50]) by ietfa.amsl.com (Postfix) with ESMTP id 97FF721F8BD7 for ; Fri, 4 Nov 2011 10:07:26 -0700 (PDT) Received: from usscch03.plt.plantronics.com (usscch03.plt.plantronics.com [10.1.3.26]) by mail4.plantronics.com (8.13.8/8.13.8) with ESMTP id pA4H7OeE006844; Fri, 4 Nov 2011 10:07:24 -0700 Received: from USSCMB03.plt.plantronics.com ([fe80::5824:67c8:930e:7c1e]) by USSCCH03.plt.plantronics.com ([::1]) with mapi id 14.01.0270.001; Fri, 4 Nov 2011 10:07:24 -0700 From: "Bran, Cary" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Xavier Marjou Thread-Topic: [rtcweb] Codec Draft Thread-Index: AcyYG7T52+iin6+9RSSZxK1D9q2OmQDGdscAAAB/HIAABJOHgAAN1ePA Date: Fri, 4 Nov 2011 17:07:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.1.18] Content-Type: multipart/alternative; boundary="_000_E37C139C5CB78244A781E9E7B721527B54C27FUSSCMB03pltplantr_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.67 on 10.63.1.50 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Codec 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: Fri, 04 Nov 2011 17:07:27 -0000 --_000_E37C139C5CB78244A781E9E7B721527B54C27FUSSCMB03pltplantr_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ScOxYWtpLA0KDQpJIGFncmVlIHdpdGggeW91IHdpdGggcmVnYXJkcyB0byBXZWJSVEMgbmVlZHMg dG8gZW1icmFjZSBhIHdlYiBwYXJhZGlnbSBhbmQgSSBhbSBhIGxpdHRsZSBjb25mdXNlZCBob3cg dGhlIGxhdGVzdCB2ZXJzaW9uIG9mIG91ciBkb2N1bWVudCBpbXBsaWVzIGEgdGVsY28gcGFyYWRp Z20uDQoNClRoZSAwMSB2ZXJzaW9uIGNhbiBiZSBmb3VuZCBoZXJlOiAgaHR0cDovL3Rvb2xzLmll dGYub3JnL2lkL2RyYWZ0LWNicmFuLXJ0Y3dlYi1jb2RlYy0wMS50eHQNCg0KDQpDdXJyZW50bHkg dGhlIGRvY3VtZW50cyBsaXN0cyB0d28gdmlkZW8gY29kZWMgY2FuZGlkYXRlcyAoVlA4L0guMjY0 KSAsIGFuZCB0aHJlZSBhdWRpbyBjb2RlYyBjYW5kaWRhdGVzLCBQQ01BL1BDTVUsIFRlbGVwaG9u ZSBFdmVudCBhbmQgT3B1cy4NCg0KDQoNCklmIHlvdSBoYXZlIGFueXRoaW5nIGNvZGVjcyB0byBh ZGQgdGhhdCB3b3VsZCBiZSBjb25zaWRlcmVkIG1vcmUgd2ViIGNlbnRyaWMsIHBsZWFzZSBsZXQg dXMga25vdyBhbmQgd2UgY2FuIGFkZCBpdCB0byB0aGUgb3BlbiBpc3N1ZXMgbGlzdC4NCg0KQ2hl ZXJzLA0KDQotQ2FyeQ0KDQpGcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86aWJjQGFs aWF4Lm5ldF0NClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMDQsIDIwMTEgOTozMSBBTQ0KVG86IFhh dmllciBNYXJqb3UNCkNjOiBCcmFuLCBDYXJ5OyBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbcnRjd2ViXSBDb2RlYyBEcmFmdA0KDQoNCkVsIDA0LzExLzIwMTEgMTU6MjAsICJYYXZpZXIg TWFyam91IiA8eGF2aWVyLm1hcmpvdUBvcmFuZ2UuY29tPG1haWx0bzp4YXZpZXIubWFyam91QG9y YW5nZS5jb20+PiBlc2NyaWJpw7M6DQo+DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWthcGxhbi1ydGN3ZWItc2lwLWludGVyd29ya2luZy1yZXF1aXJlbWVudHMtMDAsIHdoaWNo IEkgZnVsbHkgc3VwcG9ydCBieSB0aGUgd2F5Lg0KDQpYYXZpZXIsIHN1Y2ggZHJhZnQgZG9lcyBu b3QgcHJvcG9zZSB0aGF0IFdlYnJ0YyBtdXN0IGltcGxlbWVudCBhbGwgdGhlIHJlcXVpcmVtZW50 cyBpbiB0aGUgZHJhZnQuIEl0IGp1c3QgbGlzdHMgYWxsIHRoZSByZXF1aXJlbWVudHMgbmVlZGVk IGluIG9yZGVyIHRvIGZ1bGx5IGludGVyb3BlcmF0ZSB3aXRoIGN1cnJlbnQgU0lQIGRlcGxveW1l bnRzIGFuZCBvcGVucyB0aGUgZG9vciBmb3IgZGlzY3Vzc2lvbiBhYm91dCBpdC4NCg0KU28gaWYg eW91ICJmdWxseSBzdXBwb3J0IiB0aGlzIGRyYWZ0IGl0IG1lYW5zIHRoYXQgeW91IGFyZSBqdXN0 IGludGVyZXN0ZWQgaW4gbWFraW5nIFdlYnJ0YyB0byB3b3JrIHdpdGggY3VycmVudCBTSVAsIHJl Z2FyZGxlc3Mgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGluIHRoZSBXZWIuDQoNClNvIGxldCBtZSBr bm93OiBkbyB5b3Ugc3VwcG9ydCB0aGF0IGJyb3dzZXJzIG11c3QgaW1wbGVtZW50IGc3Mjk/IERv IHlvdSBzdXBwb3J0IHRoYXQgd2VicnRjIHJlcXVpcmVzIG5vdCBzZWN1cml0eSBhdCBhbGwgaW4g dGhlIG1lZGlhIHBsYW5lIChsaWtlIGxlZ2FjeSBTSVApPw0KDQpJZiBzbywgSSBkb250IHRoaW5r IHlvdSBjYXJlIGFib3V0IFdlYnJ0YyBmb3IgdGhlIFdlYiwgYnV0IGp1c3QgZm9yIHRlbGNvcy4g QmVoYXZpb3JzIGxpa2UgdGhpcyBvbmUgbWFrZXMgdGhpcyBXRyB0byBzZWVtIGEgdGVsY28gcGFy dHkgcmF0aGVyIHRoYW4gYSBXRyB3b3JraW5nIGZvciB0aGUgV2ViLiBXZWJSVEMgbWVhbnMgUlRD IGZvciB0aGUgV2ViLCByYXRoZXIgdGhhbiBXZWIgZm9yIHRlbGNvcywgb3IgdGhhdCBpcyB3aGF0 IEkgaG9wZS4NCg0KUmVnYXJkcy4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlLW1haWwgdHJhbnNtaXNzaW9uLCBhbmQg YW55IGRvY3VtZW50cywgZmlsZXMgb3IgcHJldmlvdXMgZS1tYWlsIG1lc3NhZ2VzIGF0dGFjaGVk IHRvIGl0LCBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlzIGNvbmZpZGVudGlhbCBhbmQv b3IgbGVnYWxseSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCBvciBhIHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyBpdCB0byB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgRE8gTk9UIGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBh bm90aGVyIHBlcnNvbiwgc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1 bSwgb3IgdXNlIGFueSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIG9yIGF0dGFjaGVk IHRvIHRoaXMgdHJhbnNtaXNzaW9uIGZvciBhbnkgcHVycG9zZS4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkg dGhlIHNlbmRlciBieSByZXBseSBlbWFpbCBvciBhdCBwcml2YWN5QHBsYW50cm9uaWNzLmNvbSwg YW5kIGRlc3Ryb3kgdGhlIG9yaWdpbmFsIHRyYW5zbWlzc2lvbiBhbmQgaXRzIGF0dGFjaG1lbnRz IHdpdGhvdXQgcmVhZGluZyBvciBzYXZpbmcgaW4gYW55IG1hbm5lci4NCg0KRm9yIGZ1cnRoZXIg aW5mb3JtYXRpb24gYWJvdXQgUGxhbnRyb25pY3MgLSB0aGUgQ29tcGFueSwgaXRzIHByb2R1Y3Rz LCBicmFuZHMsIHBhcnRuZXJzLCBwbGVhc2UgdmlzaXQgb3VyIHdlYnNpdGUgd3d3LnBsYW50cm9u aWNzLmNvbS4NCg== --_000_E37C139C5CB78244A781E9E7B721527B54C27FUSSCMB03pltplantr_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaX0NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hfQ0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiJ9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZX0NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZX0NCnANCgl7bWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi fQ0KcHJlDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3In0NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RH0N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3In0N Ci5Nc29DaHBEZWZhdWx0DQoJe2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiJ9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlufQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXt9DQotLT4NCjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozsg Y29sb3I6YmxhY2siPknDsWFraSw8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xv cjpibGFjayI+SSBhZ3JlZSB3aXRoIHlvdSB3aXRoIHJlZ2FyZHMgdG8gV2ViUlRDIG5lZWRzIHRv IGVtYnJhY2UgYSB3ZWIgcGFyYWRpZ20gYW5kIEkgYW0gYSBsaXR0bGUgY29uZnVzZWQgaG93IHRo ZSBsYXRlc3QgdmVyc2lvbiBvZiBvdXIgZG9jdW1lbnQgaW1wbGllcyBhIHRlbGNvIHBhcmFkaWdt LiZuYnNwOw0KPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPlRo ZSAwMSB2ZXJzaW9uIGNhbiBiZSBmb3VuZCBoZXJlOiAmbmJzcDs8YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaWQvZHJhZnQtY2JyYW4tcnRjd2ViLWNvZGVjLTAxLnR4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtY2JyYW4tcnRj d2ViLWNvZGVjLTAxLnR4dDwvc3Bhbj48L2E+DQo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNr Ij5DdXJyZW50bHkgdGhlIGRvY3VtZW50cyBsaXN0cyB0d28gdmlkZW8gY29kZWMgY2FuZGlkYXRl cyAoVlA4L0guMjY0KSAsIGFuZCB0aHJlZSBhdWRpbyBjb2RlYyBjYW5kaWRhdGVzLCBQQ01BL1BD TVUsIFRlbGVwaG9uZSBFdmVudCBhbmQgT3B1cy48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj5JZiB5b3UgaGF2ZSBhbnl0aGluZyBjb2RlY3Mg dG8gYWRkIHRoYXQgd291bGQgYmUgY29uc2lkZXJlZCBtb3JlIHdlYiBjZW50cmljLCBwbGVhc2Ug bGV0IHVzIGtub3cgYW5kIHdlIGNhbiBhZGQgaXQgdG8gdGhlIG9wZW4gaXNzdWVzIGxpc3QuPC9z cGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsgY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj5DaGVlcnMsPC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7IGNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siPi1DYXJ5PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86aWJjQGFsaWF4Lm5l dF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE5vdmVtYmVyIDA0LCAyMDExIDk6MzEgQU08 YnI+DQo8Yj5Ubzo8L2I+IFhhdmllciBNYXJqb3U8YnI+DQo8Yj5DYzo8L2I+IEJyYW4sIENhcnk7 IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gQ29kZWMg RHJhZnQ8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHA+RWwg MDQvMTEvMjAxMSAxNToyMCwgJnF1b3Q7WGF2aWVyIE1hcmpvdSZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnhhdmllci5tYXJqb3VAb3JhbmdlLmNvbSI+eGF2aWVyLm1hcmpvdUBvcmFuZ2UuY29t PC9hPiZndDsgZXNjcmliacOzOjxicj4NCiZndDs8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWthcGxhbi1ydGN3ZWItc2lwLWludGVyd29ya2luZy1y ZXF1aXJlbWVudHMtMDAiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta2FwbGFu LXJ0Y3dlYi1zaXAtaW50ZXJ3b3JraW5nLXJlcXVpcmVtZW50cy0wMDwvYT4sJm5ic3A7d2hpY2gg SSBmdWxseSBzdXBwb3J0IGJ5IHRoZSB3YXkuPC9wPg0KPHA+WGF2aWVyLCBzdWNoIGRyYWZ0IGRv ZXMgbm90IHByb3Bvc2UgdGhhdCBXZWJydGMgbXVzdCBpbXBsZW1lbnQgYWxsIHRoZSByZXF1aXJl bWVudHMgaW4gdGhlIGRyYWZ0LiBJdCBqdXN0IGxpc3RzIGFsbCB0aGUgcmVxdWlyZW1lbnRzIG5l ZWRlZCBpbiBvcmRlciB0byBmdWxseSBpbnRlcm9wZXJhdGUgd2l0aCBjdXJyZW50IFNJUCBkZXBs b3ltZW50cyBhbmQgb3BlbnMgdGhlIGRvb3IgZm9yIGRpc2N1c3Npb24gYWJvdXQgaXQuPC9wPg0K PHA+U28gaWYgeW91ICZxdW90O2Z1bGx5IHN1cHBvcnQmcXVvdDsgdGhpcyBkcmFmdCBpdCBtZWFu cyB0aGF0IHlvdSBhcmUganVzdCBpbnRlcmVzdGVkIGluIG1ha2luZyBXZWJydGMgdG8gd29yayB3 aXRoIGN1cnJlbnQgU0lQLCByZWdhcmRsZXNzIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBpbiB0aGUg V2ViLjwvcD4NCjxwPlNvIGxldCBtZSBrbm93OiBkbyB5b3Ugc3VwcG9ydCB0aGF0IGJyb3dzZXJz IG11c3QgaW1wbGVtZW50IGc3Mjk/IERvIHlvdSBzdXBwb3J0IHRoYXQgd2VicnRjIHJlcXVpcmVz IG5vdCBzZWN1cml0eSBhdCBhbGwgaW4gdGhlIG1lZGlhIHBsYW5lIChsaWtlIGxlZ2FjeSBTSVAp PzwvcD4NCjxwPklmIHNvLCBJIGRvbnQgdGhpbmsgeW91IGNhcmUgYWJvdXQgV2VicnRjIGZvciB0 aGUgV2ViLCBidXQganVzdCBmb3IgdGVsY29zLiBCZWhhdmlvcnMgbGlrZSB0aGlzIG9uZSBtYWtl cyB0aGlzIFdHIHRvIHNlZW0gYSB0ZWxjbyBwYXJ0eSByYXRoZXIgdGhhbiBhIFdHIHdvcmtpbmcg Zm9yIHRoZSBXZWIuIFdlYlJUQyBtZWFucyBSVEMgZm9yIHRoZSBXZWIsIHJhdGhlciB0aGFuIFdl YiBmb3IgdGVsY29zLCBvciB0aGF0IGlzIHdoYXQgSSBob3BlLjwvcD4NCjxwPlJlZ2FyZHMuPC9w Pg0KPC9kaXY+DQo8YnI+DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNp emU9IjIiPjxicj4NCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZS1tYWlsIHRyYW5zbWlz c2lvbiwgYW5kIGFueSBkb2N1bWVudHMsIGZpbGVzIG9yIHByZXZpb3VzIGUtbWFpbCBtZXNzYWdl cyBhdHRhY2hlZCB0byBpdCwgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBpcyBjb25maWRl bnRpYWwgYW5kL29yIGxlZ2FsbHkgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgb3IgYSBwZXJzb24gcmVzcG9uc2libGUgZm9yDQogZGVsaXZlcmluZyBp dCB0byB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgRE8gTk9UIGRpc2Nsb3NlIHRoZSBj b250ZW50cyB0byBhbm90aGVyIHBlcnNvbiwgc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24g aW4gYW55IG1lZGl1bSwgb3IgdXNlIGFueSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IG9yIGF0dGFjaGVkIHRvIHRoaXMgdHJhbnNtaXNzaW9uIGZvciBhbnkgcHVycG9zZS4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcw0KIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVk aWF0ZWx5IG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJlcGx5IGVtYWlsIG9yIGF0IHByaXZhY3lAcGxh bnRyb25pY3MuY29tLCBhbmQgZGVzdHJveSB0aGUgb3JpZ2luYWwgdHJhbnNtaXNzaW9uIGFuZCBp dHMgYXR0YWNobWVudHMgd2l0aG91dCByZWFkaW5nIG9yIHNhdmluZyBpbiBhbnkgbWFubmVyLjxi cj4NCjxicj4NCkZvciBmdXJ0aGVyIGluZm9ybWF0aW9uIGFib3V0IFBsYW50cm9uaWNzIC0gdGhl IENvbXBhbnksIGl0cyBwcm9kdWN0cywgYnJhbmRzLCBwYXJ0bmVycywgcGxlYXNlIHZpc2l0IG91 ciB3ZWJzaXRlIHd3dy5wbGFudHJvbmljcy5jb20uPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_E37C139C5CB78244A781E9E7B721527B54C27FUSSCMB03pltplantr_-- From christer.holmberg@ericsson.com Fri Nov 4 10:08:31 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3041F0C3C for ; Fri, 4 Nov 2011 10:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.137, 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 i1hctEiHT9ER for ; Fri, 4 Nov 2011 10:08:31 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B7DBA21F8BD7 for ; Fri, 4 Nov 2011 10:08:30 -0700 (PDT) X-AuditID: c1b4fb39-b7b3eae00000252a-5e-4eb41c0d778c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E9.24.09514.D0C14BE4; Fri, 4 Nov 2011 18:08:29 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 4 Nov 2011 18:08:29 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Xavier Marjou Date: Fri, 4 Nov 2011 18:08:28 +0100 Thread-Topic: [rtcweb] Codec Draft Thread-Index: AcybDzGlugj6GQloShazNa07QiBZ5wAAx+o+ Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522357173BA@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== Cc: "rtcweb@ietf.org" , "Bran, Cary" Subject: Re: [rtcweb] Codec 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: Fri, 04 Nov 2011 17:08:31 -0000 Hi, I don't think that the fact that SIP does not require media security has an= ything to do with telcos. It was a decision made by IETF to not specify any= media plane requirements. (It was also used as an argument in the good old SIP-vs-H.323 battle.) Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of I=F1ak= i Baz Castillo [ibc@aliax.net] Sent: Friday, November 04, 2011 6:31 PM To: Xavier Marjou Cc: rtcweb@ietf.org; Bran, Cary Subject: Re: [rtcweb] Codec Draft El 04/11/2011 15:20, "Xavier Marjou" X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA251F0C3D for ; Fri, 4 Nov 2011 10:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_VISITOURSITE=2, 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 SsBiK0ZX2Jnb for ; Fri, 4 Nov 2011 10:16:53 -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 9A6A11F0C34 for ; Fri, 4 Nov 2011 10:16:53 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so2677992vcb.31 for ; Fri, 04 Nov 2011 10:16:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.199.2 with SMTP id eq2mr1214881vcb.103.1320427013029; Fri, 04 Nov 2011 10:16:53 -0700 (PDT) Received: by 10.220.107.206 with HTTP; Fri, 4 Nov 2011 10:16:52 -0700 (PDT) Received: by 10.220.107.206 with HTTP; Fri, 4 Nov 2011 10:16:52 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Nov 2011 18:16:52 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Bran, Cary" Content-Type: multipart/alternative; boundary=90e6ba53ad2a10412004b0ebdf8b Cc: "rtcweb@ietf.org" , Xavier Marjou Subject: Re: [rtcweb] Codec 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: Fri, 04 Nov 2011 17:16:54 -0000 --90e6ba53ad2a10412004b0ebdf8b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bran. I meant http://tools.ietf.org/html/draft-kaplan-rtcweb-sip-interworking-requirement= s-00 . That draft describes all the requirements for out of the box interoperabiliy between current SIP and WebRTC. It does not try to mandate those requirements, but just to list them. So if somebody "fully supports" this draft it means that browsers MUST implement g729 and allow not security at all, which is annoying. I just replied to a comment "fully supporting" this draft. Regards. El 04/11/2011 18:07, "Bran, Cary" escribi=C3=B3= : > I=C3=B1aki, > > > > I agree with you with regards to WebRTC needs to embrace a web paradigm > and I am a little confused how the latest version of our document implies= a > telco paradigm. > > > > The 01 version can be found here: > http://tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt > > > > Currently the documents lists two video codec candidates (VP8/H.264) , an= d three audio codec candidates, PCMA/PCMU, Telephone Event and Opus. > > > > If you have anything codecs to add that would be considered more web cent= ric, please let us know and we can add it to the open issues list. > > > > Cheers, > > > > -Cary > > > > *From:* I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net] > *Sent:* Friday, November 04, 2011 9:31 AM > *To:* Xavier Marjou > *Cc:* Bran, Cary; rtcweb@ietf.org > *Subject:* Re: [rtcweb] Codec Draft > > > > El 04/11/2011 15:20, "Xavier Marjou" escribi= =C3=B3: > > > > > http://tools.ietf.org/html/draft-kaplan-rtcweb-sip-interworking-requireme= nts-00, which > I fully support by the way. > > Xavier, such draft does not propose that Webrtc must implement all the > requirements in the draft. It just lists all the requirements needed in > order to fully interoperate with current SIP deployments and opens the do= or > for discussion about it. > > So if you "fully support" this draft it means that you are just intereste= d > in making Webrtc to work with current SIP, regardless security requiremen= ts > in the Web. > > So let me know: do you support that browsers must implement g729? Do you > support that webrtc requires not security at all in the media plane (like > legacy SIP)? > > If so, I dont think you care about Webrtc for the Web, but just for > telcos. Behaviors like this one makes this WG to seem a telco party rathe= r > than a WG working for the Web. WebRTC means RTC for the Web, rather than > Web for telcos, or that is what I hope. > > Regards. > > ------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, file= s > or previous e-mail messages attached to it, may contain information that = is > confidential and/or legally privileged. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, please DO NOT disclose the contents to another person, store o= r > copy the information in any medium, or use any of the information contain= ed > in or attached to this transmission for any purpose. If you have received > this transmission in error, please immediately notify the sender by reply > email or at privacy@plantronics.com, and destroy the original > transmission and its attachments without reading or saving in any manner. > > For further information about Plantronics - the Company, its products, > brands, partners, please visit our website www.plantronics.com. > --90e6ba53ad2a10412004b0ebdf8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Bran. I meant http://tools.ietf.org/html/draft-kapla= n-rtcweb-sip-interworking-requirements-00.

That draft describes all the requirements for out of the box interoperab= iliy between current SIP and WebRTC. It does not try to mandate those requi= rements, but just to list them. So if somebody "fully supports" t= his draft it means that browsers MUST implement g729 and allow not security= at all, which is annoying. I just replied to a comment "fully support= ing" this draft.

Regards.

El 04/11/2011 18:07, "Bran, Cary" <= Cary.Bran@plantronics.com&= gt; escribi=C3=B3:

I=C3=B1= aki,

=C2=A0<= /span>

I agree= with you with regards to WebRTC needs to embrace a web paradigm and I am a= little confused how the latest version of our document implies a telco par= adigm.=C2=A0

=C2=A0<= /span>

The 01 = version can be found here: =C2=A0ht= tp://tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt

=C2=A0<= /span>

Currently the documents l=
ists two video codec candidates (VP8/H.264) , and three audio codec candida=
tes, PCMA/PCMU, Telephone Event and Opus.
=C2=A0
If you have anything code=
cs to add that would be considered more web centric, please let us know and=
 we can add it to the open issues list.

=C2= =A0

Cheers,=

=C2=A0<= /span>

-Cary

=C2= =A0

From:= I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net]
Sent: Friday, November 04, 2011 9:31 AM
To: Xavier Marjou
Cc: Bran, Cary; rtcweb@ietf.org
Subject: Re: [rtcweb] Codec Draft

=C2=A0

El 04/11/2011 15:20, "Xavier Marjou" <xavier.marjou@orange.com> e= scribi=C3=B3:
>
> http://tools.ietf.org/html/draft-kaplan-rtcweb-sip-interworking-requirement= s-00,=C2=A0which I fully support by the way.

Xavier, such draft does not propose that Webrtc must implement all the r= equirements in the draft. It just lists all the requirements needed in orde= r to fully interoperate with current SIP deployments and opens the door for= discussion about it.

So if you "fully support" this draft it means that you are jus= t interested in making Webrtc to work with current SIP, regardless security= requirements in the Web.

So let me know: do you support that browsers must implement g729? Do you= support that webrtc requires not security at all in the media plane (like = legacy SIP)?

If so, I dont think you care about Webrtc for the Web, but just for telc= os. Behaviors like this one makes this WG to seem a telco party rather than= a WG working for the Web. WebRTC means RTC for the Web, rather than Web fo= r telcos, or that is what I hope.

Regards.



CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain information that is= confidential and/or legally privileged. If you are not the intended recipi= ent, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the conten= ts to another person, store or copy the information in any medium, or use a= ny of the information contained in or attached to this transmission for any= purpose. If you have received this transmission in error, please immediately notify the sender by reply email= or at privacy= @plantronics.com, and destroy the original transmission and its attachm= ents without reading or saving in any manner.

For further information about Plantronics - the Company, its products, bran= ds, partners, please visit our website www.plantronics.com.
--90e6ba53ad2a10412004b0ebdf8b-- From xavier.marjou@gmail.com Fri Nov 4 10:26:06 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6B511E8086 for ; Fri, 4 Nov 2011 10:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.850, 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 RxtbY-ChcEdA for ; Fri, 4 Nov 2011 10:26:05 -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 4D01211E8082 for ; Fri, 4 Nov 2011 10:26:05 -0700 (PDT) Received: by gye5 with SMTP id 5so3113989gye.31 for ; Fri, 04 Nov 2011 10:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=3nd7SW8nKAi0AMEzC47NYcGPwy0BL/E1LkUUScfaI5c=; b=NFZKbQpvuH8VDHfbgpKaNepsAT6TQ+71FgcxbAw2PW4f0h8Salf3lZJDMVL2KlKxMe r8qGJ0McL9S65UcA31YXZ/WS6m82HPMlL5TVFqH31928XdTBhwAHkGPS/AIUhGQTtbtK v/4jUHs3DSV6nVWa0fpD5x/KnEHnadefC1mNI= MIME-Version: 1.0 Received: by 10.236.123.73 with SMTP id u49mr21300393yhh.88.1320427564850; Fri, 04 Nov 2011 10:26:04 -0700 (PDT) Sender: xavier.marjou@gmail.com Received: by 10.236.157.73 with HTTP; Fri, 4 Nov 2011 10:26:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Nov 2011 18:26:04 +0100 X-Google-Sender-Auth: x1SSmt_oQFIC6lk1VfUf2H6HOr0 Message-ID: From: Xavier Marjou To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf3010e2abf45c7d04b0ebff9e Subject: Re: [rtcweb] Codec 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: Fri, 04 Nov 2011 17:26:06 -0000 --20cf3010e2abf45c7d04b0ebff9e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Nov 4, 2011 at 5:31 PM, I=F1aki Baz Castillo wrote: > El 04/11/2011 15:20, "Xavier Marjou" escribi= =F3: > > > > > > http://tools.ietf.org/html/draft-kaplan-rtcweb-sip-interworking-requireme= nts-00, which > I fully support by the way. > > Xavier, such draft does not propose that Webrtc must implement all the > requirements in the draft. It just lists all the requirements needed in > order to fully interoperate with current SIP deployments and opens the do= or > for discussion about it. > You rephrasing is correct : however the draft does indicate that many codecs would be desirable from an interworking perspective So if you "fully support" this draft it means that you are just interested > in making Webrtc to work with current SIP, regardless security requiremen= ts > in the Web. > I am not "just" interested : I am "also" interested in making WebRTC work with existing networks using SIP and RTP. So let me know: do you support that browsers must implement g729? > yes (for some calls, not for all calls) > Do you support that webrtc requires not security at all in the media plan= e > (like legacy SIP)? > out-of-thread : no, of course. However in some circumstances some features may be done at another level or not needed at all (eg: for RTP vs SRTP) If so, I dont think you care about Webrtc for the Web, but just for telcos. > Behaviors like this one makes this WG to seem a telco party rather than a > WG working for the Web. WebRTC means RTC for the Web, rather than Web for > telcos, or that is what I hope. > > Regards. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --20cf3010e2abf45c7d04b0ebff9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Nov 4, 2011 at 5:31 PM, I=F1aki = Baz Castillo <ibc@aliax.net> wrote:

El 04/11/2011 15:20, "Xavier Marjou" <xavier.marjou@orange.com> e= scribi=F3:

Xavier, such draft does not propose that Webrtc must implement all the r= equirements in the draft. It just lists all the requirements needed in orde= r to fully interoperate with current SIP deployments and opens the door for= discussion about it.

You rephrasing is correct : however the draft does indica= te that many codecs would be desirable from an interworking perspective

So if you "fully support" this draft it means that you are jus= t interested in making Webrtc to work with current SIP, regardless security= requirements in the Web.

I am not "just" in= terested : I am "also" interested in making WebRTC work with exis= ting networks using SIP and RTP.=A0


So let me know: do you support that browsers must implement g729?

yes (for some calls, not for all calls)

=A0

Do you support that webrtc requires not security at all in the media pla= ne (like legacy SIP)?

out-of-thread : no, of course. H= owever in some circumstances some features may be done at another level or = not needed at all (eg: for RTP vs SRTP)=A0
=A0

If so, I dont think you care about Webrtc for the Web, but just for telc= os. Behaviors like this one makes this WG to seem a telco party rather than= a WG working for the Web. WebRTC means RTC for the Web, rather than Web fo= r telcos, or that is what I hope.

Regards.


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


--20cf3010e2abf45c7d04b0ebff9e-- From randell-ietf@jesup.org Fri Nov 4 13:10:39 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D298611E80C6 for ; Fri, 4 Nov 2011 13:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 9siSEqqowBeJ for ; Fri, 4 Nov 2011 13:10:38 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A861A11E80B9 for ; Fri, 4 Nov 2011 13:10:38 -0700 (PDT) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RMQ5U-00044H-JC for rtcweb@ietf.org; Fri, 04 Nov 2011 15:10:04 -0500 Message-ID: <4EB44684.30801@jesup.org> Date: Fri, 04 Nov 2011 16:09:40 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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] Codec 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: Fri, 04 Nov 2011 20:10:40 -0000 On 11/4/2011 1:26 PM, Xavier Marjou wrote: > On Fri, Nov 4, 2011 at 5:31 PM, Iñaki Baz Castillo > wrote: > http://tools.ietf.org/html/draft-kaplan-rtcweb-sip-interworking-requirements-00, which > I fully support by the way. > > Xavier, such draft does not propose that Webrtc must implement all > the requirements in the draft. It just lists all the requirements > needed in order to fully interoperate with current SIP deployments > and opens the door for discussion about it. > > You rephrasing is correct : however the draft does indicate that many > codecs would be desirable from an interworking perspective For example, G.722 would be desirable for some interoperation scenarios, even though it's worse than Opus at similar bitrates. (And it's no longer under patent) > So let me know: do you support that browsers must implement g729? > > yes (for some calls, not for all calls) Just to note: G.729's license requirements make supporting it a virtual impossibility for Mozilla, and unlikely for the other browsers. -- Randell Jesup randell-ietf@jesup.org From HKaplan@acmepacket.com Fri Nov 4 16:35:46 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C81D1F0C41 for ; Fri, 4 Nov 2011 16:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 2ldfKupyr0CY for ; Fri, 4 Nov 2011 16:35:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E10B71F0C35 for ; Fri, 4 Nov 2011 16:35:45 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 4 Nov 2011 19:35:43 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 4 Nov 2011 19:35:43 -0400 From: Hadriel Kaplan To: Magnus Westerlund Thread-Topic: [rtcweb] NAT Draft Thread-Index: AQHMm0p39Ahvf8bhNEuia+G7a2U8zw== Date: Fri, 4 Nov 2011 23:35:42 +0000 Message-ID: <3815A3A8-A6CF-4024-9FBD-AE2E7D2A2211@acmepacket.com> References: <4EB3AE5B.4090401@ericsson.com> In-Reply-To: <4EB3AE5B.4090401@ericsson.com> 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="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" , "Bran, Cary" Subject: Re: [rtcweb] NAT 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: Fri, 04 Nov 2011 23:35:46 -0000 On Nov 4, 2011, at 5:20 AM, Magnus Westerlund wrote: > I think a document of this type should and will eventually be published > as its own RFC. The reason for this I think is that the document should > evolve from requirements to actually specify how the Peer to Peer > transport flow establishment layer for WebRTC works. As that layer will > be used by both the RTP based media transport and the Data Transport > having a document only containing that functionality will make it > simpler to reference. >=20 > In addition I think it is good from specification maintenance > perspective. If we have bugs in a functionality block we don't need to > republish other functionality blocks just to update, in this case the > NAT traversal functionality. >=20 > Given that a NAT traversal document will specify how WebRTC establish > the transport flows do you think that really should be part of the > use-cases and requirements? Hey you're one of the Chairs - if the Chairs want to have a dozen RFCs on r= equirements, and another dozen on actual behavior, that's your call. =20 Seems silly to me, but most of the admin work is on the authors, the Chairs= , and the ADs I think... so it's no skin off my nose to have more RFCs. As I said in my email: draft-ietf-rtcweb-use-cases-and-requirements is high= -layer/general WebRTC requirements, and if we want a separate detailed spec= ification, that would make sense (or even multiple if that's your preferenc= e). But draft-cbran-rtcweb-nat-02 doesn't appear to be that - it reads lik= e a requirements for NAT traversal mechanism, and that the answer to that i= s native ICE support. =20 -hadriel From harald@alvestrand.no Fri Nov 4 17:18:41 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C11F1F0C46; Fri, 4 Nov 2011 17:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zr66SdXI630M; Fri, 4 Nov 2011 17:18:39 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 846331F0C35; Fri, 4 Nov 2011 17:18:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8B99939E0CD; Sat, 5 Nov 2011 01:18:38 +0100 (CET) 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 ZQjvfL0MPuqW; Sat, 5 Nov 2011 01:18:37 +0100 (CET) Received: from [10.154.240.196] (unknown [62.206.113.61]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 7E79F39E08B; Sat, 5 Nov 2011 01:18:37 +0100 (CET) Message-ID: <4EB480E7.1010200@alvestrand.no> Date: Sat, 05 Nov 2011 01:18:47 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Eric Rescorla References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Keith Moore , Ned Freed , Keith Moore , Behave WG , "rtcweb@ietf.org" Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Nov 2011 00:18:41 -0000 On 11/04/2011 04:56 PM, Eric Rescorla wrote: > On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed wrote: >>> Top-posting a general principle, detailed comment at the bottom.... >>> For all URI schemes, I think the URI needs to contain all the >>> information you need in order to make contact with the service; you >>> can't negotiate until you've made contact. >>> (the process may involve things like "resolve through a resolution >>> mechanism like DNS" or "get authorization tokens from somewhere else"). >>> In the case of TURN, you need to distinguish between TCP, UDP and TLS, >>> and you need to make that determination before you send the first >>> packet. That means the distinguishing information between those three >>> things belongs in the URL; I don't think the scheme is a good place to >>> encode it. >> I'm in complete agreement with Harald on all of these points. And while it >> would have been nice if URL syntax was less messy and more general, making >> it easier to do these sorts of things in a consistent way, it quite simply >> isn't and we have to make do with what we have. > I don't have any commitment to the scheme. What's the best place? I like parameters, like this: turn://user@host?proto=tcp Quite hard to misunderstand, and quite easy to extend. (Note: // is only allowed if what follows is [user[:pass]@]host - I don't recommend using the password, for the obvious reasons, but the syntax will allow it.) > -Ekr > From ibc@aliax.net Sat Nov 5 06:07:35 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70D821F886A for ; Sat, 5 Nov 2011 06:07:35 -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.039, 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 Jo+rlSqejchR for ; Sat, 5 Nov 2011 06:07:35 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E553021F8770 for ; Sat, 5 Nov 2011 06:07:34 -0700 (PDT) Received: by vws5 with SMTP id 5so955488vws.31 for ; Sat, 05 Nov 2011 06:07:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.113.227 with SMTP id jb3mr19100779vdb.15.1320498454290; Sat, 05 Nov 2011 06:07:34 -0700 (PDT) Received: by 10.220.107.206 with HTTP; Sat, 5 Nov 2011 06:07:34 -0700 (PDT) In-Reply-To: References: Date: Sat, 5 Nov 2011 14:07:34 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Xavier Marjou Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Codec 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: Sat, 05 Nov 2011 13:07:35 -0000 2011/11/4 Xavier Marjou : >> So if you "fully support" this draft it means that you are just interest= ed >> in making Webrtc to work with current SIP, regardless security requireme= nts >> in the Web. > > I am not "just" interested : I am "also" interested in making WebRTC work > with existing networks using SIP and RTP. If you would care just a bit about security in the Web you could never say "I fully support this draft (draft-kaplan-rtcweb-sip-interworking-requirements-01)". By saying that it's clear that you just want "WebRTC to work with *current* and *insecure* SIP and no matter how". The purpose of WebRTC is not to work with current SIP networks, even *less* with current insecure SIP networks. WebRTC: "Real Time Collaboration on the World Wide Web" >> So let me know: do you support that browsers must implement g729? > > yes (for some calls, not for all calls) So must I pay the G729 royalty fee when downloading Firefox with WebRTC sup= port? IMHO WebRTC should just define and require open codecs. >> Do you support that webrtc requires not security at all in the media pla= ne >> (like legacy SIP)? > > out-of-thread : no, of course. However in some circumstances some feature= s > may be done at another level or not needed at all (eg: for RTP vs SRTP) There is long rationale in this mailist about why SRTP must be mandatory for every WebRTC scenarios, without being optional per Web site. Best regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Sat Nov 5 06:35:38 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E32421F8726 for ; Sat, 5 Nov 2011 06:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[AWL=-0.561, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, J_CHICKENPOX_43=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 wxVxl+O8HC8J for ; Sat, 5 Nov 2011 06:35:37 -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 9E28521F84AF for ; Sat, 5 Nov 2011 06:35:37 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so3328637vcb.31 for ; Sat, 05 Nov 2011 06:35:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.33.84 with SMTP id p20mr19167563vdi.32.1320500135955; Sat, 05 Nov 2011 06:35:35 -0700 (PDT) Received: by 10.220.107.206 with HTTP; Sat, 5 Nov 2011 06:35:35 -0700 (PDT) Date: Sat, 5 Nov 2011 14:35:35 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: rtcweb@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [rtcweb] Let's define the purpose of 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: Sat, 05 Nov 2011 13:35:38 -0000 Hi, in theory WebRTC is about realtime communications for the Web, but there is interest in making it interoperable with SIP networks. So: - Who is interested in interoperability with SIP? telcos (and me). - Are telcos the main target of *Web*RTC? I don't think so. There are millons of websites out there that would be interested in realtime communications without any kind of interaction with SIP networks. There are also other VoIP protocols. - What does require "interoperability with SIP"? does it mean that WebRTC should allow plain RTP and no ICE? This has been discussed many times in this WG: Security in the media plane MUST NOT be optional, it MUST be a MUST. So sorry, but a legacy SIP device not implementing SRTP+ICE cannot interoperate with a WebRTC endoint. Period. I'm the first one interested in making WebRTC interoperable with SIP, but NOT with insecure and legacy SIP. So I assume that 99% of current SIP devices will NOT interoperate in the media plane with a WebRTC endpoint without the help of a smart media gateway implementing ICE+SRTP. Neither I know whether such media gateway is feasible or not. Sorry if not. So IMHO this WG should clarify these points so we can move on faster. If these points are already stated by WebRTC specs then forget this mail please, but I still see folks asking for "legacy SIP interoperability without requiring SRTP or ICE". Thanks a lot. --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Sat Nov 5 06:54:48 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490A621F8801 for ; Sat, 5 Nov 2011 06:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 dP+IzKh+YaKQ for ; Sat, 5 Nov 2011 06:54:47 -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 AD34321F87E2 for ; Sat, 5 Nov 2011 06:54:47 -0700 (PDT) Received: by gye5 with SMTP id 5so4065049gye.31 for ; Sat, 05 Nov 2011 06:54:47 -0700 (PDT) Received: by 10.50.85.129 with SMTP id h1mr22094860igz.47.1320501287125; Sat, 05 Nov 2011 06:54:47 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id a2sm2175074igj.7.2011.11.05.06.54.45 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Nov 2011 06:54:45 -0700 (PDT) Received: by iaeo4 with SMTP id o4so4852782iae.31 for ; Sat, 05 Nov 2011 06:54:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.153.6 with SMTP id k6mr25586102icw.30.1320501284848; Sat, 05 Nov 2011 06:54:44 -0700 (PDT) Received: by 10.68.62.170 with HTTP; Sat, 5 Nov 2011 06:54:44 -0700 (PDT) In-Reply-To: References: Date: Sat, 5 Nov 2011 09:54:44 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=90e6ba6e902602425c04b0fd2ae0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Sat, 05 Nov 2011 13:54:48 -0000 --90e6ba6e902602425c04b0fd2ae0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Nov 5, 2011 at 9:35 AM, I=F1aki Baz Castillo wrote: > > - What does require "interoperability with SIP"? does it mean that > WebRTC should allow plain RTP and no ICE? This has been discussed many > times in this WG: Security in the media plane MUST NOT be optional, it > MUST be a MUST. So sorry, but a legacy SIP device not implementing > SRTP+ICE cannot interoperate with a WebRTC endoint. Period. > I disagree very strongly in regard to security. This is insane to require features just for the sake of requiring them.This is not about interoperability. It is about the fact that 99% of users will never need or care about SRTP. They do not now for most of the web traffic. This is also about the fact that developers will not be able to debug or troubleshoot anything. If you get a quality problem, it would be next to impossible to figure out what's causing it with everything encrypted. Even now, for development, HTTPS only services allow HTTP. There are no debug tools for the media plane except wireshark. And we are effectively taking it away. So, why are we making this a requirement? It should not be any different then HTTPS vs HTTP. I think it should be DTLS-SRTP with optional RTP. The fact that RTP is allowed should be a part of the same user consent dialog that is displayed when access to local media is allowed. If user agrees, there is no harm to anybody, except the user. _____________ Roman Shpount --90e6ba6e902602425c04b0fd2ae0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Nov 5, 2011 at 9:35 AM= , I=F1aki Baz Castillo <ibc@aliax.net> wrote:

- What does require "interoperability with SIP"? does it mean tha= t
WebRTC should allow plain RTP and no ICE? This has been discussed many
times in this WG: Security in the media plane MUST NOT be optional, it
MUST be a MUST. So sorry, but a legacy SIP device not implementing
SRTP+ICE cannot interoperate with a WebRTC endoint. Period.

I disagree very strongly in regard to security. This is insane t= o require features just for the sake of requiring them.This is not about in= teroperability. It is about the fact that 99% of users will never need or c= are about SRTP. They do not now for most of the web traffic. This is also a= bout the fact that developers will not be able to debug or troubleshoot any= thing. If you get a quality problem, it would be next to impossible to figu= re out what's causing it with everything encrypted. Even now, for devel= opment, HTTPS only services allow HTTP. There are no debug tools for the me= dia plane except wireshark. And we are effectively taking it away. So, why = are we making this a requirement? It should not be any different then HTTPS= vs HTTP. I think it should be DTLS-SRTP with optional RTP. The fact that R= TP is allowed should be a part of the same user consent dialog that is disp= layed when access to local media is allowed. If user agrees, there is no ha= rm to anybody, except the user.
_____________
Roman Shpount

--90e6ba6e902602425c04b0fd2ae0-- From roman@telurix.com Sat Nov 5 06:57:52 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654AB21F886A for ; Sat, 5 Nov 2011 06:57:52 -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.070, 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 oT2Vh5a0q9er for ; Sat, 5 Nov 2011 06:57:52 -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 D8D4121F8801 for ; Sat, 5 Nov 2011 06:57:51 -0700 (PDT) Received: by gye5 with SMTP id 5so4067447gye.31 for ; Sat, 05 Nov 2011 06:57:51 -0700 (PDT) Received: by 10.50.173.74 with SMTP id bi10mr23063339igc.4.1320501471398; Sat, 05 Nov 2011 06:57:51 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id fu10sm12666968igc.6.2011.11.05.06.57.50 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 05 Nov 2011 06:57:50 -0700 (PDT) Received: by iaeo4 with SMTP id o4so4855767iae.31 for ; Sat, 05 Nov 2011 06:57:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.0.208 with SMTP id 16mr5947599ibc.50.1320501469624; Sat, 05 Nov 2011 06:57:49 -0700 (PDT) Received: by 10.68.62.170 with HTTP; Sat, 5 Nov 2011 06:57:49 -0700 (PDT) In-Reply-To: References: Date: Sat, 5 Nov 2011 09:57:49 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=00151773e4f205b82704b0fd359f Cc: rtcweb@ietf.org, Xavier Marjou Subject: Re: [rtcweb] Codec 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: Sat, 05 Nov 2011 13:57:52 -0000 --00151773e4f205b82704b0fd359f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Nov 5, 2011 at 9:07 AM, I=F1aki Baz Castillo wrote: > There is long rationale in this mailist about why SRTP must be > mandatory for every WebRTC scenarios, without being optional per Web > site. > > There is an equally long rational of the opposite. I do not think consensus was reached in this regard. _____________ Roman Shpount --00151773e4f205b82704b0fd359f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Nov 5, 2011 at 9:07 AM= , I=F1aki Baz Castillo <ibc@aliax.net> wrote:
There is long rationale in this mailist about why SRTP must be
mandatory for every WebRTC scenarios, without being optional per Web
site.

=A0
There is an equally long rational = of the opposite. I do not think consensus was reached in this regard.
__= ___________
Roman Shpount

--00151773e4f205b82704b0fd359f-- From ibc@aliax.net Sat Nov 5 07:05:39 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14FF21F88B7 for ; Sat, 5 Nov 2011 07:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAWDIxiNJZ7s for ; Sat, 5 Nov 2011 07:05:39 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id D8C8621F84A4 for ; Sat, 5 Nov 2011 07:05:38 -0700 (PDT) Received: by qyk32 with SMTP id 32so1966255qyk.10 for ; Sat, 05 Nov 2011 07:05:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.36.36 with SMTP id n4mr4509713obj.16.1320501937342; Sat, 05 Nov 2011 07:05:37 -0700 (PDT) Received: by 10.182.145.40 with HTTP; Sat, 5 Nov 2011 07:05:37 -0700 (PDT) In-Reply-To: References: Date: Sat, 5 Nov 2011 15:05:37 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Sat, 05 Nov 2011 14:05:39 -0000 2011/11/5 Roman Shpount : > The fact that RTP is allowed should be a part of the same user consent > dialog that is displayed when access to local media is allowed. If user > agrees, there is no harm to anybody, except the user. If the solution is to ask user consent for everything I would expect this: Prompt 1) ------------------------------ Website http://lalala.com attemts to make an audio/video call with you, which involves access to your microphone and webcam. Do you accept? [ Yes ] [ No ] ------------------------------ Prompt 2) ------------------------------ This audio/video call does not use encrypted media so your audio/video could be intercepted by an attacker. Do you accept it anyway? [ Yes ] [ No ] ------------------------------ Prompt 3) ------------------------------ This audio/video call does not use ICE protocol so you have no knowledge about the real destination of the audio/video your computer will sent. Do you accept it anyway? [ Yes ] [ No ] ------------------------------ Prompt 4) ------------------------------ Do you really understand what previous questions involve? this is, are you an expert in realtime communications? [ Yes ] [ No ] ------------------------------ Prompt 5) ------------------------------ Would you like to bypass all this stuf forever and accept calls regardless security concerns you don't understand? [ Yes Please !!! ] [ No, but ask me later ] ------------------------------ --=20 I=C3=B1aki Baz Castillo From ekr@rtfm.com Sat Nov 5 07:31:32 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D42C21F84C2; Sat, 5 Nov 2011 07:31:32 -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 l-NA+PJWrVjk; Sat, 5 Nov 2011 07:31:31 -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 8520B21F84C1; Sat, 5 Nov 2011 07:31:31 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so3351912vcb.31 for ; Sat, 05 Nov 2011 07:31:31 -0700 (PDT) Received: by 10.52.65.14 with SMTP id t14mr17367185vds.47.1320503491065; Sat, 05 Nov 2011 07:31:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Sat, 5 Nov 2011 07:30:51 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: <4EB480E7.1010200@alvestrand.no> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> From: Eric Rescorla Date: Sat, 5 Nov 2011 07:30:51 -0700 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: Keith Moore , Ned Freed , Keith Moore , Behave WG , "rtcweb@ietf.org" Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Nov 2011 14:31:32 -0000 On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand wrote: > On 11/04/2011 04:56 PM, Eric Rescorla wrote: >> I don't have any commitment to the scheme. What's the best place? > > I like parameters, like this: > > turn://user@host?proto=tcp > > Quite hard to misunderstand, and quite easy to extend. > > (Note: // is only allowed if what follows is [user[:pass]@]host - I don't > recommend using the password, for the obvious reasons, but the syntax will > allow it.) I don't see any security problem with that. The "break old implementations" rationale doesn't apply when we are defining a new URI scheme. -Ekr From ekr@rtfm.com Sat Nov 5 07:35:26 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E8821F8A35 for ; Sat, 5 Nov 2011 07:35: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 J9ZR96no93PJ for ; Sat, 5 Nov 2011 07:35:25 -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 7A6A521F84CE for ; Sat, 5 Nov 2011 07:35:25 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so3353459vcb.31 for ; Sat, 05 Nov 2011 07:35:12 -0700 (PDT) Received: by 10.220.187.136 with SMTP id cw8mr1413422vcb.266.1320503712093; Sat, 05 Nov 2011 07:35:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Sat, 5 Nov 2011 07:34:31 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: References: From: Eric Rescorla Date: Sat, 5 Nov 2011 07:34:31 -0700 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Sat, 05 Nov 2011 14:35:26 -0000 On Sat, Nov 5, 2011 at 6:54 AM, Roman Shpount wrote: > > On Sat, Nov 5, 2011 at 9:35 AM, I=F1aki Baz Castillo wrot= e: > If you get a quality problem, it would be next to impossible to > figure out what's causing it with everything encrypted It's actually not that bad. There are network analysis tools that can proce= ss encrypted traffic if they are provided with the keys. They're a pretty stan= dard tool for debugging HTTPS. I believe wireshark can do this and I know ssldum= p can. -Ekr From gsalguei@cisco.com Sat Nov 5 08:04:43 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A735B21F8A6C for ; Sat, 5 Nov 2011 08:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StEoIkiUNXX9 for ; Sat, 5 Nov 2011 08:04:43 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id EAA3D21F8A58 for ; Sat, 5 Nov 2011 08:04:42 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pA5F4f9R022229 for ; Sat, 5 Nov 2011 11:04:41 -0400 (EDT) Received: from rtp-gsalguei-8712.cisco.com (rtp-gsalguei-8712.cisco.com [10.116.61.51]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pA5F4dTS016108; Sat, 5 Nov 2011 11:04:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-132-748379258 From: Gonzalo Salgueiro In-Reply-To: Date: Sat, 5 Nov 2011 11:04:39 -0400 Message-Id: <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> To: Eric Rescorla X-Mailer: Apple Mail (2.1084) Cc: Ned Freed , Keith Moore , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Nov 2011 15:04:43 -0000 --Apple-Mail-132-748379258 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: > On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand = wrote: >> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >=20 >>> I don't have any commitment to the scheme. What's the best place? >>=20 >> I like parameters, like this: >>=20 >> turn://user@host?proto=3Dtcp >>=20 >> Quite hard to misunderstand, and quite easy to extend. >>=20 >> (Note: // is only allowed if what follows is [user[:pass]@]host - I = don't >> recommend using the password, for the obvious reasons, but the syntax = will >> allow it.) >=20 > I don't see any security problem with that. The "break old > implementations" rationale > doesn't apply when we are defining a new URI scheme. I agree with this as well. If we can get some consensus with this, I = will update the next version of both the STUN and TURN URI Scheme drafts = to include this format. Regards, Gonzalo >=20 > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --Apple-Mail-132-748379258 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand = <harald@alvestrand.no> = wrote:
On 11/04/2011 04:56 PM, Eric = Rescorla wrote:

I don't have any commitment to the scheme. What's the best = place?

I like = parameters, like this:

turn://user@host?proto=3Dtcp
=

Quite hard to misunderstand, and quite easy to = extend.

(Note: // is = only allowed if what follows is [user[:pass]@]host - I = don't
recommend using the = password, for the obvious reasons, but the syntax = will
allow = it.)

I don't see any security problem with that. The = "break old
implementations" rationale
doesn't apply when we are = defining a new URI scheme.

I agree = with this as well.  If we can get some consensus with this, I will = update the next version of both the STUN and TURN URI Scheme drafts to = include this = format.

Regards,

Gonzalo=


-Ekr
___________________________________________= ____
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb


= --Apple-Mail-132-748379258-- From petithug@acm.org Sat Nov 5 08:15:02 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDDB21F8A69; Sat, 5 Nov 2011 08:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.685 X-Spam-Level: X-Spam-Status: No, score=-102.685 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, NO_RELAYS=-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 w3aV8Aj8kPFw; Sat, 5 Nov 2011 08:15:01 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id C091021F8A71; Sat, 5 Nov 2011 08:15:01 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 8E02E200D1; Sat, 5 Nov 2011 15:05:56 +0000 (UTC) Message-ID: <4EB552F0.6050800@acm.org> Date: Sat, 05 Nov 2011 08:14:56 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Gonzalo Salgueiro References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> In-Reply-To: <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ned Freed , Keith Moore , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [rtcweb] [BEHAVE] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Nov 2011 15:15:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: > > On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: > >> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand > > wrote: >>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >> >>>> I don't have any commitment to the scheme. What's the best place? >>> >>> I like parameters, like this: >>> >>> turn://user@host?proto=tcp >>> >>> Quite hard to misunderstand, and quite easy to extend. >>> >>> (Note: // is only allowed if what follows is [user[:pass]@]host - I don't >>> recommend using the password, for the obvious reasons, but the syntax will >>> allow it.) >> >> I don't see any security problem with that. The "break old >> implementations" rationale >> doesn't apply when we are defining a new URI scheme. > > I agree with this as well. If we can get some consensus with this, I will > update the next version of both the STUN and TURN URI Scheme drafts to include > this format. Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is already doing it right (and had a lot of reviews back in 2008, before I split the resolution mechanism and the syntax in two separate documents). I know my email address does not contain the magical "cisco.com", but this is getting ridiculous. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk61Uu4ACgkQ9RoMZyVa61eFrQCgiw1H8kTxgpd90sV1OYuSg3tN B+cAnA9V/XhzV3MAg93WOxpKIAvwk/Nu =jYZJ -----END PGP SIGNATURE----- From cb.list6@gmail.com Sat Nov 5 08:28:13 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1084E21F8586 for ; Sat, 5 Nov 2011 08:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.939 X-Spam-Level: X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=0.659, 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 EjuPzokKYzVj for ; Sat, 5 Nov 2011 08:28:12 -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 77FAA21F8494 for ; Sat, 5 Nov 2011 08:28:12 -0700 (PDT) Received: by ywt2 with SMTP id 2so4136864ywt.31 for ; Sat, 05 Nov 2011 08:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jH4blq2GPnSRnTGSJ2+gnKjWhnAEIk8MIquFKjnuw/o=; b=M1kM0STJmg3GGN0F6W4XerUdi08IkCgVBX/vbMney3NxNov62a90jVCPyJW2x6fuaZ COSU5ffVkoGm3Q8Xnac7+j03NmiIPWSxbuFmnl9xNbjCEuYxDtMHINUakIo5K7+GcqTk ziCMN9NlhAN5uLE+CmVkwhe9B7p3CykLMz7ew= MIME-Version: 1.0 Received: by 10.43.51.69 with SMTP id vh5mr26679466icb.32.1320506891761; Sat, 05 Nov 2011 08:28:11 -0700 (PDT) Received: by 10.142.230.8 with HTTP; Sat, 5 Nov 2011 08:28:11 -0700 (PDT) Received: by 10.142.230.8 with HTTP; Sat, 5 Nov 2011 08:28:11 -0700 (PDT) In-Reply-To: References: Date: Sat, 5 Nov 2011 08:28:11 -0700 Message-ID: From: Cameron Byrne To: Eric Rescorla Content-Type: multipart/alternative; boundary=bcaec52e5eb534f80504b0fe788e Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Sat, 05 Nov 2011 15:28:13 -0000 --bcaec52e5eb534f80504b0fe788e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Nov 5, 2011 7:35 AM, "Eric Rescorla" wrote: > > On Sat, Nov 5, 2011 at 6:54 AM, Roman Shpount wrote: > > > > On Sat, Nov 5, 2011 at 9:35 AM, I=F1aki Baz Castillo wrote: > > If you get a quality problem, it would be next to impossible to > > figure out what's causing it with everything encrypted > > It's actually not that bad. There are network analysis tools that can process > encrypted traffic if they are provided with the keys. They're a pretty standard > tool for debugging HTTPS. I believe wireshark can do this and I know ssldump > can. > I think you can set crypto in srtp to null as well for troubleshooting Cb > -Ekr > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --bcaec52e5eb534f80504b0fe788e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 5, 2011 7:35 AM, "Eric Rescorla" <ekr@rtfm.com> wrote:
>
> On Sat, Nov 5, 2011 at 6:54 AM, Roman Shpount <roman@telurix.com> wrote:
> >
> > On Sat, Nov 5, 2011 at 9:35 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
> > If you get a quality problem, it would be next to impossible to > > figure out what's causing it with everything encrypted
>
> It's actually not that bad. There are network analysis tools that = can process
> encrypted traffic if they are provided with the keys. They're a pr= etty standard
> tool for debugging HTTPS. I believe wireshark can do this and I know s= sldump
> can.
>

I think you can set crypto in srtp to null as well for troubleshooting

Cb

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

--bcaec52e5eb534f80504b0fe788e-- From gsalguei@cisco.com Sat Nov 5 08:28:43 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278C121F8A35 for ; Sat, 5 Nov 2011 08:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MC6N1ZBZkd+P for ; Sat, 5 Nov 2011 08:28:42 -0700 (PDT) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 57CBE21F891D for ; Sat, 5 Nov 2011 08:28:42 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pA5FSfI0024308 for ; Sat, 5 Nov 2011 11:28:41 -0400 (EDT) Received: from rtp-gsalguei-8712.cisco.com (rtp-gsalguei-8712.cisco.com [10.116.61.51]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pA5FSeps027057; Sat, 5 Nov 2011 11:28:40 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-133-749820295 From: Gonzalo Salgueiro In-Reply-To: <4EB552F0.6050800@acm.org> Date: Sat, 5 Nov 2011 11:28:40 -0400 Message-Id: References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> <4EB552F0.6050800@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: Ned Freed , Keith Moore , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [rtcweb] [BEHAVE] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Nov 2011 15:28:43 -0000 --Apple-Mail-133-749820295 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 5, 2011, at 11:14 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: >>=20 >> On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: >>=20 >>> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand = >> > wrote: >>>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >>>=20 >>>>> I don't have any commitment to the scheme. What's the best place? >>>>=20 >>>> I like parameters, like this: >>>>=20 >>>> turn://user@host?proto=3Dtcp >>>>=20 >>>> Quite hard to misunderstand, and quite easy to extend. >>>>=20 >>>> (Note: // is only allowed if what follows is [user[:pass]@]host - I = don't >>>> recommend using the password, for the obvious reasons, but the = syntax will >>>> allow it.) >>>=20 >>> I don't see any security problem with that. The "break old >>> implementations" rationale >>> doesn't apply when we are defining a new URI scheme. >>=20 >> I agree with this as well. If we can get some consensus with this, I = will >> update the next version of both the STUN and TURN URI Scheme drafts = to include >> this format. >=20 > Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is = already > doing it right (and had a lot of reviews back in 2008, before I split = the > resolution mechanism and the syntax in two separate documents). >=20 I was under the impression (based on an exchange with Cullen) that you = had no plans to pass user credentials in the URI scheme you were = proposing. I'm perfectly OK with whatever the group decides. = Nonetheless, the change makes change to me for one or both drafts. > I know my email address does not contain the magical "cisco.com", but = this is > getting ridiculous. I have no idea where this came from, so I'll choose to leave it alone. Regards, Gonzalo >=20 > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iEYEARECAAYFAk61Uu4ACgkQ9RoMZyVa61eFrQCgiw1H8kTxgpd90sV1OYuSg3tN > B+cAnA9V/XhzV3MAg93WOxpKIAvwk/Nu > =3DjYZJ > -----END PGP SIGNATURE----- >=20 --Apple-Mail-133-749820295 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
-----BEGIN PGP SIGNED MESSAGE-----
Hash: = SHA1

On 11/05/2011 08:04 AM, Gonzalo Salgueiro = wrote:

On Nov 5, 2011, at 10:30 AM, Eric Rescorla = wrote:

On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand <harald@alvestrand.no
<mailto:harald@alvestrand.no>&g= t; wrote:
On = 11/04/2011 04:56 PM, Eric Rescorla = wrote:

I don't have any commitment to = the scheme. What's the best = place?

I like = parameters, like = this:

turn://user@host?proto=3Dtcp
=

Quite = hard to misunderstand, and quite easy to = extend.

(Note: = // is only allowed if what follows is [user[:pass]@]host - I = don't
recommend using the password, for the obvious reasons, but = the syntax will
allow = it.)

I don't see any security problem = with that. The "break old
implementations" = rationale
doesn't apply when we are = defining a new URI scheme.

I agree with = this as well.  If we can get some consensus with this, I = will
update the next version = of both the STUN and TURN URI Scheme drafts to = include
this = format.

Or you can look at = draft-petithuguenin-behave-turn-uri-bis, which is already
doing it = right (and had a lot of reviews back in 2008, before I split = the
resolution mechanism and the syntax in two separate = documents).

I was under the impression (based = on an exchange with Cullen) that you had no plans to pass user = credentials in the URI scheme you were proposing. I'm perfectly OK with = whatever the group decides. Nonetheless, the change makes change to me = for one or both drafts.

I = know my email address does not contain the magical "cisco.com", but this is
getting = ridiculous.

I have no idea where = this came from, so I'll choose to leave it = alone.

Regards,

Gonzalo<= /div>


- --
Marc = Petit-Huguenin
Personal email: marc@petit-huguenin.org
Pro= fessional email: petithug@acm.org
Blog: http://blog.marc.petit-huguen= in.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 = (GNU/Linux)

iEYEARECAAYFAk61Uu4ACgkQ9RoMZyVa61eFrQCgiw1H8kTxgpd90sV= 1OYuSg3tN
B+cAnA9V/XhzV3MAg93WOxpKIAvwk/Nu
=3DjYZJ
-----END PGP = SIGNATURE-----


= --Apple-Mail-133-749820295-- From ekr@rtfm.com Sat Nov 5 08:38:09 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4A621F8770 for ; Sat, 5 Nov 2011 08:38:09 -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 PViDIyxrOFY2 for ; Sat, 5 Nov 2011 08:38: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 1FD6821F861E for ; Sat, 5 Nov 2011 08:38:09 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so3381089vcb.31 for ; Sat, 05 Nov 2011 08:38:08 -0700 (PDT) Received: by 10.220.2.19 with SMTP id 19mr1481652vch.161.1320507486097; Sat, 05 Nov 2011 08:38:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Sat, 5 Nov 2011 08:37:25 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Sat, 5 Nov 2011 08:37:25 -0700 Message-ID: To: Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Sat, 05 Nov 2011 15:38:09 -0000 Good point. Also, of course (unless you use the SRTP header encryption extension) the SRTP header is in the clear, so you mostly just don't get the media itself. -Ekr On Sat, Nov 5, 2011 at 8:28 AM, Cameron Byrne wrote: > > On Nov 5, 2011 7:35 AM, "Eric Rescorla" wrote: >> >> On Sat, Nov 5, 2011 at 6:54 AM, Roman Shpount wrote: >> > >> > On Sat, Nov 5, 2011 at 9:35 AM, I=F1aki Baz Castillo >> > wrote: >> > If you get a quality problem, it would be next to impossible to >> > figure out what's causing it with everything encrypted >> >> It's actually not that bad. There are network analysis tools that can >> process >> encrypted traffic if they are provided with the keys. They're a pretty >> standard >> tool for debugging HTTPS. I believe wireshark can do this and I know >> ssldump >> can. >> > > I think you can set crypto in srtp to null as well for troubleshooting > > Cb > >> -Ekr > >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From petithug@acm.org Sat Nov 5 08:45:11 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CF221F8770; Sat, 5 Nov 2011 08:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, NO_RELAYS=-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 mAX7TdgMvKEc; Sat, 5 Nov 2011 08:45:11 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id C4C7021F85EF; Sat, 5 Nov 2011 08:45:10 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 71B10200D1; Sat, 5 Nov 2011 15:36:05 +0000 (UTC) Message-ID: <4EB55A01.70900@acm.org> Date: Sat, 05 Nov 2011 08:45:05 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Gonzalo Salgueiro References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> <4EB552F0.6050800@acm.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ned Freed , Keith Moore , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [rtcweb] [BEHAVE] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Nov 2011 15:45:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/05/2011 08:28 AM, Gonzalo Salgueiro wrote: > > On Nov 5, 2011, at 11:14 AM, Marc Petit-Huguenin wrote: > > On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: >>>> >>>> On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: >>>> >>>>> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand >>>> >>>>> > wrote: >>>>>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >>>>> >>>>>>> I don't have any commitment to the scheme. What's the best place? >>>>>> >>>>>> I like parameters, like this: >>>>>> >>>>>> turn://user@host?proto=tcp >>>>>> >>>>>> Quite hard to misunderstand, and quite easy to extend. >>>>>> >>>>>> (Note: // is only allowed if what follows is [user[:pass]@]host - I don't >>>>>> recommend using the password, for the obvious reasons, but the syntax will >>>>>> allow it.) >>>>> >>>>> I don't see any security problem with that. The "break old >>>>> implementations" rationale >>>>> doesn't apply when we are defining a new URI scheme. >>>> >>>> I agree with this as well. If we can get some consensus with this, I will >>>> update the next version of both the STUN and TURN URI Scheme drafts to include >>>> this format. > > Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is already > doing it right (and had a lot of reviews back in 2008, before I split the > resolution mechanism and the syntax in two separate documents). > >> I was under the impression (based on an exchange with Cullen) that you had no >> plans to pass user credentials in the URI scheme you were proposing. Yes, and you can count me as opposing user credentials in *any* new URI. >> I'm >> perfectly OK with whatever the group decides. Nonetheless, the change makes >> change to me for one or both drafts. > > I know my email address does not contain the magical "cisco.com > ", but this is > getting ridiculous. > >> I have no idea where this came from, so I'll choose to leave it alone. > >> Regards, > >> Gonzalo > > >> - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk61WgAACgkQ9RoMZyVa61dvDACfd9Aco1hi/jupuRXAyKA41s4x fzYAn2fpCMY/e5e0POFk+t4PY0lijX6O =sI2K -----END PGP SIGNATURE----- From ibc@aliax.net Sat Nov 5 08:47:29 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DB921F8663 for ; Sat, 5 Nov 2011 08:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofLvw8E7W-JA for ; Sat, 5 Nov 2011 08:47:29 -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 33DDB21F85EF for ; Sat, 5 Nov 2011 08:47:29 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so3385121vcb.31 for ; Sat, 05 Nov 2011 08:47:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.113.227 with SMTP id jb3mr19566106vdb.15.1320508048741; Sat, 05 Nov 2011 08:47:28 -0700 (PDT) Received: by 10.220.107.206 with HTTP; Sat, 5 Nov 2011 08:47:28 -0700 (PDT) In-Reply-To: References: Date: Sat, 5 Nov 2011 16:47:28 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Sat, 05 Nov 2011 15:47:29 -0000 2011/11/5 Eric Rescorla : > Good point. Also, of course (unless you use the SRTP header encryption > extension) the SRTP header is in the clear, so you mostly just don't get > the media itself. Hi, please use another thread for discussions about SRTP with no encryption. This thread was supposed to discuss the purpose and scope of WebRTC :) --=20 I=C3=B1aki Baz Castillo From ekr@rtfm.com Sat Nov 5 12:46:08 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3518021F8726; Sat, 5 Nov 2011 12:46:08 -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 pAV4cosUTokM; Sat, 5 Nov 2011 12:46:07 -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 8B29C21F86A4; Sat, 5 Nov 2011 12:46:07 -0700 (PDT) Received: by ywt2 with SMTP id 2so4336378ywt.31 for ; Sat, 05 Nov 2011 12:46:07 -0700 (PDT) Received: by 10.236.77.163 with SMTP id d23mr26392976yhe.34.1320522367144; Sat, 05 Nov 2011 12:46:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.232.12 with HTTP; Sat, 5 Nov 2011 12:45:26 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <01O823CUB1SG00XBUL@mauve.mrochek.com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <01O823CUB1SG00XBUL@mauve.mrochek.com> From: Eric Rescorla Date: Sat, 5 Nov 2011 12:45:26 -0700 Message-ID: To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Keith Moore , Keith Moore , Behave WG , "rtcweb@ietf.org" Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Nov 2011 19:46:08 -0000 On Sat, Nov 5, 2011 at 10:20 AM, Ned Freed wrote: >> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >> > On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed =A0wr= ote: >> >>> Top-posting a general principle, detailed comment at the bottom.... >> >>> For all URI schemes, I think the URI needs to contain all the >> >>> information you need in order to make contact with the service; you >> >>> can't negotiate until you've made contact. >> >>> (the process may involve things like "resolve through a resolution >> >>> mechanism like DNS" or "get authorization tokens from somewhere >> >>> else"). >> >>> In the case of TURN, you need to distinguish between TCP, UDP and TL= S, >> >>> and you need to make that determination before you send the first >> >>> packet. That means the distinguishing information between those thre= e >> >>> things belongs in the URL; I don't think the scheme is a good place = to >> >>> encode it. >> >> I'm in complete agreement with Harald on all of these points. And whi= le >> >> it >> >> would have been nice if URL syntax was less messy and more general, >> >> making >> >> it easier to do these sorts of things in a consistent way, it quite >> >> simply >> >> isn't and we have to make do with what we have. >> > I don't have any commitment to the scheme. What's the best place? > >> I like parameters, like this: > >> turn://user@host?proto=3Dtcp > >> Quite hard to misunderstand, and quite easy to extend. > >> (Note: // is only allowed if what follows is [user[:pass]@]host - I >> don't recommend using the password, for the obvious reasons, but the >> syntax will allow it.) > > Given your earlier characterization of the TCP/UDP/TLS distinction being > a single axis, I assume you mean that you'd say: > > =A0turn://user@host?proto=3Dtls > > and not > > =A0turns://user@host?proto=3Dtcp > > I have to say I prefer the parameter approach, but I wonder if these real= ly > are along a single axis - is DTLS a possibility here? TCP/TLS UDP/DTLS TCP/DTLS Are all options. Also, it seems like you might want to run DCCP or SCTP and those work with DTLS and {DTLS,TLS} respectively. So, probably better to make the parameters separate. -Ekr From Michael.Tuexen@lurchi.franken.de Sat Nov 5 14:10:29 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C7121F85D1 for ; Sat, 5 Nov 2011 14:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMoSlb5-o433 for ; Sat, 5 Nov 2011 14:10:28 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id C5C8821F85AE for ; Sat, 5 Nov 2011 14:10:27 -0700 (PDT) Received: from [192.168.1.200] (p508FBA09.dip.t-dialin.net [80.143.186.9]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 1CC451C0C0BCA; Sat, 5 Nov 2011 22:10:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <4EB2B61D.1010000@jesup.org> Date: Sat, 5 Nov 2011 22:10:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <36EE558D-548B-4280-A370-D809C7E522E5@lurchi.franken.de> References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> <4EB21DEF.5060606@jesup.org> <4EB29275.8000204@ericsson.com> <4EB2B61D.1010000@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 21:10:29 -0000 On Nov 3, 2011, at 4:41 PM, Randell Jesup wrote: > On 11/3/2011 9:09 AM, Magnus Westerlund wrote: >> When it comes to the actual usage of either of IP/UDP/SCTP/DTLS and >> IP/UDP/DTLS/SCTP we have the same two dependencies on other WGs. >>=20 >> First we need a SCTP over foo document, which is TSVWG. The SCTP over >> UDP is already an WG document and making some progress. For SCTP over >> DTLS there would be need for a new document, or possibly get that >> defined in the same as SCTP over UDP directly. >>=20 >> Secondly if one uses SDP one needs a definition of how one expresses >> this on the media description line. That includes the "proto" = identifier >> itself and any additional information, like direction for = establishing >> the connection which would be similar to what COMEDIA defines for TCP >> (RFC 4145). >=20 > We probably need to do these in any case (SCTP or not). >=20 >>> =46rom a time perspective IP/UDP/SCTP/DTLS is the quicker road as = the SCTP >> over UDP is already in progress and DTLS over SCTP is defined. >=20 > Right, but that also means we'd need to define reliable stream-like = layers on top of DTLS-over-SCTP, deal with large message fragmentation, = etc. Perhaps someone with more DTLS-over-SCTP knowledge (Michael, = Randy) could detail what the impact would be. (I'll also start = reviewing the DTLS-over-SCTP draft.) If the upper layer knows that you use stream n in "stream line mode", = you can just ignore the message framing. Pretty simple. No changes needed. Runs over = SCTP or DTLS. If you need large messages with message boundaries, it can be added to = SCTP. It should be not too hard. Randy and myself will look into it... = However,=20 to allow multiplexing with having more than one message being sent = concurrently, a new chunk is necessary. Just one note: DTLS-over-SCTP is an RFC and you can find a patch for = OpenSSL at http://sctp.fh-muenster.de/dtls-patches.html >> So what exist here is really: >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ >> https://datatracker.ietf.org/doc/rfc6083/ (DTLS over SCTP) >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps/ >>=20 >>=20 >>>=20 >>> In response I have to say: put a protocol proposal on the table or >>> gather a group to do so, and do so ASAP, because if we don't get an >>> alternative, it *will* be either SCTP/DTLS/(ICE/UDP) or >>> pseudo-TCP/DTLS/(ICE/UDP), and I don't know what we'd do for the >>> unreliable congestion-controlled channels (maybe DCCP). >>=20 >> Personally view: >>=20 >> I think the choice will be between either >>=20 >> DTLS/SCTP/UDP or SCTP/DTLS/UDP >>=20 >> and >>=20 >> TCP/UDP + DCCP/UDP >=20 > I agree that this is the fundamental choice, barring some surprise. = There is one other option, though I would vote against it and I doubt = anyone really wants it: drop internal data streams and require use of = websockets for data (and that means no unreliable streams, which = severely crimps real-time data use). >=20 >=20 > Sometimes it seems like it would be easier to rubber-stamp (document = if you prefer) an existing protocol design done outside the standards = process than to develop one inside of it, which is a problem, but not = one we'll solve here. >=20 > Realize that if we don't find a solution that works within the = standards process, the vendors in question will be forced to implement = something that gives the desired functionality in the timeframe = required, and then it would turn into a case of a defacto standard in = need of documentation. Obviously I think all here would prefer to avoid = that scenario. >=20 >>> If you do put forward a proposal, do you really believe it can be >>> done, standardized, agreed to and implemented in the timeframe >>> required? Specifying SCTP/DTLS seems relatively straightforward >>> compared to standardizing a new protocol... The timeframe for this >>> is quite constrained already; one of the strongest arguments against >>> SCTP would also be timeframe, except that SCTP gives us >>> congestion-controlled unreliable data, which pseudo-TCP-over-DTLS >>> doesn't - we'd have to use yet another unspecified mechanism for >>> congestion control of the unreliable data channels. >>>=20 >>=20 >> I personally don't think think this can be done in short time frames >> within the IETF. The reason is that IETF will have to do the = following >> to get this going and in the end produce an RFC: >=20 > [snip 16 steps] >=20 >> Just the required process steps in the above is on the order of 3 >> months. My guess is that even if interest in this holds it is 3-4 = years >> before IETF can conclude on a new transport protocol. >=20 > Even getting to the point where we have a complete enough draft within = the IETF is probably a minimum of 2 years (witness OPUS/codec). >=20 >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From derhoermi@gmx.net Sat Nov 5 14:24:15 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2CF1F0C34 for ; Sat, 5 Nov 2011 14:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, 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 PsCMgJTXn765 for ; Sat, 5 Nov 2011 14:24:14 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1090321F85B9 for ; Sat, 5 Nov 2011 14:24:13 -0700 (PDT) Received: (qmail invoked by alias); 05 Nov 2011 21:24:07 -0000 Received: from dslb-094-223-199-252.pools.arcor-ip.net (EHLO HIVE) [94.223.199.252] by mail.gmx.net (mp011) with SMTP; 05 Nov 2011 22:24:07 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18DeV5gAl0D9ehAq2ZkRSMJIofqgyMGLKE8X4m9T7 D+9x7DtZEGuQVW From: Bjoern Hoehrmann To: Harald Alvestrand Date: Sat, 05 Nov 2011 22:24:10 +0100 Message-ID: References: <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> In-Reply-To: <4EB480E7.1010200@alvestrand.no> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Nov 2011 21:24:15 -0000 * Harald Alvestrand wrote: >I like parameters, like this: > >turn://user@host?proto=tcp > >Quite hard to misunderstand, and quite easy to extend. > >(Note: // is only allowed if what follows is [user[:pass]@]host - I >don't recommend using the password, for the obvious reasons, but the >syntax will allow it.) As far as the requirements for URI schemes go, no, it is not necessary to allow a user name or password. The 'http' scheme for instance prohi- bits both, and the 'pop' scheme allows a user name but no password. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From HKaplan@acmepacket.com Sat Nov 5 20:45:47 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618E521F8446 for ; Sat, 5 Nov 2011 20:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, J_CHICKENPOX_43=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 VFssDad0eyAF for ; Sat, 5 Nov 2011 20:45:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC1E21F8444 for ; Sat, 5 Nov 2011 20:45:46 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 5 Nov 2011 23:45:42 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sat, 5 Nov 2011 23:45:42 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AQHMnDaOf7Rk7jbqSkasPb/KQmbKSA== Date: Sun, 6 Nov 2011 03:45:41 +0000 Message-ID: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> References: 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="iso-8859-1" Content-ID: <28C469E2CE0E9044B58518FD5F8B40A0@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Sun, 06 Nov 2011 03:45:47 -0000 On Nov 5, 2011, at 9:35 AM, I=F1aki Baz Castillo wrote: > Hi, in theory WebRTC is about realtime communications for the Web, but > there is interest in making it interoperable with SIP networks. So: >=20 > - Who is interested in interoperability with SIP? telcos (and me). I think that's an exaggeration, or perhaps a simplification, or generalizat= ion - well, some X-ation anyway. :) There is a ton of SIP in the Enterprise market, and they're not "Telcos". = Enterprises deploy a lot of web servers and web applications as well, obvio= usly - some for the public Internet, and some for their intranet (which may= happen to be through VPNs over the public Internet). > - What does require "interoperability with SIP"? does it mean that > WebRTC should allow plain RTP and no ICE? This has been discussed many > times in this WG: Security in the media plane MUST NOT be optional, it > MUST be a MUST. So sorry, but a legacy SIP device not implementing > SRTP+ICE cannot interoperate with a WebRTC endoint. Period. I don't think one can lump SRTP together with ICE as an all-or-nothing bina= ry choice of "security". The two solve very different problems. The WG ma= y end up deciding both have to be used in the end, but the decision should = be made independently. I don't see a way to let WebRTC happen without ICE, for example, simply for= the consent portion of it - we can't trust the Javascript well enough to d= o without it. But supporting plaintext RTP isn't about trusting/not-trusti= ng the Javascript - it's more akin to allowing web-applications to use HTTP= vs. HTTPS. Are we going to mandate HTTPS be used as well? There are web applications which don't care about securing their content. = A game app, for example, might not care about secure media and might not wa= nt to use SRTP because they have to use a central media server mixer or ann= ouncement server or whatever, and don't want to take the hit for SRTP on it= . Another example is a website for creating virtual greeting cards, which = might use WebRTC to record a personal greeting to go with the virtual card,= and might not want to take the hit to secure media to their recording serv= ers. (I don't know if they're popular elsewhere, but in the US these virtua= l greeting e-card things are popular for sending birthday/anniversary/etc. = greetings, and most of them are plaintext HTTP) -hadriel From jmillan@aliax.net Sun Nov 6 01:16:30 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E8A21F8488 for ; Sun, 6 Nov 2011 01:16:30 -0800 (PST) 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=[AWL=-0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=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 0a1hPw9dTAD3 for ; Sun, 6 Nov 2011 01:16:29 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6673021F8478 for ; Sun, 6 Nov 2011 01:16:29 -0800 (PST) Received: by eyg24 with SMTP id 24so3465560eyg.31 for ; Sun, 06 Nov 2011 01:16:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.14.10.77 with SMTP id 53mr1870991eeu.226.1320570985025; Sun, 06 Nov 2011 01:16:25 -0800 (PST) Received: by 10.14.97.73 with HTTP; Sun, 6 Nov 2011 01:16:24 -0800 (PST) In-Reply-To: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> Date: Sun, 6 Nov 2011 10:16:24 +0100 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Sun, 06 Nov 2011 09:16:30 -0000 Hello you all, 2011/11/6 Hadriel Kaplan : > > > > On Nov 5, 2011, at 9:35 AM, I=F1aki Baz Castillo wrote: > >> Hi, in theory WebRTC is about realtime communications for the Web, but >> there is interest in making it interoperable with SIP networks. So: >> >> - Who is interested in interoperability with SIP? telcos (and me). > > I think that's an exaggeration, or perhaps a simplification, or generaliz= ation - well, some X-ation anyway. :) > > There is a ton of SIP in the Enterprise market, and they're not "Telcos".= =A0Enterprises deploy a lot of web servers and web applications as well, o= bviously - some for the public Internet, and some for their intranet (which= may happen to be through VPNs over the public Internet). > > >> - What does require "interoperability with SIP"? does it mean that >> WebRTC should allow plain RTP and no ICE? This has been discussed many >> times in this WG: Security in the media plane MUST NOT be optional, it >> MUST be a MUST. So sorry, but a legacy SIP device not implementing >> SRTP+ICE cannot interoperate with a WebRTC endoint. Period. > > I don't think one can lump SRTP together with ICE as an all-or-nothing bi= nary choice of "security". =A0The two solve very different problems. =A0The= WG may end up deciding both have to be used in the end, but the decision s= hould be made independently. > > I don't see a way to let WebRTC happen without ICE, for example, simply f= or the consent portion of it - we can't trust the Javascript well enough to= do without it. =A0But supporting plaintext RTP isn't about trusting/not-tr= usting the Javascript - it's more akin to allowing web-applications to use = HTTP vs. HTTPS. =A0Are we going to mandate HTTPS be used as well? > > There are web applications which don't care about securing their content.= =A0A game app, for example, might not care about secure media and might no= t want to use SRTP because they have to use a central media server mixer or= announcement server or whatever, and don't want to take the hit for SRTP o= n it. =A0Another example is a website for creating virtual greeting cards, = which might use WebRTC to record a personal greeting to go with the virtual= card, and might not want to take the hit to secure media to their recordin= g servers. (I don't know if they're popular elsewhere, but in the US these = virtual greeting e-card things are popular for sending birthday/anniversary= /etc. greetings, and most of them are plaintext HTTP) draft-ietf-rtcweb-overview-02 downgraded the SRTP concerns from mandatory-to-use to mandatory-to-implement. So if it does not downgrade anymore, a WebRTC implementation (game app, greeting cards website..) will have to implement SRTP. IMHO, if a web service doesn't want to take, or cannot take, the hit for SRTP, WebRTC is not the appropriate solution for such a service. > > -hadriel > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From tim@phonefromhere.com Sun Nov 6 04:05:24 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B192621F8490 for ; Sun, 6 Nov 2011 04:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 sKO8zDDhrUaf for ; Sun, 6 Nov 2011 04:05:24 -0800 (PST) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD4221F848D for ; Sun, 6 Nov 2011 04:05:23 -0800 (PST) Received: from [192.168.157.49] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id F01F837A902 for ; Sun, 6 Nov 2011 12:18:00 +0000 (GMT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Tim Panton In-Reply-To: Date: Sun, 6 Nov 2011 12:05:09 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> References: To: "" X-Mailer: Apple Mail (2.1251.1) Subject: Re: [rtcweb] Let's define the purpose of 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: Sun, 06 Nov 2011 12:05:24 -0000 On 5 Nov 2011, at 15:47, I=F1aki Baz Castillo wrote: > 2011/11/5 Eric Rescorla : >> Good point. Also, of course (unless you use the SRTP header = encryption >> extension) the SRTP header is in the clear, so you mostly just don't = get >> the media itself. >=20 > Hi, please use another thread for discussions about SRTP with no > encryption. This thread was supposed to discuss the purpose and scope > of WebRTC :) "There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable data transfer directly between clients." Seems like time to rewrite the charter - that doesn't even nearly = describe what we have on the table at the moment. Tim.= From oej@edvina.net Sun Nov 6 04:25:01 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C313821F848B for ; Sun, 6 Nov 2011 04:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_SE=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 r71AaCo+2VhF for ; Sun, 6 Nov 2011 04:25:01 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD3321F848A for ; Sun, 6 Nov 2011 04:25:01 -0800 (PST) Received: from [192.168.40.76] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id C59B7754BCD5; Sun, 6 Nov 2011 12:24:57 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> Date: Sun, 6 Nov 2011 13:24:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> To: Tim Panton X-Mailer: Apple Mail (2.1251.1) Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Sun, 06 Nov 2011 12:25:01 -0000 6 nov 2011 kl. 13:05 skrev Tim Panton: >=20 > On 5 Nov 2011, at 15:47, I=F1aki Baz Castillo wrote: >=20 >> 2011/11/5 Eric Rescorla : >>> Good point. Also, of course (unless you use the SRTP header = encryption >>> extension) the SRTP header is in the clear, so you mostly just don't = get >>> the media itself. >>=20 >> Hi, please use another thread for discussions about SRTP with no >> encryption. This thread was supposed to discuss the purpose and scope >> of WebRTC :) >=20 > "There are a number of proprietary implementations that provide direct > interactive rich communication using audio, video, collaboration, > games, etc. between two peers' web-browsers. These are not > interoperable, as they require non-standard extensions or plugins to > work. There is a desire to standardize the basis for such > communication so that interoperable communication can be established > between any compatible browsers. The goal is to enable innovation on > top of a set of basic components. One core component is to enable > real-time media like audio and video, a second is to enable data > transfer directly between clients." >=20 > Seems like time to rewrite the charter - that doesn't even nearly = describe > what we have on the table at the moment. Tim, I have been unable to follow all the mail threads, but your message = worries me. Can you be a bit more specific on what you see that we have on the = mentioned table and what worries you? Thanks, /O= From christer.holmberg@ericsson.com Sun Nov 6 05:08:32 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67A221F8482 for ; Sun, 6 Nov 2011 05:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.867 X-Spam-Level: X-Spam-Status: No, score=-5.867 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, J_CHICKENPOX_43=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 zjDpv5U3NbPf for ; Sun, 6 Nov 2011 05:08:32 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7FE21F8480 for ; Sun, 6 Nov 2011 05:08:31 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-14-4eb686cecb70 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1A.68.13753.EC686BE4; Sun, 6 Nov 2011 14:08:30 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Sun, 6 Nov 2011 14:08:30 +0100 From: Christer Holmberg To: Hadriel Kaplan , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Sun, 6 Nov 2011 14:05:55 +0100 Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AQHMnDaOf7Rk7jbqSkasPb/KQmbKSJWf0SIv Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522357173C1@ESESSCMS0356.eemea.ericsson.se> References: , <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> In-Reply-To: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Sun, 06 Nov 2011 13:08:32 -0000 Hi, I totally agree with Hadriel's statement :) ...but I still care about security. However, for me the biggest issue is no= t whether *usage* of SRTP is mandated or not, but that I am able to use it = with SDES. Yes, because of legacy interoperability :) Regards, Christer ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Hadrie= l Kaplan [HKaplan@acmepacket.com] Sent: Sunday, November 06, 2011 5:45 AM To: I=F1aki Baz Castillo Cc: Subject: Re: [rtcweb] Let's define the purpose of WebRTC On Nov 5, 2011, at 9:35 AM, I=F1aki Baz Castillo wrote: > Hi, in theory WebRTC is about realtime communications for the Web, but > there is interest in making it interoperable with SIP networks. So: > > - Who is interested in interoperability with SIP? telcos (and me). I think that's an exaggeration, or perhaps a simplification, or generalizat= ion - well, some X-ation anyway. :) There is a ton of SIP in the Enterprise market, and they're not "Telcos". = Enterprises deploy a lot of web servers and web applications as well, obvio= usly - some for the public Internet, and some for their intranet (which may= happen to be through VPNs over the public Internet). > - What does require "interoperability with SIP"? does it mean that > WebRTC should allow plain RTP and no ICE? This has been discussed many > times in this WG: Security in the media plane MUST NOT be optional, it > MUST be a MUST. So sorry, but a legacy SIP device not implementing > SRTP+ICE cannot interoperate with a WebRTC endoint. Period. I don't think one can lump SRTP together with ICE as an all-or-nothing bina= ry choice of "security". The two solve very different problems. The WG ma= y end up deciding both have to be used in the end, but the decision should = be made independently. I don't see a way to let WebRTC happen without ICE, for example, simply for= the consent portion of it - we can't trust the Javascript well enough to d= o without it. But supporting plaintext RTP isn't about trusting/not-trusti= ng the Javascript - it's more akin to allowing web-applications to use HTTP= vs. HTTPS. Are we going to mandate HTTPS be used as well? There are web applications which don't care about securing their content. = A game app, for example, might not care about secure media and might not wa= nt to use SRTP because they have to use a central media server mixer or ann= ouncement server or whatever, and don't want to take the hit for SRTP on it= . Another example is a website for creating virtual greeting cards, which = might use WebRTC to record a personal greeting to go with the virtual card,= and might not want to take the hit to secure media to their recording serv= ers. (I don't know if they're popular elsewhere, but in the US these virtua= l greeting e-card things are popular for sending birthday/anniversary/etc. = greetings, and most of them are plaintext HTTP) -hadriel _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb= From tim@phonefromhere.com Sun Nov 6 06:01:42 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F281021F84BB for ; Sun, 6 Nov 2011 06:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_CHICKENPOX_75=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 XuQIqWe3lgHC for ; Sun, 6 Nov 2011 06:01:42 -0800 (PST) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 3E22721F848B for ; Sun, 6 Nov 2011 06:01:42 -0800 (PST) Received: from [192.168.157.49] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 8C5C537A902; Sun, 6 Nov 2011 14:14:25 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> Date: Sun, 6 Nov 2011 14:01:35 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1251.1) Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Sun, 06 Nov 2011 14:01:43 -0000 On 6 Nov 2011, at 12:24, Olle E. Johansson wrote: >=20 > 6 nov 2011 kl. 13:05 skrev Tim Panton: >=20 >>=20 >> On 5 Nov 2011, at 15:47, I=F1aki Baz Castillo wrote: >>=20 >>> 2011/11/5 Eric Rescorla : >>>> Good point. Also, of course (unless you use the SRTP header = encryption >>>> extension) the SRTP header is in the clear, so you mostly just = don't get >>>> the media itself. >>>=20 >>> Hi, please use another thread for discussions about SRTP with no >>> encryption. This thread was supposed to discuss the purpose and = scope >>> of WebRTC :) >>=20 >> "There are a number of proprietary implementations that provide = direct >> interactive rich communication using audio, video, collaboration, >> games, etc. between two peers' web-browsers. These are not >> interoperable, as they require non-standard extensions or plugins to >> work. There is a desire to standardize the basis for such >> communication so that interoperable communication can be established >> between any compatible browsers. The goal is to enable innovation on >> top of a set of basic components. One core component is to enable >> real-time media like audio and video, a second is to enable data >> transfer directly between clients." >>=20 >> Seems like time to rewrite the charter - that doesn't even nearly = describe >> what we have on the table at the moment. >=20 > Tim, > I have been unable to follow all the mail threads, but your message = worries me. > Can you be a bit more specific on what you see that we have on the = mentioned > table and what worries you? >=20 > Thanks, > /O Almost all of the discussions here in the last few weeks are about = interop with existing SIP=20 deployments. ( forking,glare, SDP, RTP muxing) The bulk of the use-cases = on which that effort is based are also around interop with non-browser devices and channels, but = the charter never mentions legacy interop. It only talks about browser-to-browser = and replacing the myriad plugins. It also talks about being a platform for innovation, = which is now a non-goal for the group. I=F1aki asked a question as to the purpose of WebRTC, so I quoted the = charter. As I re-read it, I found that we have drifted a _long_ way from those = stated goals. On that basis, I say we have to re-evaluate something - either the = charter or what we now have. They are (to my mind) incompatible. As a concrete example - (there are _many_ but to name a current example) = - we seem to be=20 on the point of dropping the SRTP requirement in order to ease interop = with legacy devices. How that squares with the charter - or indeed the ITEF's security stance = I have no clue. Personally I'd like the charter re-written to reflect the actual goals = of this group. That way those who disagree can go off an form a group that _does_ reflect this = group's original purpose and focus on the browser to browser innovation case. If we don't - we are likely to end up with a halfway house that is bad = at interop and bad=20 for innovation (which is pretty much where we are now). Tim. Tim. From ekr@rtfm.com Sun Nov 6 06:38:59 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911C721F84B3 for ; Sun, 6 Nov 2011 06:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=0.6, 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 kI7BHgytdLGJ for ; Sun, 6 Nov 2011 06:38:58 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0E2D21F84B0 for ; Sun, 6 Nov 2011 06:38:58 -0800 (PST) Received: by gye5 with SMTP id 5so5001554gye.31 for ; Sun, 06 Nov 2011 06:38:57 -0800 (PST) Received: by 10.236.182.137 with SMTP id o9mr29289648yhm.78.1320590337235; Sun, 06 Nov 2011 06:38:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.146.232.12 with HTTP; Sun, 6 Nov 2011 06:38:15 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> From: Eric Rescorla Date: Sun, 6 Nov 2011 06:38:15 -0800 Message-ID: To: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Sun, 06 Nov 2011 14:38:59 -0000 On Sun, Nov 6, 2011 at 1:16 AM, Jos=E9 Luis Mill=E1n wr= ote: > Hello you all, > > > 2011/11/6 Hadriel Kaplan : >> >> >> >> On Nov 5, 2011, at 9:35 AM, I=F1aki Baz Castillo wrote: >> >>> Hi, in theory WebRTC is about realtime communications for the Web, but >>> there is interest in making it interoperable with SIP networks. So: >>> >>> - Who is interested in interoperability with SIP? telcos (and me). >> >> I think that's an exaggeration, or perhaps a simplification, or generali= zation - well, some X-ation anyway. :) >> >> There is a ton of SIP in the Enterprise market, and they're not "Telcos"= . =A0Enterprises deploy a lot of web servers and web applications as well, = obviously - some for the public Internet, and some for their intranet (whic= h may happen to be through VPNs over the public Internet). >> >> >>> - What does require "interoperability with SIP"? does it mean that >>> WebRTC should allow plain RTP and no ICE? This has been discussed many >>> times in this WG: Security in the media plane MUST NOT be optional, it >>> MUST be a MUST. So sorry, but a legacy SIP device not implementing >>> SRTP+ICE cannot interoperate with a WebRTC endoint. Period. >> >> I don't think one can lump SRTP together with ICE as an all-or-nothing b= inary choice of "security". =A0The two solve very different problems. =A0Th= e WG may end up deciding both have to be used in the end, but the decision = should be made independently. >> >> I don't see a way to let WebRTC happen without ICE, for example, simply = for the consent portion of it - we can't trust the Javascript well enough t= o do without it. =A0But supporting plaintext RTP isn't about trusting/not-t= rusting the Javascript - it's more akin to allowing web-applications to use= HTTP vs. HTTPS. =A0Are we going to mandate HTTPS be used as well? >> >> There are web applications which don't care about securing their content= . =A0A game app, for example, might not care about secure media and might n= ot want to use SRTP because they have to use a central media server mixer o= r announcement server or whatever, and don't want to take the hit for SRTP = on it. =A0Another example is a website for creating virtual greeting cards,= which might use WebRTC to record a personal greeting to go with the virtua= l card, and might not want to take the hit to secure media to their recordi= ng servers. (I don't know if they're popular elsewhere, but in the US these= virtual greeting e-card things are popular for sending birthday/anniversar= y/etc. greetings, and most of them are plaintext HTTP) > > draft-ietf-rtcweb-overview-02 downgraded the SRTP concerns from > mandatory-to-use to mandatory-to-implement. So if it does not > downgrade anymore, a WebRTC implementation (game app, greeting cards > website..) will have to implement SRTP. Hmm... I I don't see any reason to allow insecure calling from one WebRTC client to another. It's a different question whether one should allow insecure calling to legacy clients. > IMHO, if a web service doesn't want to take, or cannot take, the hit > for SRTP, WebRTC is not the appropriate solution for such a service. I'm exceedingly unsympathetic to the claim that SRTP is too slow. This is precisely the claim that was made about TLS for years, but measurements (see Langley and Modadugu's Overclocking SSL talk at Velocity) show that that's not really true. -Ekr From harald@alvestrand.no Sun Nov 6 08:35:00 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A959721F8495 for ; Sun, 6 Nov 2011 08:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=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 taYCs8LRYzGZ for ; Sun, 6 Nov 2011 08:34:59 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 86A0E21F8491 for ; Sun, 6 Nov 2011 08:34:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2C4DE39E0A3 for ; Sun, 6 Nov 2011 17:34:58 +0100 (CET) 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 u8ZGE1kMCS6t for ; Sun, 6 Nov 2011 17:34:57 +0100 (CET) Received: from [10.154.240.196] (unknown [62.206.113.61]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 2838139E074 for ; Sun, 6 Nov 2011 17:34:57 +0100 (CET) Message-ID: <4EB6B73E.6010501@alvestrand.no> Date: Sun, 06 Nov 2011 17:35:10 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058522341F4A8B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852235789601@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852235789601@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - seq/sessionId vs sess-version/sess-id (Section 5.2.1 and 5.2.2) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Nov 2011 16:35:00 -0000 On 11/03/2011 08:15 PM, Christer Holmberg wrote: > Hi Cullen, > > I am not sure I receied a reply from you (or anyone else) to the questions below. > > Regards, > > Christer > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 19. lokakuuta 2011 15:50 > To: Cullen Jennings; rtcweb@ietf.org; public-webrtc@w3.org > Cc: Jonathan Rosenberg > Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - seq/sessionId vs sess-version/sess-id (Section 5.2.1 and 5.2.2) > > > Hi, > > What is the relation between the seq/sessionId values and the SDP sess-version/sess-id values (part of the SDP o= line), and why do we need seq/sessionId in the first place? My reading of the RFC is that the sess-id of an ANSWER is uncorrelated with the sess-id of an OFFER, and that in some cases, the sess-version is. RFC 3264 section 6: 6 Generating the Answer The answer to an offered session description is based on the offered session description. If the answer is different from the offer in any way (different IP addresses, ports, etc.), the origin line MUST be different in the answer, since the answer is generated by a different entity. In that case, the version number in the "o=" line of the answer is unrelated to the version number in the o line of the offer. Section 8: Nearly all aspects of the session can be modified. New streams can be added, existing streams can be deleted, and parameters of existing streams can change. When issuing an offer that modifies the session, the "o=" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP. If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number. The answerer MUST be prepared to receive an offer that contains SDP with a version that has not changed; this is effectively a no-op. However, the answerer MUST generate a valid answer (which MAY be the same as the previous SDP from the answerer, or MAY be different), according to the procedures defined in Section 6. From the first example in section 10.1: Offer: o=alice 2890844526 2890844526 IN IP4 host.anywhere.com Answer: o=bob 2890844730 2890844730 IN IP4 host.example.com Note the non-match, for both the sess-id and the version. I was hoping that someone with deeper SDP knowledge would answer, that's why I didn't reply before... > AFAIK, the only reason for having the seq/sessionId values is when sending an OK message, since there will be no SDP (and therefor no SDP sess-version/sessionId). Or, are there any other reasons? > > I think the draft should say something about the correlation. > > And, IF we need seq/sessionId, should we say that the SDP sess-version/sess-id values must be identical - or, at least saying that they must be set and incremented according to the SDP rules? I think that would help in SIP/SDP interworking cases. Otherwise the interworking gateway will have to check, keep track of, and possibly modify, the sess-version/sess-id values. > > Regards, > > Christer > > > > > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings >> Sent: 15. lokakuuta 2011 6:09 >> To: rtcweb@ietf.org; public-webrtc@w3.org >> Cc: Jonathan Rosenberg >> Subject: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling >> >> >> Jonathan and I submitted a new draft on setting up media based on the >> SDP Offer/Answer model. The ASCII flows are a bit hard to read so >> until I update them, I recommend reading the PDF version at >> >> http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf >> >> Clearly the draft is an early stage but we plan to revise it before >> the deadline for the IETF 82. Love to get input - particularly on if >> this looks like generally the right direction to go. >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From juberti@google.com Sun Nov 6 08:35:15 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32E621F84ED for ; Sun, 6 Nov 2011 08:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 jCzQHUmNEGNl for ; Sun, 6 Nov 2011 08:35:15 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1EE621F84DC for ; Sun, 6 Nov 2011 08:35:14 -0800 (PST) Received: by iaeo4 with SMTP id o4so6256085iae.31 for ; Sun, 06 Nov 2011 08:35:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=2v3wDaqxl8XBN3wTheF1nUiVLqKfLXTpJm7ToUC/v3k=; b=SxW+6cLoFeK5m+mjyvv56G3fgEqAnx1YXhySx2V0J4Xc3aXMQ7Y+v7rVsnymrIBco3 O/BYYF9wni3M7Vw/2/xA== Received: by 10.231.41.69 with SMTP id n5mr8758061ibe.92.1320597313458; Sun, 06 Nov 2011 08:35:13 -0800 (PST) Received: by 10.231.41.69 with SMTP id n5mr8758041ibe.92.1320597313165; Sun, 06 Nov 2011 08:35:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.34.4 with HTTP; Sun, 6 Nov 2011 08:34:52 -0800 (PST) In-Reply-To: References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> From: Justin Uberti Date: Sun, 6 Nov 2011 11:34:52 -0500 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=0015177407d4be1a0d04b1138587 X-System-Of-Record: true Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Sun, 06 Nov 2011 16:35:15 -0000 --0015177407d4be1a0d04b1138587 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Nov 6, 2011 at 9:38 AM, Eric Rescorla wrote: > On Sun, Nov 6, 2011 at 1:16 AM, Jos=C3=A9 Luis Mill=C3=A1n > wrote: > > Hello you all, > > > > > > 2011/11/6 Hadriel Kaplan : > >> > >> > >> > >> On Nov 5, 2011, at 9:35 AM, I=C3=B1aki Baz Castillo wrote: > >> > >>> Hi, in theory WebRTC is about realtime communications for the Web, bu= t > >>> there is interest in making it interoperable with SIP networks. So: > >>> > >>> - Who is interested in interoperability with SIP? telcos (and me). > >> > >> I think that's an exaggeration, or perhaps a simplification, or > generalization - well, some X-ation anyway. :) > >> > >> There is a ton of SIP in the Enterprise market, and they're not > "Telcos". Enterprises deploy a lot of web servers and web applications a= s > well, obviously - some for the public Internet, and some for their intran= et > (which may happen to be through VPNs over the public Internet). > >> > >> > >>> - What does require "interoperability with SIP"? does it mean that > >>> WebRTC should allow plain RTP and no ICE? This has been discussed man= y > >>> times in this WG: Security in the media plane MUST NOT be optional, i= t > >>> MUST be a MUST. So sorry, but a legacy SIP device not implementing > >>> SRTP+ICE cannot interoperate with a WebRTC endoint. Period. > >> > >> I don't think one can lump SRTP together with ICE as an all-or-nothing > binary choice of "security". The two solve very different problems. The > WG may end up deciding both have to be used in the end, but the decision > should be made independently. > >> > >> I don't see a way to let WebRTC happen without ICE, for example, simpl= y > for the consent portion of it - we can't trust the Javascript well enough > to do without it. But supporting plaintext RTP isn't about > trusting/not-trusting the Javascript - it's more akin to allowing > web-applications to use HTTP vs. HTTPS. Are we going to mandate HTTPS be > used as well? > >> > >> There are web applications which don't care about securing their > content. A game app, for example, might not care about secure media and > might not want to use SRTP because they have to use a central media serve= r > mixer or announcement server or whatever, and don't want to take the hit > for SRTP on it. Another example is a website for creating virtual greeti= ng > cards, which might use WebRTC to record a personal greeting to go with th= e > virtual card, and might not want to take the hit to secure media to their > recording servers. (I don't know if they're popular elsewhere, but in the > US these virtual greeting e-card things are popular for sending > birthday/anniversary/etc. greetings, and most of them are plaintext HTTP) > > > > draft-ietf-rtcweb-overview-02 downgraded the SRTP concerns from > > mandatory-to-use to mandatory-to-implement. So if it does not > > downgrade anymore, a WebRTC implementation (game app, greeting cards > > website..) will have to implement SRTP. > > Hmm... I I don't see any > reason to allow insecure calling from one WebRTC client to another. > It's a different question whether one should allow insecure calling > to legacy clients. > > > IMHO, if a web service doesn't want to take, or cannot take, the hit > > for SRTP, WebRTC is not the appropriate solution for such a service. > > I'm exceedingly unsympathetic to the claim that SRTP is too slow. This > is precisely the claim that was made about TLS for years, but measurement= s > (see Langley and Modadugu's Overclocking SSL talk at Velocity) show > that that's not really true. > > Agreed. I am also unsympathetic to the claim that SRTP is too hard to debug. Google+ Hangouts was built as SRTP-only, and this (as well as performance) was never an issue in the construction and deployment of the service. --0015177407d4be1a0d04b1138587 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun, Nov 6, 2011 at 9:38 AM, Eric Res= corla <ekr@rtfm.com> wrote:
On Sun, Nov 6, 2011 at 1:16 AM, Jos=C3=A9 Luis Mill=C3=A1= n <jmillan@aliax.net> wrote:=
> Hello you all,
>
>
> 2011/11/6 Hadriel Kaplan <HKaplan@acmepacket.com>:
>>
>>
>>
>> On Nov 5, 2011, at 9:35 AM, I=C3=B1aki Baz Castillo wrote:
>>
>>> Hi, in theory WebRTC is about realtime communications for the = Web, but
>>> there is interest in making it interoperable with SIP networks= . So:
>>>
>>> - Who is interested in interoperability with SIP? telcos (and = me).
>>
>> I think that's an exaggeration, or perhaps a simplification, o= r generalization - well, some X-ation anyway. :)
>>
>> There is a ton of SIP in the Enterprise market, and they're no= t "Telcos". =C2=A0Enterprises deploy a lot of web servers and web= applications as well, obviously - some for the public Internet, and some f= or their intranet (which may happen to be through VPNs over the public Inte= rnet).
>>
>>
>>> - What does require "interoperability with SIP"? doe= s it mean that
>>> WebRTC should allow plain RTP and no ICE? This has been discus= sed many
>>> times in this WG: Security in the media plane MUST NOT be opti= onal, it
>>> MUST be a MUST. So sorry, but a legacy SIP device not implemen= ting
>>> SRTP+ICE cannot interoperate with a WebRTC endoint. Period. >>
>> I don't think one can lump SRTP together with ICE as an all-or= -nothing binary choice of "security". =C2=A0The two solve very di= fferent problems. =C2=A0The WG may end up deciding both have to be used in = the end, but the decision should be made independently.
>>
>> I don't see a way to let WebRTC happen without ICE, for exampl= e, simply for the consent portion of it - we can't trust the Javascript= well enough to do without it. =C2=A0But supporting plaintext RTP isn't= about trusting/not-trusting the Javascript - it's more akin to allowin= g web-applications to use HTTP vs. HTTPS. =C2=A0Are we going to mandate HTT= PS be used as well?
>>
>> There are web applications which don't care about securing the= ir content. =C2=A0A game app, for example, might not care about secure medi= a and might not want to use SRTP because they have to use a central media s= erver mixer or announcement server or whatever, and don't want to take = the hit for SRTP on it. =C2=A0Another example is a website for creating vir= tual greeting cards, which might use WebRTC to record a personal greeting t= o go with the virtual card, and might not want to take the hit to secure me= dia to their recording servers. (I don't know if they're popular el= sewhere, but in the US these virtual greeting e-card things are popular for= sending birthday/anniversary/etc. greetings, and most of them are plaintex= t HTTP)
>
> draft-ietf-rtcweb-overview-02 downgraded the SRTP concerns from
> mandatory-to-use to mandatory-to-implement. So if it does not
> downgrade anymore, a WebRTC implementation (game app, greeting cards > website..) will have to implement SRTP.

Hmm... I I don't see any
reason to allow insecure calling from one WebRTC client to another.
It's a different question whether one should allow insecure calling
to legacy clients.

> IMHO, if a web service doesn't want to take, or cannot take, the h= it
> for SRTP, WebRTC is not the appropriate solution for such a service.
I'm exceedingly unsympathetic to the claim that SRTP is too slow.= This
is precisely the claim that was made about TLS for years, but measurements<= br> (see Langley and Modadugu's Overclocking SSL talk at Velocity) show
that that's not really true.

=C2=A0
= Agreed. I am also unsympathetic to the claim that SRTP is too hard to debug= . Google+ Hangouts was built as SRTP-only, and this (as well as performance= ) was never an issue in the construction and deployment of the service.
=C2=A0
--0015177407d4be1a0d04b1138587-- From harald@alvestrand.no Sun Nov 6 08:36:22 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E2A21F8490; Sun, 6 Nov 2011 08:36:22 -0800 (PST) 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, 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 SfEaRExNj-2A; Sun, 6 Nov 2011 08:36:21 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B1D0421F8437; Sun, 6 Nov 2011 08:36:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 077B039E0A3; Sun, 6 Nov 2011 17:36:21 +0100 (CET) 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 j5N4uk+uzpTU; Sun, 6 Nov 2011 17:36:20 +0100 (CET) Received: from [10.154.240.196] (unknown [62.206.113.61]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 0429439E074; Sun, 6 Nov 2011 17:36:19 +0100 (CET) Message-ID: <4EB6B792.8030207@alvestrand.no> Date: Sun, 06 Nov 2011 17:36:34 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> <4EB552F0.6050800@acm.org> In-Reply-To: <4EB552F0.6050800@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ned Freed , Keith Moore , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [rtcweb] [BEHAVE] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Nov 2011 16:36:22 -0000 On 11/05/2011 04:14 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: >> On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: >> >>> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand>> > wrote: >>>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >>>>> I don't have any commitment to the scheme. What's the best place? >>>> I like parameters, like this: >>>> >>>> turn://user@host?proto=tcp >>>> >>>> Quite hard to misunderstand, and quite easy to extend. >>>> >>>> (Note: // is only allowed if what follows is [user[:pass]@]host - I don't >>>> recommend using the password, for the obvious reasons, but the syntax will >>>> allow it.) >>> I don't see any security problem with that. The "break old >>> implementations" rationale >>> doesn't apply when we are defining a new URI scheme. >> I agree with this as well. If we can get some consensus with this, I will >> update the next version of both the STUN and TURN URI Scheme drafts to include >> this format. > Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is already > doing it right (and had a lot of reviews back in 2008, before I split the > resolution mechanism and the syntax in two separate documents). > > I know my email address does not contain the magical "cisco.com", but this is > getting ridiculous. Sorry, some of us were not on BEHAVE in 2008, and missed the previous discussion. From harald@alvestrand.no Sun Nov 6 08:37:56 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CBA21F84ED; Sun, 6 Nov 2011 08:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 qCheTUJ8ZiSH; Sun, 6 Nov 2011 08:37:55 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9163821F84DC; Sun, 6 Nov 2011 08:37:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E2D3639E0A3; Sun, 6 Nov 2011 17:37:54 +0100 (CET) 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 c3ejcrwS9F7S; Sun, 6 Nov 2011 17:37:54 +0100 (CET) Received: from [10.154.240.196] (unknown [62.206.113.61]) by eikenes.alvestrand.no (Postfix) with ESMTPS id D904539E074; Sun, 6 Nov 2011 17:37:53 +0100 (CET) Message-ID: <4EB6B7F0.4040001@alvestrand.no> Date: Sun, 06 Nov 2011 17:38:08 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Marc Petit-Huguenin References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> <4EB552F0.6050800@acm.org> In-Reply-To: <4EB552F0.6050800@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ned Freed , Keith Moore , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [rtcweb] [BEHAVE] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Nov 2011 16:37:56 -0000 On 11/05/2011 04:14 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: >> On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: >> >>> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand>> > wrote: >>>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >>>>> I don't have any commitment to the scheme. What's the best place? >>>> I like parameters, like this: >>>> >>>> turn://user@host?proto=tcp >>>> >>>> Quite hard to misunderstand, and quite easy to extend. >>>> >>>> (Note: // is only allowed if what follows is [user[:pass]@]host - I don't >>>> recommend using the password, for the obvious reasons, but the syntax will >>>> allow it.) >>> I don't see any security problem with that. The "break old >>> implementations" rationale >>> doesn't apply when we are defining a new URI scheme. >> I agree with this as well. If we can get some consensus with this, I will >> update the next version of both the STUN and TURN URI Scheme drafts to include >> this format. > Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is already > doing it right (and had a lot of reviews back in 2008, before I split the > resolution mechanism and the syntax in two separate documents). > > I know my email address does not contain the magical "cisco.com", but this is > getting ridiculous. Second opinion: draft-petithuguenin uses TURN and TURNS as scheme names. I still think this is doing it wrong. Harald From harald@alvestrand.no Sun Nov 6 08:42:38 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4274421F8511; Sun, 6 Nov 2011 08:42:38 -0800 (PST) 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 kuyzGVVPJvCa; Sun, 6 Nov 2011 08:42:36 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D523821F84DA; Sun, 6 Nov 2011 08:42:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5E01139E0A3; Sun, 6 Nov 2011 17:42:32 +0100 (CET) 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 wnEVSOzTp+xU; Sun, 6 Nov 2011 17:42:31 +0100 (CET) Received: from [10.154.240.196] (unknown [62.206.113.61]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 468FE39E074; Sun, 6 Nov 2011 17:42:31 +0100 (CET) Message-ID: <4EB6B904.8050607@alvestrand.no> Date: Sun, 06 Nov 2011 17:42:44 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Ned Freed References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <01O823CUB1SG00XBUL@mauve.mrochek.com> In-Reply-To: <01O823CUB1SG00XBUL@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" , Keith Moore , Keith Moore , Behave WG Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Nov 2011 16:42:38 -0000 On 11/05/2011 06:20 PM, Ned Freed wrote: >> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >> > On Fri, Nov 4, 2011 at 8:31 AM, Ned Freed >> wrote: >> >>> Top-posting a general principle, detailed comment at the bottom.... >> >>> For all URI schemes, I think the URI needs to contain all the >> >>> information you need in order to make contact with the service; you >> >>> can't negotiate until you've made contact. >> >>> (the process may involve things like "resolve through a resolution >> >>> mechanism like DNS" or "get authorization tokens from somewhere >> else"). >> >>> In the case of TURN, you need to distinguish between TCP, UDP and >> TLS, >> >>> and you need to make that determination before you send the first >> >>> packet. That means the distinguishing information between those >> three >> >>> things belongs in the URL; I don't think the scheme is a good >> place to >> >>> encode it. >> >> I'm in complete agreement with Harald on all of these points. And >> while it >> >> would have been nice if URL syntax was less messy and more >> general, making >> >> it easier to do these sorts of things in a consistent way, it >> quite simply >> >> isn't and we have to make do with what we have. >> > I don't have any commitment to the scheme. What's the best place? > >> I like parameters, like this: > >> turn://user@host?proto=tcp > >> Quite hard to misunderstand, and quite easy to extend. > >> (Note: // is only allowed if what follows is [user[:pass]@]host - I >> don't recommend using the password, for the obvious reasons, but the >> syntax will allow it.) > > Given your earlier characterization of the TCP/UDP/TLS distinction being > a single axis, I assume you mean that you'd say: > > turn://user@host?proto=tls > > and not > > turns://user@host?proto=tcp I was thinking turn://@?proto= but thought that this was going too far into details. > > I have to say I prefer the parameter approach, but I wonder if these > really > are along a single axis - is DTLS a possibility here? DTLS is a possibility, if the TURN protocol is extended to support it, and would be a fourth parameter value. Currently it's not specified (AFAIK). My opinion is that the URL needs to contain the context that the TURN client needs to know before it can contact the TURN server. There may be options that can reasonably be negotiated in the TURN channel setup procedure; those don't need to be in the URL. My current reading is that with the current TURN spec, the initial packets sent by the user is different for the 3 cases TCP, UDP and TLS. From ibc@aliax.net Sun Nov 6 08:45:23 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7438B21F8514; Sun, 6 Nov 2011 08:45:23 -0800 (PST) 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 nM9kQrsNZM4d; Sun, 6 Nov 2011 08:45:23 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE02C21F8509; Sun, 6 Nov 2011 08:45:22 -0800 (PST) Received: by vcbfl11 with SMTP id fl11so3849591vcb.31 for ; Sun, 06 Nov 2011 08:45:22 -0800 (PST) Received: by 10.220.65.16 with SMTP id g16mr1729414vci.68.1320597922063; Sun, 06 Nov 2011 08:45:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Sun, 6 Nov 2011 08:45:01 -0800 (PST) In-Reply-To: <4EB6B904.8050607@alvestrand.no> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <01O823CUB1SG00XBUL@mauve.mrochek.com> <4EB6B904.8050607@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 6 Nov 2011 17:45:01 +0100 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Keith Moore , "rtcweb@ietf.org" , Ned Freed , Keith Moore , Behave WG Subject: Re: [rtcweb] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Nov 2011 16:45:23 -0000 2011/11/6 Harald Alvestrand : > I was thinking > > =C2=A0 turn://@?proto=3D > > but thought that this was going too far into details. Is not more appropriate to use "transport" rather than "proto"? --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Sun Nov 6 08:48:43 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC2521F8549 for ; Sun, 6 Nov 2011 08:48:43 -0800 (PST) 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 rKaOe1Wm9QSv for ; Sun, 6 Nov 2011 08:48:42 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9138021F8548 for ; Sun, 6 Nov 2011 08:48:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D3B7539E0A3; Sun, 6 Nov 2011 17:48:41 +0100 (CET) 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 pyH82oCe0MlH; Sun, 6 Nov 2011 17:48:41 +0100 (CET) Received: from [10.154.240.196] (unknown [62.206.113.61]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 5BB6339E074; Sun, 6 Nov 2011 17:48:41 +0100 (CET) Message-ID: <4EB6BA76.6000505@alvestrand.no> Date: Sun, 06 Nov 2011 17:48:54 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@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] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Nov 2011 16:48:43 -0000 On 11/05/2011 10:24 PM, Bjoern Hoehrmann wrote: > * Harald Alvestrand wrote: >> I like parameters, like this: >> >> turn://user@host?proto=tcp >> >> Quite hard to misunderstand, and quite easy to extend. >> >> (Note: // is only allowed if what follows is [user[:pass]@]host - I >> don't recommend using the password, for the obvious reasons, but the >> syntax will allow it.) > As far as the requirements for URI schemes go, no, it is not necessary > to allow a user name or password. The 'http' scheme for instance prohi- > bits both, and the 'pop' scheme allows a user name but no password. Good riddance! I see that http://tools.ietf.org/html/rfc3986#section-3.2.1 still defines it as part of the generic syntax, but as "deprecated". It used to be a regularly used feature of HTTP, too, but that was long ago.... From petithug@acm.org Sun Nov 6 08:58:50 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7041721F851F; Sun, 6 Nov 2011 08:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.653 X-Spam-Level: X-Spam-Status: No, score=-102.653 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, NO_RELAYS=-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 34fiz8GP6+3y; Sun, 6 Nov 2011 08:58:49 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBC821F8515; Sun, 6 Nov 2011 08:58:49 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 424AD20138; Sun, 6 Nov 2011 16:49:41 +0000 (UTC) Message-ID: <4EB6BCC5.6020407@acm.org> Date: Sun, 06 Nov 2011 08:58:45 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Harald Alvestrand References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> <4EB552F0.6050800@acm.org> <4EB6B792.8030207@alvestrand.no> In-Reply-To: <4EB6B792.8030207@alvestrand.no> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ned Freed , Keith Moore , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [rtcweb] [BEHAVE] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Nov 2011 16:58:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/06/2011 08:36 AM, Harald Alvestrand wrote: > On 11/05/2011 04:14 PM, Marc Petit-Huguenin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: >>> On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: >>> >>>> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand>>> > wrote: >>>>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >>>>>> I don't have any commitment to the scheme. What's the best place? >>>>> I like parameters, like this: >>>>> >>>>> turn://user@host?proto=tcp >>>>> >>>>> Quite hard to misunderstand, and quite easy to extend. >>>>> >>>>> (Note: // is only allowed if what follows is [user[:pass]@]host - I don't >>>>> recommend using the password, for the obvious reasons, but the syntax will >>>>> allow it.) >>>> I don't see any security problem with that. The "break old >>>> implementations" rationale >>>> doesn't apply when we are defining a new URI scheme. >>> I agree with this as well. If we can get some consensus with this, I will >>> update the next version of both the STUN and TURN URI Scheme drafts to include >>> this format. >> Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is already >> doing it right (and had a lot of reviews back in 2008, before I split the >> resolution mechanism and the syntax in two separate documents). >> >> I know my email address does not contain the magical "cisco.com", but this is >> getting ridiculous. > > Sorry, some of us were not on BEHAVE in 2008, and missed the previous discussion. This is not the problem. The problem is that the authors of the new draft continue to ignore a draft that is the result of BEHAVE, IESG, security, gen-art, ops and other directorate reviews. (To be fair, two employees of Cisco I worked with in the past contacted me to see how to work on this but none of the authors of the draft did). - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk62vMMACgkQ9RoMZyVa61fiSwCfZtnYxYBbxMmebzKwkQa19Uus 7v4AoJiPr0aHYvKAoEUkwJNp7DyvpYVW =r7Po -----END PGP SIGNATURE----- From petithug@acm.org Sun Nov 6 09:19:01 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73AE21F853E; Sun, 6 Nov 2011 09:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.65 X-Spam-Level: X-Spam-Status: No, score=-102.65 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, NO_RELAYS=-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 LAjhZSce9ixm; Sun, 6 Nov 2011 09:19:01 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id D236C21F8532; Sun, 6 Nov 2011 09:19:00 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 2876820138; Sun, 6 Nov 2011 17:09:50 +0000 (UTC) Message-ID: <4EB6C17F.50103@acm.org> Date: Sun, 06 Nov 2011 09:18:55 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15 MIME-Version: 1.0 To: Ned Freed References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> <4EB552F0.6050800@acm.org> <4EB6B7F0.4040001@alvestrand.no> <01O83GWH5W5I00XBUL@mauve.mrochek.com> In-Reply-To: <01O83GWH5W5I00XBUL@mauve.mrochek.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Behave WG , Keith Moore , Keith Moore , rtcweb@ietf.org Subject: Re: [rtcweb] [BEHAVE] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Nov 2011 17:19:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/06/2011 09:59 AM, Ned Freed wrote: >> On 11/05/2011 04:14 PM, Marc Petit-Huguenin wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: >> >> On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: >> >> >> >>> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand> >>> > wrote: >> >>>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >> >>>>> I don't have any commitment to the scheme. What's the best place? >> >>>> I like parameters, like this: >> >>>> >> >>>> turn://user@host?proto=tcp >> >>>> >> >>>> Quite hard to misunderstand, and quite easy to extend. >> >>>> >> >>>> (Note: // is only allowed if what follows is [user[:pass]@]host - I don't >> >>>> recommend using the password, for the obvious reasons, but the syntax will >> >>>> allow it.) >> >>> I don't see any security problem with that. The "break old >> >>> implementations" rationale >> >>> doesn't apply when we are defining a new URI scheme. >> >> I agree with this as well. If we can get some consensus with this, I will >> >> update the next version of both the STUN and TURN URI Scheme drafts to include >> >> this format. >> > Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is already >> > doing it right (and had a lot of reviews back in 2008, before I split the >> > resolution mechanism and the syntax in two separate documents). >> > >> > I know my email address does not contain the magical "cisco.com", but this is >> > getting ridiculous. > >> Second opinion: draft-petithuguenin uses TURN and TURNS as scheme names. >> I still think this is doing it wrong. > > I concur, especially since two different security layers could be used for some > transports in addition to none at all. The security layer needs to be specified > as a parameter. The current syntax was inspired by RFC 3261, but I can put some text about different syntax in the spec for the purpose of the discussion[1]. What parameter name would you propose for that? [1] Note that my point of view, and IMO the first thing that should be discussed, is that a TURN URI is not needed for what RTCWEB wants to do. Why is it better to have a URI (on which we cannot put the password anyway), versus having multiple individual string characters for the security level, transport, host, port, login and password? - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk62wX0ACgkQ9RoMZyVa61cWSgCgnHXs8DWr5BKn1jB9j3+cz5Bf +68AoI0Uk3+TKbcV5OSlG/zRZD6AIXrg =tqtp -----END PGP SIGNATURE----- From oej@edvina.net Sun Nov 6 09:42:45 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A914021F8591 for ; Sun, 6 Nov 2011 09:42:45 -0800 (PST) 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_SE=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 vPF17-V3sLEp for ; Sun, 6 Nov 2011 09:42:45 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 2B28121F853A for ; Sun, 6 Nov 2011 09:42:45 -0800 (PST) Received: from [IPv6:2001:470:1f15:d79:2564:6d40:a6ee:55e6] (unknown [IPv6:2001:470:1f15:d79:2564:6d40:a6ee:55e6]) by smtp7.webway.se (Postfix) with ESMTPA id 7B267754BCD5; Sun, 6 Nov 2011 17:42:41 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522357173C1@ESESSCMS0356.eemea.ericsson.se> Date: Sun, 6 Nov 2011 18:42:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <61ED1956-412B-4E0F-B89C-6E7E68D654EE@edvina.net> References: , <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522357173C1@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1251.1) Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Sun, 06 Nov 2011 17:42:45 -0000 6 nov 2011 kl. 14:05 skrev Christer Holmberg: >=20 > Hi, >=20 > I totally agree with Hadriel's statement :) >=20 > ...but I still care about security. However, for me the biggest issue = is not whether *usage* of SRTP is mandated or not, but that I am able to = use it with SDES. Yes, because of legacy interoperability :) >=20 Personally, I don't care much about interoperability with a broken = security model, like SDES. I still think, like I voiced before, that we should have no option to disable SRTP. Game developers will not = be hurt by it, I think you are wrong there Hadriel. It's time to move forward and agree that security by default is a much = better solution for all the use cases. I have a hard time finding a use case where security by default, mandated by our specs, = will actually hurt more than interoperability with old SIP phones.=20 The SIP market teaches me that customers will not require security. If = Skype had asked customers, they would have ended up on tabloids with headlines about neighbours listening to my calls - = because customers would have said=20 "Oh no, I have no secrets to hide". And that's where we will end up too, = unless we take a position. Users won't ask for security. Web hackers won't ask for security. But = they will all need it and trust us to fix it. /O From gsalguei@cisco.com Sun Nov 6 10:11:05 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD97421F85A4 for ; Sun, 6 Nov 2011 10:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gq7incasEbp6 for ; Sun, 6 Nov 2011 10:11:05 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id BDA1521F8591 for ; Sun, 6 Nov 2011 10:11:04 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pA6IB3Pp016386 for ; Sun, 6 Nov 2011 13:11:03 -0500 (EST) Received: from rtp-gsalguei-8712.cisco.com (rtp-gsalguei-8712.cisco.com [10.116.61.51]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pA6IAv68020484; Sun, 6 Nov 2011 13:10:57 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-148-845957745 From: Gonzalo Salgueiro In-Reply-To: <4EB6BCC5.6020407@acm.org> Date: Sun, 6 Nov 2011 13:10:57 -0500 Message-Id: <430C8C33-6F5F-4278-ADEB-44D963868DFA@cisco.com> References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> <4EB552F0.6050800@acm.org> <4EB6B792.8030207@alvestrand.no> <4EB6BCC5.6020407@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1084) Cc: Ned Freed , Keith Moore , Keith Moore , Behave WG , rtcweb@ietf.org Subject: Re: [rtcweb] [BEHAVE] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Nov 2011 18:11:06 -0000 --Apple-Mail-148-845957745 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 6, 2011, at 11:58 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 11/06/2011 08:36 AM, Harald Alvestrand wrote: >> On 11/05/2011 04:14 PM, Marc Petit-Huguenin wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>>=20 >>> On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: >>>> On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: >>>>=20 >>>>> On Fri, Nov 4, 2011 at 5:18 PM, Harald = Alvestrand>>>> > wrote: >>>>>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: >>>>>>> I don't have any commitment to the scheme. What's the best = place? >>>>>> I like parameters, like this: >>>>>>=20 >>>>>> turn://user@host?proto=3Dtcp >>>>>>=20 >>>>>> Quite hard to misunderstand, and quite easy to extend. >>>>>>=20 >>>>>> (Note: // is only allowed if what follows is [user[:pass]@]host - = I don't >>>>>> recommend using the password, for the obvious reasons, but the = syntax will >>>>>> allow it.) >>>>> I don't see any security problem with that. The "break old >>>>> implementations" rationale >>>>> doesn't apply when we are defining a new URI scheme. >>>> I agree with this as well. If we can get some consensus with this, = I will >>>> update the next version of both the STUN and TURN URI Scheme drafts = to include >>>> this format. >>> Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is = already >>> doing it right (and had a lot of reviews back in 2008, before I = split the >>> resolution mechanism and the syntax in two separate documents). >>>=20 >>> I know my email address does not contain the magical "cisco.com", = but this is >>> getting ridiculous. >>=20 >> Sorry, some of us were not on BEHAVE in 2008, and missed the previous = discussion. >=20 > This is not the problem. The problem is that the authors of the new = draft > continue to ignore a draft that is the result of BEHAVE, IESG, = security, > gen-art, ops and other directorate reviews. (To be fair, two = employees of Cisco > I worked with in the past contacted me to see how to work on this but = none of > the authors of the draft did). >=20 I find it incredible I need to explain anything about ignoring your = draft when in our draft it clearly states: We acknowledge the existence of draft-petithuguenin-behave-turn-uri-bis-04 document as a parallel effort in defining the URI scheme for TURN. Awareness of this draft came late in the process and we have not had to time to reach out to the author of that memo and discuss opportunities to collaborate on a single document. It is our intentions to do so. The discussion you had with Cullen and Dan are known to us but we were = pretty much finished both the STUN and TURN drafts by the time we found = out about your draft. At this point we were waiting for you and Cullen = to discuss the best way forward to meet the needs of WebRTC. We are = happy to combine forces or yield entirely, based on that discussion. Regards, Gonzalo > - --=20 > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) >=20 > iEYEARECAAYFAk62vMMACgkQ9RoMZyVa61fiSwCfZtnYxYBbxMmebzKwkQa19Uus > 7v4AoJiPr0aHYvKAoEUkwJNp7DyvpYVW > =3Dr7Po > -----END PGP SIGNATURE----- >=20 --Apple-Mail-148-845957745 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
-----BEGIN PGP SIGNED MESSAGE-----
Hash: = SHA1

On 11/06/2011 08:36 AM, Harald Alvestrand = wrote:
On 11/05/2011 04:14 PM, Marc = Petit-Huguenin wrote:
-----BEGIN PGP SIGNED = MESSAGE-----
Hash: = SHA1

On 11/05/2011 08:04 AM, Gonzalo = Salgueiro wrote:
On Nov = 5, 2011, at 10:30 AM, Eric Rescorla = wrote:

On Fri, Nov 4, 2011 at 5:18 PM, = Harald Alvestrand<harald@alvestrand.no
<mailto:harald@alvestrand.no>&g= t; =  wrote:
On = 11/04/2011 04:56 PM, Eric Rescorla = wrote:
I don't have any commitment to = the scheme. What's the best = place?
I like parameters, like = this:
=

turn://user@host?proto=3Dtcp
=

Quite = hard to misunderstand, and quite easy to = extend.

(Note: = // is only allowed if what follows is [user[:pass]@]host - I = don't
=
recommend using the password, for the obvious reasons, but = the syntax = will
<= blockquote type=3D"cite">
allow = it.)
<= blockquote type=3D"cite">
I don't see any security problem = with that. The "break = old
implementations" = rationale
doesn't apply when we are = defining a new URI = scheme.
I = agree with this as well.  If we can get some consensus with this, I = will
update = the next version of both the STUN and TURN URI Scheme drafts to = include
this = format.
Or you can look at = draft-petithuguenin-behave-turn-uri-bis, which is = already
doing it right (and had a lot of reviews back in 2008, = before I split the
resolution mechanism and the = syntax in two separate = documents).

I know my email address does not = contain the magical "cisco.com", but = this is
getting = ridiculous.

Sorry, some of = us were not on BEHAVE in 2008, and missed the previous = discussion.

This is not the problem.  The = problem is that the authors of the new draft
continue to ignore a = draft that is the result of BEHAVE, IESG, security,
gen-art, ops and = other directorate reviews.  (To be fair, two employees of = Cisco
I worked with in the past contacted me to see how to work on = this but none of
the authors of the draft = did).


I find it incredible = I need to explain anything about ignoring your draft when in our draft = it clearly states:
   We acknowledge the existence of
   draft-petithuguenin-behave-turn-uri-bis-04 document as a parallel
   effort in defining the URI scheme for TURN.  Awareness of this draft
   came late in the process and we have not had to time to reach out to
   the author of that memo and discuss opportunities to collaborate on a
   single document.  It is our intentions to do so.
The = discussion you had with Cullen and Dan are known to us but we were = pretty much finished both the STUN and TURN drafts by the time we found = out about your draft. At this point we were waiting for you and Cullen = to discuss the best way forward to meet the needs of WebRTC.  We = are happy to combine forces or yield entirely, based on that = discussion.

Regards,

Gon= zalo


- --
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Pro= fessional email: petithug@acm.org
Blog: http://blog.marc.petit-huguen= in.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 = (GNU/Linux)

iEYEARECAAYFAk62vMMACgkQ9RoMZyVa61fiSwCfZtnYxYBbxMmebzK= wkQa19Uus
7v4AoJiPr0aHYvKAoEUkwJNp7DyvpYVW
=3Dr7Po
-----END PGP = SIGNATURE-----


= --Apple-Mail-148-845957745-- From HKaplan@acmepacket.com Sun Nov 6 17:17:53 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A9F21F87C5 for ; Sun, 6 Nov 2011 17:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGY4NtS2TosJ for ; Sun, 6 Nov 2011 17:17:53 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4253121F877F for ; Sun, 6 Nov 2011 17:17:52 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 6 Nov 2011 20:17:51 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sun, 6 Nov 2011 20:17:51 -0500 From: Hadriel Kaplan To: =?iso-8859-1?Q?Jos=E9_Luis_Mill=E1n?= Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AQHMnOsQU1Ft+mkH70qnimGgVzJd/A== Date: Mon, 7 Nov 2011 01:17:50 +0000 Message-ID: References: <8A61D801-D14D-408B-9875-63C37D0CC166@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="iso-8859-1" Content-ID: <11504C381BEA7442AFEECC5F69DDB4E7@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 01:17:53 -0000 On Nov 6, 2011, at 4:16 AM, Jos=E9 Luis Mill=E1n wrote: > draft-ietf-rtcweb-overview-02 downgraded the SRTP concerns from > mandatory-to-use to mandatory-to-implement. So if it does not > downgrade anymore, a WebRTC implementation (game app, greeting cards > website..) will have to implement SRTP. Technically, no... a mandatory-to-implement means devices complying with We= bRTC RFCs (namely browsers) must implement support for it, but not have to = use it for every session. So a game app, greeting card, etc., web applicat= ion could choose not to use SRTP, just like it chooses to use HTTP rather t= han HTTPS. That's all I'm talking about: that difference of mandatory-to-i= mplement vs. mandatory-to-use requirement. =20 -hadriel From giles@thaumas.net Sun Nov 6 17:51:50 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B1421F85EF for ; Sun, 6 Nov 2011 17:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 VTgWDt1wTSc1 for ; Sun, 6 Nov 2011 17:51:49 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4599A21F85CE for ; Sun, 6 Nov 2011 17:51:49 -0800 (PST) Received: by vcbfl11 with SMTP id fl11so4061164vcb.31 for ; Sun, 06 Nov 2011 17:51:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.9.211 with SMTP id m19mr1796381vcm.46.1320630708691; Sun, 06 Nov 2011 17:51:48 -0800 (PST) Received: by 10.220.194.72 with HTTP; Sun, 6 Nov 2011 17:51:48 -0800 (PST) X-Originating-IP: [66.183.19.247] In-Reply-To: <36EE558D-548B-4280-A370-D809C7E522E5@lurchi.franken.de> References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> <4EB21DEF.5060606@jesup.org> <4EB29275.8000204@ericsson.com> <4EB2B61D.1010000@jesup.org> <36EE558D-548B-4280-A370-D809C7E522E5@lurchi.franken.de> Date: Sun, 6 Nov 2011 17:51:48 -0800 Message-ID: From: Ralph Giles To: =?UTF-8?Q?Michael_T=C3=BCxen?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 01:51:50 -0000 On 5 November 2011 14:10, Michael T=C3=BCxen wrote: > If you need large messages with message boundaries, it can be added to SC= TP. > It should be not too hard. Randy and myself will look into it... However, > to allow multiplexing with having more than one message being sent concur= rently, > a new chunk is necessary. I humbly suggest something derived from RFC 3533 if this turns out to be necessary. -r From HKaplan@acmepacket.com Sun Nov 6 19:08:35 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22531F0C34 for ; Sun, 6 Nov 2011 19:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, J_CHICKENPOX_75=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 L1UtujzS2vbU for ; Sun, 6 Nov 2011 19:08:35 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2733621F8468 for ; Sun, 6 Nov 2011 19:08:34 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 6 Nov 2011 22:08:33 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sun, 6 Nov 2011 22:08:24 -0500 From: Hadriel Kaplan To: Tim Panton Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AQHMnPqCU1Ft+mkH70qnimGgVzJd/A== Date: Mon, 7 Nov 2011 03:08:23 +0000 Message-ID: <6345B9D1-B9B5-4353-9198-A04E56F02003@acmepacket.com> References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> In-Reply-To: <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> 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="iso-8859-1" Content-ID: <0BA29B7FE792C14AB41C7433371E959C@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 03:08:36 -0000 Hey Tim, comments inline... On Nov 6, 2011, at 9:01 AM, Tim Panton wrote: > Almost all of the discussions here in the last few weeks are about intero= p with existing SIP=20 > deployments. ( forking,glare, SDP, RTP muxing) RTP muxing is actually not an existing SIP thing - it's new. SDP obviously= is an existing mechanism and used in SIP, but if we're going to have a hig= h-layer abstracted "API" anyway regardless of SIP interop, then at least SD= P is an already existing/defined protocol. Glare and forking could both be= handled with purely application coding (ie, javascript), so yeah those are= more of a conciliation for interop. > The bulk of the use-cases on which that effort is > based are also around interop with non-browser devices and channels, but = the charter > never mentions legacy interop. It only talks about browser-to-browser and= replacing the > myriad plugins. It also talks about being a platform for innovation, whic= h is now a > non-goal for the group. Actually, in the charter itself is a list of work the WG will perform, and = item 9 says this: The group will consider options for interworking with legacy VoIP equipment. I think the reason a lot of the email discussions have been focused on that= is that it's the most contentious area of issues to solve or make decision= s about. Obviously some folks also see a reasonable use-case for interwork= ing with legacy VoIP, but so long as non-inteworking/WebRTC-only use-cases = aren't impaired by supporting interworking, what's the harm? -hadriel From randell-ietf@jesup.org Sun Nov 6 19:14:46 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E1821F84AF for ; Sun, 6 Nov 2011 19:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_75=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 iGkvKdDy4gCS for ; Sun, 6 Nov 2011 19:14:45 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 89A6421F8486 for ; Sun, 6 Nov 2011 19:14:45 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RNFfY-0004Jw-R3 for rtcweb@ietf.org; Sun, 06 Nov 2011 21:14:44 -0600 Message-ID: <4EB74D06.8000006@jesup.org> Date: Sun, 06 Nov 2011 22:14:14 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> In-Reply-To: <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> 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] Let's define the purpose of 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, 07 Nov 2011 03:14:46 -0000 On 11/6/2011 9:01 AM, Tim Panton wrote: > Almost all of the discussions here in the last few weeks are about interop with existing SIP > deployments. ( forking,glare, SDP, RTP muxing) The bulk of the use-cases on which that effort is > based are also around interop with non-browser devices and channels, but the charter > never mentions legacy interop. It only talks about browser-to-browser and replacing the > myriad plugins. It also talks about being a platform for innovation, which is now a > non-goal for the group. I respectively disagree. While I (and others) have sat back and let a bunch of people argue over that, I assure you that interop has not been a major factor in my discussions with other stakeholders or a primary use-case for me. Has interop gotten discussion? Yes, partly due to many of the people arguing here, and partly due to some of those cases being tougher, or that interop exposes some tricky edge cases that may exist without interop as well. For example, you mention forking and glare. Well, I've given very non-interop cases of where forking would be useful: contacting someone who has 2 desktops, a notebook, a tablet, and a phone all logged into the service, or some of the game scenarios, or a very non-standard-SIP-like mesh conference using forked invites. And glare: Cullen's classic example of glare is two people talking, browser to browser, and one saying "lets add video", and both turning it on. No interop or SIP required for that to cause glare. And RTP muxing? That's to avoid the startup-delay of having to ICE multiple ports (and the funny side-effects if they choose different paths). Yes that does add some requirements to think about for interop; that's not subverting the charter or drifting from it. > Iñaki asked a question as to the purpose of WebRTC, so I quoted the charter. > As I re-read it, I found that we have drifted a _long_ way from those stated goals. > > On that basis, I say we have to re-evaluate something - either the charter or what we > now have. They are (to my mind) incompatible. > > As a concrete example - (there are _many_ but to name a current example) - we seem to be > on the point of dropping the SRTP requirement in order to ease interop with legacy devices. > How that squares with the charter - or indeed the ITEF's security stance I have no clue. People have discussed cases where SRTP either doesn't really add to the user's security, and if you are interfacing to the PSTN, being forced through a media gateway might be merely a HW/$ cost to the service, or it might also be a major degrader of the call quality, of the media gateway isn't close to either the PSTN gateway or the caller. These are arguable cases, but for the time being, a number of use-cases and possible applications would want to have the option of talking to a PSTN gateway, even if that's not the primary use. That makes it worth exploring to see if it's possible while retaining other requirements, and not opening the user to bid-down attacks, etc. Thus far, we don't have a great solution or perhaps even a usable one. For browser-to-browser (webrtc-to-webrtc really), there's much less (if any) reason to avoid SRTP. As for SDES... I don't consider SDES to be secure, especially not in our threat model. The app has access to the keys, and we don't trust the app. It's more secure than no encryption, and it may be better at interop, but that's it. I think I'd oppose SDES use for anything except interop cases. -- Randell Jesup randell-ietf@jesup.org From HKaplan@acmepacket.com Sun Nov 6 19:20:29 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5463C21F86AA for ; Sun, 6 Nov 2011 19:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 Rsb44aqE7iBE for ; Sun, 6 Nov 2011 19:20:28 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id BBB7521F86A4 for ; Sun, 6 Nov 2011 19:20:28 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 6 Nov 2011 22:20:27 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sun, 6 Nov 2011 22:20:27 -0500 From: Hadriel Kaplan To: Eric Rescorla Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AQHMnPwxU1Ft+mkH70qnimGgVzJd/A== Date: Mon, 7 Nov 2011 03:20:26 +0000 Message-ID: References: <8A61D801-D14D-408B-9875-63C37D0CC166@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="iso-8859-1" Content-ID: <69346F65B66F26449572F95898B42F71@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 03:20:29 -0000 On Nov 6, 2011, at 9:38 AM, Eric Rescorla wrote: > Hmm... I I don't see any > reason to allow insecure calling from one WebRTC client to another. > It's a different question whether one should allow insecure calling > to legacy clients. Agreed. >> IMHO, if a web service doesn't want to take, or cannot take, the hit >> for SRTP, WebRTC is not the appropriate solution for such a service. >=20 > I'm exceedingly unsympathetic to the claim that SRTP is too slow. This > is precisely the claim that was made about TLS for years, but measurement= s > (see Langley and Modadugu's Overclocking SSL talk at Velocity) show > that that's not really true. Who said "too slow"? There *is* an extra round-trip or two involved I pres= ume, if we're talking DTLS-SRTP, but no I didn't mean that as a "hit". I j= ust meant the extra computing cycles for SRTP being a "hit". For WebRTC-to= -WebRTC I don't think that matters at all. For WebRTC-to-media-server it m= ight, for a free game app or greeting card app that don't care about it to = begin with, and which use plaintext HTTP to begin with. (this isn't a big deal regardless - just something to think about whether w= e care or not) -hadriel From roman@telurix.com Sun Nov 6 19:36:26 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD4121F8469 for ; Sun, 6 Nov 2011 19:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=0.083, 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 Ww+SH3CaV6YK for ; Sun, 6 Nov 2011 19:36:26 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC6F421F842A for ; Sun, 6 Nov 2011 19:36:25 -0800 (PST) Received: by iaeo4 with SMTP id o4so6844737iae.31 for ; Sun, 06 Nov 2011 19:36:23 -0800 (PST) Received: by 10.42.117.193 with SMTP id u1mr43356012icq.24.1320636983298; Sun, 06 Nov 2011 19:36:23 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id g16sm36168609ibs.8.2011.11.06.19.36.21 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Nov 2011 19:36:22 -0800 (PST) Received: by iaeo4 with SMTP id o4so6844705iae.31 for ; Sun, 06 Nov 2011 19:36:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.43.65.79 with SMTP id xl15mr42600809icb.6.1320636981247; Sun, 06 Nov 2011 19:36:21 -0800 (PST) Received: by 10.68.62.170 with HTTP; Sun, 6 Nov 2011 19:36:20 -0800 (PST) In-Reply-To: References: Date: Sun, 6 Nov 2011 22:36:20 -0500 Message-ID: From: Roman Shpount To: Cameron Byrne Content-Type: multipart/alternative; boundary=bcaec51b1c8f24ff9704b11cc2a8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 03:36:26 -0000 --bcaec51b1c8f24ff9704b11cc2a8 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Nov 5, 2011 at 11:28 AM, Cameron Byrne wrote: > I think you can set crypto in srtp to null as well for troubleshooting > > Would not that be the same as supporting RTP? _____________ Roman Shpount --bcaec51b1c8f24ff9704b11cc2a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Nov 5, 2011 at 11:28 A= M, Cameron Byrne <cb.list6@gmail.com> wrote:
I think you can set crypto in srtp to null as well for trou= bleshooting


Would not that be the same as s= upporting RTP?
_____________
Roman Shpount


--bcaec51b1c8f24ff9704b11cc2a8-- From roman@telurix.com Sun Nov 6 19:58:49 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A6A1F0C35 for ; Sun, 6 Nov 2011 19:58:49 -0800 (PST) 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.220, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_75=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 gbDArltRhChs for ; Sun, 6 Nov 2011 19:58:49 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD601F0C34 for ; Sun, 6 Nov 2011 19:58:49 -0800 (PST) Received: by iaeo4 with SMTP id o4so6865182iae.31 for ; Sun, 06 Nov 2011 19:58:48 -0800 (PST) Received: by 10.42.135.69 with SMTP id o5mr43342650ict.34.1320638328739; Sun, 06 Nov 2011 19:58:48 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id jm11sm36290628ibb.1.2011.11.06.19.58.47 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 06 Nov 2011 19:58:47 -0800 (PST) Received: by iaeo4 with SMTP id o4so6865141iae.31 for ; Sun, 06 Nov 2011 19:58:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.62.212 with SMTP id y20mr2159131ibh.11.1320638326787; Sun, 06 Nov 2011 19:58:46 -0800 (PST) Received: by 10.68.62.170 with HTTP; Sun, 6 Nov 2011 19:58:46 -0800 (PST) In-Reply-To: <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> Date: Sun, 6 Nov 2011 22:58:46 -0500 Message-ID: From: Roman Shpount To: Tim Panton Content-Type: multipart/alternative; boundary=000e0cd4b3f0584f9204b11d1266 Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 03:58:49 -0000 --000e0cd4b3f0584f9204b11d1266 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Nov 6, 2011 at 9:01 AM, Tim Panton wrote: > Almost all of the discussions here in the last few weeks are about interop > with existing SIP > deployments. ( forking,glare, SDP, RTP muxing) The bulk of the use-cases > on which that effort is > based are also around interop with non-browser devices and channels, but > the charter > never mentions legacy interop. It only talks about browser-to-browser and > replacing the > myriad plugins. It also talks about being a platform for innovation, which > is now a > non-goal for the group. > > First of all, this is not about interop. We have a fairly significant experience regarding real-time communications, but for many reasons most of this experience is related to SIP. Based on this, experience we know that there are issues, such as glare, media forking, media negotiation, support of future codecs, that need to be addressed. If we are asking about scenarios which have not been relevant to your particular "innovative" application, it does not mean that other users of WebRTC will not encounter it. This is all about creating the best possible future proof system we can. Second, the reason I raised my comment about SRTP was exactly in order to support future applications that we are not aware about now. I do not see a why we should mandate something without a good reason. The more control we will give to developer, the more applications it would be possible to build. I would strongly support required to implement, but not required to use model for SRTP. This way SRTP is available to the application developer but not something they must use. There are places where communications are illegal, unless they can be intercepted by the "big brother". Things like Skype are illegal there for this exact reason. I would not argue if this situation is appropriate, legal, or moral, but it exists. It would be better that WebRTC would be able to operate in environments like this. _____________ Roman Shpount --000e0cd4b3f0584f9204b11d1266 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Nov 6, 2011 at 9:01 AM= , Tim Panton <tim@phonefromhere.com> wrote:
Almost all of the discussions here in the= last few weeks are about interop with existing SIP
deployments. ( forking,glare, SDP, RTP muxing) The bulk of the use-cases on= which that effort is
based are also around interop with non-browser devices and channels, but th= e charter
never mentions legacy interop. It only talks about browser-to-browser and r= eplacing the
myriad plugins. It also talks about being a platform for innovation, which = is now a
non-goal for the group.


First of all, this is not about interop. We have= a fairly significant experience regarding real-time communications, but fo= r many reasons most of this experience is related to SIP. Based on this, ex= perience we know that there are issues, such as glare, media forking, media= negotiation, support of future codecs, that need to be addressed. If we ar= e asking about scenarios which have not been relevant to your particular &q= uot;innovative" application, it does not mean that other users of WebR= TC will not encounter it. This is all about creating the best possible futu= re proof system we can.

Second, the reason I raised my comment about SRTP was exactly in order = to support future applications that we are not aware about now. I do not se= e a why we should mandate something without a good reason. The more control= we will give to developer, the more applications it would be possible to b= uild. I would strongly support required to implement, but not required to u= se model for SRTP. This way SRTP is available to the application developer = but not something they must use. There are places where communications are = illegal, unless they can be intercepted by the "big brother". Thi= ngs like Skype are illegal there for this exact reason. I would not argue i= f this situation is appropriate, legal, or moral, but it exists. It would b= e better that WebRTC would be able to operate in environments like this. _____________
Roman Shpount

--000e0cd4b3f0584f9204b11d1266-- From john.r.elwell@gmail.com Mon Nov 7 00:18:02 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B1421F8549 for ; Mon, 7 Nov 2011 00:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.112 X-Spam-Level: X-Spam-Status: No, score=-3.112 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, J_CHICKENPOX_75=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 uUcfi0rKLyQE for ; Mon, 7 Nov 2011 00:18:01 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D7F0A21F84FD for ; Mon, 7 Nov 2011 00:17:55 -0800 (PST) Received: by wwi36 with SMTP id 36so4502618wwi.13 for ; Mon, 07 Nov 2011 00:17:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=Ftr51KCd3kF9ftT6dEtHNGAOD6Z4EWulhD1IMO7Bewg=; b=J1jaaQdfmMQkZKhaocNMLtYxpiQUAXk8bTZc4oCCJBbnn7ifUqBEfiR8J3SIrVBiP1 b7bhTx2h6/Or7IgSp4icPMcPIUW+7YV71yPYvlgTeX6WCQeD6INtdeKsI2V8sLTH5aH4 2gUOoaQvo8/VLDBb4c89keGeEKFZQTnk1bnTM= Received: by 10.216.133.217 with SMTP id q67mr5415766wei.97.1320653875020; Mon, 07 Nov 2011 00:17:55 -0800 (PST) Received: from JohnsComputer (cpc1-clif8-2-0-cust418.12-4.cable.virginmedia.com. [82.25.209.163]) by mx.google.com with ESMTPS id e7sm26856110wbh.12.2011.11.07.00.17.52 (version=SSLv3 cipher=OTHER); Mon, 07 Nov 2011 00:17:53 -0800 (PST) Message-ID: <58695803872B406A995EF1AA08CAAB40@JohnsComputer> From: "John Elwell" To: "Randell Jesup" , References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com><9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net><7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <4EB74D06.8000006@jesup.org> Date: Mon, 7 Nov 2011 08:17:51 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 08:18:02 -0000 Concerning SDES, I agree its security is poor. Essentially it is a hop-by-hop model, because any intermediary with access to the signalling has access to the keys, and with the help of a media gateway can trans-key or map to RTP. There are so many things one might need to do to interwork with legacy (demux, terminate ICE, terminate DTLS-SRTP, even transcode possibly). All can be done with a media gateway. Trying to avoid this for particular situations (e.g., finding a way of using RTP or SRTP/SDES) will not necessarily eliminate the need for a media gateway for other functions in those situations and will certainly not avoid the need for a media gateway in all situations. Wouldn't it be better to stick to a simple approach for WEB-RTC (minimal options) and say that if you want to interoperate with anything else you just have to use a media gateway? Applications that need to interoperate can choose whether they use WEB-RTC and take the hit, or instead can choose some other technology (such as plug-ins). In some ways this would be fairer. Also it is probably the only way of getting WEB-RTC completed in a reasonable time. John ----- Original Message ----- From: "Randell Jesup" To: Sent: Monday, November 07, 2011 3:14 AM Subject: Re: [rtcweb] Let's define the purpose of WebRTC On 11/6/2011 9:01 AM, Tim Panton wrote: > Almost all of the discussions here in the last few weeks are about interop > with existing SIP > deployments. ( forking,glare, SDP, RTP muxing) The bulk of the use-cases > on which that effort is > based are also around interop with non-browser devices and channels, but > the charter > never mentions legacy interop. It only talks about browser-to-browser and > replacing the > myriad plugins. It also talks about being a platform for innovation, which > is now a > non-goal for the group. I respectively disagree. While I (and others) have sat back and let a bunch of people argue over that, I assure you that interop has not been a major factor in my discussions with other stakeholders or a primary use-case for me. Has interop gotten discussion? Yes, partly due to many of the people arguing here, and partly due to some of those cases being tougher, or that interop exposes some tricky edge cases that may exist without interop as well. For example, you mention forking and glare. Well, I've given very non-interop cases of where forking would be useful: contacting someone who has 2 desktops, a notebook, a tablet, and a phone all logged into the service, or some of the game scenarios, or a very non-standard-SIP-like mesh conference using forked invites. And glare: Cullen's classic example of glare is two people talking, browser to browser, and one saying "lets add video", and both turning it on. No interop or SIP required for that to cause glare. And RTP muxing? That's to avoid the startup-delay of having to ICE multiple ports (and the funny side-effects if they choose different paths). Yes that does add some requirements to think about for interop; that's not subverting the charter or drifting from it. > Iñaki asked a question as to the purpose of WebRTC, so I quoted the > charter. > As I re-read it, I found that we have drifted a _long_ way from those > stated goals. > > On that basis, I say we have to re-evaluate something - either the charter > or what we > now have. They are (to my mind) incompatible. > > As a concrete example - (there are _many_ but to name a current example) - > we seem to be > on the point of dropping the SRTP requirement in order to ease interop > with legacy devices. > How that squares with the charter - or indeed the ITEF's security stance I > have no clue. People have discussed cases where SRTP either doesn't really add to the user's security, and if you are interfacing to the PSTN, being forced through a media gateway might be merely a HW/$ cost to the service, or it might also be a major degrader of the call quality, of the media gateway isn't close to either the PSTN gateway or the caller. These are arguable cases, but for the time being, a number of use-cases and possible applications would want to have the option of talking to a PSTN gateway, even if that's not the primary use. That makes it worth exploring to see if it's possible while retaining other requirements, and not opening the user to bid-down attacks, etc. Thus far, we don't have a great solution or perhaps even a usable one. For browser-to-browser (webrtc-to-webrtc really), there's much less (if any) reason to avoid SRTP. As for SDES... I don't consider SDES to be secure, especially not in our threat model. The app has access to the keys, and we don't trust the app. It's more secure than no encryption, and it may be better at interop, but that's it. I think I'd oppose SDES use for anything except interop cases. -- Randell Jesup randell-ietf@jesup.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Mon Nov 7 00:51:16 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB06421F8545 for ; Mon, 7 Nov 2011 00:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.568 X-Spam-Level: X-Spam-Status: No, score=-110.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yooFbFPvfjtj for ; Mon, 7 Nov 2011 00:51:16 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3897421F8538 for ; Mon, 7 Nov 2011 00:51:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 174F539E119; Mon, 7 Nov 2011 09:51:14 +0100 (CET) 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 pk0jlbmVcgl2; Mon, 7 Nov 2011 09:51:13 +0100 (CET) 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 ESMTPS id 7370A39E112; Mon, 7 Nov 2011 09:51:13 +0100 (CET) Message-ID: <4EB79C01.9020609@alvestrand.no> Date: Mon, 07 Nov 2011 09:51:13 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Roman Shpount References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070404060901000706060100" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 08:51:17 -0000 This is a multi-part message in MIME format. --------------070404060901000706060100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/07/2011 04:36 AM, Roman Shpount wrote: > > On Sat, Nov 5, 2011 at 11:28 AM, Cameron Byrne > wrote: > > I think you can set crypto in srtp to null as well for troubleshooting > > > Would not that be the same as supporting RTP? I don't think so - SRTP with null encryption would still be able to deliver integrity protection. That said, in our deployment of the SRTP-based Google Talk Video and Hangouts services, I don't think we've ever had a critical debugging scenario where the lack of null crypto was a blocker. (we don't support null crypto). --------------070404060901000706060100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/07/2011 04:36 AM, Roman Shpount wrote:

On Sat, Nov 5, 2011 at 11:28 AM, Cameron Byrne <cb.list6@gmail.com> wrote:
I think you can set crypto in srtp to null as well for troubleshooting


Would not that be the same as supporting RTP?

I don't think so - SRTP with null encryption would still be able to deliver integrity protection.

That said, in our deployment of the SRTP-based Google Talk Video and Hangouts services, I don't think we've ever had a critical debugging scenario where the lack of null crypto was a blocker.
(we don't support null crypto).


--------------070404060901000706060100-- From harald@alvestrand.no Mon Nov 7 01:01:51 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6654421F84F5 for ; Mon, 7 Nov 2011 01:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.57 X-Spam-Level: X-Spam-Status: No, score=-110.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 M4vaqa4lRVyt for ; Mon, 7 Nov 2011 01:01:51 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CD07421F844E for ; Mon, 7 Nov 2011 01:01:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1E03E39E119; Mon, 7 Nov 2011 10:01:50 +0100 (CET) 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 h7oU834tEFmb; Mon, 7 Nov 2011 10:01:49 +0100 (CET) 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 ESMTPS id D647039E112; Mon, 7 Nov 2011 10:01:48 +0100 (CET) Message-ID: <4EB79E7C.9070708@alvestrand.no> Date: Mon, 07 Nov 2011 10:01:48 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <20111024224257.28459.65554.idtracker@ietfa.amsl.com><6EB8679A-13D5-4AD7-97F2-BC35FC0966F0@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF51159C32@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51159D7A@sonusinmail02.sonusnet.com> <4EAAF413.8030501@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF51159D7B@sonusinmail02.sonusnet.com> <247FFE2C-DB2C-4280-A219-BE1503662F92@acmepacket.com> <387F9047F55E8C42850AD6B3A7A03C6CB953@inba-mail01.sonusnet.com> <4EAEC609.1040707@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6CD0B4@inba-mail01.sonusnet.com> <4EB26EE5.40703@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6CD31E@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6CD31E@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [rtcweb] New usecase & requirement for media forking in browser X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Nov 2011 09:01:51 -0000 On 11/03/2011 12:56 PM, Ravindran Parthasarathi wrote: > Harald, > > Please read inline. > > Thanks > Partha >>> 2) Remote Recording: The call is forked towards remote peer as well as >> recording server. This usecase is already covered in usecase document >> Again, this does not need forking. The client creating 2 connections is >> the one deciding to do so. > I'll take this usecase because it is very common usecase. Client (browser) is not required to create two connection in this scenario if recording request is going as metadata and WebRTC Server forks the request to remote peer and recorder. Please note that client is not required to know the recorder destination till get the answer. Partha, thanks for the details. What do you base your assertion that this is a "very common usecase" on? (In previous discussions on recording, when people argued for a solution with media relaying in the client, people have variously argued that this should not be supported at all.) In the scenario you sketch, the recording device will also fail to capture media from the destination, so I assume that the scenario you suggest is just part of the scenaroi. From harald@alvestrand.no Mon Nov 7 01:07:16 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D08221F858C for ; Mon, 7 Nov 2011 01:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.422 X-Spam-Level: X-Spam-Status: No, score=-110.422 tagged_above=-999 required=5 tests=[AWL=-0.123, 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 8E+Bwf9Ps+fi for ; Mon, 7 Nov 2011 01:07:16 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 03E8321F8514 for ; Mon, 7 Nov 2011 01:07:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 44CA039E119; Mon, 7 Nov 2011 10:07:15 +0100 (CET) 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 5rcVUTMOfpIm; Mon, 7 Nov 2011 10:07:14 +0100 (CET) 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 ESMTPS id C74C839E112; Mon, 7 Nov 2011 10:07:14 +0100 (CET) Message-ID: <4EB79FC2.10400@alvestrand.no> Date: Mon, 07 Nov 2011 10:07:14 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: [rtcweb] SRTP - mandatory to implement vs mandatory to use (Re: Let's define the purpose of 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, 07 Nov 2011 09:07:16 -0000 On 11/06/2011 10:16 AM, José Luis Millán wrote: > draft-ietf-rtcweb-overview-02 downgraded the SRTP concerns from > mandatory-to-use to mandatory-to-implement. So if it does not > downgrade anymore, a WebRTC implementation (game app, greeting cards > website..) will have to implement SRTP. > > IMHO, if a web service doesn't want to take, or cannot take, the hit > for SRTP, WebRTC is not the appropriate solution for such a service. > Forking this thread, since it's actually about a line in the documents.... in draft-ietf-rtcweb-overview-02, I changed this section: 5. Data framing and securing SRTP [RFC3550] is used for transport of all real-time media. The detailed considerations for usage of functions from RTP and SRTP, as well as for non-media real-time data, are given in . into this section: 5. Data framing and securing The format for media transport is RTP [RFC3550]. Implementation of SRTP [RFC3711] is required for all implementations. The detailed considerations for usage of functions from RTP and SRTP are given in [I-D.ietf-rtcweb-rtp-usage]. Key negotiation for SRTP is described in . Transfer of data that is not in RTP format is described in . At the moment, draft-ietf-rtcweb-rtp-usage does not contain any requirement on SRTP usage (the security section says "A mandatory to implement media security solution will be required to be picked", which I think is a bit weak), and the discussion at the time did not seem to indicate consensus that SRTP must be used always, so I decided to document what we seemed to have consensus on - that SRTP MUST be implemented. If we have consensus to make it stronger again, I'm happy to change it back. Harald From magnus.westerlund@ericsson.com Mon Nov 7 02:18:00 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEC521F8AC9; Mon, 7 Nov 2011 02:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.967 X-Spam-Level: X-Spam-Status: No, score=-105.967 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_28=0.6, 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 lFY-W1lHchme; Mon, 7 Nov 2011 02:17:59 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C241E21F8AD1; Mon, 7 Nov 2011 02:17:58 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-c3-4eb7b055fe63 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8F.0A.13753.550B7BE4; Mon, 7 Nov 2011 11:17:57 +0100 (CET) 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.137.0; Mon, 7 Nov 2011 11:17:57 +0100 Message-ID: <4EB7B054.3000706@ericsson.com> Date: Mon, 7 Nov 2011 11:17:56 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" , IETF AVTCore WG , Jonathan Lennox , Jonathan Rosenberg X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Comments on draft-lennox-rtcweb-rtp-media-type-mux-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: IETF AVTCore WG List-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, 07 Nov 2011 10:18:00 -0000 Hi, (as individual) I have reviewed draft-lennox-rtcweb-rtp-media-type-mux-00 and have some comments. I think this document is most appropriately discussed in AVTCORE as it concerns RTP details. Therefore both lists are cc:ed and reply-to set to AVTCORE WG mailing list. So if you are on RTCWEB and would like to follow this discussion, please follow the AVTCORE mailing list also (avt@ietf.org). 1. I think the biggest issue with multiple media type in a single RTP session isn't discussed. I think it is very important that this issue is brought up as it has to do with the applicability of this solution. To start the discussion on this issue I think a quote from section 4.3 of draft-westerlund-avtcore-transport-multiplexing-01 is appropriate: Many transition scenarios use an RTP translator as a gateway between a single RTP session containing multiple media types multiplexed together, and several separate RTP sessions each using a single media type. In this scenario, it is possible that a legacy device that uses one RTP session for each media type will use the same SSRC in each session. When translating these into a single RTP session, it will be necessary to rewrite one of the SSRCs, so that each stream has a unique SSRC. This SSRC translation process is straight-forward for RTP packets, but is very complex for RTCP packets. It also hinders innovation, since such a gateway will not be able to translate new RTCP extensions that it is unaware of, even if they are supported by devices on both sides of the gateway. The issue is that in any case where you have a desire to mix end-points supporting this and where some don't you create a situation where you will either get malfunctioning translators or translators that likely are a barrier for deploying new RTP/RTCP extensions. Even in WebRTC contexts the case combing the single session and multiple sessions are likely to occur. One case is media plane gateways to legacy that will negotiate the multiplexing between the WebRTC end-point and the gateway and then attempt to perform basic splitting to two RTP sessions on the legacy side based on the payload formats. Another scenario is the centralized conferences where the RTP mixer or translator can negotiate individual behavior to each end-point. Thus one might start out fine with all being single session compliant. Then someone joins who is not and the result is that one is in a situation that either requires renegotiation (including NAT traversal) for the already connected end-points or to do a translator. I am certain that translator is going to be the approach rather than interrupting the ongoing media streams. So yes this would not be an issue if everyone supported it. But it is clear that the world will be one of incremental deployment. So I am quite worried on the future impact using a single RTP session creates. I think RTCWEB needs to seriously consider if this really is the right way to go or if another solution would be better. 2. Section 7.2.9 of draft-westerlund-avtcore-multiplex-architecture-00 discusses a number of aspects of this type of multiplexing. I think the document covers most in a reasonable fashion. The ones that seems to be missing are; A) the number space limitation of the PT field. The 128 values should after all cover all the RTP payload configurations one like to use/offer + the RTCP payload type overlap due to RTP/RTCP multiplexing. So the fact that the real limitations in RTP payload types are in fact that all media types need to share in 96+ available payload type values rather than 128 per each media type. B) I think the bit-rate issues could be improved but it is present. C) Decomposited end-points are missing. This is not a big issue, only a down side with this that increases the bit-rate to the actual functional end-points and require them to have handling of the multiple media types. So this is a limitation if one attempt to use this in a Telepresence scenario with dedicated hardware, not an issue in a browser context. 3. Section 3: For sessions using the RTP/AVPF [RFC4585] and RTP/SAVPF [RFC5124] profiles, however, endpoints SHOULD set the minimum RTCP regular reporting interval trr-int to 5000 (5 seconds), unless they explicitly need it to be lower. This minimizes the excessive RTCP bandwidth consumption, as well as aiding compatibility with AVP endpoints. Since this value only affects regular RTCP reports, not RTCP feedback, this does not prevent AVPF feedback messages from being sent as needed. When AVP compatibility is the goal, I think 5 seconds is mostly ok. The regular RTCP suppression algorithm has a bit of strange behavior in cases where the Td value becomes similar to the T_rr_interval. That as the scheduled transmission time of an regular RTCP packet might close to the randomized value of the T_rr_interval but still smaller, that can in worst case result in that the AVPF RTCP sender sends RTCP some cases with close 2*T_rr_interval but no more often than 0.5*T_rr_interval. Thus the median of the distribution gets skewed towards higher value than T_rr_interval. I will send a separate email about this as it requires a bit of graphs and more in detail discussion. 4. Section 3.1: "An endpoint MAY choose to send multiple sources' RTCP messages in a single compound RTCP packet (though such compound packets SHOULD NOT exceed the path MTU, if avoidable and if it is known)." I think this recommendation is appropriate but I think should likely become a general recommendation for RTCP. However, that clearly requires some feedback if it will fail with some implementations. And if it does, I think that signalling support may be necessary. If that is the case, this optimization can't be used when working in the separate RTP session mode in WEBRTC, thus causing a situation where WebRTC end-points needs to have a run-time switch to control if this is used or not. 5. Section 3.1: Regular (non- feedback) RTCP compound packets MUST still begin with an SR or RR packet, but otherwise may contain RTCP packets in any order. Receivers MUST be prepared to receive such compound packets. I think this needs to make clear that for each SSRC include, both SR/RR and the corresponding SDES CNAME items MUST be included. 6. Section 3.1: "An endpoint SHOULD NOT send reception reports from one of its own sources about another one ("cross-reports")." This topic should also likely be discussed if it should be a general clarifications to RFC3550. That includes how one determines what is the considered the same end-point and what implications it provides. Is it based on all SSRCs with the same CNAME in an end-point SHOULD NOT send report blocks from more than one? I do note that all SSRC still needs to send an SR or an RR(possibly empty) just to announce there presence in the RTP session. 7. Section 3.1: Similarly, an endpoint sending multiple sources SHOULD NOT send reception reports about a remote source from more than one of its local sources. The same comments as for 6) applies to this. 8. Section 4: The more difficult case is if an offerer cannot reply on its potential peers supporting any features beyond baseline RTP (i.e., neither ICE nor multiplexing). I don't think this becomes a real issue if one assumes the offer following the signalling as defined by https://datatracker.ietf.org/doc/draft-holmberg-mmusic-sdp-bundle-negotiation/ 9. Section 5: So we do now have two proposals on the table for how to signal this. One in https://datatracker.ietf.org/doc/draft-holmberg-mmusic-sdp-bundle-negotiation/ (BUNDLE) and one in this document (Lennox). A comparison is quite interesting. BUNDLE will have very straightforward back-wards compatibility as that can happen in the single offer/answer exchange. However, there exist no way of forcing the usage of BUNDLE. Lennox requires a new Offer if the peer doesn't support this. In addition it creates a SDP media type that isn't supposed to be used with MIME. That is likely going to be an interesting to execute. It does allow for mandating support and refusing to establish a session not compliant. In addition it reduces the risk of confusion around payload types as they are only listed on a single media description. I personally prefer the BUNDLE approach. 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 Mon Nov 7 02:59:45 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6DA21F8A6F for ; Mon, 7 Nov 2011 02:59:45 -0800 (PST) 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 ZUbMEHqYkxgp for ; Mon, 7 Nov 2011 02:59:45 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 530D621F86C3 for ; Mon, 7 Nov 2011 02:59:45 -0800 (PST) Received: by vcbfl11 with SMTP id fl11so4300123vcb.31 for ; Mon, 07 Nov 2011 02:59:44 -0800 (PST) Received: by 10.220.205.198 with SMTP id fr6mr1941645vcb.138.1320663584814; Mon, 07 Nov 2011 02:59:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Mon, 7 Nov 2011 02:59:23 -0800 (PST) In-Reply-To: <4EB74D06.8000006@jesup.org> References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <4EB74D06.8000006@jesup.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 7 Nov 2011 11:59:23 +0100 Message-ID: To: Randell Jesup Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 10:59:46 -0000 2011/11/7 Randell Jesup : > =C2=A0I think I'd oppose SDES use for anything except interop cases. What you say means that the web browser MUST accept SDES always, since it won't know when it is interoperating with a non WebRTC client. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Mon Nov 7 04:11:46 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2494721F8508 for ; Mon, 7 Nov 2011 04:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.255 X-Spam-Level: X-Spam-Status: No, score=-110.255 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, J_CHICKENPOX_57=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 V6qqkfVG7xf9 for ; Mon, 7 Nov 2011 04:11:41 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0027B21F84D8 for ; Mon, 7 Nov 2011 04:11:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 35A3139E119; Mon, 7 Nov 2011 13:11:40 +0100 (CET) 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 svaNHCSpTXCU; Mon, 7 Nov 2011 13:11:39 +0100 (CET) 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 ESMTPS id 9F03239E112; Mon, 7 Nov 2011 13:11:39 +0100 (CET) Message-ID: <4EB7CAFB.3070707@alvestrand.no> Date: Mon, 07 Nov 2011 13:11:39 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: "rtcweb@ietf.org" , Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] ROAP minor bug: Retransmitted non-initial OFFER X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 12:11:46 -0000 Hello, I think this is a nit, but worth completing. during review of ROAP, I spotted this one: 5.3.1.2. Answerer Behavior A answerer can receive an OFFER in three cases: o A new session (this is detected by seeing a new offererSessionId value); o A retransmit of a new OFFER (known offererSessionId, empty answererSessionId); or o A request to change media parameters (known offererSessionId, known answererSessionId, new seq value). The first two situations are described in this section. The third case is described in Section 5.4. Any other condition represents an alien packet and SHOULD be rejected with Error:NOMATCH I think this is incomplete; if a non-initial OFFER is retransmitted, it will have a known offererSessionId, a known answererSessionId, and an old seq value. I think the correct response to such an OFFER is the same response as to the 2nd bullet: to retransmit the previously sent answer (which will either be ANSWER or ERROR), and not change any internal state. This seems to be the meaning of the last paragraph of the section: If an OFFER is received that has already been received and responded to and the media session still exists, then the answerer MUST respond with the same message as before. If the session has been terminated in the meantime, then an Error:NOMATCH message SHOULD be sent. but it was a bit hard to parse this - this "if" isn't the inverse of "If no media session exists with the given "offererSessionId" value", so it's not 100% clear if it's possible to arrive at the end with both paragraphs being false (media session exists, but this isn't an OFFER that has been responded to). A somewhat more rigorous structure might be a Good Thing. Harald From wolfgang.beck01@googlemail.com Mon Nov 7 04:20:04 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED36B21F8B5D for ; Mon, 7 Nov 2011 04:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 57QY73Iiy9ct for ; Mon, 7 Nov 2011 04:20:04 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0905621F8B5C for ; Mon, 7 Nov 2011 04:20:03 -0800 (PST) Received: by iaeo4 with SMTP id o4so7379355iae.31 for ; Mon, 07 Nov 2011 04:20:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tgvR8bnBQwasxkioNl4OMLqesfTg630JgSenAHOBbeE=; b=Oq/2xHqD+1k5wl/1hT1pCY/kNlXZ/RFKzUP1yExaI1YgV70zBXDQaC4ZgwC+uLi5tK IRtJIEGWFp/mf+LeMYm/KOQSR657biTAwQvZH7Ldg9Z76IPyCaNmGjjyY9rLaNbM/ck8 CB5qhvAz1S/hYaOPqqb2n8xuZsQfnZxe4S8EQ= MIME-Version: 1.0 Received: by 10.42.135.69 with SMTP id o5mr47432066ict.34.1320668403699; Mon, 07 Nov 2011 04:20:03 -0800 (PST) Received: by 10.68.64.66 with HTTP; Mon, 7 Nov 2011 04:20:03 -0800 (PST) In-Reply-To: <4EB74D06.8000006@jesup.org> References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <4EB74D06.8000006@jesup.org> Date: Mon, 7 Nov 2011 13:20:03 +0100 Message-ID: From: Wolfgang Beck To: Randell Jesup Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 12:20:05 -0000 On Mon, Nov 7, 2011 at 4:14 AM, Randell Jesup wrot= e: > On 11/6/2011 9:01 AM, Tim Panton wrote: >> [..] > > For example, you mention forking and glare. =A0Well, I've given very > non-interop cases of where forking would be useful: contacting someone wh= o > has 2 desktops, a notebook, a tablet, and a phone all logged into the > service, or some of the game scenarios, or a very non-standard-SIP-like m= esh > conference using forked invites. Do you really need forking to achieve this? Couldn't you just return references to those devices back to the caller which can then decide how to call them? A redirect server instead of a forking proxy? Forking is a good example how interop -- with SIP or with different RTCWEB apps -- complicates things significantly. > And glare: Cullen's classic example of glare is two people talking, brows= er to browser, and one saying "lets add > video", and both turning it on. =A0No interop or SIP required for that to > cause glare. If your service requires this function, yes, you're right. It has nothing to do with SIP and interop. The question is: does a JS client have to deal with glare handling if it can exclude conflicting offers by other means. My 'click here to speak to a human' application might never need this at all. > And RTP muxing? That's to avoid the startup-delay of having to > ICE multiple ports (and the funny side-effects if they choose different > paths). =A0Yes that does add some requirements to think about for interop= ; > that's not subverting the charter or drifting from it. > RTP muxing has little to with RTCWEB. If it is a good thing, SIP and other protocols using RTP/ICE should profit from it, too. Wolfgang Beck From stefan.lk.hakansson@ericsson.com Mon Nov 7 04:39:37 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45AB21F8B5E for ; Mon, 7 Nov 2011 04:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79ZKNgqOPTQl for ; Mon, 7 Nov 2011 04:39:37 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7770F21F8B37 for ; Mon, 7 Nov 2011 04:39:32 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-68-4eb7d183c69e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6B.CF.13753.381D7BE4; Mon, 7 Nov 2011 13:39:31 +0100 (CET) Received: from [150.132.142.220] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 7 Nov 2011 13:39:31 +0100 Message-ID: <4EB7D17D.8080307@ericsson.com> Date: Mon, 7 Nov 2011 13:39:25 +0100 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <4EB74D06.8000006@jesup.org> In-Reply-To: <4EB74D06.8000006@jesup.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 12:39:38 -0000 On 11/07/2011 04:14 AM, Randell Jesup wrote: .... > And glare: > Cullen's classic example of glare is two people talking, browser to > browser, and one saying "lets add video", and both turning it on. No > interop or SIP required for that to cause glare. I would say, if we could completely forget legacy we could also forget glare. We could have one offer/answer to open a connection (using ICE). Setting up the RTP-streams could then be separate for each end: the A side initiaes offer/answer to set up the streams flowing A->B and B does the corresponding for streams B->A, and these o/a dialogues could be separated. (In essence each side set's up what is in its localStreams array independently.) Then there would be no glare. (Not that I'm arguing for it) From ekr@rtfm.com Mon Nov 7 05:57:36 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FB521F8B70 for ; Mon, 7 Nov 2011 05:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.936 X-Spam-Level: X-Spam-Status: No, score=-102.936 tagged_above=-999 required=5 tests=[AWL=0.041, 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 sxvm9ul4RTGg for ; Mon, 7 Nov 2011 05:57:36 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id F290D21F846D for ; Mon, 7 Nov 2011 05:57:35 -0800 (PST) Received: by ywt2 with SMTP id 2so6208721ywt.31 for ; Mon, 07 Nov 2011 05:57:35 -0800 (PST) Received: by 10.146.110.15 with SMTP id i15mr3965186yac.19.1320674255445; Mon, 07 Nov 2011 05:57:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.146.232.12 with HTTP; Mon, 7 Nov 2011 05:50:20 -0800 (PST) X-Originating-IP: [74.95.2.169] In-Reply-To: References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> From: Eric Rescorla Date: Mon, 7 Nov 2011 05:50:20 -0800 Message-ID: To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 13:57:36 -0000 On Sun, Nov 6, 2011 at 7:20 PM, Hadriel Kaplan wro= te: >>> IMHO, if a web service doesn't want to take, or cannot take, the hit >>> for SRTP, WebRTC is not the appropriate solution for such a service. >> >> I'm exceedingly unsympathetic to the claim that SRTP is too slow. This >> is precisely the claim that was made about TLS for years, but measuremen= ts >> (see Langley and Modadugu's Overclocking SSL talk at Velocity) show >> that that's not really true. > > Who said "too slow"? =A0There *is* an extra round-trip or two involved I = presume, if we're talking DTLS-SRTP, but no I didn't mean that as a "hit". = =A0I just meant the extra computing cycles for SRTP being a "hit". =A0For W= ebRTC-to-WebRTC I don't think that matters at all. =A0For WebRTC-to-media-s= erver it might, for a free game app or greeting card app that don't care ab= out it to begin with, and which use plaintext HTTP to begin with. Sorry, I didn't mean to put words in your mouth. Performance measurements of HTTP versus HTTPS in modern Web environments suggest that the additional load for HTTPS is not significant. Do you have evidence that the situation = is different for SRTP versus RTP? -Ekr > (this isn't a big deal regardless - just something to think about whether= we care or not) > > -hadriel > > From harald@alvestrand.no Mon Nov 7 06:09:48 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDA621F8BEF for ; Mon, 7 Nov 2011 06:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.545 X-Spam-Level: X-Spam-Status: No, score=-110.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 An0ILknv2FNf for ; Mon, 7 Nov 2011 06:09:47 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D81AE21F8B85 for ; Mon, 7 Nov 2011 06:09:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1C62B39E119 for ; Mon, 7 Nov 2011 15:09:46 +0100 (CET) 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 nOxwuruFqVO4 for ; Mon, 7 Nov 2011 15:09:42 +0100 (CET) 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 ESMTPS id 0F08439E112 for ; Mon, 7 Nov 2011 15:09:42 +0100 (CET) Message-ID: <4EB7E6A5.70209@alvestrand.no> Date: Mon, 07 Nov 2011 15:09:41 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 14:09:48 -0000 On 11/07/2011 02:50 PM, Eric Rescorla wrote: > On Sun, Nov 6, 2011 at 7:20 PM, Hadriel Kaplan wrote: >>>> IMHO, if a web service doesn't want to take, or cannot take, the hit >>>> for SRTP, WebRTC is not the appropriate solution for such a service. >>> I'm exceedingly unsympathetic to the claim that SRTP is too slow. This >>> is precisely the claim that was made about TLS for years, but measurements >>> (see Langley and Modadugu's Overclocking SSL talk at Velocity) show >>> that that's not really true. >> Who said "too slow"? There *is* an extra round-trip or two involved I presume, if we're talking DTLS-SRTP, but no I didn't mean that as a "hit". I just meant the extra computing cycles for SRTP being a "hit". For WebRTC-to-WebRTC I don't think that matters at all. For WebRTC-to-media-server it might, for a free game app or greeting card app that don't care about it to begin with, and which use plaintext HTTP to begin with. > Sorry, I didn't mean to put words in your mouth. Performance measurements > of HTTP versus HTTPS in modern Web environments suggest that the additional > load for HTTPS is not significant. Do you have evidence that the situation is > different for SRTP versus RTP? FWIW, one particularly clumsy implementation of a test of SRTP encryption speed that I dealt with spent nearly forty microseconds of (single-thread, no-hardware-acceleration) CPU time AES-encrypting an RTP packet - consuming nearly 0.1% of the time I had before the next packet arrived on that audio channel. This, like all measurements, is false. But it convinced me that this was not the part of the system I needed to optimize. From randell-ietf@jesup.org Mon Nov 7 07:36:47 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2175521F85A4 for ; Mon, 7 Nov 2011 07:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 KvQ2VeVT1zMA for ; Mon, 7 Nov 2011 07:36:46 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 79C1A21F8512 for ; Mon, 7 Nov 2011 07:36:46 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RNRFd-0000vP-K4 for rtcweb@ietf.org; Mon, 07 Nov 2011 09:36:45 -0600 Message-ID: <4EB7FAED.4070104@jesup.org> Date: Mon, 07 Nov 2011 10:36:13 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <4EB74D06.8000006@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] Let's define the purpose of 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, 07 Nov 2011 15:36:47 -0000 On 11/7/2011 7:20 AM, Wolfgang Beck wrote: > On Mon, Nov 7, 2011 at 4:14 AM, Randell Jesup wrote: >> On 11/6/2011 9:01 AM, Tim Panton wrote: >>> [..] >> >> For example, you mention forking and glare. Well, I've given very >> non-interop cases of where forking would be useful: contacting someone who >> has 2 desktops, a notebook, a tablet, and a phone all logged into the >> service, or some of the game scenarios, or a very non-standard-SIP-like mesh >> conference using forked invites. > Do you really need forking to achieve this? Couldn't you just return > references to those devices back to the caller > which can then decide how to call them? A redirect server instead of a > forking proxy? So I assume instead of letting the server fork, you'd have the server return "you should really call these N specific sub-addresses", and have the client redo the call with those sub-addresses (which BTW complicates the security and camera/mic access model, I think). It would then generate N parallel OFFERs via the server. This generates several unwanted side-effects: a) possible more complex security/user-agreement issues b) at a minimum an extra round-trip for call setup if "forking" is needed, before any client is informed there's an incoming call. In practice this may be much worse, since N parallel OFFERs will mean N ICE candidate harvestings in order to send out the OFFERs. c) when one candidate is ACCEPTed, the client will be responsible for cancelling the OFFERs to the others (assuming it only wanted one conversation), or more ongoing resources used, if it wants to leave the option for other 'forked' destinations to answer. d) higher bandwidth and resource use, both by the client and the server. While this may seem minor, the extra energy used (and extra network traffic for ICE, cancelling OFFERs, etc) could actually matter for mobile clients, which is where all of this will likely be moving to. There's also a timing hole opened (small) where the list returned may no longer be correct when the multiple OFFERs are sent - I think this, while real, doesn't really matter in practice. > Forking is a good example how interop -- with SIP or with different > RTCWEB apps -- complicates things significantly. I think letting the server fork it (parallel forking) actually is less complication in practice. >> And glare: Cullen's classic example of glare is two people talking, browser to browser, and one saying "lets add >> video", and both turning it on. No interop or SIP required for that to >> cause glare. > If your service requires this function, yes, you're right. It has > nothing to do with SIP and interop. > > The question is: does a JS client have to deal with glare handling if > it can exclude conflicting offers by other means. My 'click here to > speak to a human' application might never need this at all. If there's any way both the client and the person at the other end could cause a re-OFFER (say if your local IP address changes??), then glare is always possible. Best to simply design for it so the application doesn't need to, especially since most app developers will have no concept what glare is or why it might happen. -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Mon Nov 7 07:40:56 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E65E21F8C20 for ; Mon, 7 Nov 2011 07:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 0pZQw2gr3gTQ for ; Mon, 7 Nov 2011 07:40:55 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id B629E21F8C1B for ; Mon, 7 Nov 2011 07:40:55 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RNRJf-0002f5-CU for rtcweb@ietf.org; Mon, 07 Nov 2011 09:40:55 -0600 Message-ID: <4EB7FBE8.9070506@jesup.org> Date: Mon, 07 Nov 2011 10:40:24 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <4EB74D06.8000006@jesup.org> <4EB7D17D.8080307@ericsson.com> In-Reply-To: <4EB7D17D.8080307@ericsson.com> 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] Let's define the purpose of 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, 07 Nov 2011 15:40:56 -0000 On 11/7/2011 7:39 AM, Stefan Håkansson LK wrote: > On 11/07/2011 04:14 AM, Randell Jesup wrote: > .... > >> And glare: >> Cullen's classic example of glare is two people talking, browser to >> browser, and one saying "lets add video", and both turning it on. No >> interop or SIP required for that to cause glare. > I would say, if we could completely forget legacy we could also forget > glare. We could have one offer/answer to open a connection (using ICE). > Setting up the RTP-streams could then be separate for each end: the A > side initiaes offer/answer to set up the streams flowing A->B and B does > the corresponding for streams B->A, and these o/a dialogues could be > separated. (In essence each side set's up what is in its localStreams > array independently.) Then there would be no glare. (Not that I'm > arguing for it) Even two one-way channels could have glare between an IP change at one end (or change in what resources it has to receive codecs, or window size it's displayed, etc), and the sender wanting to change something (even simply to go inactive/MUTE). -- Randell Jesup randell-ietf@jesup.org From HKaplan@acmepacket.com Mon Nov 7 07:42:19 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314EF21F87D6 for ; Mon, 7 Nov 2011 07:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 jLL6aWQfJ4b5 for ; Mon, 7 Nov 2011 07:42:18 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1001921F86D0 for ; Mon, 7 Nov 2011 07:42:17 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 7 Nov 2011 10:42:14 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 7 Nov 2011 10:42:14 -0500 From: Hadriel Kaplan To: Eric Rescorla Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AQHMnVQwkzEfyATo80e1sofLGuSnyQ== Date: Mon, 7 Nov 2011 15:42:14 +0000 Message-ID: References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> In-Reply-To: <4EB7E6A5.70209@alvestrand.no> 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: <49CF0D086307B74C9A0B26AEEC82383B@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 15:42:19 -0000 On 11/07/2011 02:50 PM, Eric Rescorla wrote: > On Sun, Nov 6, 2011 at 7:20 PM, Hadriel Kaplan w= rote: >> Who said "too slow"? There *is* an extra round-trip or two involved I p= resume, if we're talking DTLS-SRTP, but no I didn't mean that as a "hit". = I just meant the extra computing cycles for SRTP being a "hit". For WebRTC= -to-WebRTC I don't think that matters at all. For WebRTC-to-media-server i= t might, for a free game app or greeting card app that don't care about it = to begin with, and which use plaintext HTTP to begin with. > Sorry, I didn't mean to put words in your mouth. Performance measurements > of HTTP versus HTTPS in modern Web environments suggest that the addition= al > load for HTTPS is not significant. Do you have evidence that the situatio= n is > different for SRTP versus RTP? Only from the DSP guys, and those would be hardware DSPs not softDSPs. It = runs them anywhere from 10-25% overhead, they say, depending on the vendor = and what else their DSPs are doing at the time. But ultimately even in software I assume it's all relative to what other wo= rk you're doing. If you have to render a video stream on a screen and enco= de camera input into a codec being sent out, then my guess is SRTP overhead= is a tiny factor not worth talking about. If you're mixing multiple RTP s= treams as a conference server, then I assume doing SRTP for thousands of si= multaneous audio RTP streams for multiple simultaneous conferences becomes = noticeable. Or at least so they seem to claim - I don't know since I don't= build a media server (hardware SBCs often offload SRTP onto dedicated hard= ware). One large software company even created their own proprietary packe= t format for SRTP that they claimed was done for improving performance/scal= ability, so I assume it has some impact they don't want their customers to = incur. -hadriel From ibc@aliax.net Mon Nov 7 07:50:42 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A9C21F8C04 for ; Mon, 7 Nov 2011 07:50:42 -0800 (PST) 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 eTRitm530qb3 for ; Mon, 7 Nov 2011 07:50:40 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0368021F8BF3 for ; Mon, 7 Nov 2011 07:50:39 -0800 (PST) Received: by vcbfl11 with SMTP id fl11so4604372vcb.31 for ; Mon, 07 Nov 2011 07:50:39 -0800 (PST) Received: by 10.220.199.2 with SMTP id eq2mr2029626vcb.103.1320681039090; Mon, 07 Nov 2011 07:50:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Mon, 7 Nov 2011 07:50:18 -0800 (PST) In-Reply-To: References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <4EB74D06.8000006@jesup.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 7 Nov 2011 16:50:18 +0100 Message-ID: To: Wolfgang Beck Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 15:50:42 -0000 2011/11/7 Wolfgang Beck : >> For example, you mention forking and glare. =C2=A0Well, I've given very >> non-interop cases of where forking would be useful: contacting someone w= ho >> has 2 desktops, a notebook, a tablet, and a phone all logged into the >> service, or some of the game scenarios, or a very non-standard-SIP-like = mesh >> conference using forked invites. > Do you really need forking to achieve this? Couldn't you just return > references to those devices back to the caller > which can then decide how to call them? A redirect server instead of a > forking proxy? That's a limitation rather than a simplification, and would make lot of scenarios just harder. Don't think just in SIP. Any future *pure* WebRTC scenario could desire to fork a call into multiple N destinations without making the *JavaScript* client code to deal with N different sessions. --=20 I=C3=B1aki Baz Castillo From randell-ietf@jesup.org Mon Nov 7 07:55:07 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD7421F8C34 for ; Mon, 7 Nov 2011 07:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 Qgs8qZXmebBL for ; Mon, 7 Nov 2011 07:55:07 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 1964921F8C0A for ; Mon, 7 Nov 2011 07:55:07 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RNRXO-0000gj-MA for rtcweb@ietf.org; Mon, 07 Nov 2011 09:55:06 -0600 Message-ID: <4EB7FF3B.8060304@jesup.org> Date: Mon, 07 Nov 2011 10:54:35 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> In-Reply-To: <4EB7E6A5.70209@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] Let's define the purpose of 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, 07 Nov 2011 15:55:07 -0000 On 11/7/2011 9:09 AM, Harald Alvestrand wrote: > On 11/07/2011 02:50 PM, Eric Rescorla wrote: >> Sorry, I didn't mean to put words in your mouth. Performance measurements >> of HTTP versus HTTPS in modern Web environments suggest that the >> additional >> load for HTTPS is not significant. Do you have evidence that the >> situation is >> different for SRTP versus RTP? > FWIW, one particularly clumsy implementation of a test of SRTP > encryption speed that I dealt with spent nearly forty microseconds of > (single-thread, no-hardware-acceleration) CPU time AES-encrypting an RTP > packet - consuming nearly 0.1% of the time I had before the next packet > arrived on that audio channel. > > This, like all measurements, is false. But it convinced me that this was > not the part of the system I needed to optimize. Not that I disagree about SRTP and overhead(!), but I will note that video can easily use 30-100x the bandwidth (and typically 30-100x the encryption/decryption overhead) of audio, which could approach 3-10% perhaps in a 'clumsy implementation', and you need to consider decode (similar overhead) and multiple streams. It may not be a lot on it's own, but the amount of CPU left over after audio/video encode/decode/AEC/processing/etc may not be a lot, and on many devices that may limit of the client's ability to process calls at good frame rates and resolutions, forcing it down the the next-lower resolution shelf, especially on clients with minimal HW assist and on mobile. I agree encryption/decryption overhead should not be a significant factor in the discussion of SRTP. I would like to see estimates of encrypt/decrypt speed per byte on mobile devices, though. -- Randell Jesup randell-ietf@jesup.org From jonathan@vidyo.com Mon Nov 7 08:16:12 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B702C21F8C75 for ; Mon, 7 Nov 2011 08:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 UZ7l5LRAc3-C for ; Mon, 7 Nov 2011 08:16:12 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 47C8621F8C73 for ; Mon, 7 Nov 2011 08:16:12 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id CE8A07A1C0B; Mon, 7 Nov 2011 11:16:11 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 9A2FA7A18BF; Mon, 7 Nov 2011 11:16:05 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Mon, 7 Nov 2011 11:15:58 -0500 From: Jonathan Lennox To: Eric Rescorla , Cameron Byrne Date: Mon, 7 Nov 2011 11:16:03 -0500 Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AcydZkReBf/Q9K7/SoSGU169XM6zZQAAAw9w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 16:16:12 -0000 Eric Rescorla wrote: > Good point. Also, of course (unless you use the SRTP header encryption > extension) the SRTP header is in the clear, so you mostly just don't get = the media itself. The extension (assuming you're talking about draft-ietf-avtcore-srtp-encryp= ted-header-ext) is header extension encryption, not a header encryption ext= ension ... the base RTP header remains in the clear in SRTP, even with this= draft.=20 SRTP forms its per-packet IVs based on the SSRC and sequence number, so tho= se fundamentally have to be sent in the clear. I suppose in theory you cou= ld encrypt some of the other fields of the RTP header, but I don't see much= point in it. (At some point, if things are this sensitive, you're better o= ff just using IPSec.) --=20 Jonathan Lennox jonathan@vidyo.com From harald@alvestrand.no Mon Nov 7 08:27:37 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B702021F8BF3 for ; Mon, 7 Nov 2011 08:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.547 X-Spam-Level: X-Spam-Status: No, score=-110.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 bMWbpZ8IpPYQ for ; Mon, 7 Nov 2011 08:27:37 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0E65821F8B6C for ; Mon, 7 Nov 2011 08:27:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 51B6E39E119 for ; Mon, 7 Nov 2011 17:27:36 +0100 (CET) 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 0uAl8ecSXB4g for ; Mon, 7 Nov 2011 17:27:35 +0100 (CET) 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 ESMTPS id A051539E112 for ; Mon, 7 Nov 2011 17:27:35 +0100 (CET) Message-ID: <4EB806F7.2090603@alvestrand.no> Date: Mon, 07 Nov 2011 17:27:35 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <4EB74D06.8000006@jesup.org> <4EB7FAED.4070104@jesup.org> In-Reply-To: <4EB7FAED.4070104@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 16:27:37 -0000 On 11/07/2011 04:36 PM, Randell Jesup wrote: > On 11/7/2011 7:20 AM, Wolfgang Beck wrote: >> On Mon, Nov 7, 2011 at 4:14 AM, Randell >> Jesup wrote: >>> On 11/6/2011 9:01 AM, Tim Panton wrote: >>>> [..] >>> >>> For example, you mention forking and glare. Well, I've given very >>> non-interop cases of where forking would be useful: contacting >>> someone who >>> has 2 desktops, a notebook, a tablet, and a phone all logged into the >>> service, or some of the game scenarios, or a very >>> non-standard-SIP-like mesh >>> conference using forked invites. > >> Do you really need forking to achieve this? Couldn't you just return >> references to those devices back to the caller >> which can then decide how to call them? A redirect server instead of a >> forking proxy? > > So I assume instead of letting the server fork, you'd have the server > return "you should really call these N specific sub-addresses", and > have the client redo the call with those sub-addresses (which BTW > complicates the security and camera/mic access model, I think). It > would then generate N parallel OFFERs via the server. If we were doing a greenfield application, I'd let the server tell all the possible endpoints that they should set up a connection to the original caller, and forget about the caller calling anyone. The difference between caller and callee is a question of your level of abstraction..... From wolfgang.beck01@googlemail.com Mon Nov 7 08:53:06 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B47921F8C31 for ; Mon, 7 Nov 2011 08:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.929 X-Spam-Level: X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 BwOVsHjehqjj for ; Mon, 7 Nov 2011 08:53:05 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB8621F8A7D for ; Mon, 7 Nov 2011 08:53:05 -0800 (PST) Received: by qadc10 with SMTP id c10so4581120qad.31 for ; Mon, 07 Nov 2011 08:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8a+Iktj+Xkn4rS1+0imXdT85sxmJKyD7Jv1Up0OyI5U=; b=JwEbfgSMh/79zU2SCZThmRhzP1l80TeeSU5z7f5e+NBERqR5+u60ObEszf+RfW7oT+ xABmabCwn+gtwvzp0tGeeGIlGE2QL2ptjk62tmRS515qCYkZegikUZaFGxJdhwenbJXb je01UoHxSgFPmmqhdNlFqVui6HbUMbJIGhn1g= MIME-Version: 1.0 Received: by 10.68.52.134 with SMTP id t6mr336558pbo.96.1320684784667; Mon, 07 Nov 2011 08:53:04 -0800 (PST) Received: by 10.68.64.66 with HTTP; Mon, 7 Nov 2011 08:53:04 -0800 (PST) In-Reply-To: <4EB806F7.2090603@alvestrand.no> References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <4EB74D06.8000006@jesup.org> <4EB7FAED.4070104@jesup.org> <4EB806F7.2090603@alvestrand.no> Date: Mon, 7 Nov 2011 17:53:04 +0100 Message-ID: From: Wolfgang Beck To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 16:53:06 -0000 On Mon, Nov 7, 2011 at 5:27 PM, Harald Alvestrand wrote: [on SIP-style forking] > If we were doing a greenfield application, I'd let the server tell all the > possible endpoints that they should set up a connection to the original > caller, and forget about the caller calling anyone. > > The difference between caller and callee is a question of your level of > abstraction..... That's the kind of innovative thinking I thought RTCWEB was all about. And this forking discussion is a good example how the requirement to have interop between different RTCWEB apps and/or SIP is holding us back. Ditch the trapezoid and do greenfield. Wolfgang Beck From ibc@aliax.net Mon Nov 7 09:35:14 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831FB21F8B66 for ; Mon, 7 Nov 2011 09:35:14 -0800 (PST) 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 zFBwwQuP3oWI for ; Mon, 7 Nov 2011 09:35:13 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D51521F8B65 for ; Mon, 7 Nov 2011 09:35:13 -0800 (PST) Received: by vcbfl11 with SMTP id fl11so4734730vcb.31 for ; Mon, 07 Nov 2011 09:35:13 -0800 (PST) Received: by 10.52.33.239 with SMTP id u15mr14004699vdi.49.1320687313055; Mon, 07 Nov 2011 09:35:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Mon, 7 Nov 2011 09:34:52 -0800 (PST) In-Reply-To: <4EB806F7.2090603@alvestrand.no> References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <4EB74D06.8000006@jesup.org> <4EB7FAED.4070104@jesup.org> <4EB806F7.2090603@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 7 Nov 2011 18:34:52 +0100 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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, 07 Nov 2011 17:35:14 -0000 2011/11/7 Harald Alvestrand : > If we were doing a greenfield application, I'd let the server tell all th= e > possible endpoints that they should set up a connection to the original > caller, and forget about the caller calling anyone. > > The difference between caller and callee is a question of your level of > abstraction..... Of course that would be a possible scenario, but such scenario assumes that the logic is in the webserver and clients are dumb. There is no problem with that, of course. But I hope I must not assume that the JS is dumb for all the possible WebRTC scenarios. I do need the concept of "caller" and "callee". --=20 I=C3=B1aki Baz Castillo From randell-ietf@jesup.org Mon Nov 7 09:35:55 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38F921F8C07 for ; Mon, 7 Nov 2011 09:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 sM5Ul3wyEVK7 for ; Mon, 7 Nov 2011 09:35:55 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id E3F1321F8B66 for ; Mon, 7 Nov 2011 09:35:54 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RNT6n-0007Zx-8Q for rtcweb@ietf.org; Mon, 07 Nov 2011 11:35:45 -0600 Message-ID: <4EB816D1.1040708@jesup.org> Date: Mon, 07 Nov 2011 12:35:13 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <4EB74D06.8000006@jesup.org> <4EB7FAED.4070104@jesup.org> <4EB806F7.2090603@alvestrand.no> 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] Let's define the purpose of 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, 07 Nov 2011 17:35:56 -0000 On 11/7/2011 11:53 AM, Wolfgang Beck wrote: > On Mon, Nov 7, 2011 at 5:27 PM, Harald Alvestrand wrote: > [on SIP-style forking] >> If we were doing a greenfield application, I'd let the server tell all the >> possible endpoints that they should set up a connection to the original >> caller, and forget about the caller calling anyone. >> >> The difference between caller and callee is a question of your level of >> abstraction..... > > That's the kind of innovative thinking I thought RTCWEB was all about. > > And this forking discussion is a good example how the requirement to > have interop between different RTCWEB apps and/or SIP is holding us > back. Ditch the trapezoid and do greenfield. This has nothing to do with trapezoids. This is something I believe we need even if there was an absolute block on SIP interop. And I disagree with Harald here; telling the clients they should open connections to the "caller" is exactly what parallel forking by the server does. It tells them "here's the offer and ICE candidates, open a connection to the "caller" and complete negotiation." It'd be silly not to include the OFFER in the message to the "callee's", since we have to send them the ICE candidates anyways - plus, the "callee's" may need that info for alerting, etc, and not providing it would add more round-trips. Never forget that even half-round-trips can be PAINFUL to some applications! And don't forget that this might get used on links that bounce off a satellite (or two!), or transit low-bandwidth wireless networks or mesh networks, etc. Now there's RTT... ;-) Now, the "caller" may have taken the first ACCEPT, or it might run them parallel until a final accept on one, or it might keep all the options open for the entire "call" (which doesn't map super-well to SIP, note, though it can be emulated in SIP). So the "caller" may decline the ANSWERs or final ANSWERS (ACCEPTs) from any of the forked "callees". That's entirely up to the app. -- Randell Jesup randell-ietf@jesup.org From xiphmont@gmail.com Mon Nov 7 11:02:52 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDBF11E809C for ; Mon, 7 Nov 2011 11:02:52 -0800 (PST) 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 g+yopTm-Mx9k for ; Mon, 7 Nov 2011 11:02:48 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD4EF11E808E for ; Mon, 7 Nov 2011 11:02:47 -0800 (PST) Received: by wwi36 with SMTP id 36so5129193wwi.13 for ; Mon, 07 Nov 2011 11:02:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=067mNMhS2ApYXXLfHjYWTMVzpvPcM31xrr5IeLv0/n0=; b=nyRJCvKcJhYt93UKYTLIliowFLzMA/BARsNA0qkfIH9paBVrdkXxpOQ47r5ZXHLT3N s2S75knopNwczszrPlwg78plT/Uc52zMbILyhaUn8Ij+f3KSryt3VcUZn5LZzVzZWA1D AS7+6/iwxqOcWXL2wsb+9hwMot/xp+wBSmBM4= MIME-Version: 1.0 Received: by 10.227.209.5 with SMTP id ge5mr30364070wbb.1.1320692564958; Mon, 07 Nov 2011 11:02:44 -0800 (PST) Received: by 10.227.121.68 with HTTP; Mon, 7 Nov 2011 11:02:44 -0800 (PST) Date: Mon, 7 Nov 2011 14:02:44 -0500 Message-ID: From: Monty Montgomery To: rtcweb@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Opus RF status, was: Re: Codec 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, 07 Nov 2011 19:02:52 -0000 > I find it strange that we consider making an declared-as-royalty-bearing audio codec mandatory, Stephan, You've asserted that Opus is 'declared as royalty bearing' several times now. This is outright false. The only IPR filing that doesn't include explicit RF terms is Qualcomm's filing[1] which lists six patents. Our analysis indicates these patents have no chance of covering Opus. It further suggests that Qualcomm did little or no analysis on these patents beyond an automated search. Xiph has presented the above summary directly to Qualcomm. Qualcomm declined to alter or amend the language in their IPR filing, replying that the disclosure standard is merely "IPR the Contributor or other IETF participant believes Covers or may ultimately Cover the technology under discussion."[2]. Qualcomm explicitly added that they had no obligation to make a stronger statement. Thus, Qualcomm themselves confirm that they have made no definitive suggestion or statement that Qualcomm IPR covers Opus. Qualcomm has filed nearly identical IPR claims in several IETF working groups working under RF terms. Are you suggesting that WebRTC must avoid SIP[3] or drop SDP because of similar Qualcomm IPR filings[4] that differ only in the patent numbers? Opus is not 'declared as royalty bearing' nor are there credible royalty-bearing patent claims or assertions against Opus. Anyone who would like to assert otherwise can do so trivially by posting their claims charts. Monty Xiph.Org [1] https://datatracker.ietf.org/ipr/1520/ [2] https://www.ietf.org/rfc/rfc3979.txt sec 6.1.2(c) [3] OK, sure, there are other reasons to avoid SIP :-) [4] https://datatracker.ietf.org/ipr/1389/ https://datatracker.ietf.org/ipr/1390/ From harald@alvestrand.no Mon Nov 7 11:33:24 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA5021F8B1E for ; Mon, 7 Nov 2011 11:33:24 -0800 (PST) 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 LRaTrVB0Lfgd for ; Mon, 7 Nov 2011 11:33:23 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7657C21F8B0E for ; Mon, 7 Nov 2011 11:33:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 20F3D39E119; Mon, 7 Nov 2011 20:33:22 +0100 (CET) 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 WD9rQKlZ4ZxI; Mon, 7 Nov 2011 20:33:21 +0100 (CET) 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 ESMTPS id 31BE839E112; Mon, 7 Nov 2011 20:33:21 +0100 (CET) Message-ID: <4EB83281.6020905@alvestrand.no> Date: Mon, 07 Nov 2011 20:33:21 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Wolfgang Beck References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <4EB74D06.8000006@jesup.org> <4EB7FAED.4070104@jesup.org> <4EB806F7.2090603@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] Let's define the purpose of 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, 07 Nov 2011 19:33:24 -0000 On 11/07/2011 05:53 PM, Wolfgang Beck wrote: > On Mon, Nov 7, 2011 at 5:27 PM, Harald Alvestrand wrote: > [on SIP-style forking] >> If we were doing a greenfield application, I'd let the server tell all the >> possible endpoints that they should set up a connection to the original >> caller, and forget about the caller calling anyone. >> >> The difference between caller and callee is a question of your level of >> abstraction..... > That's the kind of innovative thinking I thought RTCWEB was all about. It's also something that is eminently doable with the currently proposed API. > And this forking discussion is a good example how the requirement to > have interop between different RTCWEB apps and/or SIP is holding us > back. Ditch the trapezoid and do greenfield. > > > Wolfgang Beck > From Markus.Isomaki@nokia.com Mon Nov 7 11:41:51 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7846C21F8C4F for ; Mon, 7 Nov 2011 11:41:51 -0800 (PST) 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 8imjElK6LZP9 for ; Mon, 7 Nov 2011 11:41:51 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id DFACD21F8C26 for ; Mon, 7 Nov 2011 11:41:50 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pA7JfkM4006151; Mon, 7 Nov 2011 21:41:48 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Nov 2011 21:41:42 +0200 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by 008-AM1MMR1-010.mgdnok.nokia.com (65.54.30.26) with Microsoft SMTP Server (TLS) id 14.1.339.2; Mon, 7 Nov 2011 20:41:41 +0100 Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.190]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0339.002; Mon, 7 Nov 2011 20:41:28 +0100 From: To: , Thread-Topic: [rtcweb] Opus RF status, was: Re: Codec Draft Thread-Index: AQHMnX/fvYR5fKnZ8UGEbAKzMP4xyZWhx9Xg Date: Mon, 7 Nov 2011 19:41:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [88.114.26.217] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Nov 2011 19:41:42.0393 (UTC) FILETIME=[4661D690:01CC9D85] X-Nokia-AV: Clean Subject: Re: [rtcweb] Opus RF status, was: Re: Codec 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, 07 Nov 2011 19:41:51 -0000 Hi, Monty Montgomery wrote: > >Qualcomm has filed nearly identical IPR claims in several IETF working gro= ups >working under RF terms. Are you suggesting that WebRTC must avoid SIP[3] >or drop SDP because of similar Qualcomm IPR filings[4] that differ only in= the >patent numbers? > Hmm... It's indeed interesting why there is such a fuss about royalty free = codecs, but not so much on the other parts of the WebRTC framework. At leas= t codecs are easily changeable, unlike some of the other components. (Not t= hat I have done any research on how many known patent claims there are agai= nst the other components.) Markus From stewe@stewe.org Mon Nov 7 12:44:21 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6CC11E80A6 for ; Mon, 7 Nov 2011 12:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mX4CfvPLswHz for ; Mon, 7 Nov 2011 12:44:17 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 2040611E80D5 for ; Mon, 7 Nov 2011 12:44:15 -0800 (PST) Received: from [192.168.1.63] (unverified [71.202.147.60]) by stewe.org (SurgeMail 3.9e) with ESMTP id 57162-1743317 for multiple; Mon, 07 Nov 2011 21:44:09 +0100 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Mon, 07 Nov 2011 12:43:52 -0700 From: Stephan Wenger To: Message-ID: Thread-Topic: [rtcweb] Opus RF status, was: Re: Codec Draft In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 71.202.147.60 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.147.60) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [rtcweb] Opus RF status, was: Re: Codec 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, 07 Nov 2011 20:44:21 -0000 Hi Monty, We disagree (as usual on these matters). Please see inline. Stephan On 11.7.2011 12:02 , "Monty Montgomery" wrote: >> I find it strange that we consider making an >>declared-as-royalty-bearing audio codec mandatory, > >Stephan, > >You've asserted that Opus is 'declared as royalty bearing' several >times now. This is outright false. I disagree. Please note that I DID NOT write something like Opus is royalty-bearing". I only wrote "is declared as". In support of this statement, please see section VI of QC's declaration, which can be found at https://datatracker.ietf.org/ipr/1520/ (or your reference [2]) and reads "Reasonable and Non-Discriminatory License to All Implementers *with Possible Royalty/Fee.*" (Emphasis added.) If you are referring to the fact that "with Possible Royalty/Fee" also includes an option, at the right holders discretion, to also offer an RF license... that's true. However, that's equally true for stuff like H.264. You only need to convince all right holders to extent such free license. Which, incidentally, has happened in the past for a certain use of H.264 and for those right holders that are part of the MPEG-LA pool. This is all I am referring to in the context of this thread. >The only IPR filing that doesn't include explicit RF terms is >Qualcomm's filing[1] which lists six patents. Our analysis >indicates these patents have no chance of covering Opus. It >further suggests that Qualcomm did little or no analysis on >these patents beyond an automated search. > >Xiph has presented the above summary directly to Qualcomm. Qualcomm >declined to alter or amend the language in their IPR filing, replying >that the disclosure standard is merely "IPR the Contributor or other >IETF participant believes Covers or may ultimately Cover the >technology under discussion."[2]. Qualcomm explicitly added that they >had no obligation to make a stronger statement. > >Thus, Qualcomm themselves confirm that they have made no definitive >suggestion or statement that Qualcomm IPR covers Opus. This is an interesting set of statements and interpretations, as well as an interesting data point I was not aware of. It doesn't change anything related to my statement. It merely provides insight into your risk assessment, which obviously can be (and probably should be) different than mine. There are a number of good reasons why most (if not all) IPR declaration documents, whether templates or free form, avoid committing language with respect to (alleged) infringement of a patent by a standards implementation. The details of these reasons are IMO beyond the scope of this mailing list, so I'm not posting them here. > >Qualcomm has filed nearly identical IPR claims in several IETF working >groups working under RF terms. With the possible exception of some technical fields (not WGs) in the security field (only mandatory cyphers come to my mind right now), I'm not aware that IETF WGs can work under "RF terms". I don't think such a modus operandi is supported by the IETF's patent policy. We are not OASIS or W3C here... >Are you suggesting that WebRTC must >avoid SIP[3] or drop SDP because of similar Qualcomm IPR filings[4] that >differ only in the patent numbers? Quite to the contrary. I'm not overly worried about RAND IPR claims (which exist also in other fields closer to WebRTC's core mission; see for example Ericsson's recent declaration filings on stuff related to RTP multiplexing; RAND terms). I'm worried about unfair treatment of established technologies and codecs (H.264 and some audio codecs) over unestablished ones, just because the latter are believed (by some) to be unencumbered by potentially royalty-bearing patent claims. That's particularly unfair if there is already evidence to the contrary. Which, unfortunately, is the case with opus. > >Opus is not 'declared as royalty bearing' As I explained above, I believe this is an incorrect statement. >nor are there credible >royalty-bearing patent claims or assertions against Opus. And this is a subjective viewpoint of one proponent organization. >Anyone who >would like to assert otherwise can do so trivially by posting their >claims charts. Perhaps they could. Should they? Would it be to their advantage? As I mentioned a number of times before, there are certain risks involved in publishing documents suggesting a detailed study of someone else's patent. Certainly a claim chart would fall into a category of documents where the risk is a bit higher than the broad statements generally made on this (and other IETF-) mailing list(s). > >Monty >Xiph.Org > >[1] https://datatracker.ietf.org/ipr/1520/ >[2] https://www.ietf.org/rfc/rfc3979.txt sec 6.1.2(c) >[3] OK, sure, there are other reasons to avoid SIP :-) >[4] https://datatracker.ietf.org/ipr/1389/ > https://datatracker.ietf.org/ipr/1390/ >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From matthew.kaufman@skype.net Mon Nov 7 13:48:43 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACB211E80B2 for ; Mon, 7 Nov 2011 13:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.359 X-Spam-Level: X-Spam-Status: No, score=-5.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SERRFmW3+xIN for ; Mon, 7 Nov 2011 13:48:42 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 322DA11E80B4 for ; Mon, 7 Nov 2011 13:48:41 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id A817C16F6; Mon, 7 Nov 2011 22:48:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=zkJi1tdr1pnxQO HCbFgP0ub1M/s=; b=xDv55/nNBoi1lvD6LyndGRVJUDFaSoPvHWLewxtiZmB03e rE4NKEJWVPA1JnIfPtEHCKnnXoT/gVBaC0l4oybvalC7FRrX17Ugq5O0ZuJnV5l5 7JDz9YseuwfE/4KLNrlR8hrEK0mATmmivx6xdW/GkMZ6fJFGewjQgPNjsFElA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=ZYPolE05gI4ASYBxV23ya6 +oHhf2SC3Gx94sgFysvNH2VcQMLh/p7hL/sOwzYH07VU3fT6IC2FNC0lqSnTsuAJ znDYC5xu5HL1/AvSoUn0lLhX0KCdLNw3Q+E65Us2arsHQGgfd/PLsE3RxnB/na/f W++BRamDRz7YOtPJclugM= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id A69DF7F6; Mon, 7 Nov 2011 22:48:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 77AC93507521; Mon, 7 Nov 2011 22:48:39 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VheVRcF-HcZt; Mon, 7 Nov 2011 22:48:38 +0100 (CET) Received: from Matthew-Kaufman-Air.local (50-0-2-20.static.sonic.net [50.0.2.20]) by zimbra.skype.net (Postfix) with ESMTPSA id C82671672681; Mon, 7 Nov 2011 22:48:37 +0100 (CET) Message-ID: <4EB85233.7020103@skype.net> Date: Mon, 07 Nov 2011 13:48:35 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Harald Alvestrand References: <99DF5455-9961-41E6-A506-1DD09AF6D1C0@acmepacket.com> <4EA9ECE9.4050500@skype.net> <4EAA0801.3030701@alvestrand.no> In-Reply-To: <4EAA0801.3030701@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Security issue: initial consent X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Nov 2011 21:48:43 -0000 On 10/27/11 6:40 PM, Harald Alvestrand wrote: > On 10/27/2011 04:44 PM, Matthew Kaufman wrote: >> On 10/28/11 12:39 AM, Hadriel Kaplan wrote: >>> ... >>> Heck, we could even mandate using a new TCP header option to be >>> reflected by the other side, similar to the TCP Timestamp option, >>> but put a random number in it. >>> >> >> Again, the STUN connectivity test used by ICE does more than simply >> prove that the far end got the packet and can reflect it back. The >> reflection isn't even done unless the long-term credentials are valid. > Nit: the STUN usage I have seen so far uses short-term credentials > (ephemeral username + password, RFC 5389 section 10.1) per RFC 5245 > section 7.1.2.3, not long-term credentials (realm + username + > password, RFC 5389 section 10.2). > > Since "short term" and "long term" are used with specific meaning in > ICE, I hope we're using them in the same way in this discussion. Correct. I had been looking at TURN code that day, sorry about the mix-up. Matthew Kaufman From matthew.kaufman@skype.net Mon Nov 7 15:38:51 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB9F11E80BB for ; Mon, 7 Nov 2011 15:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=0.620, 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 FLqMT8N9i2PQ for ; Mon, 7 Nov 2011 15:38:50 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 230A021F84D8 for ; Mon, 7 Nov 2011 15:38:50 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 6DC5716FD; Tue, 8 Nov 2011 00:38:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=fjEspzglsEfGDp N0FcDRao3KcPM=; b=FpjXxkv6R0UMfZY51OgxosckE7d0J26rS2ztNn+qtTzs1g P/sy1bsFiScS+g5d3GeFFuDzBu3Pfxvl2dfyyWILAeBjUf4qZqv+gHrvq1A+0Bwa uQvOglqiIIY6LU9Vm76SGESXUU4eJngh7alFGWXytOdt8ufbkB/onLdcE68xU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=FG7qeQGZ04z0Db8fuHL/dV 9/gqDZxk5wAUHME0LFcnrxOWRoUlTo2+v4E5Vr1Ttnj/RD79+N6BIUaGC3VAZ8LD RMykJr63WLjk+oPFIbuVDxr4EnHrLfvcHbXuVl2jGp4ofuBBSZz7moiaJ/kP8/3f 0nl2VaxRNwgnIy8eGYbcg= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 62D4A7F6; Tue, 8 Nov 2011 00:38:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 43A0135075E3; Tue, 8 Nov 2011 00:38:49 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncldPGo9d6WK; Tue, 8 Nov 2011 00:38:48 +0100 (CET) Received: from Matthew-Kaufman-Air.local (50-0-2-20.static.sonic.net [50.0.2.20]) by zimbra.skype.net (Postfix) with ESMTPSA id 4D63035075DE; Tue, 8 Nov 2011 00:38:47 +0100 (CET) Message-ID: <4EB86C05.1040107@skype.net> Date: Mon, 07 Nov 2011 15:38:45 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <4EA20101.8090401@skype.net> <405C23A2-8E22-464E-A0A3-038E497237B4@acmepacket.com> In-Reply-To: <405C23A2-8E22-464E-A0A3-038E497237B4@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] ROAP Example Application X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Nov 2011 23:38:51 -0000 (Leaving the trailing included text below in case context must be re-established... my travel schedule has precluded answering all threads promptly) On 10/21/11 6:12 PM, Hadriel Kaplan wrote: > I think what you're getting at is: if we threw out SDP and re-designed how/what devices indicated/negotiated media-plan stuff, we wouldn't end up with SDP again - neither in syntax nor semantics nor even architecture, as we'd likely separate the higher-layer info portion, transport portion, and the pure codec-type negotiation stuff into separate components; and we'd probably move the codec negotiation into the media-path itself potentially, for example. Is that what you mean? That isn't what I was getting at, but it is also a valid point. We would certainly separate the higher layer info, the transport, and the codec negotiation into separate components. Whether or not we would change where the information flows, I don't know. But what I was getting at was actually whether or not we could use *what we actually have* to build a better-decomposed system, not what we would do if we were starting from scratch. > > I don't disagree with that, and it's been raised many times in the SIP-related working groups over the years. We know SDP isn't "clean" in terms of either syntax or semantics, but obviously in the SIP world it was way too late to change, and folks now use the info all being together in the SIP signaling-plane to their advantage. Exactly, it is "way too late to change", so I'm trying to determine if there's a path forward that has at least some of the advantages without throwing out the past. > > I think though you can sort of emulate the separation in RTCWeb, even with the SDP offer/answer and ROAP. You create a MediaStream with a track of "data" type, put it in a PeerConnection, and issue the SDP Offer. Then when the data connection is open to the peer Browser/device, you create your audio/video tracks/streams and add them in, and when the new Offer is issued by the Browser you send the ROAP over the data connection to the peer, who does likewise for the Answer. That might work. The above is only about moving where the message goes to the media plane from the signaling plane, and that's not the part that is important. Matthew Kaufman > > > On Oct 21, 2011, at 7:32 PM, Matthew Kaufman wrote: > >> On 10/21/2011 12:01 PM, Ted Hardie wrote: >>> On Fri, Oct 21, 2011 at 10:37 AM, Matthew Kaufman wrote: >>> Thought experiment: >>> >>> If one had a connection object that supported an underlying protocol that could send one or more encrypted flows of both real-time media and reliable data, what information would you need to exchange between the two browser endpoints in order to ensure that any pair of browsers with any future audio or video codec could use the best mutually-supported codecs? >>> >>> >>> I think I am missing your point slightly. Do you mean the connection object talks to an abstraction layer that manages how the flows are sent, and the swapping occurs in what it manages, or do you mean the connection object should be able to swap out whether it is talking to ICE, DTLS-SRTP, or TCP-over-UDP transparently? or something else? >> I mean "what if the connection object was sitting on top of something like RTMFP", in other words a protocol that can trivially be asked to open a secure (encrypted and authenticated) NAT-traversing session between your browser and another browser and then can deliver multiple parallel flows of partially-reliable media and fully-reliable data (prioritized appropriately) to the far end. >> >> Then the next question I asked is, IF you had a connection object like that, what is the minimum you need to get the latest-and-greatest-codec-just-works behavior that Cullen, et. al. have described? >> >> Matthew Kaufman >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From matthew.kaufman@skype.net Mon Nov 7 15:42:45 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6427321F8B73 for ; Mon, 7 Nov 2011 15:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 illUCX914U1b for ; Mon, 7 Nov 2011 15:42:44 -0800 (PST) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA6C21F8A62 for ; Mon, 7 Nov 2011 15:42:44 -0800 (PST) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id D05C416F6; Tue, 8 Nov 2011 00:42:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mx; bh=+jnhhYlG7u4vT0 pQs1VdbT1IZo0=; b=nd0n1TmNeLTI36IJ7K8ftoSIYSm5WvBE0u0N79Qrt6bjLe F92P5wiFhIrplTQ6mGmNI5WUk/pc0CvmZAb6FxQnyBoomaQgub1boGahO9UlsnwG 4AZL73sKw1Xm9EBdlLx2m/XY42Hq6SQnC84daLEaaynUaaxRQjldO2grbsrow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type: content-transfer-encoding; q=dns; s=mx; b=TrfibpXBXRPd6vX46JZihc xIlZ9sM280OEXnb2v7vYG6127ZmYaCuGmgh1RKDlm6xBL97XFcyojlw1ERrWnH2u 1Wqf7IKVpyO5QwIUwqsaLwfy0rNjEAskq+/eCFAS1Xho7EhioJKYYgf7WKILqO04 YWwHI9cVn5J9qInhE0+T4= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id CE9517F6; Tue, 8 Nov 2011 00:42:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id A3BA51685A01; Tue, 8 Nov 2011 00:42:42 +0100 (CET) X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7nkEXyqPYq4; Tue, 8 Nov 2011 00:42:41 +0100 (CET) Received: from Matthew-Kaufman-Air.local (50-0-2-20.static.sonic.net [50.0.2.20]) by zimbra.skype.net (Postfix) with ESMTPSA id E95851672681; Tue, 8 Nov 2011 00:42:40 +0100 (CET) Message-ID: <4EB86CEF.9040201@skype.net> Date: Mon, 07 Nov 2011 15:42:39 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Randell Jesup References: <4EA20101.8090401@skype.net> <405C23A2-8E22-464E-A0A3-038E497237B4@acmepacket.com> <4EA2378E.4010502@jesup.org> In-Reply-To: <4EA2378E.4010502@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ROAP Example Application X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Nov 2011 23:42:45 -0000 On 10/21/11 8:25 PM, Randell Jesup wrote: > On 10/21/2011 9:12 PM, Hadriel Kaplan wrote: >> I think what you're getting at is: if we threw out SDP and >> re-designed how/what devices indicated/negotiated media-plan stuff, >> we wouldn't end up with SDP again - neither in syntax nor semantics >> nor even architecture, as we'd likely separate the higher-layer info >> portion, transport portion, and the pure codec-type negotiation stuff >> into separate components; and we'd probably move the codec >> negotiation into the media-path itself potentially, for example. Is >> that what you mean? > > > Actually, I think Matthew is thinking of something else entirely > (though you're right that SDP is not what we'd do with a clean piece > of paper - but that would be a multi-year effort, and in the end > unless there was a major driving adopter, it would fall by the wayside > like SDP-ng (and for that matter, cap-neg)). Yes, I was thinking of something other than re-creating SDP. > >> I don't disagree with that, and it's been raised many times in the >> SIP-related working groups over the years. We know SDP isn't "clean" >> in terms of either syntax or semantics, but obviously in the SIP >> world it was way too late to change, and folks now use the info all >> being together in the SIP signaling-plane to their advantage. >> >> I think though you can sort of emulate the separation in RTCWeb, even >> with the SDP offer/answer and ROAP. You create a MediaStream with a >> track of "data" type, put it in a PeerConnection, and issue the SDP >> Offer. Then when the data connection is open to the peer >> Browser/device, you create your audio/video tracks/streams and add >> them in, and when the new Offer is issued by the Browser you send the >> ROAP over the data connection to the peer, who does likewise for the >> Answer. That might work. > > > This isn't what Matthew was thinking of - he wanted to know if with > these tools, it would ease negotiating codecs that didn't exist when > the web-app was written (especially with a low-level API to the > browser and its codecs). Approximately yes. What I want to know is, with the tools we have (SDP), would it be possible to solve the negotiate-a-codec-that-didn't-exist problem while *NOT* impacting the underlying transport... and, separately, would it be possible to solve the negotiate-a-transport-session problem while *NOT* impacting the codec selection. My original thought experiment from October 21st has, to date, not been addressed by anyone other than myself I'm afraid. Matthew Kaufman > >> -hadriel >> >> >> On Oct 21, 2011, at 7:32 PM, Matthew Kaufman wrote: >> >>> On 10/21/2011 12:01 PM, Ted Hardie wrote: >>>> On Fri, Oct 21, 2011 at 10:37 AM, Matthew >>>> Kaufman wrote: >>>> Thought experiment: >>>> >>>> If one had a connection object that supported an underlying >>>> protocol that could send one or more encrypted flows of both >>>> real-time media and reliable data, what information would you need >>>> to exchange between the two browser endpoints in order to ensure >>>> that any pair of browsers with any future audio or video codec >>>> could use the best mutually-supported codecs? >>>> >>>> >>>> I think I am missing your point slightly. Do you mean the >>>> connection object talks to an abstraction layer that manages how >>>> the flows are sent, and the swapping occurs in what it manages, or >>>> do you mean the connection object should be able to swap out >>>> whether it is talking to ICE, DTLS-SRTP, or TCP-over-UDP >>>> transparently? or something else? >>> I mean "what if the connection object was sitting on top of >>> something like RTMFP", in other words a protocol that can trivially >>> be asked to open a secure (encrypted and authenticated) >>> NAT-traversing session between your browser and another browser and >>> then can deliver multiple parallel flows of partially-reliable media >>> and fully-reliable data (prioritized appropriately) to the far end. >>> >>> Then the next question I asked is, IF you had a connection object >>> like that, what is the minimum you need to get the >>> latest-and-greatest-codec-just-works behavior that Cullen, et. al. >>> have described? >>> >>> Matthew Kaufman >>> > > From wolfgang.beck01@googlemail.com Tue Nov 8 01:43:11 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0CB21F8CCA for ; Tue, 8 Nov 2011 01:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Cd6dx0a28-YJ for ; Tue, 8 Nov 2011 01:43:10 -0800 (PST) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id AD32821F8CC8 for ; Tue, 8 Nov 2011 01:43:10 -0800 (PST) Received: by pzk4 with SMTP id 4so953467pzk.9 for ; Tue, 08 Nov 2011 01:43:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=o5jNpkgVZHHP4Mg+GMn0bPpVx2dSITA9ZdISQ8ZWfwg=; b=XsRWub1p6RzdPg/y0UmNYKWuAgSaFoRV/LcM/lR5EDbPNddSNcyHIPBO17Zvq1B0De LvGWrUGQkXtNpLGsByTCCysfL/lAHXMy5ogye7ktDFD6uZujarS+sJVWbUduDzIKi1AG PRahCXNyeMkfkDTiTftlssw9KvOnmlffdm214= MIME-Version: 1.0 Received: by 10.68.52.134 with SMTP id t6mr6422322pbo.96.1320745390385; Tue, 08 Nov 2011 01:43:10 -0800 (PST) Received: by 10.68.64.66 with HTTP; Tue, 8 Nov 2011 01:43:10 -0800 (PST) In-Reply-To: <4EB816D1.1040708@jesup.org> References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <4EB74D06.8000006@jesup.org> <4EB7FAED.4070104@jesup.org> <4EB806F7.2090603@alvestrand.no> <4EB816D1.1040708@jesup.org> Date: Tue, 8 Nov 2011 10:43:10 +0100 Message-ID: From: Wolfgang Beck To: Randell Jesup Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Tue, 08 Nov 2011 09:43:11 -0000 On Mon, Nov 7, 2011 at 6:35 PM, Randell Jesup wrot= e: > On 11/7/2011 11:53 AM, Wolfgang Beck wrote: >> >> On Mon, Nov 7, 2011 at 5:27 PM, Harald Alvestrand >> =A0wrote: >> [on SIP-style forking] [..] > And I disagree with Harald here; telling the clients they should open > connections to the "caller" is exactly what parallel forking by the serve= r > does. =A0It tells them "here's the offer and ICE candidates, open a conne= ction > to the "caller" and complete negotiation." =A0It'd be silly not to includ= e the > OFFER in the message to the "callee's", since we have to send them the IC= E > candidates anyways - plus, the "callee's" may need that info for alerting= , > etc, and not providing it would add more round-trips. =A0Never forget tha= t > even half-round-trips can be PAINFUL to some applications! =A0And don't f= orget > that this might get used on links that bounce off a satellite (or two!), = or > transit low-bandwidth wireless networks or mesh networks, etc. =A0Now the= re's > RTT... ;-) > If you are on satellite links, the signaling round trip time is not your most pressing problem. Is forking really essential or is it just a way to optimize call setup time under certain conditions? Has forking still an advantage if you want to do multiple early media? [suppressing a remark how overlap dialing could speed up call setup times in some interop scenarios, too] Wolfgang Beck From pravindran@sonusnet.com Tue Nov 8 06:30:04 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8684A21F8CC5 for ; Tue, 8 Nov 2011 06:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.040, 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 3A-1yn1+06LX for ; Tue, 8 Nov 2011 06:30:03 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id B3DB221F8CC2 for ; Tue, 8 Nov 2011 06:30:02 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA8EUZFX017777; Tue, 8 Nov 2011 09:30:35 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 09:29:58 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 20:00:06 +0530 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.0339.001; Tue, 8 Nov 2011 20:00:06 +0530 From: Ravindran Parthasarathi To: Hadriel Kaplan , Eric Rescorla Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AQHMm7/XxS9yQix74UmCewMPtvNQWZWe2WiAgABcZwCAAFnsgIAA1PQAgACv/gCAAAVogIAAGdwAgAHTzNA= Date: Tue, 8 Nov 2011 14:30:06 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Nov 2011 14:30:06.0667 (UTC) FILETIME=[E94631B0:01CC9E22] Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Tue, 08 Nov 2011 14:30:04 -0000 I agree with Hadriel that it is not required to mandate SRTP for WebRTC. My= reasoning are as follows: 1) Security could be in the lower layer itself (IPsec, VPN, private MPLS cl= oud). For Enterprise-only-WebRTC application (no federation & no interop), = there is no need of security by specific application like WebRTC as it is e= nsured in the infrastructure. WebRTC security will be duplicated for these = infrastructure and may leads double encryption unnecessarily. 2) Being in India, I'm interested in avoiding Government restriction on Web= RTC proposal (Thanks to Tim for pointing this). I may not surprise to see t= hat WebRTC mechanism is banned in India because intelligent agency struggle= s to break the key in each terrorist WebRTC site. (http://www.pcworld.com/b= usinesscenter/article/235639/india_wants_to_intercept_skype_google_communic= ations.html) In case there is no use case to illustrate in RTCWeb draft, let us discuss = in detail. >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Hadriel Kaplan >Sent: Monday, November 07, 2011 9:12 PM >To: Eric Rescorla >Cc: >Subject: Re: [rtcweb] Let's define the purpose of WebRTC > > >On 11/07/2011 02:50 PM, Eric Rescorla wrote: >> On Sun, Nov 6, 2011 at 7:20 PM, Hadriel Kaplan >wrote: >>> Who said "too slow"? There *is* an extra round-trip or two involved >I presume, if we're talking DTLS-SRTP, but no I didn't mean that as a >"hit". I just meant the extra computing cycles for SRTP being a "hit". >For WebRTC-to-WebRTC I don't think that matters at all. For WebRTC-to- >media-server it might, for a free game app or greeting card app that >don't care about it to begin with, and which use plaintext HTTP to begin >with. >> Sorry, I didn't mean to put words in your mouth. Performance >measurements >> of HTTP versus HTTPS in modern Web environments suggest that the >additional >> load for HTTPS is not significant. Do you have evidence that the >situation is >> different for SRTP versus RTP? > >Only from the DSP guys, and those would be hardware DSPs not softDSPs. >It runs them anywhere from 10-25% overhead, they say, depending on the >vendor and what else their DSPs are doing at the time. > >But ultimately even in software I assume it's all relative to what other >work you're doing. If you have to render a video stream on a screen and >encode camera input into a codec being sent out, then my guess is SRTP >overhead is a tiny factor not worth talking about. If you're mixing >multiple RTP streams as a conference server, then I assume doing SRTP >for thousands of simultaneous audio RTP streams for multiple >simultaneous conferences becomes noticeable. Or at least so they seem >to claim - I don't know since I don't build a media server (hardware >SBCs often offload SRTP onto dedicated hardware). One large software >company even created their own proprietary packet format for SRTP that >they claimed was done for improving performance/scalability, so I assume >it has some impact they don't want their customers to incur. > >-hadriel > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Tue Nov 8 06:40:46 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D4E21F8CC5 for ; Tue, 8 Nov 2011 06:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 PuQjY2DKo3TH for ; Tue, 8 Nov 2011 06:40:45 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 35C5A21F8AE1 for ; Tue, 8 Nov 2011 06:40:45 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-e6-4eb93f6c8936 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id FE.F2.13753.C6F39BE4; Tue, 8 Nov 2011 15:40:44 +0100 (CET) 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.137.0; Tue, 8 Nov 2011 15:40:43 +0100 Message-ID: <4EB93F69.7090809@ericsson.com> Date: Tue, 8 Nov 2011 15:40:41 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <4EB3AE5B.4090401@ericsson.com> <3815A3A8-A6CF-4024-9FBD-AE2E7D2A2211@acmepacket.com> In-Reply-To: <3815A3A8-A6CF-4024-9FBD-AE2E7D2A2211@acmepacket.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" , "Bran, Cary" Subject: Re: [rtcweb] NAT 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: Tue, 08 Nov 2011 14:40:46 -0000 On 2011-11-05 00:35, Hadriel Kaplan wrote: > > > On Nov 4, 2011, at 5:20 AM, Magnus Westerlund wrote: > >> I think a document of this type should and will eventually be >> published as its own RFC. The reason for this I think is that the >> document should evolve from requirements to actually specify how >> the Peer to Peer transport flow establishment layer for WebRTC >> works. As that layer will be used by both the RTP based media >> transport and the Data Transport having a document only containing >> that functionality will make it simpler to reference. >> >> In addition I think it is good from specification maintenance >> perspective. If we have bugs in a functionality block we don't need >> to republish other functionality blocks just to update, in this >> case the NAT traversal functionality. >> >> Given that a NAT traversal document will specify how WebRTC >> establish the transport flows do you think that really should be >> part of the use-cases and requirements? > > Hey you're one of the Chairs - if the Chairs want to have a dozen > RFCs on requirements, and another dozen on actual behavior, that's > your call. Seems silly to me, but most of the admin work is on the > authors, the Chairs, and the ADs I think... so it's no skin off my > nose to have more RFCs. No, you misunderstood me, or more likely I wasn't clear enough. I at least, expect the NAT draft to define how to actually do it. Not requirements on the solution. > > As I said in my email: draft-ietf-rtcweb-use-cases-and-requirements > is high-layer/general WebRTC requirements, and if we want a separate > detailed specification, that would make sense (or even multiple if > that's your preference). But draft-cbran-rtcweb-nat-02 doesn't > appear to be that - it reads like a requirements for NAT traversal > mechanism, and that the answer to that is native ICE support. Agreed, and I do expect the document to go in the direction of a specification of what is needed to implement by the WebRTC end-point. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From oej@edvina.net Tue Nov 8 07:00:10 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1163A21F8CE6 for ; Tue, 8 Nov 2011 07:00:10 -0800 (PST) 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.200, BAYES_00=-2.599, HELO_EQ_SE=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 tYWQpXEsj178 for ; Tue, 8 Nov 2011 07:00:09 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 0317821F8CE5 for ; Tue, 8 Nov 2011 07:00:09 -0800 (PST) Received: from [192.168.20.63] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp7.webway.se (Postfix) with ESMTPA id 71948754BCD5; Tue, 8 Nov 2011 15:00:05 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> Date: Tue, 8 Nov 2011 15:58:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> To: Ravindran Parthasarathi X-Mailer: Apple Mail (2.1251.1) Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Tue, 08 Nov 2011 15:00:10 -0000 8 nov 2011 kl. 15:30 skrev Ravindran Parthasarathi: > I agree with Hadriel that it is not required to mandate SRTP for = WebRTC. My reasoning are as follows: >=20 > 1) Security could be in the lower layer itself (IPsec, VPN, private = MPLS cloud). For Enterprise-only-WebRTC application (no federation & no = interop), there is no need of security by specific application like = WebRTC as it is ensured in the infrastructure. WebRTC security will be = duplicated for these infrastructure and may leads double encryption = unnecessarily. For me this is not a valid objection. You can not ask the customer to = try to find out if they are using the web browser in a secure or in an = insecure=20 network... That paradigm will just fail. >=20 > 2) Being in India, I'm interested in avoiding Government restriction = on WebRTC proposal (Thanks to Tim for pointing this). I may not surprise = to see that WebRTC mechanism is banned in India because intelligent = agency struggles to break the key in each terrorist WebRTC site. = (http://www.pcworld.com/businesscenter/article/235639/india_wants_to_inter= cept_skype_google_communications.html) That is an interesting objection. I don't think SRTP by default is the = problem here. In the case where you need lawful interception in the = application, the server needs to route the calls through an RTCweb b2b media server. /O >=20 > In case there is no use case to illustrate in RTCWeb draft, let us = discuss in detail. >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf >> Of Hadriel Kaplan >> Sent: Monday, November 07, 2011 9:12 PM >> To: Eric Rescorla >> Cc: >> Subject: Re: [rtcweb] Let's define the purpose of WebRTC >>=20 >>=20 >> On 11/07/2011 02:50 PM, Eric Rescorla wrote: >>> On Sun, Nov 6, 2011 at 7:20 PM, Hadriel = Kaplan >> wrote: >>>> Who said "too slow"? There *is* an extra round-trip or two = involved >> I presume, if we're talking DTLS-SRTP, but no I didn't mean that as a >> "hit". I just meant the extra computing cycles for SRTP being a = "hit". >> For WebRTC-to-WebRTC I don't think that matters at all. For = WebRTC-to- >> media-server it might, for a free game app or greeting card app that >> don't care about it to begin with, and which use plaintext HTTP to = begin >> with. >>> Sorry, I didn't mean to put words in your mouth. Performance >> measurements >>> of HTTP versus HTTPS in modern Web environments suggest that the >> additional >>> load for HTTPS is not significant. Do you have evidence that the >> situation is >>> different for SRTP versus RTP? >>=20 >> Only from the DSP guys, and those would be hardware DSPs not = softDSPs. >> It runs them anywhere from 10-25% overhead, they say, depending on = the >> vendor and what else their DSPs are doing at the time. >>=20 >> But ultimately even in software I assume it's all relative to what = other >> work you're doing. If you have to render a video stream on a screen = and >> encode camera input into a codec being sent out, then my guess is = SRTP >> overhead is a tiny factor not worth talking about. If you're mixing >> multiple RTP streams as a conference server, then I assume doing SRTP >> for thousands of simultaneous audio RTP streams for multiple >> simultaneous conferences becomes noticeable. Or at least so they = seem >> to claim - I don't know since I don't build a media server (hardware >> SBCs often offload SRTP onto dedicated hardware). One large software >> company even created their own proprietary packet format for SRTP = that >> they claimed was done for improving performance/scalability, so I = assume >> it has some impact they don't want their customers to incur. >>=20 >> -hadriel >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From magnus.westerlund@ericsson.com Tue Nov 8 07:19:30 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFBC21F8CE6 for ; Tue, 8 Nov 2011 07:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 tU3YeElzNt06 for ; Tue, 8 Nov 2011 07:19:29 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 46D4D21F8CC3 for ; Tue, 8 Nov 2011 07:19:29 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-7d-4eb948804e1e Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A7.09.13753.08849BE4; Tue, 8 Nov 2011 16:19:28 +0100 (CET) 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.137.0; Tue, 8 Nov 2011 16:19:27 +0100 Message-ID: <4EB9487F.4080303@ericsson.com> Date: Tue, 8 Nov 2011 16:19:27 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Harald Alvestrand References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB79FC2.10400@alvestrand.no> In-Reply-To: <4EB79FC2.10400@alvestrand.no> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [rtcweb] SRTP - mandatory to implement vs mandatory to use (Re: Let's define the purpose of 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: Tue, 08 Nov 2011 15:19:30 -0000 On 2011-11-07 10:07, Harald Alvestrand wrote: > > At the moment, draft-ietf-rtcweb-rtp-usage does not contain any > requirement on SRTP usage (the security section says "A mandatory to > implement media security solution will be required to be picked", which > I think is a bit weak), and the discussion at the time did not seem to > indicate consensus that SRTP must be used always, so I decided to > document what we seemed to have consensus on - that SRTP MUST be > implemented. Yes, we haven't spent much time on the security consideration section yet. "A mandatory to implement media security solution will be required to be picked" is pointer at this WG not the implementor. I would also point at our Charter that in its last paragraph says: "The products of the working group will support security and keying as required by BCP 61" If you haven't read BCP 61 you probably should. It is basically says two things. IETF should pick strong security and it shall be MANDATORY to IMPLEMENT. I at least as chair will ensure that we have fulfilled this. And that means for RTP not only encryption and integrity protection, probably SRTP, but also a keying method. Yes, we (authors of draft-ietf-rtcweb-rtp-usage) will write that SRTP is a MUST implement as soon as we have that consensus established. But we will need a keying scheme also and determine where it should be documented. 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 fluffy@cisco.com Tue Nov 8 07:59:08 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD1C21F8B1B for ; Tue, 8 Nov 2011 07:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.415 X-Spam-Level: X-Spam-Status: No, score=-106.415 tagged_above=-999 required=5 tests=[AWL=0.184, 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 v-i2LqGu6P2Y for ; Tue, 8 Nov 2011 07:59:07 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6F74721F8B08 for ; Tue, 8 Nov 2011 07:59:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1476; q=dns/txt; s=iport; t=1320767947; x=1321977547; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=dL1XdmoCtabiGvZJk3RoQPAPvUlSgXRbdhToeJU2OQ4=; b=dOQ1XvmAo0aiMxCt8GN9LFM/SjeickzrDl5/PFEcn2mIw9YziH9RVOex +xlo4RwMl1cgxPjBqOt3M/rjN60jhbcEYybJZm8O0nTrsexC3eCjHdViX v63FSrryRuNxslDAnDOi2LBKIGgzJuUUkB/KK03QRsfU7C8cyY0HTd/EE 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAMdQuU6rRDoI/2dsb2JhbABDqGGBJoEFgXIBAQEEEgEnLBMQC0ZXBjWHaJhXAZ8miEpjBIgLjBaFMYxd X-IronPort-AV: E=Sophos;i="4.69,477,1315180800"; d="scan'208";a="12953804" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 08 Nov 2011 15:59:07 +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 pA8Fx61Q017381; Tue, 8 Nov 2011 15:59:06 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> Date: Tue, 8 Nov 2011 08:59:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1084) Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Tue, 08 Nov 2011 15:59:08 -0000 On Nov 8, 2011, at 7:58 AM, Olle E. Johansson wrote: >>=20 >> 2) Being in India, I'm interested in avoiding Government restriction = on WebRTC proposal (Thanks to Tim for pointing this). I may not surprise = to see that WebRTC mechanism is banned in India because intelligent = agency struggles to break the key in each terrorist WebRTC site. = (http://www.pcworld.com/businesscenter/article/235639/india_wants_to_inter= cept_skype_google_communications.html) > That is an interesting objection. I don't think SRTP by default is the = problem here. In the case where you need lawful interception in the = application, > the server needs to route the calls through an RTCweb b2b media = server. I think the situation in India is a taxiation not encryption issue. = Partha and I can do VoIP between Canada and India fully encrypted no = problem - in fact we have a dial plan set up specifically so I can do = that with him. The issue is a taxation issue. If we want to be able to = connect that voip server to the PSTN in a way that it becomes what the = regulators in India consider a telephone service, then we need = permission to effectively be an indian telco. Right now I can make a = full SRTP encrypted conversation with between my IP phones and Partha's = but I don't think Partha can use his IP phone to access one the the PSTN = GWs outside India.=20 Anyways, I will remind people of RAVEN = http://www.rfc-editor.org/rfc/rfc2804.txt From roman@telurix.com Tue Nov 8 08:01:27 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8602021F8AAA for ; Tue, 8 Nov 2011 08:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.888 X-Spam-Level: X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[AWL=0.088, 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 RdQ1mpgxQCuA for ; Tue, 8 Nov 2011 08:01:27 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E598D21F8A58 for ; Tue, 8 Nov 2011 08:01:26 -0800 (PST) Received: by qadc10 with SMTP id c10so572865qad.10 for ; Tue, 08 Nov 2011 08:01:26 -0800 (PST) Received: by 10.229.26.73 with SMTP id d9mr2106934qcc.290.1320768086141; Tue, 08 Nov 2011 08:01:26 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by mx.google.com with ESMTPS id du5sm1867711qab.14.2011.11.08.08.01.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Nov 2011 08:01:25 -0800 (PST) Received: by qyk32 with SMTP id 32so704089qyk.10 for ; Tue, 08 Nov 2011 08:01:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.72.103 with SMTP id c7mr1888554pbv.1.1320768084939; Tue, 08 Nov 2011 08:01:24 -0800 (PST) Received: by 10.68.62.170 with HTTP; Tue, 8 Nov 2011 08:01:24 -0800 (PST) In-Reply-To: <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> Date: Tue, 8 Nov 2011 11:01:24 -0500 Message-ID: From: Roman Shpount To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=f46d041b47f688950004b13b4863 Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Tue, 08 Nov 2011 16:01:27 -0000 --f46d041b47f688950004b13b4863 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 8, 2011 at 9:58 AM, Olle E. Johansson wrote: > > That is an interesting objection. I don't think SRTP by default is the > problem here. In the case where you need lawful interception in the > application, > the server needs to route the calls through an RTCweb b2b media server. > > SRTP is exactly what is the problem here. Do not confuse this with lawful intercept in the application. This is about encrypted communications being illegal in some places. If your web site is using encryption or cannot be accessed without encryption it would be blocked. As an example we are all familiar with, think about the key length restrictions TLS used to have due to US export regulations. This has been lifted, but there are numerous regulations in other countries that prohibit encryption at all, across the borders, or from certain institutions (like prisons). I am not arguing that we should not include SRTP. In fact I think we must, but it should be possible to turn it off. ______________ Roman Shpount --f46d041b47f688950004b13b4863 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 8, 2011 at 9:58 AM= , Olle E. Johansson <oej@edvina.net> wrote:

That is an interesting objection. I don't think SRTP by default is the = problem here. In the case where you need lawful interception in the applica= tion,
the server needs to route the calls through an RTCweb b2b media server.


SRTP is exactly what is the problem here. Do not = confuse this with lawful intercept in the application. This is about encryp= ted communications being illegal in some places. If your web site is using = encryption or cannot be accessed without encryption it would be blocked. As= an example we are all familiar with, think about the key length restrictio= ns TLS used to have due to US export regulations. This has been lifted, but= there are numerous regulations in other countries that prohibit encryption= at all, across the borders, or from certain institutions (like prisons).
I am not arguing that we should not include SRTP. In fact I think we mu= st, but it should be possible to turn it off.
______________
Roman Sh= pount
--f46d041b47f688950004b13b4863-- From randell-ietf@jesup.org Tue Nov 8 08:42:44 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492E321F8B62 for ; Tue, 8 Nov 2011 08:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 eBiZ8j2iQjMi for ; Tue, 8 Nov 2011 08:42:43 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id B7DBD21F8B4A for ; Tue, 8 Nov 2011 08:42:43 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RNol0-00064C-Sk for rtcweb@ietf.org; Tue, 08 Nov 2011 10:42:42 -0600 Message-ID: <4EB95BE1.5060706@jesup.org> Date: Tue, 08 Nov 2011 11:42:09 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <9C4C8AE2-4AFF-4553-9D19-556F12AC066E@phonefromhere.com> <9B907E0E-7FE7-4302-BDFA-CEEC12734B8C@edvina.net> <7BF02133-2A7E-48ED-982F-90B7868F9FB9@phonefromhere.com> <4EB74D06.8000006@jesup.org> <4EB7FAED.4070104@jesup.org> <4EB806F7.2090603@alvestrand.no> <4EB816D1.1040708@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] Let's define the purpose of 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: Tue, 08 Nov 2011 16:42:44 -0000 On 11/8/2011 4:43 AM, Wolfgang Beck wrote: > On Mon, Nov 7, 2011 at 6:35 PM, Randell Jesup wrote: >> On 11/7/2011 11:53 AM, Wolfgang Beck wrote: >>> >>> On Mon, Nov 7, 2011 at 5:27 PM, Harald Alvestrand >>> wrote: >>> [on SIP-style forking] > [..] >> And I disagree with Harald here; telling the clients they should open >> connections to the "caller" is exactly what parallel forking by the server >> does. It tells them "here's the offer and ICE candidates, open a connection >> to the "caller" and complete negotiation." It'd be silly not to include the >> OFFER in the message to the "callee's", since we have to send them the ICE >> candidates anyways - plus, the "callee's" may need that info for alerting, >> etc, and not providing it would add more round-trips. Never forget that >> even half-round-trips can be PAINFUL to some applications! And don't forget >> that this might get used on links that bounce off a satellite (or two!), or >> transit low-bandwidth wireless networks or mesh networks, etc. Now there's >> RTT... ;-) >> > If you are on satellite links, the signaling round trip time is not > your most pressing problem. Yes, but people do talk over them, and may do other "real-time" things over them. Sometimes that's simply the only option. Even my Uncle in Virginia "horse country" (= $$$$$) can't get anything better than dial-up or satellite internet, because houses are so far apart and far from telco office. And then there are people/soldiers/etc in 3rd-world countries or disaster relief efforts, etc. > > Is forking really essential or is it just a way to optimize call setup > time under certain conditions? I think in most cases you can set up the calls with other methods of varying complexity and delays. Hard to be sure that all uses would be covered by that, and some might involve extra consents be generated to the user, or some method of tying the OFFERs together, and I'm not sure that can easily be done if we don't trust the JS code. (though it might not be a real concern - we haven't looked at this re: security/privacy yet). > Has forking still an advantage if you want to do multiple early media? I suspect forking is an advantage here, but haven't analyzed it. -- Randell Jesup randell-ietf@jesup.org From harald@alvestrand.no Tue Nov 8 14:28:23 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B474F21F85BB for ; Tue, 8 Nov 2011 14:28:23 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peeEOEqti48j for ; Tue, 8 Nov 2011 14:28:23 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1184521F85AE for ; Tue, 8 Nov 2011 14:28:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 60CEA39E0F3; Tue, 8 Nov 2011 23:28:06 +0100 (CET) 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 mTgp+BR4WrZe; Tue, 8 Nov 2011 23:28:05 +0100 (CET) Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 586DC39E072; Tue, 8 Nov 2011 23:28:05 +0100 (CET) Message-ID: <4EB9ACF5.80805@alvestrand.no> Date: Tue, 08 Nov 2011 23:28:05 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of 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: Tue, 08 Nov 2011 22:28:23 -0000 Changing the subject again to mention SRTP.... On 11/08/2011 03:30 PM, Ravindran Parthasarathi wrote: > I agree with Hadriel that it is not required to mandate SRTP for WebRTC. My reasoning are as follows: > > 1) Security could be in the lower layer itself (IPsec, VPN, private MPLS cloud). For Enterprise-only-WebRTC application (no federation& no interop), there is no need of security by specific application like WebRTC as it is ensured in the infrastructure. WebRTC security will be duplicated for these infrastructure and may leads double encryption unnecessarily. This argument makes some sense. > > 2) Being in India, I'm interested in avoiding Government restriction on WebRTC proposal (Thanks to Tim for pointing this). I may not surprise to see that WebRTC mechanism is banned in India because intelligent agency struggles to break the key in each terrorist WebRTC site. (http://www.pcworld.com/businesscenter/article/235639/india_wants_to_intercept_skype_google_communications.html) This argument is contrary to stated IETF policy (RFC 2804). I recommend the RFC for background reading. > > In case there is no use case to illustrate in RTCWeb draft, let us discuss in detail. > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of Hadriel Kaplan >> Sent: Monday, November 07, 2011 9:12 PM >> To: Eric Rescorla >> Cc: >> Subject: Re: [rtcweb] Let's define the purpose of WebRTC >> >> >> On 11/07/2011 02:50 PM, Eric Rescorla wrote: >>> On Sun, Nov 6, 2011 at 7:20 PM, Hadriel Kaplan >> wrote: >>>> Who said "too slow"? There *is* an extra round-trip or two involved >> I presume, if we're talking DTLS-SRTP, but no I didn't mean that as a >> "hit". I just meant the extra computing cycles for SRTP being a "hit". >> For WebRTC-to-WebRTC I don't think that matters at all. For WebRTC-to- >> media-server it might, for a free game app or greeting card app that >> don't care about it to begin with, and which use plaintext HTTP to begin >> with. >>> Sorry, I didn't mean to put words in your mouth. Performance >> measurements >>> of HTTP versus HTTPS in modern Web environments suggest that the >> additional >>> load for HTTPS is not significant. Do you have evidence that the >> situation is >>> different for SRTP versus RTP? >> Only from the DSP guys, and those would be hardware DSPs not softDSPs. >> It runs them anywhere from 10-25% overhead, they say, depending on the >> vendor and what else their DSPs are doing at the time. >> >> But ultimately even in software I assume it's all relative to what other >> work you're doing. If you have to render a video stream on a screen and >> encode camera input into a codec being sent out, then my guess is SRTP >> overhead is a tiny factor not worth talking about. If you're mixing >> multiple RTP streams as a conference server, then I assume doing SRTP >> for thousands of simultaneous audio RTP streams for multiple >> simultaneous conferences becomes noticeable. Or at least so they seem >> to claim - I don't know since I don't build a media server (hardware >> SBCs often offload SRTP onto dedicated hardware). One large software >> company even created their own proprietary packet format for SRTP that >> they claimed was done for improving performance/scalability, so I assume >> it has some impact they don't want their customers to incur. >> >> -hadriel >> >> _______________________________________________ >> 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 Tue Nov 8 14:50:50 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6CE21F8B05 for ; Tue, 8 Nov 2011 14:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.122 X-Spam-Level: X-Spam-Status: No, score=-107.122 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_55=0.6, 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 Ojc5tbhOMGyU for ; Tue, 8 Nov 2011 14:50:49 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 052B921F8B03 for ; Tue, 8 Nov 2011 14:50:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=9190; q=dns/txt; s=iport; t=1320792634; x=1322002234; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=RP3p8FLcwVCqTdHH1bGaglSOSzZczRbWwQEdikb9k1U=; b=YJ1benG8QuQTMKNhMmCqr07zIZmsyQVFwUJB5ECfHXrXcSYPAL6OUVrz VYs4tACr9dSd2bnU+sbS5/MXBmrodf0L7xB2Nz9neLil/joJRnCgXcawP 0OKKqhfMjAvciX7+P4yGtAmth5qfBlSDy8KhRk1Z6Xji742krb0iE1QQh w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FAASyuU6rRDoG/2dsb2JhbABDqH2BJoEFgXIBAQEDAQEBAQkGAVsLBQkCCz8HGwwfEQYTGweHYAiZMwGeYwQCiEhjBIgLjBaFMYxd X-IronPort-AV: E=Sophos;i="4.69,479,1315180800"; d="scan'208";a="13069372" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 08 Nov 2011 22:50:33 +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 pA8MoWQM023260; Tue, 8 Nov 2011 22:50:33 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <4EB26945.40607@ericsson.com> Date: Tue, 8 Nov 2011 15:50:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0E287F18-E335-472D-853A-0A1B449D2AD7@cisco.com> References: <4EB26945.40607@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] State of the Forking discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Nov 2011 22:50:50 -0000 Much of this I don't feel too strongly about but there is one thing that = I do have a strong opinion on. I don't want to require PRACK for legacy = SIP support because it is has many problems.=20 Cullen On Nov 3, 2011, at 4:13 AM, Magnus Westerlund wrote: > WG, >=20 > I just reviewed the last weeks Forking discussion. This includes the > threads "RTCWeb Forking usecase [was RE: > draft-kaplan-rtcweb-sip-interworking-requirements-00]" and "Media > forking solution for SIP interoperability (without a media gateway)" >=20 > As far as I can tell there is not yet even a rough consensus. = Therefore > I will attempt to summarize what I personally believe to be the > important points and alternatives in this discussion. Keep in mind = that > my assumptions or understanding may be unclear or have errors. So = don't > hesitate to challenge what I write. >=20 > I think it is important that there are in fact at least two important > questions here. >=20 > 1. Is forking needed to be supported at all? >=20 > 2. If it is supported in which form would it supported in. >=20 > so lets start looking into the arguments and possibilities for these = two > questions. And I do hope that you will read to the end of this mail > which is quite long. >=20 > Lets start with the high level functionality part. Is forking needed = and > what usage does it have. So forking is all about sending out an > invitation to a media session including an actual media configuration > offer, i.e. SDP Offer, then get more than a single answer to that = offer > back. How you deal with these answers as they come in is the = difference > between serial and parallel forking. So lets define those. >=20 > Parallel forking: For each answer you receive you establish a new = actual > media session. Thus if you receive two answers you will have to > different media sessions that are potentially in use at the same time. >=20 > Serial forking: The first answer is received and results the > establishment of a media session. At a later point in time a second > answer is received. At that point you take the decision if that second > answer is going to be used to establish a new media session that > replaces the first one. In other words at any given time you will only > have a single media session established based on each offer. >=20 > So there has been a number of different views on how one can see on > forking. And I think I will have to bring in a bit reflections on how > this can be done with the current PeerConnection API. >=20 > A) No forking is needed: Between WebRTC end-points there is no need = for > forking. Instead the application can send out session invitations to = the > peers it wants to talk to. These are without any SDP Offer equivalent, > instead end-points that want to communicate they create = PeerConnections, > which results in SDP Offers. Thus the communication initiating = end-point > becomes the ones that provides SDP answers and get one PeerConnection > per remote end-point that actually want to communicate. >=20 > B) We need to have some interworking with SIP: So the fundamental here > is that it needs to be reasonable to interwork with SIP, independent = if > one uses a SIP in JS in the application running on the WebRTC enabled > browser, or have signalling gateway in the webserver, or as a remote > WebRTC peer. The issue is that A)'s method of initiating call doesn't > work well with SIP. There is a need to send a SIP Invite with an SDP > Offer and that can result in multiple answers. >=20 > To resolve this one could deal with this in a couple of different = ways: >=20 > B1) Use I=F1aki's proposal which forces the WebRTC application to = create a > second PeerConnection and then forces an update in the SIP domain with > the second peer-connections Offer. However, it was pointed out that = this > doesn't work with SIP Provisional answers, as used by ICE for example, > unless PRACK is supported. The level of PRACK support is reasonable = but > far from universal so this would limit the SIP UAs one can interwork > with. However, from WebRTC perspective no forking support is needed. A > single PeerConnection results in one offer and a single answer is > processed. >=20 > B2) Require WebRTC to handle replace Answers: So the idea here is that > one changes the PeerConnection API and have underlying functionality = so > that at any point in time a new Answer can pushed onto a = PeerConnection > and that forces the media session to be reestablished if needed. So if > the ICE candidate list is different an ICE restart happens. This = clearly > supports serial forking. It also can create some complexities in the > underlying SDP handling logic if one desires to minimize the media = impact. >=20 > B3) Local side shared parameters in multiple PeerConnections: The idea > in this proposal is that all PeerConnections generated in a browser > context, like a tab will implicit share the fundamental parameters = like > ICE candidates etc for the number of media streams added. So if one > creates a second PeerConnection with the same audio+video MediaStream > object added I will get an offer that is mostly identical to the the > first PeerConnection, thus I can push in the answer from the first > PeerConnection Offer into the second PC object and it will still work. > The downside of this is that it is implicit and it becomes difficult = to > determine when it works and when it will fail. It will also be highly > dependent on the application performing the right process to get it to > work. It also causes a sharing of the parameters when not needed or > desired, which primarily is an issue from a security point of view, > especially with SDES keys (see below). The positive is this likely > requires no API changes. This method would also support parallel = forking. >=20 > B4) Cloning/Factory for PeerConnection: On the API level there will be > explicit support for generating multiple PeerConnections from the same > base. This could either be a factory for PeerConnections or some = Object > constructor that clones an existing PeerConnection but that is a W3C > question. By being explicit some of the B3) issues goes away and the > applications can choose when this should happen or not. This also > support parallel forking as the application can deal with each media > session independently. This clearly will have some impact on the API. >=20 >=20 > Additional considerations: >=20 > Shared SDES keys: B2 to B4 will result in that SDES keys from the > Offering party to be used towards all invited parties. This is = security > risk as any of the invited parties can spoof the offering side towards > any of the other invited parties. This threat can be resolved by = having > the inviter rekey immediately after having received an answer. >=20 > Sharing ICE candidates: B3 and B4 and also B2 to some degree will = share > the ICE candidates. That has certain implications. One is the positive > in that it minimizes the resource consumption as additional > PeerConnections come at very little extra cost, no need for additional > ICE gathering candidate phases, and also be very quick as no external > communication is required. The downside of this is that the end-points > candidates must always be kept alive as long as some PeerConnection > instance exist. Because the browser never knows when the application = may > create an additional PC and expect them to have the same ICE = candidates. > It should also be noted that the answering WebRTC end-point will need = to > gather candidates for each offer. Otherwise it will become impossible = to > create multiple PeerConnections between the same end-points if that is > desired by the application. >=20 >=20 > I know the above doesn't list all of the pro and cons of the different > alternatives. So please fill in additional arguments. And if I missed > some proposal please add that also if relevant >=20 > As you may have noted I the two questions in the above have kind of > floated together. The reason for this is that I think the majority are > fine with having SIP support as long as it doesn't have to high cost = or > complexity associated with it. Thus, the question how becomes very > intertwined with forking support yes or no. >=20 > So please continue the discussion >=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 fluffy@cisco.com Tue Nov 8 14:57:27 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3941F0C70 for ; Tue, 8 Nov 2011 14:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.439 X-Spam-Level: X-Spam-Status: No, score=-106.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 f96FfbBxprcG for ; Tue, 8 Nov 2011 14:57:27 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 320221F0C6F for ; Tue, 8 Nov 2011 14:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2112; q=dns/txt; s=iport; t=1320793047; x=1322002647; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=++pfCUJUH2BVvFjIPK9Fo7FxJjRvC3qEImhIFnoe2Oc=; b=MrGMK3D5r6vmGvf6pEQLlI1ps8A8bo7ELPuGOcZfZUg+c2BexHHXVk8O FUO0M+wmSjg5gCaJhjv71WrbOjqllj7ah6T3X2FF62mZqU4q6Sy8anD+s Uvquv3ygE/1qjcK7uF6Dj8v8IWTEzPy6fB/W1y34NXQtmBe8Od87952F7 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FAF+zuU6rRDoG/2dsb2JhbABDqH2BJoEFgXIBAQEDAQEBAQ8BJzQLBQsLRicwBhMih2AImTsBi1STE4hKYwSIC4wWhTGFEIdN X-IronPort-AV: E=Sophos;i="4.69,479,1315180800"; d="scan'208";a="13056041" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 08 Nov 2011 22:57:26 +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 pA8MvMEp027166; Tue, 8 Nov 2011 22:57:22 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com> Date: Tue, 8 Nov 2011 15:57:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6CB98137-B2A4-488C-BF5C-D7D87B23C7EC@cisco.com> References: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com> To: Tim Panton X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Usecases for innovation. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Nov 2011 22:57:27 -0000 Hmm ... both of these seem to work fine with the direction we are = going....both require the W3C getMedia API to allow JS access to the = data so it's more of a W3C issue than IETF but my read of the tea leafs = is that is the direction W3C is going. At the TPAC meeting Opera bought = up good use cases for this and they seemed to get a good reception that = people wanted to solve them. My recollection was there were only one or = two people at IETF objecting to JS access to media ( and come to think = of they were all fans of the "low level" API :-) For purpose of = argument, one could imagine implementing the Kinect stereo correlation = in JS and just using any two camera along with auto calibration of = geometry. That would be cool.... On Nov 1, 2011, at 2:30 AM, Tim Panton wrote: > I've repeatedly been asked for use-cases for innovative applications = of webRTC > to justify my contention that we should be providing a low-level = framework, > not an embedded legacy compatibility application. >=20 > It's a 'when did you stop beating your wife?' question, there is no = good answer. > By definition we don't know what innovative uses are yet, so we are = reduced to > guessing, which sounds unconvincing. >=20 > By chance, this weekend I was exposed to 2 innovative uses of = real-time-communications > in a browser that _won't_ fit in the current looking-over-its-shoulder = scheme. >=20 > 1) H264 implementation in Javascript http://yfrog.com/nmng0z=20 > 2) Kinect as an input device for a virtual receptionist in a real = reception area > (Voxeo's as it happens). >=20 > Neither of these are production ready - or indeed necessarily a good = idea, > but the fact that neither (minor) innovation fits at all into our = brand new framework > should give us pause for thought. (but given the pell-mell dash to be = compatible > with last century's deskphones I don't imagine it will). >=20 > Tim. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Tue Nov 8 15:05:26 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B3D11E80AD for ; Tue, 8 Nov 2011 15:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.442 X-Spam-Level: X-Spam-Status: No, score=-106.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 Rs3NyzrjMHw1 for ; Tue, 8 Nov 2011 15:05:26 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECD411E80A3 for ; Tue, 8 Nov 2011 15:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=934; q=dns/txt; s=iport; t=1320793526; x=1322003126; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=79E0WG3qe4ANQ44Wm0TByGsCC5fH6QDzguzWYl2jw1o=; b=kIPKUAB6em/WNGyVArjelNyFewm9tGGtjCxD7+s1Pexrwf5OGseEeV7M l2otVMzSIn/i1HxrhMIfYnSq2fukxgHYRrt5LkkI+oPrj3yB1oHNtfRmX XpckK9cCI0kr/xe8TKlNEcrY0PzAGR/q9w4IEB9zvZ1bHkONYMWeVNbSB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANG0uU6rRDoG/2dsb2JhbABDqiOBBYFyAQEBAwESASc4BwULCzsLVwY1h2CZOAGeZohKYwSIC4wWhTGMXQ X-IronPort-AV: E=Sophos;i="4.69,479,1315180800"; d="scan'208";a="11566862" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 08 Nov 2011 23:05:26 +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 pA8N5PbK001156; Tue, 8 Nov 2011 23:05:25 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4EB14599.5000509@ericsson.com> Date: Tue, 8 Nov 2011 16:05:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6BC2ABF1-B528-4951-B50A-F74AE77A9772@cisco.com> References: <4EB14599.5000509@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Summary of draft-sipdoc-rtcweb-open-wire-protocol-00 (Open In-The-Wire Protocol for RTC-Web) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Nov 2011 23:05:26 -0000 On Nov 2, 2011, at 7:28 AM, Magnus Westerlund wrote: > The second piece I think the authors of the ROAP draft should take = into > consideration on their next update to clarify the purpose of the > protocol and its relation to the API the application. Noted and will try to do that in the next version. = I expect a future version of API draft to change to have a reference to = ROAP which will make this all much easier to explain.=20 The main thing I want to emphasize is that if we go down the ROAP path, = it does not mandate you have to use ROAP. If you want to implement SIP = in JS, or your own special protocol, that is all just fine. It's just = one think you could use if you wanted and I would expect to see some Web = to SIP gateways implement it. It also does not stop the definition of a = low level API. It could exist side by side with things using a low level = API.=20= From fluffy@cisco.com Tue Nov 8 15:09:28 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F73E11E80A3 for ; Tue, 8 Nov 2011 15:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.445 X-Spam-Level: X-Spam-Status: No, score=-106.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 ZhRvGrTZfE3C for ; Tue, 8 Nov 2011 15:09:27 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id AAE7821F84B2 for ; Tue, 8 Nov 2011 15:09:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=4168; q=dns/txt; s=iport; t=1320793767; x=1322003367; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=przJSVpiki3lRGLNtBA/kqLJ0N+JFn642FnIFVfzGfM=; b=HFVI3tN5pK02Bx43O4gE9ETGh1669kPPfZZmB37Uc80AeevXW+dspOsx gNSf1Pjjlkg1VDljeBee5ngiXgCG5799XuZstwszeUTYqUG3wfUI4JZ1d PklRezfFNFm4/ne1FyDA8zg/pOphopPaPIAGr+VukiyqFBUYd7i5oIGfH A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FAOG1uU6rRDoJ/2dsb2JhbABDqH2BJoEFgXIBAQEDAQEBAQkGAVsLBQkCCz8HGwwfEQYTGweHYAiZNAGeYwQCiEhjBIgLjBaFMYxd X-IronPort-AV: E=Sophos;i="4.69,479,1315180800"; d="scan'208";a="13060709" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 08 Nov 2011 23:09:26 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA8N9QIb013962; Tue, 8 Nov 2011 23:09:26 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <4EB26D22.5090000@ericsson.com> Date: Tue, 8 Nov 2011 16:09:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EB26D22.5090000@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Nov 2011 23:09:28 -0000 I don't understand the meaning of the sentence=20 This part is outside the scope of the RTCWEB standards suite. I think we need to construct a solution that can work if domains want to = federate with SIP - therefore this should be one our use cases. However, = I think domain should be free to choose whatever they want to federate - = it just needs to be possible to federate. I'd like to see this = clarified.=20 On Nov 3, 2011, at 4:29 AM, Magnus Westerlund wrote: > WG, >=20 > There has been a number of posts that makes arguments based on > federation and the federation protocol. This is the protocol used > between the webservers, called "Signalling path" in the trappzoid > picture (from draft-ietf-rtcweb-overview-02) below: >=20 > +-----------+ +-----------+ > | Web | | Web | > | | Signalling | | > | |-------------| | > | Server | path | Server | > | | | | > +-----------+ +-----------+ > / \ > / \ Proprietary over > / \ HTTP/Websockets > / \ > / Proprietary over \ > / HTTP/Websockets \ > / \ > +-----------+ +-----------+ > |JS/HTML/CSS| |JS/HTML/CSS| > +-----------+ +-----------+ > +-----------+ +-----------+ > | | | | > | | | | > | Browser | ------------------------- | Browser | > | | Media path | | > | | | | > +-----------+ +-----------+ >=20 > Figure 2: Browser RTC Trapezoid >=20 >=20 > Please consider that the current WG consensus is well captured in the > overview draft: >=20 > If the two Web servers are operated by different entities, the > signalling path needs to be agreed upon, either by standardization = or > by other means of agreement; for example, both servers might > implement SIP, and the servers would talk SIP to each other, and = each > would translate between the SIP protocol and their proprietary > representation for sending to their application running in the > browser. This part is outside the scope of the RTCWEB standars > suite. >=20 > So, it may be SIP, it doesn't need to be SIP. The important from the > WG's perspective is that is a possible deployment model we intended to > support. It is not the only deployment model. We don't define what is > used on the signalling path and there is freedom here. >=20 > Please consider that when writing arguments so that you don't > misrepresent the current WG consensus or ignore the set of = possibilities > that currently are considered. >=20 > If you don't like the WG consensus, then suggest to change it and see = if > you get support for it. >=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 fluffy@cisco.com Tue Nov 8 15:42:03 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E4A21F8540 for ; Tue, 8 Nov 2011 15:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.447 X-Spam-Level: X-Spam-Status: No, score=-106.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 XntHEaZm6-U8 for ; Tue, 8 Nov 2011 15:42:02 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B3B4321F8538 for ; Tue, 8 Nov 2011 15:42:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=414; q=dns/txt; s=iport; t=1320795722; x=1322005322; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=nW0vLR8BYFWi6R8QiZ6Xjuad3Mln5uII0N+bXOs6/TQ=; b=dGTxWnNOZ9Z5WKBEQbMfITenG3NbaLwtFy+nNGvKionvJZefbny1pZa9 lD19hju6AFyK0I/nESajR4pLuHxE2gghYeatJN0grYzRhn6ibYSHo1W5b 3tQNdoqcG0HiElVfdz2ynxNIXXsDWC0kbDlN2VN9Q7TuhS7CVuaMrMvxo 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMe9uU6rRDoI/2dsb2JhbABEpz+CZIEFgXIBAQUSASc/EAtGVwY1oRkBnmyISmMEiAuMFoUxjF0 X-IronPort-AV: E=Sophos;i="4.69,479,1315180800"; d="scan'208";a="13085244" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 08 Nov 2011 23:31:38 +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 pA8NVcOW018736; Tue, 8 Nov 2011 23:31:38 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4EB44684.30801@jesup.org> Date: Tue, 8 Nov 2011 16:31:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5CA5BC55-60E5-4837-AC6D-ED2DAF225296@cisco.com> References: <4EB44684.30801@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Codec 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: Tue, 08 Nov 2011 23:42:03 -0000 On Nov 4, 2011, at 2:09 PM, Randell Jesup wrote: >=20 > Just to note: G.729's license requirements make supporting it a = virtual impossibility for Mozilla, and unlikely for the other browsers. I realize this was the case at one point in time but I thought we worked = with VoiceAge to solve the problem of open source software using 729. Is = it still a problem ? Can we send Jean-Marc to fix it?=20 From giles@thaumas.net Tue Nov 8 16:22:13 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6E71F0C3B for ; Tue, 8 Nov 2011 16:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 nlog2JK-XwAi for ; Tue, 8 Nov 2011 16:22:12 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A3A351F0C3E for ; Tue, 8 Nov 2011 16:22:12 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so1082396vcb.31 for ; Tue, 08 Nov 2011 16:22:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.112.74 with SMTP id io10mr33941vdb.116.1320798131987; Tue, 08 Nov 2011 16:22:11 -0800 (PST) Received: by 10.220.194.72 with HTTP; Tue, 8 Nov 2011 16:22:11 -0800 (PST) X-Originating-IP: [66.183.19.247] In-Reply-To: <5CA5BC55-60E5-4837-AC6D-ED2DAF225296@cisco.com> References: <4EB44684.30801@jesup.org> <5CA5BC55-60E5-4837-AC6D-ED2DAF225296@cisco.com> Date: Tue, 8 Nov 2011 16:22:11 -0800 Message-ID: From: Ralph Giles To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Codec 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: Wed, 09 Nov 2011 00:22:13 -0000 On 8 November 2011 15:31, Cullen Jennings wrote: > I realize this was the case at one point in time but I thought we worked with VoiceAge to solve the problem of open source software using 729. Is it still a problem ? Can we send Jean-Marc to fix it? First I've heard of it. VoiceAge has a "free download" win32 binary for evaluation of G.729, but both VoiceAge and Wikipedia point to http://www.sipro.com/g729onestop.php for licensing. -r From giles@thaumas.net Tue Nov 8 16:25:38 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2203211E8086 for ; Tue, 8 Nov 2011 16:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 xmTHYrURWEfW for ; Tue, 8 Nov 2011 16:25:37 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6972F11E8081 for ; Tue, 8 Nov 2011 16:25:37 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so1084256vcb.31 for ; Tue, 08 Nov 2011 16:25:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.26.47 with SMTP id i15mr349250vdg.0.1320798335703; Tue, 08 Nov 2011 16:25:35 -0800 (PST) Received: by 10.220.194.72 with HTTP; Tue, 8 Nov 2011 16:25:35 -0800 (PST) X-Originating-IP: [66.183.19.247] In-Reply-To: References: <4EB44684.30801@jesup.org> <5CA5BC55-60E5-4837-AC6D-ED2DAF225296@cisco.com> Date: Tue, 8 Nov 2011 16:25:35 -0800 Message-ID: From: Ralph Giles To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Codec 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: Wed, 09 Nov 2011 00:25:38 -0000 On 8 November 2011 16:22, Ralph Giles wrote: > VoiceAge and Wikipedia point to > http://www.sipro.com/g729onestop.php for licensing. Which should be http://www.sipro.com/g729_about.php There are various terms available, but I don't see anything about open source. -r From fluffy@cisco.com Tue Nov 8 16:26:27 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5A511E8081 for ; Tue, 8 Nov 2011 16:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.45 X-Spam-Level: X-Spam-Status: No, score=-106.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 KKGW31C4oD38 for ; Tue, 8 Nov 2011 16:26:26 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id CCDFB21F8672 for ; Tue, 8 Nov 2011 16:26:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=854; q=dns/txt; s=iport; t=1320798386; x=1322007986; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=mrb4ESWO+vVfk3f8pPvQ9iDlb9oRuuxC+2nqYOmRYXU=; b=AesEcBjkbvyCRBpd4/SAbiTy+KAu5ipXj3aUWt0PYCu/SUZ1TeL1RB4w DvvWXceaVvHicRfBT+AhpdHgy4GCjNaj0ZrGrMCsOh5VApWyKTFjTGzqQ KF0ZECqgzl4c+Qt48m5YP1gdeG2XdmcrZuMZzz9EqxBYMoLL4SXgzYT5Y w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0FAEPIuU6rRDoH/2dsb2JhbAAqGqdAgT6BJoEFgXIBAQEDARIBJz8FCwsYLlcGEyKHYAgjmSMBnm2ISmMEiAuISINOhTGMXUw X-IronPort-AV: E=Sophos;i="4.69,480,1315180800"; d="scan'208";a="13094141" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 09 Nov 2011 00:26:26 +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 pA90QPbd018415; Wed, 9 Nov 2011 00:26:26 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Tue, 8 Nov 2011 17:26:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EB44684.30801@jesup.org><5CA5BC55-60E5-4837-AC6D-ED2DAF225296@cisco.com> To: "Ralph Giles" X-Mailer: Apple Mail (2.1084) Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Codec 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: Wed, 09 Nov 2011 00:26:27 -0000 Hmm - perhaps the state is far more messed up than I thought. Initially = there was the free download stuff for testing development but not real = use. I thought there had been some agreement on broader usage for open = source software but I've lost track of where things are on that.=20 On Nov 8, 2011, at 5:22 PM, Ralph Giles wrote: > On 8 November 2011 15:31, Cullen Jennings wrote: >=20 > > I realize this was the case at one point in time but I thought we = worked with VoiceAge to solve the problem of open source software using = 729. Is it still a problem ? Can we send Jean-Marc to fix it? >=20 > First I've heard of it. VoiceAge has a "free download" win32 binary > for evaluation of G.729, but both VoiceAge and Wikipedia point to > http://www.sipro.com/g729onestop.php for licensing. >=20 > -r >=20 From bernard_aboba@hotmail.com Tue Nov 8 16:28:11 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8D221F8770 for ; Tue, 8 Nov 2011 16:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 4a74O5GjAWST for ; Tue, 8 Nov 2011 16:28:11 -0800 (PST) Received: from blu0-omc4-s9.blu0.hotmail.com (blu0-omc4-s9.blu0.hotmail.com [65.55.111.148]) by ietfa.amsl.com (Postfix) with ESMTP id F298921F86C3 for ; Tue, 8 Nov 2011 16:28:10 -0800 (PST) Received: from BLU152-W48 ([65.55.111.135]) by blu0-omc4-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 16:28:07 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_53d1fa37-6c09-465c-bf27-306fd7397392_" X-Originating-IP: [131.107.0.94] From: Bernard Aboba To: , Magnus Westerlund Date: Tue, 8 Nov 2011 16:28:06 -0800 Importance: Normal In-Reply-To: References: <4EB26D22.5090000@ericsson.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2011 00:28:07.0306 (UTC) FILETIME=[73CD36A0:01CC9E76] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 00:28:11 -0000 --_53d1fa37-6c09-465c-bf27-306fd7397392_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BA] I don't understand that sentence either=2C partly because it's not cl= ear to me what "this" refers to. The previous sentence talks about "the si= gnaling path needs to be agreed upon=2C either by standardization or by oth= er means of agreement"=2C but also talks about "their proprietary represent= ation". Is "this" referring to the former or the latter? Here's a rewrit= e that makes more sense (at least to me): "If the two Web servers are oper= ated by different entities=2C the inter-domain signalling mechanism needs t= o be agreed upon=2C either by standardization or by other means of agreemen= t. Existing protocols that support federation (SIP or XMPP) could be used = to enable inter-domain federation between servers=2C while either a standar= ds-based or proprietary protocol could be used between the browser and the = web server. For example=2C if both domains implement SIP=2C SIP could be = used for inter-domain communication between servers=2C along with either a = standardized signaling mechanism (e.g. SIP over Websockets) or a a propriet= ary signaling mechanism used between the application running in the browser= and the web server. Similarly=2C if both domains implement XMPP=2C XMPP = couild be used for inter-domain communication between XMPP servers=2C with = either a standardized signaling mechanism (e.g. XMPP over Websockets or BOS= H) or a proprietary signaling mechanism used between the application runnin= g in the browser and the web server." Cullen said: "I don't understand th= e meaning of the sentence=20 =20 This part is outside the scope of the RTCWEB standards suite. I think we need to construct a solution that can work if domains want to fe= derate with SIP - therefore this should be one our use cases. However=2C I = think domain should be free to choose whatever they want to federate - it j= ust needs to be possible to federate. I'd like to see this clarified." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D "If the two Web servers are operate= d by different entities=2C the signalling path needs to be agreed upon=2C either by standardization or by other means of agreement=3B for example=2C both servers mightimplement S= IP=2C and the servers would talk SIP to each other=2C and eachwould transla= te between the SIP protocol and their proprietary representation for sending to their application running in the browser.This part is outside the scope of the RTCWEB standars suite." = --_53d1fa37-6c09-465c-bf27-306fd7397392_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[BA] =3B I don't understand that sentence either=2C partly because it's= not clear to me what "this" refers to. =3B The previous sentence talks= about "the signaling path needs to be agreed upon=2C either by standardiza= tion or by other means of agreement"=2C but also talks about "their proprie= tary representation". =3B Is "this" referring to the former or the latt= er? =3B
 =3B
Here's a rewrite that makes more sense (at leas= t to me):
 =3B
"If the two Web servers are operated by different= entities=2C the inter-domain =3Bsignalling mechanism needs to be agree= d upon=2C either by standardization or by other means of agreement. =3B= Existing protocols that support federation (SIP or XMPP) could be used to = enable inter-domain federation between servers=2C while either a standards-= based or proprietary protocol could be used between the browser and the web= server.
 =3B
For example=2C if both domains implement SIP=2C&nb= sp=3B SIP could be used for inter-domain communication between servers=2C a= long with either a standardized signaling mechanism (e.g. SIP over Websocke= ts) or a a proprietary signaling mechanism used between the application run= ning in the browser and the web server. =3B =3B
 =3B
Simi= larly=2C if both domains implement XMPP=2C XMPP couild be used for inter-do= main communication between XMPP servers=2C with either a standardized signa= ling mechanism (e.g. XMPP over Websockets or BOSH) or a proprietary signali= ng mechanism used between the application running in the browser and the we= b server."
 =3B
 =3B
 =3B
Cullen said:
 =3B<= BR>"I don't understand the meaning of the sentence =3B

This par= t is outside the scope of the RTCWEB standards suite.

I think we nee= d to construct a solution that can work if domains want to federate with SI= P - therefore this should be one our use cases. However=2C I think domain s= hould be free to choose whatever they want to federate - it just needs to b= e possible to federate. I'd like to see this clarified."

 =3B =3B
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 =3B
"If the = two Web servers are operated by different entities=2C the
signalling pat= h needs to be agreed upon=2C either by standardization or
by other means= of agreement=3B for example=2C both servers might
implement SIP=2C and = the servers would talk SIP to each other=2C and each
would translate bet= ween the SIP protocol and their proprietary
representation for sending t= o their application running in the
browser.This part is outside the scop= e of the RTCWEB standars
suite."
 =3B
 =3B
=
= --_53d1fa37-6c09-465c-bf27-306fd7397392_-- From ibc@aliax.net Tue Nov 8 16:33:46 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D581F0C3E for ; Tue, 8 Nov 2011 16:33:46 -0800 (PST) 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 X-25ivBtb764 for ; Tue, 8 Nov 2011 16:33:45 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A24D91F0C3B for ; Tue, 8 Nov 2011 16:33:45 -0800 (PST) Received: by vws5 with SMTP id 5so1188095vws.31 for ; Tue, 08 Nov 2011 16:33:45 -0800 (PST) Received: by 10.52.33.239 with SMTP id u15mr265474vdi.49.1320798825064; Tue, 08 Nov 2011 16:33:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Tue, 8 Nov 2011 16:33:24 -0800 (PST) In-Reply-To: References: <4EB26D22.5090000@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 9 Nov 2011 01:33:24 +0100 Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 00:33:46 -0000 2011/11/9 Bernard Aboba : > Here's a rewrite that makes more sense (at least to me): > > "If the two Web servers are operated by different entities, the > inter-domain=C2=A0signalling mechanism needs to be agreed upon, either by > standardization or by other means of agreement.=C2=A0 Existing protocols = that > support federation (SIP or XMPP) could be used to enable inter-domain > federation between servers, while either a standards-based or proprietary > protocol could be used between the browser and the web server. > > For example, if both domains implement SIP,=C2=A0 SIP could be used for > inter-domain communication between servers, along with either a standardi= zed > signaling mechanism (e.g. SIP over Websockets) or a a proprietary signali= ng > mechanism used between the application running in the browser and the web > server. > > Similarly, if both domains implement XMPP, XMPP couild be used for > inter-domain communication between XMPP servers, with either a standardiz= ed > signaling mechanism (e.g. XMPP over Websockets or BOSH) or a proprietary > signaling mechanism used between the application running in the browser a= nd > the web server." Which basically means the same as saying nothing or "if you want do whatever you want". --=20 I=C3=B1aki Baz Castillo From bernard_aboba@hotmail.com Tue Nov 8 16:49:25 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6549B21F8ADC for ; Tue, 8 Nov 2011 16:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, 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 MD2eBRlu6sYG for ; Tue, 8 Nov 2011 16:49:24 -0800 (PST) Received: from blu0-omc3-s15.blu0.hotmail.com (blu0-omc3-s15.blu0.hotmail.com [65.55.116.90]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC3721F8AEA for ; Tue, 8 Nov 2011 16:49:24 -0800 (PST) Received: from BLU152-W37 ([65.55.116.73]) by blu0-omc3-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 16:49:20 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_f9f9d88b-74f0-407a-820f-ab4ff6c8b2d3_" X-Originating-IP: [131.107.0.94] From: Bernard Aboba To: Date: Tue, 8 Nov 2011 16:49:19 -0800 Importance: Normal In-Reply-To: <4EB44684.30801@jesup.org> References: , , , , , <4EB44684.30801@jesup.org> MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2011 00:49:20.0127 (UTC) FILETIME=[6A7648F0:01CC9E79] Subject: Re: [rtcweb] Codec 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: Wed, 09 Nov 2011 00:49:25 -0000 --_f9f9d88b-74f0-407a-820f-ab4ff6c8b2d3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > So let me know: do you support that browsers must implement g729? Simple answer: No. We've been through the issues relating to G.729 in a nu= mber of other contexts=2C such as emergency service requirements (e.g. ECRI= T Phone-BCP=2C NENA i3). It didn't get in=2C even as OPTIONAL. For exampl= e=2C here is what ECRIT PhoneBCP Section 14 says on the subject of audio co= decs (end system requirements): ED-71 Endpoints MUST send and receive media streams on RTP [RFC3550]. ED-72 Normal SIP offer/answer [RFC3264] negotiations MUST be used to agree on the media streams to be used. ED-73/SP-41 G.711 A law (and mu Law if they are intended be used in North America) encoded voice as described in [RFC3551] MUST be supported. If the endpoint cannot support G.711=2C a transcoder MUST be used so that the offer received at the PSAP contains G.711. It is desirable to include wideband codecs such as G.722 and AMR-WB in the offer. PSAPs SHOULD support narrowband codecs common on endpoints in their area to avoid transcoding. ED-74 Silence suppression (Voice Activity Detection methods) MUST NOT be used on emergency calls. Here is what NENA i3 stage 3 says (ESINet r= equirements): 4.1.8.1 AudioAll User Agents in the ESInet must support g.71= 1 mu-law and a-law. A-law support is required in the case that devices manu= factured primarily for non-North American markets is used within North Amer= ica. It is recommended that AMR=2C AMR-WB=2C EVRC[138]=2C EVRC-B[139]=2C EV= RC-WB[140]=2C and EVRC-NW[141] also be supported. = --_f9f9d88b-74f0-407a-820f-ab4ff6c8b2d3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B So let me know: do you support that browsers must implement g729?
Simple answer: =3B No.
 =3B
We've been through the issue= s relating to G.729 in a number of other contexts=2C such as emergency serv= ice requirements (e.g. ECRIT Phone-BCP=2C NENA i3). =3B It didn't get i= n=2C even as OPTIONAL.
 =3B
For example=2C here is what ECRIT Ph= oneBCP Section 14 says on the subject of audio codecs (end system requireme= nts):

ED-71 Endpoints MUST send and receive media streams on RTP [RFC3550].

ED-72 Normal SIP offer/answer [RFC3264] negotiations MUST be used to agree on the media streams to be used.

ED-73/SP-41 G.711 A law (and mu Law if they are intended be use= d in North America) encoded voice as described in [RFC3551] MUST be supported. If the endpoint cannot support G.711=2C a transcoder MUST be used so that the offer received at the PSAP contains G.711. It is desirable to include wideband codecs such as G.722 and AMR-WB in the offer. PSAPs SHOULD support narrowband codecs common on endpoints in their area to avoid transcoding.

ED-74 Silence suppression (Voice Activity Detection methods) MU= ST NOT be used on emergency calls. =3B

Here is what NENA i3 stage 3 sa= ys (ESINet requirements):
 =3B

4.1.8.1 Audio

All User Agen= ts in the ESInet must support g.711 mu-law and a-law. A-law support is requ= ired in the case that devices manufactured primaril= y for non-North American markets is used within North America. It is recommended that AMR=2C AMR-WB=2C EVRC[138]=2C EVRC-B[139= ]=2C EVRC-WB[140]=2C and EVRC-NW[141] also be suppo= rted.

 =3B
 =3B
 =3B
 =3B
&nbs= p=3B
 =3B
 =3B
 =3B
 =3B
 =3B
 = =3B
 =3B
= --_f9f9d88b-74f0-407a-820f-ab4ff6c8b2d3_-- From bernard_aboba@hotmail.com Tue Nov 8 17:05:21 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69BB1F0C45 for ; Tue, 8 Nov 2011 17:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.26 X-Spam-Level: X-Spam-Status: No, score=-102.26 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, 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 C9ARY8LmoJE4 for ; Tue, 8 Nov 2011 17:05:21 -0800 (PST) Received: from blu0-omc3-s37.blu0.hotmail.com (blu0-omc3-s37.blu0.hotmail.com [65.55.116.112]) by ietfa.amsl.com (Postfix) with ESMTP id 4B30E1F0C3B for ; Tue, 8 Nov 2011 17:05:21 -0800 (PST) Received: from BLU152-W60 ([65.55.116.73]) by blu0-omc3-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 17:05:17 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_db859661-c3ec-499a-8004-33b968545c86_" X-Originating-IP: [131.107.0.94] From: Bernard Aboba To: Date: Tue, 8 Nov 2011 17:05:17 -0800 Importance: Normal In-Reply-To: <6CB98137-B2A4-488C-BF5C-D7D87B23C7EC@cisco.com> References: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com>, <6CB98137-B2A4-488C-BF5C-D7D87B23C7EC@cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2011 01:05:17.0344 (UTC) FILETIME=[A5020200:01CC9E7B] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Usecases for innovation. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 01:05:22 -0000 --_db859661-c3ec-499a-8004-33b968545c86_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BA] I'm trying to understand the "generic" issues presented by these case= s. For #1=2C is the generic issue the ability to add support for codecs n= ot supported natively (e.g. ability to add and use a codec added by a plugi= n=2C for example)? For #2=2C is the generic issue the ability to add supp= ort for new types of devices without standardized APIs=2C or is the issue b= eing able to represent the input/output of a non-standard device in terms o= f a media stream? Tim said: " 1) H264 implementation in Javascript http= ://yfrog.com/nmng0z=20 2) Kinect as an input device for a virtual receptionist in a real reception= area (Voxeo's as it happens). =20 Neither of these are production ready - or indeed necessarily a good idea= =2Cbut the fact that neither (minor) innovation fits at all into our brand = new framework should give us pause for thought. (but given the pell-mell dash to be compa= tiblewith last century's deskphones I don't imagine it will)." = --_db859661-c3ec-499a-8004-33b968545c86_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[BA] =3B I'm trying to understand the "generic" issues presented by the= se cases.  =3B
 =3B
For #1=2C is the generic issue the abilit= y to add support for codecs not supported natively (e.g. ability to add and= use a codec added by a plugin=2C for example)? =3B
 =3B
For= #2=2C is the generic issue the ability to add support for new types of dev= ices without standardized APIs=2C or is the issue being able to represent t= he input/output of a non-standard device in terms of a media stream? = =3B
 =3B
 =3B
 =3B
 =3B
Tim said:
 = =3B
" 1) H264 implementation in Javascript http://yfrog.com/nmng0z
2= ) Kinect as an input device for a virtual receptionist in a real reception = area
 =3B (Voxeo's as it happens).
 =3B
Neither of these = are production ready - or indeed necessarily a good idea=2C
but the fact= that neither (minor) innovation fits at all into our brand new frameworkshould give us pause for thought. (but given the pell-mell dash to be com= patible
with last century's deskphones I don't imagine it will)."
= --_db859661-c3ec-499a-8004-33b968545c86_-- From pravindran@sonusnet.com Tue Nov 8 17:21:44 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A709F11E80AD for ; Tue, 8 Nov 2011 17:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.040, 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 zp2rZft3n9PE for ; Tue, 8 Nov 2011 17:21:43 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9D15711E8095 for ; Tue, 8 Nov 2011 17:21:43 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA91MFuQ021871; Tue, 8 Nov 2011 20:22:15 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 20:21:38 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 06:51:47 +0530 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.0339.001; Wed, 9 Nov 2011 06:51:46 +0530 From: Ravindran Parthasarathi To: "" Thread-Topic: SRTP requirement - wiretapping (Re: [rtcweb] Let's define the purpose of WebRTC) Thread-Index: AQHMnmW59i9wHJTlK0G7Y20+Lj8YEZWjrx4Q Date: Wed, 9 Nov 2011 01:21:46 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <4EB9ACF5.80805@alvestrand.no> In-Reply-To: <4EB9ACF5.80805@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.53.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2011 01:21:47.0296 (UTC) FILETIME=[F310B200:01CC9E7D] Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of 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: Wed, 09 Nov 2011 01:21:44 -0000 Thanks to Harald/Cullen for pointing out RFC 2804. I take back my #2 commen= t based on RFC 2804 wiretapping policy.=20 I wish to clarify why I gave this comment before closing on #2: It is the common practice in India to buy computer to talk/chat with the re= latives who are outside India by using Skype/Gtalk/Yahoo (avoiding Internat= ional subscriber dialing charges). Of course, Cell phone is more popular th= an Computer and cheap (~$100) Wi-Fi enabled (Android) Smartphones are avail= able in market. WebRTC will bring the new innovative way of communicating u= sing Smartphone (like free WebRTC session to street provisional store). Bro= wser in Smartphone is the platform for making outgoing session towards prov= isional store. I really don't want these kind of WebRTC service are forbidd= en by Government laws unnecessarily due to security (SRTP) reasons.=20 >-----Original Message----- >From: Harald Alvestrand [mailto:harald@alvestrand.no] >Sent: Wednesday, November 09, 2011 3:58 AM >To: Ravindran Parthasarathi >Cc: Hadriel Kaplan; Eric Rescorla; >Subject: SRTP requirement - wiretapping (Re: [rtcweb] Let's define the >purpose of WebRTC) > >Changing the subject again to mention SRTP.... > >On 11/08/2011 03:30 PM, Ravindran Parthasarathi wrote: >> I agree with Hadriel that it is not required to mandate SRTP for >WebRTC. My reasoning are as follows: >> >> 1) Security could be in the lower layer itself (IPsec, VPN, private >MPLS cloud). For Enterprise-only-WebRTC application (no federation& no >interop), there is no need of security by specific application like >WebRTC as it is ensured in the infrastructure. WebRTC security will be >duplicated for these infrastructure and may leads double encryption >unnecessarily. >This argument makes some sense. >> >> 2) Being in India, I'm interested in avoiding Government restriction >on WebRTC proposal (Thanks to Tim for pointing this). I may not surprise >to see that WebRTC mechanism is banned in India because intelligent >agency struggles to break the key in each terrorist WebRTC site. >(http://www.pcworld.com/businesscenter/article/235639/india_wants_to_int >ercept_skype_google_communications.html) >This argument is contrary to stated IETF policy (RFC 2804). > >I recommend the RFC for background reading. >> >> In case there is no use case to illustrate in RTCWeb draft, let us >discuss in detail. >> >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >Behalf >>> Of Hadriel Kaplan >>> Sent: Monday, November 07, 2011 9:12 PM >>> To: Eric Rescorla >>> Cc: >>> Subject: Re: [rtcweb] Let's define the purpose of WebRTC >>> >>> >>> On 11/07/2011 02:50 PM, Eric Rescorla wrote: >>>> On Sun, Nov 6, 2011 at 7:20 PM, Hadriel >Kaplan >>> wrote: >>>>> Who said "too slow"? There *is* an extra round-trip or two >involved >>> I presume, if we're talking DTLS-SRTP, but no I didn't mean that as a >>> "hit". I just meant the extra computing cycles for SRTP being a >"hit". >>> For WebRTC-to-WebRTC I don't think that matters at all. For WebRTC- >to- >>> media-server it might, for a free game app or greeting card app that >>> don't care about it to begin with, and which use plaintext HTTP to >begin >>> with. >>>> Sorry, I didn't mean to put words in your mouth. Performance >>> measurements >>>> of HTTP versus HTTPS in modern Web environments suggest that the >>> additional >>>> load for HTTPS is not significant. Do you have evidence that the >>> situation is >>>> different for SRTP versus RTP? >>> Only from the DSP guys, and those would be hardware DSPs not >softDSPs. >>> It runs them anywhere from 10-25% overhead, they say, depending on >the >>> vendor and what else their DSPs are doing at the time. >>> >>> But ultimately even in software I assume it's all relative to what >other >>> work you're doing. If you have to render a video stream on a screen >and >>> encode camera input into a codec being sent out, then my guess is >SRTP >>> overhead is a tiny factor not worth talking about. If you're mixing >>> multiple RTP streams as a conference server, then I assume doing SRTP >>> for thousands of simultaneous audio RTP streams for multiple >>> simultaneous conferences becomes noticeable. Or at least so they >seem >>> to claim - I don't know since I don't build a media server (hardware >>> SBCs often offload SRTP onto dedicated hardware). One large software >>> company even created their own proprietary packet format for SRTP >that >>> they claimed was done for improving performance/scalability, so I >assume >>> it has some impact they don't want their customers to incur. >>> >>> -hadriel >>> >>> _______________________________________________ >>> 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 bernard_aboba@hotmail.com Tue Nov 8 17:25:16 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF9A1F0C4F for ; Tue, 8 Nov 2011 17:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.067, 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 OQ+7Md0A1Gr0 for ; Tue, 8 Nov 2011 17:25:15 -0800 (PST) Received: from blu0-omc3-s37.blu0.hotmail.com (blu0-omc3-s37.blu0.hotmail.com [65.55.116.112]) by ietfa.amsl.com (Postfix) with ESMTP id EB9461F0C3B for ; Tue, 8 Nov 2011 17:25:14 -0800 (PST) Received: from BLU152-W34 ([65.55.116.74]) by blu0-omc3-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 17:25:13 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_6f9615c1-c543-4be7-9000-21883a008e83_" X-Originating-IP: [131.107.0.94] From: Bernard Aboba To: , Magnus Westerlund Date: Tue, 8 Nov 2011 17:25:13 -0800 Importance: Normal In-Reply-To: <4EB2A58E.1040000@jesup.org> References: <4EB26945.40607@ericsson.com>,<4EB2A58E.1040000@jesup.org> MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2011 01:25:13.0820 (UTC) FILETIME=[6E29C1C0:01CC9E7E] Subject: Re: [rtcweb] SRTP mandatory to implement versus mandatory to use X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 01:25:16 -0000 --_6f9615c1-c543-4be7-9000-21883a008e83_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support SRTP being "mandatory to implement" but not "mandatory to use". = With respect to mandating a keying mechanism=2C I would point out the argum= ents in the following document: http://tools.ietf.org/html/draft-ietf-avt-s= rtp-not-mandatory It appears that the arguments made in this document also = apply to RTCWEB in that many (though not all) of the use cases mentioned th= ere are also to be supported by RTCWEB=2C potentially leading to disparate = keying requirements. 2. RTP Applications and Deployment Scenarios The range of application and deployment scenarios where RTP has been Perkins & Westerlund Expires May 3=2C 2012 [Page 3] used includes=2C but is not limited to=2C the following: o Point-to-point voice telephony (fixed and wireless networks) o Point-to-point voice and video conferencing o Centralised group video conferencing with a multipoint conference unit (MCU) o Any Source Multicast video conferencing (light-weight sessions=3B Mbone conferencing) o Point-to-point streaming audio and/or video o Source-specific multicast (SSM) streaming to large group (IPTV and 3GPP Multimedia Broadcast Multicast Service (MBMS) [MBMS]) o Replicated unicast streaming to a group o Interconnecting components in music production studios and video editing suites o Interconnecting components of distributed simulation systems o Streaming real-time sensor data As can be seen=2C these scenarios vary from point-to-point to very large multicast groups=2C from interactive to non-interactive=2C and fro= m low bandwidth (kilobits per second) to very high bandwidth (multiple gigabits per second). While most of these applications run over UDP [RFC0768]=2C some use TCP [RFC0793]=2C [RFC4614] or DCCP [RFC4340] as their underlying transport. Some run on highly reliable optical networks=2C others use low rate unreliable wireless networks. Some applications of RTP operate entirely within a single trust domain=2C others are inter-domain=2C with untrusted (and potentially unknown) users. The range of scenarios is wide=2C and growing both in number and in heterogeneity. 3. Implications for RTP Security The wide range of application scenarios where RTP is used has led to the development of multiple solutions for securing RTP media streams and RTCP control messages=2C considering different requirements. Perhaps the most widely applicable of these solutions is the Secure RTP (SRTP) framework [RFC3711]. This is an application-level media security solution=2C encrypting the media payload data (but not the RTP headers) to provide some degree of confidentiality=2C and providing op= tional source origin authentication. It was carefully designed to be both low overhead=2C and to support the group communication features of RTP=2C across a range of networks. SRTP is not the only media security solution in use=2C however=2C and alternatives are more appropriate for some scenarios. For example=2C many client-server streaming media applications can run over a single TCP connection=2C multiplexing media data with control information on that connection (RTSP [I-D.ietf-mmusic-rfc2326bis] is a widely used example of such a protocol). One way to provide media security for such client-server media applications is to use TLS [RFC5246] to protect the TCP connection=2C sending the RTP media data over the TLS connection. Using the SRTP framework in addition to TLS is unnecessary=2C and would result in double encryption of the media=2C and SRTP cannot be used instead of TLS since it is RTP-specific=2C and so cannot protect the control traffic. Other RTP use cases work over networks which provide security at the network layer=2C using IPsec. For example=2C certain 3GPP networks need IPsec security associations for other purposes=2C and can reuse those to secure the RTP session [TS-33210]. SRTP is=2C again=2C unnecessary i= n such environments=2C and its use would only introduce overhead for no gain. For some applications it is sufficient to protect the RTP payload data while leaving RTP=2C transport=2C and network layer headers unprotected. An example of this is RTP broadcast over DVB-H [ETSI.TS.102.474]=2C where one mode of operation uses ISMA Cryp 2.0 [ISMA] to encrypt the RTP payload data only. All these are application scenarios where RTP has seen commercial deployment. Other use cases exist=2C with additional requirements. For example=2C if the media transport is done over UDP [RFC0768]=2C DCCP [RFC4340] or SCTP [RFC4960]=2C then using DTLS [RFC4347] to protect the whole RTP packets is an option. There is no media security protocol that is appropriate for all these environments. Accordingly=2C multiple RTP media security protocols can be expected to remain in wide use. 4. Implications for Key Management With such a diverse range of use cases come a range of different protocols for RTP session establishment. Mechanisms used to provide security keying for these different session establishment protocols can basically be put into two categories: inband and out-of-band in relation to the session establishment mechanism. The requirements for these solutions are highly varying. Thus a wide range of solutions have been developed in this space: o A common use case for RTP is probably point-to-point voice calls or centralised group conferences=2C negotiated using SIP [RFC3261] with the SDP offer/answer model [RFC3264]=2C operating on a trusted infrastructure. In such environments=2C SDP security descriptions [RFC4568]=2C or the MIKEY [RFC3830] protocol using the Key Management Extensions for SDP [RFC4567]=2C are appropriate keying mechanisms=2C where the keying messages/material are embedded in the SDP [RFC4566] exchange. The infrastructure may be secured by protecting the SDP exchange in SIP using TLS or S/MIME=2C for example [RFC3261]. Protocols such as DTLS-SRTP [RFC5764] or ZRTP [RFC6189] are also appropriate in such environments. o Point-to-point RTP sessions may be negotiated using SIP with the offer/answer model=2C but operating over a network with untrusted infrastructure. In such environments=2C the key management protocol can be run on the media path=2C bypassing the untrusted infrastructure. Protocols such as DTLS-SRTP [RFC5764] or ZRTP [RFC6189] are useful here=2C as are inband mechanism that protect the keying material such as MIKEY [RFC3830] using the Key Management Extensions for SDP [RFC4567]. It should be noted that the end-points for all the above mechanisms must prevent total downgrade to no security for the RTP media streams. o For point-to-point client-server streaming of RTP over RTSP=2C a TLS association is appropriate to manage keying material=2C in much the same manner as would be used to secure an HTTP session. But also using SRTP with DTLS-SRTP keying or DTLS are appropriate choices. o A session description may be sent by email=2C secured using S/MIME or PGP=2C or retrieved from a web page=2C using HTTP with TLS. o A session description may be distributed to a multicast group using SAP or FLUTE secured with S/MIME. o A session description may be distributed using the Open Mobile Alliance DRM key management specification [OMA-DRM] when using a point-to-point streaming session setup with RTSP in the 3GPP PSS environment [PSS]. o In the 3GPP Multimedia Broadcast Multicast Service (MBMS) system=2C HTTP and MIKEY are used for key management [MBMS-SEC]. A more detailed survey of requirements for media security management protocols can be found in [RFC5479]. As can be seen=2C the range of use cases is wide=2C and there is no single protocol that is appropriate for all scenarios. These solutions have been further diver= sified by the existence of infrastructure elements such as authentication solutions that are tied into the key management. Magnus said: "Yes=2C we haven't spent much time on the security consi= deration section yet. "A mandatory to implement media security solution will be required to be picked" is pointer at this WG not the implementor. I would also point at our Charter that in its last paragraph says: "The products of the working group will support security and keying as required by BCP 61" If you haven't read BCP 61 you probably should. It is basically says two things. IETF should pick strong security and it shall be MANDATORY to IMPLEMENT. I at least as chair will ensure that we have fulfilled this. And that means for RTP not only encryption and integrity protection=2C probably SRTP=2C but also a keying method. Yes=2C we (authors of draft-ietf-rtcweb-rtp-usage) will write that SRTP is a MUST implement as soon as we have that consensus established. But we will need a keying scheme also and determine where it should be documented. Cheers Magnus Westerlund " = --_6f9615c1-c543-4be7-9000-21883a008e83_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I support SRTP being "mandatory to implement" but not "mandatory to use". <= BR> =3B
With respect to mandating a keying mechanism=2C I would poin= t out the arguments in the following document:
 =3B
http://tools.ie= tf.org/html/draft-ietf-avt-srtp-not-mandatory
 =3B
It appears= that the arguments made in this document also apply to RTCWEB in that many= (though not all) of the =3Buse cases =3Bmentioned there are also t= o be supported by RTCWEB=2C potentially leading to disparate keying require= ments.
 =3B
 =3B

2. RTP Applications and Deployment Scenarios

 The range of application and deployment scenarios where RTP has been Perkins &=3B Westerlund = Expires May 3=2C 2012 [Page 3] 
    used includes=2C but is not limited to=2C th=
e following:

   o  Point-to-point voice telephony (fixed and wireless networks)

   o  Point-to-point voice and video conferencing

   o  Centralised group video conferencing with a multipoint conference
      unit (MCU)

   o  Any Source Multicast video conferencing (light-weight sessions=3B
      Mbone conferencing)

   o  Point-to-point streaming audio and/or video

   o  Source-specific multicast (SSM) streaming to large group (IPTV and
      3GPP Multimedia Broadcast Multicast Service (MBMS) [MBMS])

   o  Replicated unicast streaming to a group

   o  Interconnecting components in music production studios and video
      editing suites

   o  Interconnecting components of distributed simulation systems

   o  Streaming real-time sensor data

   As can be seen=2C these scenarios vary from point-to-point to very
   large multicast groups=2C from interactive to non-interactive=2C and fro=
m
   low bandwidth (kilobits per second) to very high bandwidth (multiple
   gigabits per second).  While most of these applications run over UDP
   [RFC0768]=2C some use TCP [RFC0793]=2C [RFC4614] or DCCP=
 [RFC4340] as
   their underlying transport.  Some run on highly reliable optical
   networks=2C others use low rate unreliable wireless networks.  Some
   applications of RTP operate entirely within a single trust domain=2C
   others are inter-domain=2C with untrusted (and potentially unknown)
   users.  The range of scenarios is wide=2C and growing both in number
   and in heterogeneity.



3.  Implications for RTP S=
ecurity


   The wide range of application scenarios where RTP is used has led to
   the development of multiple solutions for securing RTP media streams
   and RTCP control messages=2C considering different requirements.
   Perhaps the most widely applicable of these solutions is the Secure
   RTP (SRTP) framework [RFC3711].  This=
 is an application-level media
   security solution=2C encrypting the media payload data (but not the RTP
   headers) to provide some degree of confidentiality=2C and providing
   optional source origin authentication.  It was c=
arefully designed to
   be both low overhead=2C and to support the group communication features
   of RTP=2C across a range of networks.

   SRTP is not the only media security solution in use=2C however=2C and
   alternatives are more appropriate for some scenarios.  For example=2C
   many client-server streaming media applications can run over a single
   TCP connection=2C multiplexing media data with control information on
   that connection (RTSP [I-D.ietf-mmusic-r=
fc2326bis] is a widely used
   example of such a protocol).  One way to provide media security for
   such client-server media applications is to use TLS [RFC5246] to
   protect the TCP connection=2C sending the RTP media data over the TLS
   connection.  Using the SRTP framework in addition to TLS is
   unnecessary=2C and would result in double encryption of the media=2C and
   SRTP cannot be used instead of TLS since it is RTP-specific=2C and so
   cannot protect the control traffic.

   Other RTP use cases work over networks which provide security at the
   network layer=2C using IPsec.  For example=2C certain 3GPP networks need
   IPsec security associations for other purposes=2C and can reuse those
   to secure the RTP session [TS-33210].  SRTP is=2C agai=
n=2C unnecessary in
   such environments=2C and its use would only introduce overhead for no
   gain.

   For some applications it is sufficient to protect the RTP payload
   data while leaving RTP=2C transport=2C and network layer headers
   unprotected.  An example of this is RTP broadcast over DVB-H
   [ETSI.TS.102.474]=2C where one mode of operatio=
n uses ISMA Cryp 2.0
   [ISMA] to encrypt the RTP payload data only.

   All these are application scenarios where RTP has seen commercial
   deployment.  Other use cases exist=2C with additional requirements.
   For example=2C if the media transport is done over UDP [RFC0768]=2C DCCP
   [RFC4340] or SCTP [=
RFC4960]=2C then using DTLS [RFC4347] to protect =
the
   whole RTP packets is an option.  There is no media security protocol
   that is appropriate for all these environments.  Accordingly=2C
   multiple RTP media security protocols can be expected to remain in
   wide use.



4.  Implications for Key M=
anagement


   With such a diverse range of use cases come a range of different
   protocols for RTP session establishment.  Mechanisms used to provide
   security keying for these different session establishment protocols
   can basically be put into two categories: inband and out-of-band in
   relation to the session establishment mechanism.  The requirements
   for these solutions are highly varying.  Thus a wide range of

  solutions have been developed in this space:

   o  A common use case for RTP is probably point-to-point voice calls
      or centralised group conferences=2C negotiated using SIP [RFC3261]
      with the SDP offer/answer model [RFC3264]=2C operating on a trusted
      infrastructure.  In such environments=2C SDP security descriptions
      [RFC4568]=2C or the MIKEY [RFC3830] protocol using the Key
      Management Extensions for SDP [RFC4567]=2C are appr=
opriate keying
      mechanisms=2C where the keying messages/material are embedded in the
      SDP [RFC4566] exchange.  The infrastructure may=
 be secured by
      protecting the SDP exchange in SIP using TLS or S/MIME=2C for
      example [RFC3261].  Protocols such as DTLS-SRTP =
[RFC5764] or ZRTP
      [RFC6189] are also appropri=
ate in such environments.

   o  Point-to-point RTP sessions may be negotiated using SIP with the
      offer/answer model=2C but operating over a network with untrusted
      infrastructure.  In such environments=2C the key management protocol
      can be run on the media path=2C bypassing the untrusted
      infrastructure.  Protocols such as DTLS-SRTP [RFC5764] or ZRTP
      [RFC6189] are useful here=
=2C as are inband mechanism that protect
      the keying material such as MIKEY [RFC3830] usi=
ng the Key
      Management Extensions for SDP [RFC4567].  It should=
 be noted that
      the end-points for all the above mechanisms must prevent total
      downgrade to no security for the RTP media streams.

   o  For point-to-point client-server streaming of RTP over RTSP=2C a TLS
      association is appropriate to manage keying material=2C in much the
      same manner as would be used to secure an HTTP session.  But also
      using SRTP with DTLS-SRTP keying or DTLS are appropriate choices.

   o  A session description may be sent by email=2C secured using S/MIME
      or PGP=2C or retrieved from a web page=2C using HTTP with TLS.

   o  A session description may be distributed to a multicast group
      using SAP or FLUTE secured with S/MIME.

   o  A session description may be distributed using the Open Mobile
      Alliance DRM key management specification [OMA-DRM] when using a
      point-to-point streaming session setup with RTSP in the 3GPP PSS
      environment [PSS].

   o  In the 3GPP Multimedia Broadcast Multicast Service (MBMS) system=2C
      HTTP and MIKEY are used for key management [MBMS-SEC].

   A more detailed survey of requirements for media security management
   protocols can be found in [RFC5479].  As can be seen=2C the range of
   use cases is wide=2C and there is no single protocol that is
   appropriate for all scenarios.  These solutions have been further
<=
pre class=3D"newpage">  diversified by the existence of infrastructure elem=
ents such as
   authentication solutions that are tied into the key management.
 =3B
 =3B
 =3B
 =3B
Magnus said:
&nbs= p=3B
 =3B
"Yes=2C we haven't spent much time on the security cons= ideration section
yet. "A mandatory to implement media security solution= will be required
to be picked" is pointer at this WG not the implemento= r.

I would also point at our Charter that in its last paragraph says= :
"The products of the working group will support security and keying as=
required by BCP 61"

If you haven't read BCP 61 you probably shou= ld. It is basically says two
things. IETF should pick strong security an= d it shall be MANDATORY to
IMPLEMENT. I at least as chair will ensure th= at we have fulfilled this.
And that means for RTP not only encryption an= d integrity protection=2C
probably SRTP=2C but also a keying method.
=
Yes=2C we (authors of draft-ietf-rtcweb-rtp-usage) will write that SRTP= is
a MUST implement as soon as we have that consensus established. But = we
will need a keying scheme also and determine where it should be docum= ented.

Cheers

Magnus Westerlund
"
 =3B
 =3B<= BR>
= --_6f9615c1-c543-4be7-9000-21883a008e83_-- From bernard_aboba@hotmail.com Tue Nov 8 17:41:45 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF511F0C56 for ; Tue, 8 Nov 2011 17:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.060, 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 EVp4HSYSuV+p for ; Tue, 8 Nov 2011 17:41:45 -0800 (PST) Received: from blu0-omc3-s32.blu0.hotmail.com (blu0-omc3-s32.blu0.hotmail.com [65.55.116.107]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1991F0C3B for ; Tue, 8 Nov 2011 17:41:45 -0800 (PST) Received: from BLU152-W41 ([65.55.116.74]) by blu0-omc3-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 17:41:44 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_a4e52f37-b132-40b3-9cca-6670740274ef_" X-Originating-IP: [131.107.0.94] From: Bernard Aboba To: , Date: Tue, 8 Nov 2011 17:41:44 -0800 Importance: Normal In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com> References: , <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com>, , , , , <4EB7E6A5.70209@alvestrand.no>, , <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com>, <4EB9ACF5.80805@alvestrand.no>, <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com> MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2011 01:41:44.0641 (UTC) FILETIME=[BCBD0B10:01CC9E80] Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of 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: Wed, 09 Nov 2011 01:41:46 -0000 --_a4e52f37-b132-40b3-9cca-6670740274ef_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BA] If the concern is that we will make RTCWEB soooo secure that wiretapp= ing would be "too difficult" even for national governments with lots of res= ources=2C that is what I'd call a "high quality problem". Reading Eric's = draft=2C I would not say that the available security solutions are soooo ad= vanced at the moment that this is a practical concern. Even if we were to = mandate a "heap o' crypto" (e.g. SRTP=2C DTLS/SRTP=2C PKI=2C etc.) the chan= ces are excellent that it would not be deployed=2C would be contravened by = disreputable CAs=2C or would not be understood well enough by users to avoi= d misfortunes on a regular basis. What *does* worry me is that "wiretappi= ng" in RTCWEB would be so easy that any script kiddie could do it=2C and th= at browser-based surveillance could become an everyday occurrence. = = --_a4e52f37-b132-40b3-9cca-6670740274ef_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[BA] =3B If the concern is that we will make RTCWEB =3Bsoooo secure= that wiretapping would be "too difficult" even for national governments wi= th lots of resources=2C that is what I'd call a "high quality problem".&nbs= p=3B
 =3B
Reading Eric's draft=2C I would not say that the avail= able security solutions =3Bare soooo advanced at the moment that this&n= bsp=3Bis =3Ba practical concern. =3B =3BEven if we were to mand= ate a "heap o' crypto" (e.g. SRTP=2C DTLS/SRTP=2C PKI=2C etc.) the chances = are excellent that it would not be deployed=2C would be contravened by disr= eputable CAs=2C =3Bor would not be understood well enough by users to a= void misfortunes on =3Ba regular basis. =3B
 =3B
What *d= oes* worry me is that "wiretapping" in RTCWEB would be so easy that any scr= ipt kiddie could do it=2C and that browser-based surveillance could become = an everyday occurrence. =3B
 =3B
 =3B
 =3B
=
= --_a4e52f37-b132-40b3-9cca-6670740274ef_-- From bernard_aboba@hotmail.com Tue Nov 8 17:50:37 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431FB21F8801 for ; Tue, 8 Nov 2011 17:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.055, 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 0hRvZ3tqc93w for ; Tue, 8 Nov 2011 17:50:36 -0800 (PST) Received: from blu0-omc3-s13.blu0.hotmail.com (blu0-omc3-s13.blu0.hotmail.com [65.55.116.88]) by ietfa.amsl.com (Postfix) with ESMTP id B1B3721F87FA for ; Tue, 8 Nov 2011 17:50:36 -0800 (PST) Received: from BLU152-W59 ([65.55.116.74]) by blu0-omc3-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 17:50:36 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_76f37926-2912-4363-b475-3651c285e336_" X-Originating-IP: [131.107.0.94] From: Bernard Aboba To: Date: Tue, 8 Nov 2011 17:50:35 -0800 Importance: Normal In-Reply-To: References: , , <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com>, , , , , , , , , , <4EB7E6A5.70209@alvestrand.no>, , , , <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com>, , <4EB9ACF5.80805@alvestrand.no>, , <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2011 01:50:36.0251 (UTC) FILETIME=[F99A4AB0:01CC9E81] Subject: Re: [rtcweb] surveillance in RTCWEB (was wiretapping) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 01:50:37 -0000 --_76f37926-2912-4363-b475-3651c285e336_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BA] If the concern is that we will make RTCWEB soooo secure that browser-= based surveillance would be "too difficult" even for national governments w= ith lots of resources=2C that is what I'd call a "high quality problem". =20 =20 Reading Eric's draft=2C I would not say that the available security solutio= ns are soooo advanced at the moment that this is a practical concern. Even= if we were to mandate a "heap o' crypto" (e.g. SRTP=2C DTLS/SRTP=2C PKI=2C= etc.) the chances are excellent that it would not be deployed=2C would be = contravened by disreputable CAs=2C or would not be understood well enough b= y users to avoid misfortunes on a regular basis. =20 =20 What *does* worry me is that surveillance in RTCWEB would be so easy that a= ny script kiddie could do it=2C and that it could become an everyday occurr= ence.=20 = --_76f37926-2912-4363-b475-3651c285e336_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

[BA] =3B If the concern is that we will make RTCWEB =3Bsoooo secure= that =3Bbrowser-based surveillance would be "too difficult" even for n= ational governments with lots of resources=2C that is what I'd call a "high= quality problem". =3B
 =3B
Reading Eric's draft=2C I would = not say that the available security solutions =3Bare soooo advanced at = the moment that this =3Bis =3Ba practical concern. =3B =3BE= ven if we were to mandate a "heap o' crypto" (e.g. SRTP=2C DTLS/SRTP=2C PKI= =2C etc.) the chances are excellent that it would not be deployed=2C would = be contravened by disreputable CAs=2C =3Bor would not be understood wel= l enough by users to avoid misfortunes on =3Ba regular basis. =3B <= br> =3B
What *does* worry me is that =3Bsurveillance in RTCWEB w= ould be so easy that any script kiddie could do it=2C and that it could bec= ome an everyday occurrence. =3B
 =3B
= --_76f37926-2912-4363-b475-3651c285e336_-- From cb.list6@gmail.com Tue Nov 8 18:37:25 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2703611E8091 for ; Tue, 8 Nov 2011 18:37:25 -0800 (PST) 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.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_UNSUB22=0.948] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHCcc8OIvpFw for ; Tue, 8 Nov 2011 18:37:24 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC68811E8090 for ; Tue, 8 Nov 2011 18:37:23 -0800 (PST) Received: by gye5 with SMTP id 5so1496803gye.31 for ; Tue, 08 Nov 2011 18:37:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Dm+IhscD1n/jyA68mPL6bs5Qz+bx7MZ+I7pk+Jt+Yz0=; b=U2+JagniFZj/V8kYAA7BpXrnQqWKLxBAtRp0pdqe52nlKuR6z8+2V9rVYzYKeIwO4k W98bB3hHEDjjizH+AsOFo7aphKT9FTtdzhWzemdxZ8viT8Kk251os0zrLWiq2S+Ys8B9 w2Tc+lpn3cMRAsu0GYtO9XMMxQEZUbJylL3PU= MIME-Version: 1.0 Received: by 10.68.28.4 with SMTP id x4mr1493330pbg.56.1320806242779; Tue, 08 Nov 2011 18:37:22 -0800 (PST) Received: by 10.142.230.8 with HTTP; Tue, 8 Nov 2011 18:37:22 -0800 (PST) Received: by 10.142.230.8 with HTTP; Tue, 8 Nov 2011 18:37:22 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <4EB9ACF5.80805@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com> Date: Tue, 8 Nov 2011 18:37:22 -0800 Message-ID: From: Cameron Byrne To: Ravindran Parthasarathi Content-Type: multipart/alternative; boundary=bcaec520eaedeb002b04b1442a67 Cc: "<,rtcweb@ietf.org>," Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of 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: Wed, 09 Nov 2011 02:37:25 -0000 --bcaec520eaedeb002b04b1442a67 Content-Type: text/plain; charset=ISO-8859-1 On Nov 8, 2011 5:21 PM, "Ravindran Parthasarathi" wrote: > > Thanks to Harald/Cullen for pointing out RFC 2804. I take back my #2 comment based on RFC 2804 wiretapping policy. > > I wish to clarify why I gave this comment before closing on #2: > > It is the common practice in India to buy computer to talk/chat with the relatives who are outside India by using Skype/Gtalk/Yahoo (avoiding International subscriber dialing charges). Of course, Cell phone is more popular than Computer and cheap (~$100) Wi-Fi enabled (Android) Smartphones are available in market. WebRTC will bring the new innovative way of communicating using Smartphone (like free WebRTC session to street provisional store). Browser in Smartphone is the platform for making outgoing session towards provisional store. I really don't want these kind of WebRTC service are forbidden by Government laws unnecessarily due to security (SRTP) reasons. > > Getting into murky waters here. I believe the ietf values privacy and I would like srtp to be mandatory since I value privacy. If not supporting privacy is a requirement for your government, then perhaps webrtc is not for you. Cb > >-----Original Message----- > >From: Harald Alvestrand [mailto:harald@alvestrand.no] > >Sent: Wednesday, November 09, 2011 3:58 AM > >To: Ravindran Parthasarathi > >Cc: Hadriel Kaplan; Eric Rescorla; > >Subject: SRTP requirement - wiretapping (Re: [rtcweb] Let's define the > >purpose of WebRTC) > > > >Changing the subject again to mention SRTP.... > > > >On 11/08/2011 03:30 PM, Ravindran Parthasarathi wrote: > >> I agree with Hadriel that it is not required to mandate SRTP for > >WebRTC. My reasoning are as follows: > >> > >> 1) Security could be in the lower layer itself (IPsec, VPN, private > >MPLS cloud). For Enterprise-only-WebRTC application (no federation& no > >interop), there is no need of security by specific application like > >WebRTC as it is ensured in the infrastructure. WebRTC security will be > >duplicated for these infrastructure and may leads double encryption > >unnecessarily. > >This argument makes some sense. > >> > >> 2) Being in India, I'm interested in avoiding Government restriction > >on WebRTC proposal (Thanks to Tim for pointing this). I may not surprise > >to see that WebRTC mechanism is banned in India because intelligent > >agency struggles to break the key in each terrorist WebRTC site. > >(http://www.pcworld.com/businesscenter/article/235639/india_wants_to_int > >ercept_skype_google_communications.html) > >This argument is contrary to stated IETF policy (RFC 2804). > > > >I recommend the RFC for background reading. > >> > >> In case there is no use case to illustrate in RTCWeb draft, let us > >discuss in detail. > >> > >>> -----Original Message----- > >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >Behalf > >>> Of Hadriel Kaplan > >>> Sent: Monday, November 07, 2011 9:12 PM > >>> To: Eric Rescorla > >>> Cc: > >>> Subject: Re: [rtcweb] Let's define the purpose of WebRTC > >>> > >>> > >>> On 11/07/2011 02:50 PM, Eric Rescorla wrote: > >>>> On Sun, Nov 6, 2011 at 7:20 PM, Hadriel > >Kaplan > >>> wrote: > >>>>> Who said "too slow"? There *is* an extra round-trip or two > >involved > >>> I presume, if we're talking DTLS-SRTP, but no I didn't mean that as a > >>> "hit". I just meant the extra computing cycles for SRTP being a > >"hit". > >>> For WebRTC-to-WebRTC I don't think that matters at all. For WebRTC- > >to- > >>> media-server it might, for a free game app or greeting card app that > >>> don't care about it to begin with, and which use plaintext HTTP to > >begin > >>> with. > >>>> Sorry, I didn't mean to put words in your mouth. Performance > >>> measurements > >>>> of HTTP versus HTTPS in modern Web environments suggest that the > >>> additional > >>>> load for HTTPS is not significant. Do you have evidence that the > >>> situation is > >>>> different for SRTP versus RTP? > >>> Only from the DSP guys, and those would be hardware DSPs not > >softDSPs. > >>> It runs them anywhere from 10-25% overhead, they say, depending on > >the > >>> vendor and what else their DSPs are doing at the time. > >>> > >>> But ultimately even in software I assume it's all relative to what > >other > >>> work you're doing. If you have to render a video stream on a screen > >and > >>> encode camera input into a codec being sent out, then my guess is > >SRTP > >>> overhead is a tiny factor not worth talking about. If you're mixing > >>> multiple RTP streams as a conference server, then I assume doing SRTP > >>> for thousands of simultaneous audio RTP streams for multiple > >>> simultaneous conferences becomes noticeable. Or at least so they > >seem > >>> to claim - I don't know since I don't build a media server (hardware > >>> SBCs often offload SRTP onto dedicated hardware). One large software > >>> company even created their own proprietary packet format for SRTP > >that > >>> they claimed was done for improving performance/scalability, so I > >assume > >>> it has some impact they don't want their customers to incur. > >>> > >>> -hadriel > >>> > >>> _______________________________________________ > >>> rtcweb mailing list > >>> rtcweb@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rtcweb > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --bcaec520eaedeb002b04b1442a67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 8, 2011 5:21 PM, "Ravindran Parthasarathi" <pravindran@sonusnet.com> wrote:
>
> Thanks to Harald/Cullen for pointing out RFC 2804. I take back my #2 c= omment based on RFC 2804 wiretapping policy.
>
> I wish to clarify why I gave this comment before closing on #2:
>
> It is the common practice in India to buy computer to talk/chat with t= he relatives who are outside India by using Skype/Gtalk/Yahoo (avoiding Int= ernational subscriber dialing charges). Of course, Cell phone is more popul= ar than Computer and cheap (~$100) Wi-Fi enabled (Android) Smartphones are = available in market. WebRTC will bring the new innovative way of communicat= ing using Smartphone (like free WebRTC session to street provisional store)= . Browser in Smartphone is the platform for making outgoing session towards= provisional store. I really don't want these kind of WebRTC service ar= e forbidden by Government laws unnecessarily due to security (SRTP) reasons= .
>
>

Getting into murky waters here.

I believe the ietf values privacy and I would like srtp to be mandatory = since I value privacy.

If not supporting privacy is a requirement for your government, then per= haps webrtc is not for you.

Cb

> >-----Original Message-----
> >From: Harald Alvestrand [mailto:harald@alvestrand.no]
> >Sent: Wednesday, November 09, 2011 3:58 AM
> >To: Ravindran Parthasarathi
> >Cc: Hadriel Kaplan; Eric Rescorla; <rtcweb@ietf.org>
> >Subject: SRTP requirement - wiretapping (Re: [rtcweb] Let's de= fine the
> >purpose of WebRTC)
> >
> >Changing the subject again to mention SRTP....
> >
> >On 11/08/2011 03:30 PM, Ravindran Parthasarathi wrote:
> >> I agree with Hadriel that it is not required to mandate SRTP = for
> >WebRTC. My reasoning are as follows:
> >>
> >> 1) Security could be in the lower layer itself (IPsec, VPN, p= rivate
> >MPLS cloud). For Enterprise-only-WebRTC application (no federation= & =A0no
> >interop), there is no need of security by specific application lik= e
> >WebRTC as it is ensured in the infrastructure. WebRTC security wil= l be
> >duplicated for these infrastructure and may leads double encryptio= n
> >unnecessarily.
> >This argument makes some sense.
> >>
> >> 2) Being in India, I'm interested in avoiding Government = restriction
> >on WebRTC proposal (Thanks to Tim for pointing this). I may not su= rprise
> >to see that WebRTC mechanism is banned in India because intelligen= t
> >agency struggles to break the key in each terrorist WebRTC site. > >(http://www.pcworld.com/businesscenter/article/235639/ind= ia_wants_to_int
> >ercept_skype_google_communications.html)
> >This argument is contrary to stated IETF policy (RFC 2804).
> >
> >I recommend the RFC for background reading.
> >>
> >> In case there is no use case to illustrate in RTCWeb draft, l= et us
> >discuss in detail.
> >>
> >>> -----Original Message-----
> >>> From: rtcweb-b= ounces@ietf.org [mailto:rtcw= eb-bounces@ietf.org] On
> >Behalf
> >>> Of Hadriel Kaplan
> >>> Sent: Monday, November 07, 2011 9:12 PM
> >>> To: Eric Rescorla
> >>> Cc:<rtcweb@ietf.org= >
> >>> Subject: Re: [rtcweb] Let's define the purpose of Web= RTC
> >>>
> >>>
> >>> On 11/07/2011 02:50 PM, Eric Rescorla wrote:
> >>>> On Sun, Nov 6, 2011 at 7:20 PM, Hadriel
> >Kaplan<HKaplan@acmepa= cket.com>
> >>> wrote:
> >>>>> Who said "too slow"? =A0There *is* an e= xtra round-trip or two
> >involved
> >>> I presume, if we're talking DTLS-SRTP, but no I didn&= #39;t mean that as a
> >>> "hit". =A0I just meant the extra computing cycl= es for SRTP being a
> >"hit".
> >>> For WebRTC-to-WebRTC I don't think that matters at al= l. =A0For WebRTC-
> >to-
> >>> media-server it might, for a free game app or greeting ca= rd app that
> >>> don't care about it to begin with, and which use plai= ntext HTTP to
> >begin
> >>> with.
> >>>> Sorry, I didn't mean to put words in your mouth. = Performance
> >>> measurements
> >>>> of HTTP versus HTTPS in modern Web environments sugge= st that the
> >>> additional
> >>>> load for HTTPS is not significant. Do you have eviden= ce that the
> >>> situation is
> >>>> different for SRTP versus RTP?
> >>> Only from the DSP guys, and those would be hardware DSPs = not
> >softDSPs.
> >>> It runs them anywhere from 10-25% overhead, they say, dep= ending on
> >the
> >>> vendor and what else their DSPs are doing at the time. > >>>
> >>> But ultimately even in software I assume it's all rel= ative to what
> >other
> >>> work you're doing. =A0If you have to render a video s= tream on a screen
> >and
> >>> encode camera input into a codec being sent out, then my = guess is
> >SRTP
> >>> overhead is a tiny factor not worth talking about. =A0If = you're mixing
> >>> multiple RTP streams as a conference server, then I assum= e doing SRTP
> >>> for thousands of simultaneous audio RTP streams for multi= ple
> >>> simultaneous conferences becomes noticeable. =A0Or at lea= st so they
> >seem
> >>> to claim - I don't know since I don't build a med= ia server (hardware
> >>> SBCs often offload SRTP onto dedicated hardware). =A0One = large software
> >>> company even created their own proprietary packet format = for SRTP
> >that
> >>> they claimed was done for improving performance/scalabili= ty, so I
> >assume
> >>> it has some impact they don't want their customers to= incur.
> >>>
> >>> -hadriel
> >>>
> >>> _______________________________________________
> >>> rtcweb mailing list
> >>> rtcweb@ietf.org > >>> = https://www.ietf.org/mailman/listinfo/rtcweb
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> http= s://www.ietf.org/mailman/listinfo/rtcweb
> >>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--bcaec520eaedeb002b04b1442a67-- From pravindran@sonusnet.com Tue Nov 8 18:50:35 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4651F0C49 for ; Tue, 8 Nov 2011 18:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_UNSUB22=0.948] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfWA54263Y2h for ; Tue, 8 Nov 2011 18:50:34 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7751F0C4F for ; Tue, 8 Nov 2011 18:50:32 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA92p5sB014863; Tue, 8 Nov 2011 21:51:05 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 21:50:29 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 08:20:37 +0530 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.0339.001; Wed, 9 Nov 2011 08:20:37 +0530 From: Ravindran Parthasarathi To: Cameron Byrne Thread-Topic: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of WebRTC) Thread-Index: AQHMnoiMLXoobGtfx0Kkx8oSZTnrRJWj1oYw Date: Wed, 9 Nov 2011 02:50:37 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01349FE6@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <4EB9ACF5.80805@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.53.6] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C01349FE6inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2011 02:50:37.0671 (UTC) FILETIME=[5C375F70:01CC9E8A] Cc: "<,rtcweb@ietf.org>," Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of 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: Wed, 09 Nov 2011 02:50:35 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C01349FE6inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cameron, I guess that we are in the same w.r.t IETF privacy policy and it is main re= ason, I take back my comment #2. But, Please look into comment #1 for Enter= prise WebRTC application wherein SRTP is not required to be mandated. > >> 1) Security could be in the lower layer itself (IPsec, VPN, private > >MPLS cloud). For Enterprise-only-WebRTC application (no federation& no > >interop), there is no need of security by specific application like > >WebRTC as it is ensured in the infrastructure. WebRTC security will be > >duplicated for these infrastructure and may leads double encryption > >unnecessarily. Thanks Partha From: Cameron Byrne [mailto:cb.list6@gmail.com] Sent: Wednesday, November 09, 2011 8:07 AM To: Ravindran Parthasarathi Cc: <,rtcweb@ietf.org>, Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the = purpose of WebRTC) On Nov 8, 2011 5:21 PM, "Ravindran Parthasarathi" > wrote: > > Thanks to Harald/Cullen for pointing out RFC 2804. I take back my #2 comm= ent based on RFC 2804 wiretapping policy. > > I wish to clarify why I gave this comment before closing on #2: > > It is the common practice in India to buy computer to talk/chat with the = relatives who are outside India by using Skype/Gtalk/Yahoo (avoiding Intern= ational subscriber dialing charges). Of course, Cell phone is more popular = than Computer and cheap (~$100) Wi-Fi enabled (Android) Smartphones are ava= ilable in market. WebRTC will bring the new innovative way of communicating= using Smartphone (like free WebRTC session to street provisional store). B= rowser in Smartphone is the platform for making outgoing session towards pr= ovisional store. I really don't want these kind of WebRTC service are forbi= dden by Government laws unnecessarily due to security (SRTP) reasons. > > Getting into murky waters here. I believe the ietf values privacy and I would like srtp to be mandatory sin= ce I value privacy. If not supporting privacy is a requirement for your government, then perhap= s webrtc is not for you. Cb > >-----Original Message----- > >From: Harald Alvestrand [mailto:harald@alvestrand.no] > >Sent: Wednesday, November 09, 2011 3:58 AM > >To: Ravindran Parthasarathi > >Cc: Hadriel Kaplan; Eric Rescorla; > > >Subject: SRTP requirement - wiretapping (Re: [rtcweb] Let's define the > >purpose of WebRTC) > > > >Changing the subject again to mention SRTP.... > > > >On 11/08/2011 03:30 PM, Ravindran Parthasarathi wrote: > >> I agree with Hadriel that it is not required to mandate SRTP for > >WebRTC. My reasoning are as follows: > >> > >> 1) Security could be in the lower layer itself (IPsec, VPN, private > >MPLS cloud). For Enterprise-only-WebRTC application (no federation& no > >interop), there is no need of security by specific application like > >WebRTC as it is ensured in the infrastructure. WebRTC security will be > >duplicated for these infrastructure and may leads double encryption > >unnecessarily. > >This argument makes some sense. > >> > >> 2) Being in India, I'm interested in avoiding Government restriction > >on WebRTC proposal (Thanks to Tim for pointing this). I may not surprise > >to see that WebRTC mechanism is banned in India because intelligent > >agency struggles to break the key in each terrorist WebRTC site. > >(http://www.pcworld.com/businesscenter/article/235639/india_wants_to_int > >ercept_skype_google_communications.html) > >This argument is contrary to stated IETF policy (RFC 2804). > > > >I recommend the RFC for background reading. > >> > >> In case there is no use case to illustrate in RTCWeb draft, let us > >discuss in detail. > >> > >>> -----Original Message----- > >>> From: rtcweb-bounces@ietf.org [mailto= :rtcweb-bounces@ietf.org] On > >Behalf > >>> Of Hadriel Kaplan > >>> Sent: Monday, November 07, 2011 9:12 PM > >>> To: Eric Rescorla > >>> Cc:> > >>> Subject: Re: [rtcweb] Let's define the purpose of WebRTC > >>> > >>> > >>> On 11/07/2011 02:50 PM, Eric Rescorla wrote: > >>>> On Sun, Nov 6, 2011 at 7:20 PM, Hadriel > >Kaplan> > >>> wrote: > >>>>> Who said "too slow"? There *is* an extra round-trip or two > >involved > >>> I presume, if we're talking DTLS-SRTP, but no I didn't mean that as a > >>> "hit". I just meant the extra computing cycles for SRTP being a > >"hit". > >>> For WebRTC-to-WebRTC I don't think that matters at all. For WebRTC- > >to- > >>> media-server it might, for a free game app or greeting card app that > >>> don't care about it to begin with, and which use plaintext HTTP to > >begin > >>> with. > >>>> Sorry, I didn't mean to put words in your mouth. Performance > >>> measurements > >>>> of HTTP versus HTTPS in modern Web environments suggest that the > >>> additional > >>>> load for HTTPS is not significant. Do you have evidence that the > >>> situation is > >>>> different for SRTP versus RTP? > >>> Only from the DSP guys, and those would be hardware DSPs not > >softDSPs. > >>> It runs them anywhere from 10-25% overhead, they say, depending on > >the > >>> vendor and what else their DSPs are doing at the time. > >>> > >>> But ultimately even in software I assume it's all relative to what > >other > >>> work you're doing. If you have to render a video stream on a screen > >and > >>> encode camera input into a codec being sent out, then my guess is > >SRTP > >>> overhead is a tiny factor not worth talking about. If you're mixing > >>> multiple RTP streams as a conference server, then I assume doing SRTP > >>> for thousands of simultaneous audio RTP streams for multiple > >>> simultaneous conferences becomes noticeable. Or at least so they > >seem > >>> to claim - I don't know since I don't build a media server (hardware > >>> SBCs often offload SRTP onto dedicated hardware). One large software > >>> company even created their own proprietary packet format for SRTP > >that > >>> they claimed was done for improving performance/scalability, so I > >assume > >>> it has some impact they don't want their customers to incur. > >>> > >>> -hadriel > >>> > >>> _______________________________________________ > >>> rtcweb mailing list > >>> rtcweb@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rtcweb > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --_000_387F9047F55E8C42850AD6B3A7A03C6C01349FE6inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Cameron,

 

I guess that we are in the same w.r.t IETF privacy policy an= d it is main reason, I take back my comment #2. But, Please look into comme= nt #1 for Enterprise WebRTC application wherein SRTP is not required to be mandated.=

 

> >> 1) Security could be in the lower laye= r itself (IPsec, VPN, private
> >MPLS cloud). For Enterprise-only-WebRTC application (no federation= &  no
> >interop), there is no need of security by specific application lik= e
> >WebRTC as it is ensured in the infrastructure. WebRTC security wil= l be
> >duplicated for these infrastructure and may leads double encryptio= n
> >unnecessarily.

Thanks

Partha

 

From: Cameron = Byrne [mailto:cb.list6@gmail.com]
Sent: Wednesday, November 09, 2011 8:07 AM
To: Ravindran Parthasarathi
Cc: &lt,rtcweb@ietf.org&gt,
Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's defi= ne the purpose of WebRTC)

 


On Nov 8, 2011 5:21 PM, "Ravindran Parthasarathi" <pravindran@sonusnet.com> wrote:
>
> Thanks to Harald/Cullen for pointing out RFC 2804. I take back my #2 c= omment based on RFC 2804 wiretapping policy.
>
> I wish to clarify why I gave this comment before closing on #2:
>
> It is the common practice in India to buy computer to talk/chat with t= he relatives who are outside India by using Skype/Gtalk/Yahoo (avoiding Int= ernational subscriber dialing charges). Of course, Cell phone is more popul= ar than Computer and cheap (~$100) Wi-Fi enabled (Android) Smartphones are available in market. WebRTC will b= ring the new innovative way of communicating using Smartphone (like free We= bRTC session to street provisional store). Browser in Smartphone is the pla= tform for making outgoing session towards provisional store. I really don't want these kind of WebRTC servic= e are forbidden by Government laws unnecessarily due to security (SRTP) rea= sons.
>
>

Getting into murky waters here.

I believe the ietf values privacy and I would like srtp to be mandatory = since I value privacy.

If not supporting privacy is a requirement for your government, then per= haps webrtc is not for you.

Cb

> >-----Original Message-----
> >From: Harald Alvestrand [mailto:harald@alvestrand.no]
> >Sent: Wednesday, November 09, 2011 3:58 AM
> >To: Ravindran Parthasarathi
> >Cc: Hadriel Kaplan; Eric Rescorla; <rtcweb@ietf.org>
> >Subject: SRTP requirement - wiretapping (Re: [rtcweb] Let's define= the
> >purpose of WebRTC)
> >
> >Changing the subject again to mention SRTP....
> >
> >On 11/08/2011 03:30 PM, Ravindran Parthasarathi wrote:
> >> I agree with Hadriel that it is not required to mandate SRTP = for
> >WebRTC. My reasoning are as follows:
> >>
> >> 1) Security could be in the lower layer itself (IPsec, VPN, p= rivate
> >MPLS cloud). For Enterprise-only-WebRTC application (no federation= &  no
> >interop), there is no need of security by specific application lik= e
> >WebRTC as it is ensured in the infrastructure. WebRTC security wil= l be
> >duplicated for these infrastructure and may leads double encryptio= n
> >unnecessarily.
> >This argument makes some sense.
> >>
> >> 2) Being in India, I'm interested in avoiding Government rest= riction
> >on WebRTC proposal (Thanks to Tim for pointing this). I may not su= rprise
> >to see that WebRTC mechanism is banned in India because intelligen= t
> >agency struggles to break the key in each terrorist WebRTC site. > >(http://www.pcworld.com/businesscenter/article/235639/ind= ia_wants_to_int
> >ercept_skype_google_communications.html)
> >This argument is contrary to stated IETF policy (RFC 2804).
> >
> >I recommend the RFC for background reading.
> >>
> >> In case there is no use case to illustrate in RTCWeb draft, l= et us
> >discuss in detail.
> >>
> >>> -----Original Message-----
> >>> From: rtcweb-b= ounces@ietf.org [mailto:rtcw= eb-bounces@ietf.org] On
> >Behalf
> >>> Of Hadriel Kaplan
> >>> Sent: Monday, November 07, 2011 9:12 PM
> >>> To: Eric Rescorla
> >>> Cc:<rtcweb@ietf.org= >
> >>> Subject: Re: [rtcweb] Let's define the purpose of WebRTC<= br> > >>>
> >>>
> >>> On 11/07/2011 02:50 PM, Eric Rescorla wrote:
> >>>> On Sun, Nov 6, 2011 at 7:20 PM, Hadriel
> >Kaplan<HKaplan@acmepa= cket.com>
> >>> wrote:
> >>>>> Who said "too slow"?  There *is* a= n extra round-trip or two
> >involved
> >>> I presume, if we're talking DTLS-SRTP, but no I didn't me= an that as a
> >>> "hit".  I just meant the extra computing c= ycles for SRTP being a
> >"hit".
> >>> For WebRTC-to-WebRTC I don't think that matters at all. &= nbsp;For WebRTC-
> >to-
> >>> media-server it might, for a free game app or greeting ca= rd app that
> >>> don't care about it to begin with, and which use plaintex= t HTTP to
> >begin
> >>> with.
> >>>> Sorry, I didn't mean to put words in your mouth. Perf= ormance
> >>> measurements
> >>>> of HTTP versus HTTPS in modern Web environments sugge= st that the
> >>> additional
> >>>> load for HTTPS is not significant. Do you have eviden= ce that the
> >>> situation is
> >>>> different for SRTP versus RTP?
> >>> Only from the DSP guys, and those would be hardware DSPs = not
> >softDSPs.
> >>> It runs them anywhere from 10-25% overhead, they say, dep= ending on
> >the
> >>> vendor and what else their DSPs are doing at the time. > >>>
> >>> But ultimately even in software I assume it's all relativ= e to what
> >other
> >>> work you're doing.  If you have to render a video st= ream on a screen
> >and
> >>> encode camera input into a codec being sent out, then my = guess is
> >SRTP
> >>> overhead is a tiny factor not worth talking about.  = If you're mixing
> >>> multiple RTP streams as a conference server, then I assum= e doing SRTP
> >>> for thousands of simultaneous audio RTP streams for multi= ple
> >>> simultaneous conferences becomes noticeable.  Or at = least so they
> >seem
> >>> to claim - I don't know since I don't build a media serve= r (hardware
> >>> SBCs often offload SRTP onto dedicated hardware).  O= ne large software
> >>> company even created their own proprietary packet format = for SRTP
> >that
> >>> they claimed was done for improving performance/scalabili= ty, so I
> >assume
> >>> it has some impact they don't want their customers to inc= ur.
> >>>
> >>> -hadriel
> >>>
> >>> _______________________________________________
> >>> rtcweb mailing list
> >>> rtcweb@ietf.org > >>> = https://www.ietf.org/mailman/listinfo/rtcweb
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> http= s://www.ietf.org/mailman/listinfo/rtcweb
> >>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--_000_387F9047F55E8C42850AD6B3A7A03C6C01349FE6inbamail01sonus_-- From pravindran@sonusnet.com Tue Nov 8 18:58:08 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BFA11E8073 for ; Tue, 8 Nov 2011 18:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 kHyLkoiAWxve for ; Tue, 8 Nov 2011 18:58:07 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 229A51F0C47 for ; Tue, 8 Nov 2011 18:58:07 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA92wdQ2019199; Tue, 8 Nov 2011 21:58:39 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 21:58:02 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 08:28:11 +0530 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.0339.001; Wed, 9 Nov 2011 08:28:11 +0530 From: Ravindran Parthasarathi To: Cullen Jennings , "Olle E. Johansson" Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AQHMm7/XxS9yQix74UmCewMPtvNQWZWe2WiAgABcZwCAAFnsgIAA1PQAgACv/gCAAAVogIAAGdwAgAHTzND//7JMAIAAEPMAgAESTSA= Date: Wed, 9 Nov 2011 02:58:10 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> In-Reply-To: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.53.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2011 02:58:11.0483 (UTC) FILETIME=[6AB596B0:01CC9E8B] Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 02:58:08 -0000 Cullen, As I mentioned in http://www.ietf.org/mail-archive/web/rtcweb/current/msg02= 674.html, below comment #2 is not valid in IETF.=20 But I'm interested in your opinion as Enterprise UC expert on my 1st commen= t: "1) Security could be in the lower layer itself (IPsec, VPN, private MPLS c= loud). For Enterprise-only-WebRTC application (no federation & no interop),= there is no need of security for specific application like WebRTC as it is= ensured in the infrastructure. WebRTC security will be duplicated for thes= e infrastructure and may lead to double encryption unnecessarily." Thanks Partha >-----Original Message----- >From: Cullen Jennings [mailto:fluffy@cisco.com] >Sent: Tuesday, November 08, 2011 9:29 PM >To: Olle E. Johansson >Cc: Ravindran Parthasarathi; >Subject: Re: [rtcweb] Let's define the purpose of WebRTC > > >On Nov 8, 2011, at 7:58 AM, Olle E. Johansson wrote: > >>> >>> 2) Being in India, I'm interested in avoiding Government restriction >on WebRTC proposal (Thanks to Tim for pointing this). I may not surprise >to see that WebRTC mechanism is banned in India because intelligent >agency struggles to break the key in each terrorist WebRTC site. >(http://www.pcworld.com/businesscenter/article/235639/india_wants_to_int >ercept_skype_google_communications.html) >> That is an interesting objection. I don't think SRTP by default is the >problem here. In the case where you need lawful interception in the >application, >> the server needs to route the calls through an RTCweb b2b media >server. > >I think the situation in India is a taxiation not encryption issue. >Partha and I can do VoIP between Canada and India fully encrypted no >problem - in fact we have a dial plan set up specifically so I can do >that with him. The issue is a taxation issue. If we want to be able to >connect that voip server to the PSTN in a way that it becomes what the >regulators in India consider a telephone service, then we need >permission to effectively be an indian telco. Right now I can make a >full SRTP encrypted conversation with between my IP phones and Partha's >but I don't think Partha can use his IP phone to access one the the PSTN >GWs outside India. > >Anyways, I will remind people of RAVEN http://www.rfc- >editor.org/rfc/rfc2804.txt > From jmvalin@mozilla.com Tue Nov 8 19:22:18 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED8D1F0C4D for ; Tue, 8 Nov 2011 19:22:18 -0800 (PST) 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 gsVsNdlHWaRr for ; Tue, 8 Nov 2011 19:22:17 -0800 (PST) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7BD1F0C44 for ; Tue, 8 Nov 2011 19:22:17 -0800 (PST) Received: from [192.168.1.15] (modemcable239.192-178-173.mc.videotron.ca [173.178.192.239]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 590324AED8C; Tue, 8 Nov 2011 19:22:16 -0800 (PST) Message-ID: <4EB9F221.9000706@mozilla.com> Date: Tue, 08 Nov 2011 22:23:13 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Cullen Jennings References: <4EB44684.30801@jesup.org> <5CA5BC55-60E5-4837-AC6D-ED2DAF225296@cisco.com> In-Reply-To: <5CA5BC55-60E5-4837-AC6D-ED2DAF225296@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Codec 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: Wed, 09 Nov 2011 03:22:18 -0000 On 08/11/11 06:31 PM, Cullen Jennings wrote: >> Just to note: G.729's license requirements make supporting it a >> virtual impossibility for Mozilla, and unlikely for the other >> browsers. > > I realize this was the case at one point in time but I thought we > worked with VoiceAge to solve the problem of open source software > using 729. Is it still a problem ? Can we send Jean-Marc to fix it? I'm also not aware of anything that was done to make G.729 available in open source software. G.729 licensing is a bit of a mess and last I heard (though it could have changed), VoiceAge does not even license all of the patents that (are thought to) cover G.729. Jean-Marc From cb.list6@gmail.com Tue Nov 8 19:28:01 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AEB1F0C4D for ; Tue, 8 Nov 2011 19:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_UNSUB22=0.948] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDqhL52l9p4U for ; Tue, 8 Nov 2011 19:28:00 -0800 (PST) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id A35D11F0C44 for ; Tue, 8 Nov 2011 19:27:38 -0800 (PST) Received: by pzk4 with SMTP id 4so491568pzk.9 for ; Tue, 08 Nov 2011 19:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7itZN1RiAZsGt7BVZmqS3Gd66rfzMukZmI2PlonLpew=; b=CSnhXKC5c6wYicUDAVnG//5oTxXrkqv5hxXJt0ThZPHFB2qixj9GWo7V+IJ8gnDWXq MeCgXs+4hYR9CgFEBKew3zTq/AWk+6JiTD9EezgzchjTqXDIWk+oQxESgi1jK+AhQk4Y mAZjUcwDmh52aJBReTa+tgZKX607JyXmU2mJM= MIME-Version: 1.0 Received: by 10.68.37.42 with SMTP id v10mr1898784pbj.22.1320809256649; Tue, 08 Nov 2011 19:27:36 -0800 (PST) Received: by 10.142.230.8 with HTTP; Tue, 8 Nov 2011 19:27:34 -0800 (PST) Received: by 10.142.230.8 with HTTP; Tue, 8 Nov 2011 19:27:34 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01349FE6@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <4EB9ACF5.80805@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FE6@inba-mail01.sonusnet.com> Date: Tue, 8 Nov 2011 19:27:34 -0800 Message-ID: From: Cameron Byrne To: Ravindran Parthasarathi Content-Type: multipart/alternative; boundary=bcaec520e9a98f03a404b144de0b Cc: "<,rtcweb@ietf.org>," Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of 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: Wed, 09 Nov 2011 03:28:01 -0000 --bcaec520e9a98f03a404b144de0b Content-Type: text/plain; charset=ISO-8859-1 On Nov 8, 2011 6:50 PM, "Ravindran Parthasarathi" wrote: > > Cameron, > > > > I guess that we are in the same w.r.t IETF privacy policy and it is main reason, I take back my comment #2. But, Please look into comment #1 for Enterprise WebRTC application wherein SRTP is not required to be mandated. > > > > > >> 1) Security could be in the lower layer itself (IPsec, VPN, private > > >MPLS cloud). For Enterprise-only-WebRTC application (no federation& no > > >interop), there is no need of security by specific application like > > >WebRTC as it is ensured in the infrastructure. WebRTC security will be > > >duplicated for these infrastructure and may leads double encryption > > >unnecessarily. > > Thanks > > Partha > I don't believe we can assume other crypto measures are in place Bob and Alice work for Toobigtofail Inc. They are on the same LAN segment and using webrtc to communicate about making a large investment. On that same LAN segment there is a compromised host intercepting all traffic (it did some arp spoofing or something like that ) No problem here since Bob and Alice are using srtp. If they did not, the financial info would have been exposed Cb > > > From: Cameron Byrne [mailto:cb.list6@gmail.com] > Sent: Wednesday, November 09, 2011 8:07 AM > To: Ravindran Parthasarathi > Cc: <,rtcweb@ietf.org>, > Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of WebRTC) > > > > > On Nov 8, 2011 5:21 PM, "Ravindran Parthasarathi" wrote: > > > > Thanks to Harald/Cullen for pointing out RFC 2804. I take back my #2 comment based on RFC 2804 wiretapping policy. > > > > I wish to clarify why I gave this comment before closing on #2: > > > > It is the common practice in India to buy computer to talk/chat with the relatives who are outside India by using Skype/Gtalk/Yahoo (avoiding International subscriber dialing charges). Of course, Cell phone is more popular than Computer and cheap (~$100) Wi-Fi enabled (Android) Smartphones are available in market. WebRTC will bring the new innovative way of communicating using Smartphone (like free WebRTC session to street provisional store). Browser in Smartphone is the platform for making outgoing session towards provisional store. I really don't want these kind of WebRTC service are forbidden by Government laws unnecessarily due to security (SRTP) reasons. > > > > > > Getting into murky waters here. > > I believe the ietf values privacy and I would like srtp to be mandatory since I value privacy. > > If not supporting privacy is a requirement for your government, then perhaps webrtc is not for you. > > Cb > > > >-----Original Message----- > > >From: Harald Alvestrand [mailto:harald@alvestrand.no] > > >Sent: Wednesday, November 09, 2011 3:58 AM > > >To: Ravindran Parthasarathi > > >Cc: Hadriel Kaplan; Eric Rescorla; > > >Subject: SRTP requirement - wiretapping (Re: [rtcweb] Let's define the > > >purpose of WebRTC) > > > > > >Changing the subject again to mention SRTP.... > > > > > >On 11/08/2011 03:30 PM, Ravindran Parthasarathi wrote: > > >> I agree with Hadriel that it is not required to mandate SRTP for > > >WebRTC. My reasoning are as follows: > > >> > > >> 1) Security could be in the lower layer itself (IPsec, VPN, private > > >MPLS cloud). For Enterprise-only-WebRTC application (no federation& no > > >interop), there is no need of security by specific application like > > >WebRTC as it is ensured in the infrastructure. WebRTC security will be > > >duplicated for these infrastructure and may leads double encryption > > >unnecessarily. > > >This argument makes some sense. > > >> > > >> 2) Being in India, I'm interested in avoiding Government restriction > > >on WebRTC proposal (Thanks to Tim for pointing this). I may not surprise > > >to see that WebRTC mechanism is banned in India because intelligent > > >agency struggles to break the key in each terrorist WebRTC site. > > >( http://www.pcworld.com/businesscenter/article/235639/india_wants_to_int > > >ercept_skype_google_communications.html) > > >This argument is contrary to stated IETF policy (RFC 2804). > > > > > >I recommend the RFC for background reading. > > >> > > >> In case there is no use case to illustrate in RTCWeb draft, let us > > >discuss in detail. > > >> > > >>> -----Original Message----- > > >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > >Behalf > > >>> Of Hadriel Kaplan > > >>> Sent: Monday, November 07, 2011 9:12 PM > > >>> To: Eric Rescorla > > >>> Cc: > > >>> Subject: Re: [rtcweb] Let's define the purpose of WebRTC > > >>> > > >>> > > >>> On 11/07/2011 02:50 PM, Eric Rescorla wrote: > > >>>> On Sun, Nov 6, 2011 at 7:20 PM, Hadriel > > >Kaplan > > >>> wrote: > > >>>>> Who said "too slow"? There *is* an extra round-trip or two > > >involved > > >>> I presume, if we're talking DTLS-SRTP, but no I didn't mean that as a > > >>> "hit". I just meant the extra computing cycles for SRTP being a > > >"hit". > > >>> For WebRTC-to-WebRTC I don't think that matters at all. For WebRTC- > > >to- > > >>> media-server it might, for a free game app or greeting card app that > > >>> don't care about it to begin with, and which use plaintext HTTP to > > >begin > > >>> with. > > >>>> Sorry, I didn't mean to put words in your mouth. Performance > > >>> measurements > > >>>> of HTTP versus HTTPS in modern Web environments suggest that the > > >>> additional > > >>>> load for HTTPS is not significant. Do you have evidence that the > > >>> situation is > > >>>> different for SRTP versus RTP? > > >>> Only from the DSP guys, and those would be hardware DSPs not > > >softDSPs. > > >>> It runs them anywhere from 10-25% overhead, they say, depending on > > >the > > >>> vendor and what else their DSPs are doing at the time. > > >>> > > >>> But ultimately even in software I assume it's all relative to what > > >other > > >>> work you're doing. If you have to render a video stream on a screen > > >and > > >>> encode camera input into a codec being sent out, then my guess is > > >SRTP > > >>> overhead is a tiny factor not worth talking about. If you're mixing > > >>> multiple RTP streams as a conference server, then I assume doing SRTP > > >>> for thousands of simultaneous audio RTP streams for multiple > > >>> simultaneous conferences becomes noticeable. Or at least so they > > >seem > > >>> to claim - I don't know since I don't build a media server (hardware > > >>> SBCs often offload SRTP onto dedicated hardware). One large software > > >>> company even created their own proprietary packet format for SRTP > > >that > > >>> they claimed was done for improving performance/scalability, so I > > >assume > > >>> it has some impact they don't want their customers to incur. > > >>> > > >>> -hadriel > > >>> > > >>> _______________________________________________ > > >>> rtcweb mailing list > > >>> rtcweb@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/rtcweb > > >> _______________________________________________ > > >> rtcweb mailing list > > >> rtcweb@ietf.org > > >> https://www.ietf.org/mailman/listinfo/rtcweb > > >> > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb --bcaec520e9a98f03a404b144de0b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 8, 2011 6:50 PM, "Ravindran Parthasarathi" <pravindran@sonusnet.com> wrote:
>
> Cameron,
>
> =A0
>
> I guess that we are in the same w.r.t IETF privacy policy and it is ma= in reason, I take back my comment #2. But, Please look into comment #1 for = Enterprise WebRTC application wherein SRTP is not required to be mandated.<= br> >
> =A0
>
> > >> 1) Security could be in the lower layer itself (IPsec, V= PN, private
> > >MPLS cloud). For Enterprise-only-WebRTC application (no feder= ation& =A0no
> > >interop), there is no need of security by specific applicatio= n like
> > >WebRTC as it is ensured in the infrastructure. WebRTC securit= y will be
> > >duplicated for these infrastructure and may leads double encr= yption
> > >unnecessarily.
>
> Thanks
>
> Partha
>

I don't believe we can assume other crypto measures are in place

Bob and Alice work for Toobigtofail Inc. They are on the same LAN segme= nt and using webrtc to communicate about making a large investment. On that= same LAN segment there is a compromised host intercepting all traffic (it = did some arp spoofing or something like that )

No problem here since Bob and Alice are using srtp.=A0

If they did not, the financial info would have been exposed

Cb
> =A0
>
> From: Cameron Byrne [mailto:cb.l= ist6@gmail.com]
> Sent: Wednesday, November 09, 2011 8:07 AM
> To: Ravindran Parthasarathi
> Cc: &lt,rtcweb@ietf.org&= ;gt,
> Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's de= fine the purpose of WebRTC)
>
> =A0
>
>
> On Nov 8, 2011 5:21 PM, "Ravindran Parthasarathi" <pravindran@sonusnet.com> wrote:=
> >
> > Thanks to Harald/Cullen for pointing out RFC 2804. I take back my= #2 comment based on RFC 2804 wiretapping policy.
> >
> > I wish to clarify why I gave this comment before closing on #2: > >
> > It is the common practice in India to buy computer to talk/chat w= ith the relatives who are outside India by using Skype/Gtalk/Yahoo (avoidin= g International subscriber dialing charges). Of course, Cell phone is more = popular than Computer and cheap (~$100) Wi-Fi enabled (Android) Smartphones= are available in market. WebRTC will bring the new innovative way of commu= nicating using Smartphone (like free WebRTC session to street provisional s= tore). Browser in Smartphone is the platform for making outgoing session to= wards provisional store. I really don't want these kind of WebRTC servi= ce are forbidden by Government laws unnecessarily due to security (SRTP) re= asons.
> >
> >
>
> Getting into murky waters here.
>
> I believe the ietf values privacy and I would like srtp to be mandator= y since I value privacy.
>
> If not supporting privacy is a requirement for your government, then p= erhaps webrtc is not for you.
>
> Cb
>
> > >-----Original Message-----
> > >From: Harald Alvestrand [mailto:harald@alvestrand.no]
> > >Sent: Wednesday, November 09, 2011 3:58 AM
> > >To: Ravindran Parthasarathi
> > >Cc: Hadriel Kaplan; Eric Rescorla; <rtcweb@ietf.org>
> > >Subject: SRTP requirement - wiretapping (Re: [rtcweb] Let'= ;s define the
> > >purpose of WebRTC)
> > >
> > >Changing the subject again to mention SRTP....
> > >
> > >On 11/08/2011 03:30 PM, Ravindran Parthasarathi wrote:
> > >> I agree with Hadriel that it is not required to mandate = SRTP for
> > >WebRTC. My reasoning are as follows:
> > >>
> > >> 1) Security could be in the lower layer itself (IPsec, V= PN, private
> > >MPLS cloud). For Enterprise-only-WebRTC application (no feder= ation& =A0no
> > >interop), there is no need of security by specific applicatio= n like
> > >WebRTC as it is ensured in the infrastructure. WebRTC securit= y will be
> > >duplicated for these infrastructure and may leads double encr= yption
> > >unnecessarily.
> > >This argument makes some sense.
> > >>
> > >> 2) Being in India, I'm interested in avoiding Govern= ment restriction
> > >on WebRTC proposal (Thanks to Tim for pointing this). I may n= ot surprise
> > >to see that WebRTC mechanism is banned in India because intel= ligent
> > >agency struggles to break the key in each terrorist WebRTC si= te.
> > >(http://www.pcworld.com/businesscenter/article/23563= 9/india_wants_to_int
> > >ercept_skype_google_communications.html)
> > >This argument is contrary to stated IETF policy (RFC 2804). > > >
> > >I recommend the RFC for background reading.
> > >>
> > >> In case there is no use case to illustrate in RTCWeb dra= ft, let us
> > >discuss in detail.
> > >>
> > >>> -----Original Message-----
> > >>> From: rtc= web-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > >Behalf
> > >>> Of Hadriel Kaplan
> > >>> Sent: Monday, November 07, 2011 9:12 PM
> > >>> To: Eric Rescorla
> > >>> Cc:<rtcweb@iet= f.org>
> > >>> Subject: Re: [rtcweb] Let's define the purpose o= f WebRTC
> > >>>
> > >>>
> > >>> On 11/07/2011 02:50 PM, Eric Rescorla wrote:
> > >>>> On Sun, Nov 6, 2011 at 7:20 PM, Hadriel
> > >Kaplan<HKaplan@a= cmepacket.com>
> > >>> wrote:
> > >>>>> Who said "too slow"? =A0There *is*= an extra round-trip or two
> > >involved
> > >>> I presume, if we're talking DTLS-SRTP, but no I = didn't mean that as a
> > >>> "hit". =A0I just meant the extra computing= cycles for SRTP being a
> > >"hit".
> > >>> For WebRTC-to-WebRTC I don't think that matters = at all. =A0For WebRTC-
> > >to-
> > >>> media-server it might, for a free game app or greeti= ng card app that
> > >>> don't care about it to begin with, and which use= plaintext HTTP to
> > >begin
> > >>> with.
> > >>>> Sorry, I didn't mean to put words in your mo= uth. Performance
> > >>> measurements
> > >>>> of HTTP versus HTTPS in modern Web environments = suggest that the
> > >>> additional
> > >>>> load for HTTPS is not significant. Do you have e= vidence that the
> > >>> situation is
> > >>>> different for SRTP versus RTP?
> > >>> Only from the DSP guys, and those would be hardware = DSPs not
> > >softDSPs.
> > >>> It runs them anywhere from 10-25% overhead, they say= , depending on
> > >the
> > >>> vendor and what else their DSPs are doing at the tim= e.
> > >>>
> > >>> But ultimately even in software I assume it's al= l relative to what
> > >other
> > >>> work you're doing. =A0If you have to render a vi= deo stream on a screen
> > >and
> > >>> encode camera input into a codec being sent out, the= n my guess is
> > >SRTP
> > >>> overhead is a tiny factor not worth talking about. = =A0If you're mixing
> > >>> multiple RTP streams as a conference server, then I = assume doing SRTP
> > >>> for thousands of simultaneous audio RTP streams for = multiple
> > >>> simultaneous conferences becomes noticeable. =A0Or a= t least so they
> > >seem
> > >>> to claim - I don't know since I don't build = a media server (hardware
> > >>> SBCs often offload SRTP onto dedicated hardware). = =A0One large software
> > >>> company even created their own proprietary packet fo= rmat for SRTP
> > >that
> > >>> they claimed was done for improving performance/scal= ability, so I
> > >assume
> > >>> it has some impact they don't want their custome= rs to incur.
> > >>>
> > >>> -hadriel
> > >>>
> > >>> _______________________________________________
> > >>> rtcweb mailing list
> > >>> rtcweb@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/rtcweb
> > >> _______________________________________________
> > >> rtcweb mailing list
> > >> rtcweb@ietf.org > > >> https://www.ietf.org/mailman/listinfo/rtcweb
> > >>
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://= www.ietf.org/mailman/listinfo/rtcweb

--bcaec520e9a98f03a404b144de0b-- From mperumal@cisco.com Tue Nov 8 19:42:34 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659BF1F0C44 for ; Tue, 8 Nov 2011 19:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.522 X-Spam-Level: X-Spam-Status: No, score=-7.522 tagged_above=-999 required=5 tests=[AWL=-0.923, 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 e0OyJMbl1xc0 for ; Tue, 8 Nov 2011 19:42:33 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 50EF121F8493 for ; Tue, 8 Nov 2011 19:42:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3473; q=dns/txt; s=iport; t=1320810153; x=1322019753; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=TV1jT7ohHDIPBmrUWt7qfyVNR76sKiSR71UtYEKrUNY=; b=i8fxEmdPjklqF+BxuaJit1Xjg28kbbwmYmsjaZMk9S6INgmVglBhe5px 9xMpbpG5YT8dftMgUFf3uowZiZoUClADLHAa0GqXvu9qxc8VN8179w0v4 +4bD/iY/rcHutz6vnW9b4Pn0FiiEoEvYi6xZ4xCeS9R93fBMnoIrg+8cK I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUAAKv1uU5Io8UQ/2dsb2JhbABDmiKOXoEmgQWBcgEBAQQBAQEPAR0KLAUDCwwEAgEIDgMEAQELBhcBBgEmHwkIAgQBCggIARmHaJl9AZ56iEpjBIgJkVKMPA X-IronPort-AV: E=Sophos;i="4.69,481,1315180800"; d="scan'208";a="2683354" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-4.cisco.com with ESMTP; 09 Nov 2011 03:42:27 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA93gRbc007604; Wed, 9 Nov 2011 03:42:27 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 09:12:26 +0530 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: Wed, 9 Nov 2011 09:12:22 +0530 Message-ID: <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AQHMm7/XxS9yQix74UmCewMPtvNQWZWe2WiAgABcZwCAAFnsgIAA1PQAgACv/gCAAAVogIAAGdwAgAHTzND//7JMAIAAEPMAgAESTSCAAAmSMA== References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com><4EB7E6A5.70209@alvestrand.no><387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com><845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net><5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Ravindran Parthasarathi" , "Cullen Jennings (fluffy)" , "Olle E. Johansson" X-OriginalArrivalTime: 09 Nov 2011 03:42:26.0905 (UTC) FILETIME=[9976D490:01CC9E91] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 03:42:34 -0000 |"1) Security could be in the lower layer itself=20 |(IPsec, VPN, private MPLS cloud). For Enterprise-only- |WebRTC application (no federation & no interop),=20 |there is no need of security for specific application |like WebRTC as it is ensured in the infrastructure. One of the primary deployments for SRTP I've come across is actually within the enterprise -- financial institutions and defense establishments concerned about eavesdropping within their organization. The fact that the WAN connection is secured using IPSec VPN or a private leased line isn't good enough for such deployments. Muthu |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ravindran Parthasarathi |Sent: Wednesday, November 09, 2011 8:28 AM |To: Cullen Jennings (fluffy); Olle E. Johansson |Cc: |Subject: Re: [rtcweb] Let's define the purpose of WebRTC | |Cullen, | |As I mentioned in http://www.ietf.org/mail-archive/web/rtcweb/current/msg02674.html, below comment #2 |is not valid in IETF. | |But I'm interested in your opinion as Enterprise UC expert on my 1st comment: | |"1) Security could be in the lower layer itself (IPsec, VPN, private MPLS cloud). For Enterprise-only- |WebRTC application (no federation & no interop), there is no need of security for specific application |like WebRTC as it is ensured in the infrastructure. WebRTC security will be duplicated for these |infrastructure and may lead to double encryption unnecessarily." | |Thanks |Partha | |>-----Original Message----- |>From: Cullen Jennings [mailto:fluffy@cisco.com] |>Sent: Tuesday, November 08, 2011 9:29 PM |>To: Olle E. Johansson |>Cc: Ravindran Parthasarathi; |>Subject: Re: [rtcweb] Let's define the purpose of WebRTC |> |> |>On Nov 8, 2011, at 7:58 AM, Olle E. Johansson wrote: |> |>>> |>>> 2) Being in India, I'm interested in avoiding Government restriction |>on WebRTC proposal (Thanks to Tim for pointing this). I may not surprise |>to see that WebRTC mechanism is banned in India because intelligent |>agency struggles to break the key in each terrorist WebRTC site. |>(http://www.pcworld.com/businesscenter/article/235639/india_wants_to_i nt |>ercept_skype_google_communications.html) |>> That is an interesting objection. I don't think SRTP by default is the |>problem here. In the case where you need lawful interception in the |>application, |>> the server needs to route the calls through an RTCweb b2b media |>server. |> |>I think the situation in India is a taxiation not encryption issue. |>Partha and I can do VoIP between Canada and India fully encrypted no |>problem - in fact we have a dial plan set up specifically so I can do |>that with him. The issue is a taxation issue. If we want to be able to |>connect that voip server to the PSTN in a way that it becomes what the |>regulators in India consider a telephone service, then we need |>permission to effectively be an indian telco. Right now I can make a |>full SRTP encrypted conversation with between my IP phones and Partha's |>but I don't think Partha can use his IP phone to access one the the PSTN |>GWs outside India. |> |>Anyways, I will remind people of RAVEN http://www.rfc- |>editor.org/rfc/rfc2804.txt |> | |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Tue Nov 8 22:25:00 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B567321F849E for ; Tue, 8 Nov 2011 22:25:00 -0800 (PST) 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.030, 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 ocPkRUFxzpxM for ; Tue, 8 Nov 2011 22:24:59 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id B695821F8497 for ; Tue, 8 Nov 2011 22:24:59 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA96PVKT024317; Wed, 9 Nov 2011 01:25:31 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 01:24:00 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 11:54:09 +0530 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.0339.001; Wed, 9 Nov 2011 11:54:08 +0530 From: Ravindran Parthasarathi To: "Muthu Arul Mozhi Perumal (mperumal)" , "Cullen Jennings (fluffy)" , "Olle E. Johansson" Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AQHMm7/XxS9yQix74UmCewMPtvNQWZWe2WiAgABcZwCAAFnsgIAA1PQAgACv/gCAAAVogIAAGdwAgAHTzND//7JMAIAAEPMAgAESTSCAAAmSMIAALVkA Date: Wed, 9 Nov 2011 06:24:08 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com><4EB7E6A5.70209@alvestrand.no><387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com><845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net><5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2011 06:24:09.0130 (UTC) FILETIME=[3070E0A0:01CC9EA8] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 06:25:00 -0000 Hi Muthu, I agree with you that Defense & Financial Enterprise customer mandates for = security mechanism in media path but it is not mandated for rest of the Ent= erprise customer. The argument here is whether it is "mandatory to implemen= t" vs "mandatory to use". I agree that it is mandatory to implement in brow= ser but it is not required to be mandatory to use by all the applications. = Hope you agree with me. Thanks Partha >-----Original Message----- >From: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] >Sent: Wednesday, November 09, 2011 9:12 AM >To: Ravindran Parthasarathi; Cullen Jennings (fluffy); Olle E. Johansson >Cc: rtcweb@ietf.org >Subject: RE: [rtcweb] Let's define the purpose of WebRTC > >|"1) Security could be in the lower layer itself >|(IPsec, VPN, private MPLS cloud). For Enterprise-only- >|WebRTC application (no federation & no interop), >|there is no need of security for specific application >|like WebRTC as it is ensured in the infrastructure. > >One of the primary deployments for SRTP I've come across is actually >within the enterprise -- financial institutions and defense >establishments concerned about eavesdropping within their organization. >The fact that the WAN connection is secured using IPSec VPN or a private >leased line isn't good enough for such deployments. > >Muthu > >|-----Original Message----- >|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >Behalf Of Ravindran Parthasarathi >|Sent: Wednesday, November 09, 2011 8:28 AM >|To: Cullen Jennings (fluffy); Olle E. Johansson >|Cc: >|Subject: Re: [rtcweb] Let's define the purpose of WebRTC >| >|Cullen, >| >|As I mentioned in >http://www.ietf.org/mail-archive/web/rtcweb/current/msg02674.html, below >comment #2 >|is not valid in IETF. >| >|But I'm interested in your opinion as Enterprise UC expert on my 1st >comment: >| >|"1) Security could be in the lower layer itself (IPsec, VPN, private >MPLS cloud). For Enterprise-only- >|WebRTC application (no federation & no interop), there is no need of >security for specific application >|like WebRTC as it is ensured in the infrastructure. WebRTC security >will be duplicated for these >|infrastructure and may lead to double encryption unnecessarily." >| >|Thanks >|Partha >| >|>-----Original Message----- >|>From: Cullen Jennings [mailto:fluffy@cisco.com] >|>Sent: Tuesday, November 08, 2011 9:29 PM >|>To: Olle E. Johansson >|>Cc: Ravindran Parthasarathi; >|>Subject: Re: [rtcweb] Let's define the purpose of WebRTC >|> >|> >|>On Nov 8, 2011, at 7:58 AM, Olle E. Johansson wrote: >|> >|>>> >|>>> 2) Being in India, I'm interested in avoiding Government >restriction >|>on WebRTC proposal (Thanks to Tim for pointing this). I may not >surprise >|>to see that WebRTC mechanism is banned in India because intelligent >|>agency struggles to break the key in each terrorist WebRTC site. >|>(http://www.pcworld.com/businesscenter/article/235639/india_wants_to_i >nt >|>ercept_skype_google_communications.html) >|>> That is an interesting objection. I don't think SRTP by default is >the >|>problem here. In the case where you need lawful interception in the >|>application, >|>> the server needs to route the calls through an RTCweb b2b media >|>server. >|> >|>I think the situation in India is a taxiation not encryption issue. >|>Partha and I can do VoIP between Canada and India fully encrypted no >|>problem - in fact we have a dial plan set up specifically so I can do >|>that with him. The issue is a taxation issue. If we want to be able to >|>connect that voip server to the PSTN in a way that it becomes what the >|>regulators in India consider a telephone service, then we need >|>permission to effectively be an indian telco. Right now I can make a >|>full SRTP encrypted conversation with between my IP phones and >Partha's >|>but I don't think Partha can use his IP phone to access one the the >PSTN >|>GWs outside India. >|> >|>Anyways, I will remind people of RAVEN http://www.rfc- >|>editor.org/rfc/rfc2804.txt >|> >| >|_______________________________________________ >|rtcweb mailing list >|rtcweb@ietf.org >|https://www.ietf.org/mailman/listinfo/rtcweb From Ranjit.Avasarala@Polycom.com Tue Nov 8 22:33:42 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6F221F8AF2 for ; Tue, 8 Nov 2011 22:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 LUDm9fg0GQZ9 for ; Tue, 8 Nov 2011 22:33:41 -0800 (PST) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2EF21F8AEE for ; Tue, 8 Nov 2011 22:33:40 -0800 (PST) Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([::1]) with mapi; Wed, 9 Nov 2011 14:33:39 +0800 From: "Avasarala, Ranjit" To: Ravindran Parthasarathi , "Muthu Arul Mozhi Perumal (mperumal)" , "Cullen Jennings (fluffy)" , "Olle E. Johansson" Date: Wed, 9 Nov 2011 14:33:36 +0800 Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AQHMm7/XxS9yQix74UmCewMPtvNQWZWe2WiAgABcZwCAAFnsgIAA1PQAgACv/gCAAAVogIAAGdwAgAHTzND//7JMAIAAEPMAgAESTSCAAAmSMIAALVkAgAAFPXA= Message-ID: <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com><4EB7E6A5.70209@alvestrand.no><387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com><845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net><5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 06:33:42 -0000 Hi Partha I feel including all kinds of security mechanisms like SRTP, TLS, etc in br= owser would make the browser very bulky. It would be better to provide a me= chanism in the signaling protocol that browser supports to negotiate the de= sired security mechanism (depending on application requirement) and then us= e that mechanism (which is part of the system). Regards Ranjit -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Ravindran Parthasarathi Sent: Wednesday, November 09, 2011 11:54 AM To: Muthu Arul Mozhi Perumal (mperumal); Cullen Jennings (fluffy); Olle E. = Johansson Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of WebRTC Hi Muthu, I agree with you that Defense & Financial Enterprise customer mandates for = security mechanism in media path but it is not mandated for rest of the Ent= erprise customer. The argument here is whether it is "mandatory to implemen= t" vs "mandatory to use". I agree that it is mandatory to implement in brow= ser but it is not required to be mandatory to use by all the applications. = Hope you agree with me. Thanks Partha >-----Original Message----- >From: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] >Sent: Wednesday, November 09, 2011 9:12 AM >To: Ravindran Parthasarathi; Cullen Jennings (fluffy); Olle E. Johansson >Cc: rtcweb@ietf.org >Subject: RE: [rtcweb] Let's define the purpose of WebRTC > >|"1) Security could be in the lower layer itself >|(IPsec, VPN, private MPLS cloud). For Enterprise-only- >|WebRTC application (no federation & no interop), >|there is no need of security for specific application >|like WebRTC as it is ensured in the infrastructure. > >One of the primary deployments for SRTP I've come across is actually >within the enterprise -- financial institutions and defense >establishments concerned about eavesdropping within their organization. >The fact that the WAN connection is secured using IPSec VPN or a private >leased line isn't good enough for such deployments. > >Muthu > >|-----Original Message----- >|From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >Behalf Of Ravindran Parthasarathi >|Sent: Wednesday, November 09, 2011 8:28 AM >|To: Cullen Jennings (fluffy); Olle E. Johansson >|Cc: >|Subject: Re: [rtcweb] Let's define the purpose of WebRTC >| >|Cullen, >| >|As I mentioned in >http://www.ietf.org/mail-archive/web/rtcweb/current/msg02674.html, below >comment #2 >|is not valid in IETF. >| >|But I'm interested in your opinion as Enterprise UC expert on my 1st >comment: >| >|"1) Security could be in the lower layer itself (IPsec, VPN, private >MPLS cloud). For Enterprise-only- >|WebRTC application (no federation & no interop), there is no need of >security for specific application >|like WebRTC as it is ensured in the infrastructure. WebRTC security >will be duplicated for these >|infrastructure and may lead to double encryption unnecessarily." >| >|Thanks >|Partha >| >|>-----Original Message----- >|>From: Cullen Jennings [mailto:fluffy@cisco.com] >|>Sent: Tuesday, November 08, 2011 9:29 PM >|>To: Olle E. Johansson >|>Cc: Ravindran Parthasarathi; >|>Subject: Re: [rtcweb] Let's define the purpose of WebRTC >|> >|> >|>On Nov 8, 2011, at 7:58 AM, Olle E. Johansson wrote: >|> >|>>> >|>>> 2) Being in India, I'm interested in avoiding Government >restriction >|>on WebRTC proposal (Thanks to Tim for pointing this). I may not >surprise >|>to see that WebRTC mechanism is banned in India because intelligent >|>agency struggles to break the key in each terrorist WebRTC site. >|>(http://www.pcworld.com/businesscenter/article/235639/india_wants_to_i >nt >|>ercept_skype_google_communications.html) >|>> That is an interesting objection. I don't think SRTP by default is >the >|>problem here. In the case where you need lawful interception in the >|>application, >|>> the server needs to route the calls through an RTCweb b2b media >|>server. >|> >|>I think the situation in India is a taxiation not encryption issue. >|>Partha and I can do VoIP between Canada and India fully encrypted no >|>problem - in fact we have a dial plan set up specifically so I can do >|>that with him. The issue is a taxation issue. If we want to be able to >|>connect that voip server to the PSTN in a way that it becomes what the >|>regulators in India consider a telephone service, then we need >|>permission to effectively be an indian telco. Right now I can make a >|>full SRTP encrypted conversation with between my IP phones and >Partha's >|>but I don't think Partha can use his IP phone to access one the the >PSTN >|>GWs outside India. >|> >|>Anyways, I will remind people of RAVEN http://www.rfc- >|>editor.org/rfc/rfc2804.txt >|> >| >|_______________________________________________ >|rtcweb mailing list >|rtcweb@ietf.org >|https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Tue Nov 8 22:55:00 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8218521F8C30 for ; Tue, 8 Nov 2011 22:55:00 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfa1DoQfUpY4 for ; Tue, 8 Nov 2011 22:55:00 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1393321F8C2D for ; Tue, 8 Nov 2011 22:54:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 380AA39E123 for ; Wed, 9 Nov 2011 07:54:58 +0100 (CET) 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 3edurvAiUvpw for ; Wed, 9 Nov 2011 07:54:57 +0100 (CET) Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id EFA5C39E04C for ; Wed, 9 Nov 2011 07:54:56 +0100 (CET) Message-ID: <4EBA23C0.2060606@alvestrand.no> Date: Wed, 09 Nov 2011 07:54:56 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Codec draft - VP8 description X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 06:55:00 -0000 Hi, the codec draft currently says about VP8: o If VP8, then MUST support a the bilinear and none reconstruction filters I've checked with our VP8 people, and they say that subset implementations of VP8 are STRONGLY discouraged; any decoders should be capable of decoding all modes defined. I suggest just removing the sentence. Harald From harald@alvestrand.no Tue Nov 8 23:02:17 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB76D21F84CD for ; Tue, 8 Nov 2011 23:02:17 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRYuGeAq67wg for ; Tue, 8 Nov 2011 23:02:17 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 53CF421F84A6 for ; Tue, 8 Nov 2011 23:02:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D869239E123 for ; Wed, 9 Nov 2011 08:02:12 +0100 (CET) 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 zPl1Xpicn5-v for ; Wed, 9 Nov 2011 08:02:12 +0100 (CET) Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 1C12339E04C for ; Wed, 9 Nov 2011 08:02:12 +0100 (CET) Message-ID: <4EBA2573.1000104@alvestrand.no> Date: Wed, 09 Nov 2011 08:02:11 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com><4EB7E6A5.70209@alvestrand.no><387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com><845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net><5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> In-Reply-To: <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 07:02:18 -0000 On 11/09/2011 07:33 AM, Avasarala, Ranjit wrote: > Hi Partha > > I feel including all kinds of security mechanisms like SRTP, TLS, etc in browser would make the browser very bulky. It would be better to provide a mechanism in the signaling protocol that browser supports to negotiate the desired security mechanism (depending on application requirement) and then use that mechanism (which is part of the system). > The bulk of the browser is not reduced by a single byte by not using crypto functions that are present. Not having crypto functions available would contravene the "MUST implement SRTP" mandate. (btw, the code bulk of SRTP is minuscule compared to stuff like CSS3). Harald From christer.holmberg@ericsson.com Wed Nov 9 01:14:24 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF8621F8AF5 for ; Wed, 9 Nov 2011 01:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, 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 wgse-7zzSO+f for ; Wed, 9 Nov 2011 01:14:24 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 36A7421F8AF0 for ; Wed, 9 Nov 2011 01:14:24 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-06-4eba446e9cf7 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 05.44.09514.E644ABE4; Wed, 9 Nov 2011 10:14:23 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 9 Nov 2011 10:14:22 +0100 From: Christer Holmberg To: Cullen Jennings Date: Wed, 9 Nov 2011 10:14:21 +0100 Thread-Topic: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - More-coming and final answer (Section 5.2.3) Thread-Index: AcybCI/HqecDN0zNQyanRaCXc/kwrADtlvNw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852235A07262@ESESSCMS0356.eemea.ericsson.se> References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058522341F4AB9@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852235789602@ESESSCMS0356.eemea.ericsson.se> <088367F5-90D3-45B5-939E-904411CF2D7B@cisco.com> In-Reply-To: <088367F5-90D3-45B5-939E-904411CF2D7B@cisco.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Jonathan Rosenberg , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - More-coming and final answer (Section 5.2.3) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 09:14:25 -0000 Hi Cullen,=20 >>>> Q2. Are there restrictions when it comes to changing=20 >>>> information in a non-final answer and a final answer? Or, can the fina= l=20 >>>> answer be completely different from previously sent non-final=20 >>>> ANSWERS? In "legacy" O/A there are restrictions. >>>>=20 >>> Any answer has to be a valid answer for the offer but other than=20 >>> that, no restrictions, so the final answer can change=20 >>> everything from an earlier one. >>=20 >> Is there a reason/use-case/requirement why we need to allow=20 >> that? As far as I know, the reason behind this is ICE. >>=20 > There a bunch of use cases but to mention two: In the browser=20 > to browser case, imagine that you start sending audio in the=20 > first answer but need to wait for user feedback to find out=20 > if video can be added or not in the final answer. In a=20 > browser to SIP use case, the early media for 1-800-go-fedex. I think that could cause interoperability issues. For example, assume that a gateway would map a more-to-come answer to a SIP= 18x response. Then, if the no-more-to-come answer is different, the gateway can't map it = to SIP 200 response - at least not without chaning the SIP dialog identifie= r. Also, if you map a more-to-come answer to a SIP 18x answer, and then receiv= es a new SIP offer, the gateway *cannot* map it to a ROAP offer, as it is s= till wating waiting for the no-more-to-come answer. Regards, Christer From christer.holmberg@ericsson.com Wed Nov 9 01:20:36 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C20E21F8B5B for ; Wed, 9 Nov 2011 01:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.031 X-Spam-Level: X-Spam-Status: No, score=-7.031 tagged_above=-999 required=5 tests=[AWL=0.968, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74l5Nc9PJziY for ; Wed, 9 Nov 2011 01:20:35 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id EA33721F8B59 for ; Wed, 9 Nov 2011 01:20:34 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-de-4eba45e1af85 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A8.22.13753.1E54ABE4; Wed, 9 Nov 2011 10:20:34 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 9 Nov 2011 10:20:32 +0100 From: Christer Holmberg To: Cullen Jennings , Magnus Westerlund Date: Wed, 9 Nov 2011 10:20:31 +0100 Thread-Topic: [rtcweb] State of the Forking discussion Thread-Index: AcyeaN7jugkm2j8NRLyaQxPGFgy5YQAV8RXQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852235A07275@ESESSCMS0356.eemea.ericsson.se> References: <4EB26945.40607@ericsson.com> <0E287F18-E335-472D-853A-0A1B449D2AD7@cisco.com> In-Reply-To: <0E287F18-E335-472D-853A-0A1B449D2AD7@cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] State of the Forking discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 09:20:36 -0000 Hi,=20 > >=20 > Much of this I don't feel too strongly about but there is one=20 > thing that I do have a strong opinion on. I don't want to=20 > require PRACK for legacy SIP support because it is has many problems.=20 If you are not using PRACK, you will not be able to receive a "real" answer= before 200 OK, at a point where forking will be no issue anymore :) Regards, Christer > On Nov 3, 2011, at 4:13 AM, Magnus Westerlund wrote: >=20 > > WG, > >=20 > > I just reviewed the last weeks Forking discussion. This=20 > includes the=20 > > threads "RTCWeb Forking usecase [was RE: > > draft-kaplan-rtcweb-sip-interworking-requirements-00]" and "Media=20 > > forking solution for SIP interoperability (without a media gateway)" > >=20 > > As far as I can tell there is not yet even a rough consensus.=20 > > Therefore I will attempt to summarize what I personally=20 > believe to be=20 > > the important points and alternatives in this discussion.=20 > Keep in mind=20 > > that my assumptions or understanding may be unclear or have=20 > errors. So=20 > > don't hesitate to challenge what I write. > >=20 > > I think it is important that there are in fact at least two=20 > important=20 > > questions here. > >=20 > > 1. Is forking needed to be supported at all? > >=20 > > 2. If it is supported in which form would it supported in. > >=20 > > so lets start looking into the arguments and possibilities=20 > for these=20 > > two questions. And I do hope that you will read to the end of this=20 > > mail which is quite long. > >=20 > > Lets start with the high level functionality part. Is=20 > forking needed=20 > > and what usage does it have. So forking is all about sending out an=20 > > invitation to a media session including an actual media=20 > configuration=20 > > offer, i.e. SDP Offer, then get more than a single answer to that=20 > > offer back. How you deal with these answers as they come in is the=20 > > difference between serial and parallel forking. So lets=20 > define those. > >=20 > > Parallel forking: For each answer you receive you establish a new=20 > > actual media session. Thus if you receive two answers you=20 > will have to=20 > > different media sessions that are potentially in use at the=20 > same time. > >=20 > > Serial forking: The first answer is received and results the=20 > > establishment of a media session. At a later point in time a second=20 > > answer is received. At that point you take the decision if=20 > that second=20 > > answer is going to be used to establish a new media session that=20 > > replaces the first one. In other words at any given time=20 > you will only=20 > > have a single media session established based on each offer. > >=20 > > So there has been a number of different views on how one can see on=20 > > forking. And I think I will have to bring in a bit=20 > reflections on how=20 > > this can be done with the current PeerConnection API. > >=20 > > A) No forking is needed: Between WebRTC end-points there is no need=20 > > for forking. Instead the application can send out session=20 > invitations=20 > > to the peers it wants to talk to. These are without any SDP Offer=20 > > equivalent, instead end-points that want to communicate they create=20 > > PeerConnections, which results in SDP Offers. Thus the=20 > communication=20 > > initiating end-point becomes the ones that provides SDP answers and=20 > > get one PeerConnection per remote end-point that actually=20 > want to communicate. > >=20 > > B) We need to have some interworking with SIP: So the=20 > fundamental here=20 > > is that it needs to be reasonable to interwork with SIP,=20 > independent=20 > > if one uses a SIP in JS in the application running on the WebRTC=20 > > enabled browser, or have signalling gateway in the=20 > webserver, or as a=20 > > remote WebRTC peer. The issue is that A)'s method of=20 > initiating call=20 > > doesn't work well with SIP. There is a need to send a SIP=20 > Invite with=20 > > an SDP Offer and that can result in multiple answers. > >=20 > > To resolve this one could deal with this in a couple of=20 > different ways: > >=20 > > B1) Use I=F1aki's proposal which forces the WebRTC=20 > application to create=20 > > a second PeerConnection and then forces an update in the SIP domain=20 > > with the second peer-connections Offer. However, it was pointed out=20 > > that this doesn't work with SIP Provisional answers, as used by ICE=20 > > for example, unless PRACK is supported. The level of PRACK=20 > support is=20 > > reasonable but far from universal so this would limit the=20 > SIP UAs one=20 > > can interwork with. However, from WebRTC perspective no forking=20 > > support is needed. A single PeerConnection results in one=20 > offer and a=20 > > single answer is processed. > >=20 > > B2) Require WebRTC to handle replace Answers: So the idea=20 > here is that=20 > > one changes the PeerConnection API and have underlying=20 > functionality=20 > > so that at any point in time a new Answer can pushed onto a=20 > > PeerConnection and that forces the media session to be=20 > reestablished=20 > > if needed. So if the ICE candidate list is different an ICE restart=20 > > happens. This clearly supports serial forking. It also can=20 > create some=20 > > complexities in the underlying SDP handling logic if one=20 > desires to minimize the media impact. > >=20 > > B3) Local side shared parameters in multiple=20 > PeerConnections: The idea=20 > > in this proposal is that all PeerConnections generated in a browser=20 > > context, like a tab will implicit share the fundamental parameters=20 > > like ICE candidates etc for the number of media streams=20 > added. So if=20 > > one creates a second PeerConnection with the same audio+video=20 > > MediaStream object added I will get an offer that is mostly=20 > identical=20 > > to the the first PeerConnection, thus I can push in the answer from=20 > > the first PeerConnection Offer into the second PC object=20 > and it will still work. > > The downside of this is that it is implicit and it becomes=20 > difficult=20 > > to determine when it works and when it will fail. It will also be=20 > > highly dependent on the application performing the right process to=20 > > get it to work. It also causes a sharing of the parameters when not=20 > > needed or desired, which primarily is an issue from a=20 > security point=20 > > of view, especially with SDES keys (see below). The=20 > positive is this=20 > > likely requires no API changes. This method would also=20 > support parallel forking. > >=20 > > B4) Cloning/Factory for PeerConnection: On the API level=20 > there will be=20 > > explicit support for generating multiple PeerConnections=20 > from the same=20 > > base. This could either be a factory for PeerConnections or some=20 > > Object constructor that clones an existing PeerConnection=20 > but that is=20 > > a W3C question. By being explicit some of the B3) issues=20 > goes away and=20 > > the applications can choose when this should happen or not.=20 > This also=20 > > support parallel forking as the application can deal with=20 > each media=20 > > session independently. This clearly will have some impact=20 > on the API. > >=20 > >=20 > > Additional considerations: > >=20 > > Shared SDES keys: B2 to B4 will result in that SDES keys from the=20 > > Offering party to be used towards all invited parties. This is=20 > > security risk as any of the invited parties can spoof the offering=20 > > side towards any of the other invited parties. This threat can be=20 > > resolved by having the inviter rekey immediately after=20 > having received an answer. > >=20 > > Sharing ICE candidates: B3 and B4 and also B2 to some degree will=20 > > share the ICE candidates. That has certain implications. One is the=20 > > positive in that it minimizes the resource consumption as=20 > additional=20 > > PeerConnections come at very little extra cost, no need for=20 > additional=20 > > ICE gathering candidate phases, and also be very quick as=20 > no external=20 > > communication is required. The downside of this is that the=20 > end-points=20 > > candidates must always be kept alive as long as some PeerConnection=20 > > instance exist. Because the browser never knows when the=20 > application=20 > > may create an additional PC and expect them to have the=20 > same ICE candidates. > > It should also be noted that the answering WebRTC end-point=20 > will need=20 > > to gather candidates for each offer. Otherwise it will become=20 > > impossible to create multiple PeerConnections between the same=20 > > end-points if that is desired by the application. > >=20 > >=20 > > I know the above doesn't list all of the pro and cons of=20 > the different=20 > > alternatives. So please fill in additional arguments. And=20 > if I missed=20 > > some proposal please add that also if relevant > >=20 > > As you may have noted I the two questions in the above have kind of=20 > > floated together. The reason for this is that I think the=20 > majority are=20 > > fine with having SIP support as long as it doesn't have to=20 > high cost=20 > > or complexity associated with it. Thus, the question how=20 > becomes very=20 > > intertwined with forking support yes or no. > >=20 > > So please continue the discussion > >=20 > > Cheers > >=20 > > Magnus Westerlund > >=20 > >=20 > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > >=20 > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > >=20 > ---------------------------------------------------------------------- > >=20 > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From ibc@aliax.net Wed Nov 9 01:35:02 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B22021F8B5B for ; Wed, 9 Nov 2011 01:35:02 -0800 (PST) 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 k3qO3HCFfaz3 for ; Wed, 9 Nov 2011 01:35:02 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D43A421F8B52 for ; Wed, 9 Nov 2011 01:35:01 -0800 (PST) Received: by vws5 with SMTP id 5so1484234vws.31 for ; Wed, 09 Nov 2011 01:35:00 -0800 (PST) Received: by 10.52.187.68 with SMTP id fq4mr3142718vdc.32.1320831300037; Wed, 09 Nov 2011 01:35:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Wed, 9 Nov 2011 01:34:39 -0800 (PST) In-Reply-To: <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 9 Nov 2011 10:34:39 +0100 Message-ID: To: "Avasarala, Ranjit" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 09:35:02 -0000 2011/11/9 Avasarala, Ranjit : > I feel including all kinds of security mechanisms like SRTP, TLS, etc in = browser would make the browser very bulky. Including TLS in a browser makes it bulky? Then we must discourage HTTPS usage, right? In the other side, have you really measured how much expensive SRTP is? it's not at all. > It would be better to provide a mechanism in the signaling protocol that = browser supports to negotiate the desired security mechanism (depending on = application requirement) and then use that mechanism (which is part of the = system). The "application" is untrusted by nature, and we don't want to make the end-user to decide whether to trust it or not. Explained many times in this maillist. --=20 I=C3=B1aki Baz Castillo From oej@edvina.net Wed Nov 9 01:42:05 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03E921F8A6C for ; Wed, 9 Nov 2011 01:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 56JusqRMV3CP for ; Wed, 9 Nov 2011 01:42:05 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 372CB21F8A66 for ; Wed, 9 Nov 2011 01:42:05 -0800 (PST) Received: from [192.168.20.63] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp7.webway.se (Postfix) with ESMTPA id D399F754BD1C; Wed, 9 Nov 2011 09:42:01 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Wed, 9 Nov 2011 10:42:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <99C883E4-2614-49A9-98D4-E38C8E5FA1F5@edvina.net> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 09:42:05 -0000 9 nov 2011 kl. 10:34 skrev I=F1aki Baz Castillo: > 2011/11/9 Avasarala, Ranjit : >> I feel including all kinds of security mechanisms like SRTP, TLS, etc = in browser would make the browser very bulky. >=20 > Including TLS in a browser makes it bulky? Then we must discourage > HTTPS usage, right? > In the other side, have you really measured how much expensive SRTP > is? it's not at all. This kind of argument is just a no-op. We need to be able to move = forward and as Eric has said on this list, these arguments against = encryption is no longer valid. You could use this against HTTP clients in SIP (SIP identity) and the = whole ICE engine too. Moore's law is always helping :-) >=20 >=20 >> It would be better to provide a mechanism in the signaling protocol = that browser supports to negotiate the desired security mechanism = (depending on application requirement) and then use that mechanism = (which is part of the system). >=20 > The "application" is untrusted by nature, and we don't want to make > the end-user to decide whether to trust it or not. Explained many > times in this maillist. Agree, we have explained this a number of times. If we leave this up to = the web developers and users, we'll end up in trouble. /O= From Ranjit.Avasarala@Polycom.com Wed Nov 9 01:45:12 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B88D21F8B4E for ; Wed, 9 Nov 2011 01:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 OR7+aOvDRvyR for ; Wed, 9 Nov 2011 01:45:12 -0800 (PST) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7D89321F8B1E for ; Wed, 9 Nov 2011 01:45:11 -0800 (PST) Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([::1]) with mapi; Wed, 9 Nov 2011 17:45:09 +0800 From: "Avasarala, Ranjit" To: "Olle E. Johansson" , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 9 Nov 2011 17:45:07 +0800 Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: Acyew97IbCRXVkNoR4+ILwi8CKablgAAE69g Message-ID: <1F2A2C70609D9E41844A2126145FC09804691E09@HKGMBOXPRD22.polycom.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <99C883E4-2614-49A9-98D4-E38C8E5FA1F5@edvina.net> In-Reply-To: <99C883E4-2614-49A9-98D4-E38C8E5FA1F5@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 09:45:12 -0000 Ok so any consensus s far on which signaling would be used for negotiating = these parameters - SIP/Jingle/etc.. Regards Ranjit -----Original Message----- From: Olle E. Johansson [mailto:oej@edvina.net]=20 Sent: Wednesday, November 09, 2011 3:12 PM To: I=F1aki Baz Castillo Cc: Avasarala, Ranjit; Ravindran Parthasarathi; Muthu Arul Mozhi Perumal (m= perumal); Cullen Jennings (fluffy); rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of WebRTC 9 nov 2011 kl. 10:34 skrev I=F1aki Baz Castillo: > 2011/11/9 Avasarala, Ranjit : >> I feel including all kinds of security mechanisms like SRTP, TLS, etc in= browser would make the browser very bulky. >=20 > Including TLS in a browser makes it bulky? Then we must discourage > HTTPS usage, right? > In the other side, have you really measured how much expensive SRTP > is? it's not at all. This kind of argument is just a no-op. We need to be able to move forward a= nd as Eric has said on this list, these arguments against encryption is no = longer valid. You could use this against HTTP clients in SIP (SIP identity) and the whole= ICE engine too. Moore's law is always helping :-) >=20 >=20 >> It would be better to provide a mechanism in the signaling protocol that= browser supports to negotiate the desired security mechanism (depending on= application requirement) and then use that mechanism (which is part of the= system). >=20 > The "application" is untrusted by nature, and we don't want to make > the end-user to decide whether to trust it or not. Explained many > times in this maillist. Agree, we have explained this a number of times. If we leave this up to the= web developers and users, we'll end up in trouble. /O From oej@edvina.net Wed Nov 9 01:50:26 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452E221F8B63 for ; Wed, 9 Nov 2011 01:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HELO_EQ_SE=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 nxf70sgzxglj for ; Wed, 9 Nov 2011 01:50:25 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id BAEAE21F8B51 for ; Wed, 9 Nov 2011 01:50:25 -0800 (PST) Received: from [192.168.20.63] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp7.webway.se (Postfix) with ESMTPA id E6F8A754BD1C; Wed, 9 Nov 2011 09:50:23 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <1F2A2C70609D9E41844A2126145FC09804691E09@HKGMBOXPRD22.polycom.com> Date: Wed, 9 Nov 2011 10:50:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2977E86F-BAB8-45F7-927F-DC4F39329A14@edvina.net> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <99C 883E4-2614-49A9-98D4-E38C8E5FA1F5@edvina.net> <1F2A2C70609D9E41844A2126145FC09804691E09@HKGMBOXPRD22.polycom.com> To: "Avasarala, Ranjit" X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 09:50:26 -0000 9 nov 2011 kl. 10:45 skrev Avasarala, Ranjit: > Ok so any consensus s far on which signaling would be used for = negotiating these parameters - SIP/Jingle/etc.. >=20 I would advice you kindly to go through the mail archives. The consensus = seems to be "no default signaling" after a very long and intensive = discussion. /O From ibc@aliax.net Wed Nov 9 01:58:10 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF0621F84C1 for ; Wed, 9 Nov 2011 01:58:10 -0800 (PST) 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 P81n0267NPOI for ; Wed, 9 Nov 2011 01:58:09 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 76DAE21F8B0D for ; Wed, 9 Nov 2011 01:58:09 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so1400891vcb.31 for ; Wed, 09 Nov 2011 01:58:09 -0800 (PST) Received: by 10.220.65.16 with SMTP id g16mr224687vci.68.1320832688772; Wed, 09 Nov 2011 01:58:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Wed, 9 Nov 2011 01:57:46 -0800 (PST) In-Reply-To: <1F2A2C70609D9E41844A2126145FC09804691E09@HKGMBOXPRD22.polycom.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <99C883E4-2614-49A9-98D4-E38C8E5FA1F5@edvina.net> <1F2A2C70609D9E41844A2126145FC09804691E09@HKGMBOXPRD22.polycom.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 9 Nov 2011 10:57:46 +0100 Message-ID: To: "Avasarala, Ranjit" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 09:58:10 -0000 2011/11/9 Avasarala, Ranjit : > Ok so any consensus s far on which signaling would be used for negotiatin= g these parameters - SIP/Jingle/etc.. No one. Or anyone. Just choose or design it (it must be a protocol on top of HTTP or WebSocket, the protocols JavaScript can deal with). --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Wed Nov 9 02:41:16 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682BF21F8C0E for ; Wed, 9 Nov 2011 02:41:16 -0800 (PST) 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.030, 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 rUOv4oLGMAUL for ; Wed, 9 Nov 2011 02:41:16 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id C99FB21F8B98 for ; Wed, 9 Nov 2011 02:41:10 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA9AffjG028658; Wed, 9 Nov 2011 05:41:41 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 05:41:04 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 16:11:13 +0530 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.0339.001; Wed, 9 Nov 2011 16:11:12 +0530 From: Ravindran Parthasarathi To: "Olle E. Johansson" , "Avasarala, Ranjit" Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AQHMm7/XxS9yQix74UmCewMPtvNQWZWe2WiAgABcZwCAAFnsgIAA1PQAgACv/gCAAAVogIAAGdwAgAHTzND//7JMAIAAEPMAgAESTSCAAAmSMIAALVkAgAAFPXD//9h2gIAAAg+AgAAA3YCAAAF5gIAAaZHQ Date: Wed, 9 Nov 2011 10:41:12 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0134A265@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <99C 883E4-2614-49A9-98D4-E38C8E5FA1F5@edvina.net> <1F2A2C70609D9E41844A2126145FC09804691E09@HKGMBOXPRD22.polycom.com> <2977E86F-BAB8-45F7-927F-DC4F39329A14@edvina.net> In-Reply-To: <2977E86F-BAB8-45F7-927F-DC4F39329A14@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.164] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2011 10:41:13.0552 (UTC) FILETIME=[1A1CE500:01CC9ECC] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 10:41:16 -0000 I agree that there is no need of negotiation for security mechanism. I'll reply to "no standard signaling" protocol in another mail thread as pa= rt of comment to ROAP draft as request by Ted (Chair) to track WebRTC signa= ling related stuff. =20 Thanks Partha >-----Original Message----- >From: Olle E. Johansson [mailto:oej@edvina.net] >Sent: Wednesday, November 09, 2011 3:20 PM >To: Avasarala, Ranjit >Cc: I=F1aki Baz Castillo; Ravindran Parthasarathi; Muthu Arul Mozhi >Perumal (mperumal); Cullen Jennings (fluffy); rtcweb@ietf.org >Subject: Re: [rtcweb] Let's define the purpose of WebRTC > > >9 nov 2011 kl. 10:45 skrev Avasarala, Ranjit: > >> Ok so any consensus s far on which signaling would be used for >negotiating these parameters - SIP/Jingle/etc.. >> >I would advice you kindly to go through the mail archives. The consensus >seems to be "no default signaling" after a very long and intensive >discussion. > >/O From mperumal@cisco.com Wed Nov 9 02:57:35 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505E621F8C14 for ; Wed, 9 Nov 2011 02:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[AWL=-0.611, 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 bSRX3IHx896o for ; Wed, 9 Nov 2011 02:57:34 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 68BC821F8C13 for ; Wed, 9 Nov 2011 02:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2448; q=dns/txt; s=iport; t=1320836254; x=1322045854; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=jgQCPMRkLcOiRR0mD/YBqzlsLwr75YoTzS2v+VHQAxk=; b=YdOjjmB2Cw1gt/N2q6HQBn3dH8Al+RHRPdsUMpGotI5iqJNW4hF/ZTCc uTwhSnTUwYQTJ5nJpYoGeVJHlnsAmkrGVHYYzFSyaQFdVj8PqoJHQ83Px OvZZDyG+6Ia1au7hQx4G24WwonY240hBhxOiuLhV4X27HmkMXwSYhSpBS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAAC9cuk5Io8UR/2dsb2JhbABChH2VKY50gQKBBYFyAQEBBBIBEA0ERQwEAgEIEQQBAQMCBgYXAQICAgEBRAkIAQEECwgIGqEaAYxZkkSBMIc5M2MEiAqRWYw8 X-IronPort-AV: E=Sophos;i="4.69,483,1315180800"; d="scan'208";a="2712216" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-3.cisco.com with ESMTP; 09 Nov 2011 10:57:32 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA9AvV9j011723; Wed, 9 Nov 2011 10:57:31 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 16:27:31 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 9 Nov 2011 16:27:28 +0530 Message-ID: <1D062974A4845E4D8A343C653804920206D3B9C1@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AcyewttF81xR6ZeeT5K2GLper1nh6AABIbBA References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "Avasarala, Ranjit" X-OriginalArrivalTime: 09 Nov 2011 10:57:31.0431 (UTC) FILETIME=[60F96370:01CC9ECE] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 10:57:35 -0000 fFRoZSAiYXBwbGljYXRpb24iIGlzIHVudHJ1c3RlZCBieSBuYXR1cmUsIGFuZCB3ZSBkb24ndCB3 YW50IA0KfHRvIG1ha2UgdGhlIGVuZC11c2VyIHRvIGRlY2lkZSB3aGV0aGVyIHRvIHRydXN0IGl0 IG9yIG5vdC4gDQp8RXhwbGFpbmVkIG1hbnkgdGltZXMgaW4gdGhpcyBtYWlsbGlzdC4NCg0KSSBh bSB0aGlua2luZyB3ZSBjb3VsZCBidXJuIFNSVFAgaW50byB0aGUgYnJvd3NlciBzdWNoIHRoYXQg dGhlIGRlY2lzaW9uIG9mIHdoZXRoZXIgb3Igbm90IHRvIHVzZSBTUlRQIHZlc3RzIHNvbGVseSB3 aXRoIHRoZSBicm93c2VyLiBJZiBhIFdlYlJUQyBicm93c2VyIGlzIGV4Y2hhbmdpbmcgbWVkaWEg d2l0aCBhbm90aGVyIFdlYlJUQyBicm93c2VyIHRoZXkgYWx3YXlzIGRvIFNSVFAvU1JUQ1AuIElm IGVpdGhlciBzaWRlIGlzbid0IFdlYlJUQyBjb21wbGlhbnQgdGhleSBlbmQgdXAgd2l0aCBSVFAv UlRDUC4gVGhpcyB3YXkgd2UgZG9uJ3QgbmVlZCB0byB0cnVzdCB0aGUgSlMsIGluc3RlYWQgdHJ1 c3Qgb25seSB0aGUgYnJvd3Nlci4gV2UgY2FuIGFsc28gaW50ZXJvcGVyYXRlIHdpdGggbGVnYWN5 IGRldmljZXMgd2l0aG91dCB0YXhpbmcgdGhlbS4NCg0KTXV0aHUNCg0KfC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQp8RnJvbTogScOxYWtpIEJheiBDYXN0aWxsbyBbbWFpbHRvOmliY0BhbGlh eC5uZXRdDQp8U2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAwOSwgMjAxMSAzOjA1IFBNDQp8VG86 IEF2YXNhcmFsYSwgUmFuaml0DQp8Q2M6IFJhdmluZHJhbiBQYXJ0aGFzYXJhdGhpOyBNdXRodSBB cnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKTsgQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkpOyBP bGxlIEUuDQp8Sm9oYW5zc29uOyBydGN3ZWJAaWV0Zi5vcmcNCnxTdWJqZWN0OiBSZTogW3J0Y3dl Yl0gTGV0J3MgZGVmaW5lIHRoZSBwdXJwb3NlIG9mIFdlYlJUQw0KfA0KfDIwMTEvMTEvOSBBdmFz YXJhbGEsIFJhbmppdCA8UmFuaml0LkF2YXNhcmFsYUBwb2x5Y29tLmNvbT46DQp8PiBJIGZlZWwg aW5jbHVkaW5nIGFsbCBraW5kcyBvZiBzZWN1cml0eSBtZWNoYW5pc21zIGxpa2UgU1JUUCwgVExT LCBldGMgaW4gYnJvd3NlciB3b3VsZCBtYWtlIHRoZQ0KfGJyb3dzZXIgdmVyeSBidWxreS4NCnwN CnxJbmNsdWRpbmcgVExTIGluIGEgYnJvd3NlciBtYWtlcyBpdCBidWxreT8gVGhlbiB3ZSBtdXN0 IGRpc2NvdXJhZ2UNCnxIVFRQUyB1c2FnZSwgcmlnaHQ/DQp8SW4gdGhlIG90aGVyIHNpZGUsIGhh dmUgeW91IHJlYWxseSBtZWFzdXJlZCBob3cgbXVjaCBleHBlbnNpdmUgU1JUUA0KfGlzPyBpdCdz IG5vdCBhdCBhbGwuDQp8DQp8DQp8PiBJdCB3b3VsZCBiZSBiZXR0ZXIgdG8gcHJvdmlkZSBhIG1l Y2hhbmlzbSBpbiB0aGUgc2lnbmFsaW5nIHByb3RvY29sIHRoYXQgYnJvd3NlciBzdXBwb3J0cyB0 bw0KfG5lZ290aWF0ZSB0aGUgZGVzaXJlZCBzZWN1cml0eSBtZWNoYW5pc20gKGRlcGVuZGluZyBv biBhcHBsaWNhdGlvbiByZXF1aXJlbWVudCkgYW5kIHRoZW4gdXNlIHRoYXQNCnxtZWNoYW5pc20g KHdoaWNoIGlzIHBhcnQgb2YgdGhlIHN5c3RlbSkuDQp8DQp8VGhlICJhcHBsaWNhdGlvbiIgaXMg dW50cnVzdGVkIGJ5IG5hdHVyZSwgYW5kIHdlIGRvbid0IHdhbnQgdG8gbWFrZQ0KfHRoZSBlbmQt dXNlciB0byBkZWNpZGUgd2hldGhlciB0byB0cnVzdCBpdCBvciBub3QuIEV4cGxhaW5lZCBtYW55 DQp8dGltZXMgaW4gdGhpcyBtYWlsbGlzdC4NCnwNCnwtLQ0KfEnDsWFraSBCYXogQ2FzdGlsbG8N Cnw8aWJjQGFsaWF4Lm5ldD4NCg== From pravindran@sonusnet.com Wed Nov 9 03:19:03 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2123521F8C2D for ; Wed, 9 Nov 2011 03:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyjGxcK4-8yV for ; Wed, 9 Nov 2011 03:19:01 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9817721F8C30 for ; Wed, 9 Nov 2011 03:19:01 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA9BJXT4020246; Wed, 9 Nov 2011 06:19:33 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 06:18:57 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 16:49:06 +0530 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.0339.001; Wed, 9 Nov 2011 16:49:05 +0530 From: Ravindran Parthasarathi To: Roman Shpount , "Olle E. Johansson" Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AQHMm7/XxS9yQix74UmCewMPtvNQWZWe2WiAgABcZwCAAFnsgIAA1PQAgACv/gCAAAVogIAAGdwAgAHTzND//7JMAIAAEZcAgAGfP0A= Date: Wed, 9 Nov 2011 11:19:05 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0134A2DB@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> 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.164] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0134A2DBinbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2011 11:19:06.0224 (UTC) FILETIME=[64BB1F00:01CC9ED1] Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 11:19:03 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0134A2DBinbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree with Roman. I'm considering your statement as "mandate to implement" = SRTP. From: Roman Shpount [mailto:roman@telurix.com] Sent: Tuesday, November 08, 2011 9:31 PM To: Olle E. Johansson Cc: Ravindran Parthasarathi; Subject: Re: [rtcweb] Let's define the purpose of WebRTC On Tue, Nov 8, 2011 at 9:58 AM, Olle E. Johansson > wrote: That is an interesting objection. I don't think SRTP by default is the prob= lem here. In the case where you need lawful interception in the application= , the server needs to route the calls through an RTCweb b2b media server. SRTP is exactly what is the problem here. Do not confuse this with lawful i= ntercept in the application. This is about encrypted communications being i= llegal in some places. If your web site is using encryption or cannot be ac= cessed without encryption it would be blocked. As an example we are all fam= iliar with, think about the key length restrictions TLS used to have due to= US export regulations. This has been lifted, but there are numerous regula= tions in other countries that prohibit encryption at all, across the border= s, or from certain institutions (like prisons). I am not arguing that we should not include SRTP. In fact I think we must, = but it should be possible to turn it off. ______________ Roman Shpount --_000_387F9047F55E8C42850AD6B3A7A03C6C0134A2DBinbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agree with Roman. I’m considering your statement as &#= 8220;mandate to implement” SRTP.

 

From: Roman Sh= pount [mailto:roman@telurix.com]
Sent: Tuesday, November 08, 2011 9:31 PM
To: Olle E. Johansson
Cc: Ravindran Parthasarathi; <rtcweb@ietf.org>
Subject: Re: [rtcweb] Let's define the purpose of WebRTC<= /span>

 


On Tue, Nov 8, 2011 at 9:58 AM, Olle E. Johansson &l= t;oej@edvina.net> wrote:


That is an interesting objection. I don't think SRTP by default is the prob= lem here. In the case where you need lawful interception in the application= ,
the server needs to route the calls through an RTCweb b2b media server.


SRTP is exactly what is the problem here. Do not confuse this with lawful i= ntercept in the application. This is about encrypted communications being i= llegal in some places. If your web site is using encryption or cannot be ac= cessed without encryption it would be blocked. As an example we are all familiar with, think about the key le= ngth restrictions TLS used to have due to US export regulations. This has b= een lifted, but there are numerous regulations in other countries that proh= ibit encryption at all, across the borders, or from certain institutions (like prisons).

I am not arguing that we should not include SRTP. In fact I think we must, = but it should be possible to turn it off.
______________
Roman Shpount

--_000_387F9047F55E8C42850AD6B3A7A03C6C0134A2DBinbamail01sonus_-- From oej@edvina.net Wed Nov 9 03:23:49 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCAF21F8C32 for ; Wed, 9 Nov 2011 03:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_SE=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 UJfHhfcbsGJs for ; Wed, 9 Nov 2011 03:23:49 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8C80B21F8A67 for ; Wed, 9 Nov 2011 03:23:46 -0800 (PST) Received: from [192.168.20.63] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp7.webway.se (Postfix) with ESMTPA id 5D920754BD20; Wed, 9 Nov 2011 11:23:41 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <1D062974A4845E4D8A343C653804920206D3B9C1@XMB-BGL-414.cisco.com> Date: Wed, 9 Nov 2011 12:23:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <34771C19-DD51-46B4-97ED-703A93F7329E@edvina.net> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D0 62974A4845E4D8A343C653804920206D3B9C1@XMB-BGL-414.cisco.com> To: "Muthu Arul Mozhi Perumal (mperumal)" X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 11:23:49 -0000 9 nov 2011 kl. 11:57 skrev Muthu Arul Mozhi Perumal (mperumal): > |The "application" is untrusted by nature, and we don't want=20 > |to make the end-user to decide whether to trust it or not.=20 > |Explained many times in this maillist. >=20 > I am thinking we could burn SRTP into the browser such that the = decision of whether or not to use SRTP vests solely with the browser. If = a WebRTC browser is exchanging media with another WebRTC browser they = always do SRTP/SRTCP. If either side isn't WebRTC compliant they end up = with RTP/RTCP. This way we don't need to trust the JS, instead trust = only the browser. We can also interoperate with legacy devices without = taxing them. That opens up for downgrade attacks and put a lot of trust on the web = browser UI to show what happens and on the users to understand what the = web browser UA is trying to tell them. /O= From ibc@aliax.net Wed Nov 9 03:58:46 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4B221F8C78 for ; Wed, 9 Nov 2011 03:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_93=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 bhrhVBVdf9TV for ; Wed, 9 Nov 2011 03:58:45 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 88BF621F8B52 for ; Wed, 9 Nov 2011 03:58:45 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so1485020vcb.31 for ; Wed, 09 Nov 2011 03:58:45 -0800 (PST) Received: by 10.52.187.68 with SMTP id fq4mr4042412vdc.32.1320839925053; Wed, 09 Nov 2011 03:58:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Wed, 9 Nov 2011 03:58:23 -0800 (PST) In-Reply-To: <1D062974A4845E4D8A343C653804920206D3B9C1@XMB-BGL-414.cisco.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3B9C1@XMB-BGL-414.cisco.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 9 Nov 2011 12:58:23 +0100 Message-ID: To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 11:58:46 -0000 2011/11/9 Muthu Arul Mozhi Perumal (mperumal) : > I am thinking we could burn SRTP into the browser such that the decision = of whether or not to use SRTP vests solely with the browser. The "browser" cannot decide that. Probably you mean the user, that person that in 99.999% of cases does not know what "encryption" or "SRTP" is, and in 85% of cases does not matter about security. > If a WebRTC browser is exchanging media with another WebRTC browser they = always do SRTP/SRTCP. The browser has NO way to determine whether it's exchanging media with another browser or not. And what you state is that, in case the peer does not annouce support for SRTP then the browser should downgrade security to plain RTP. The user (web visitor) has no way to know whether the WebRTC application will contact a WebRTC browser or another device at the media plane. > If either side isn't WebRTC compliant they end up with RTP/RTCP. So no security. Bad. > This way we don't need to trust the JS, instead trust only the browser. You mean the user. > We can also interoperate with legacy devices without taxing them. Sorry, but WebRTC is about "realtime communications for the Web", rather than "SIP business coming to the Web". SIP uses RTP, including RFC's about SRTP. If you want SIP interoperability with a WebRTC device, then make your work as vendor and add security to your SIP devices rather than asking no-security for WebRTC. Please, take a look to XMPP/Jingle !! They implement SRTP and ICE from the beginning!! *Do* your homeworks as SIP vendor. This is a problem of SIP vendors/telcos, this is not a problem of WebRTC. You should implement SRTP in your legacy and non-secure SIP devices and make them valid for communication across the open Internet in which security is a MUST (Internet is not a telco wallen garden). The main purpose of WebRTC is not to interoperate with insecure devices, do we all agree here? I don't support this kind of arguments in favour of non mandating SRTP. PS: Somebody could argue that, in the Web, neither HTTPS or WebSocket+TLS is a MUST but optional per website, so why to make SRTP mandatory? That would be a very different argument I could understand and discuss about. But forcing a *new* specification to be insecure just to allow interoperability with non-secure devices is not welcome. WebRTC is for the Web, not for SIP. PS: This kind of discussions give the reason to recent comments like the one from Tim Parton. This WG is too much focused on SIP vendors/telcos which are not fully interested in RTC communications in pure Web/Internet environments, but in making the web browsers a new SIP phone for integratting them into their telco business. Bad. PS: I'm also interested in interoperability between WebRTC browsers and SIP devices (as much as you), but I assume that just a few SIP devices MUST be able to interop with WebRTC (those that have done their homeworks by implementing SRTP and ICE). And those discussions are becoming very boring. There are not new arguments at all. It seems than within next weeks/months, SIP telcos/vendors will continue requesting not mandatory SRTP just to facilitate their business without investing in improving their non-secure devices. This is a no-go. Regards. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Wed Nov 9 04:13:01 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC1A21F8B52 for ; Wed, 9 Nov 2011 04:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=-0.503, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_UNSUB22=0.948] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Va-iEpbJOB7 for ; Wed, 9 Nov 2011 04:13:00 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id B2E0721F8C51 for ; Wed, 9 Nov 2011 04:12:59 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA9CDXkD022912; Wed, 9 Nov 2011 07:13:33 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 07:12:56 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 17:43:05 +0530 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.0339.001; Wed, 9 Nov 2011 17:43:05 +0530 From: "Ravindran, Parthasarathi" To: Cameron Byrne Thread-Topic: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of WebRTC) Thread-Index: AQHMnoiMLXoobGtfx0Kkx8oSZTnrRJWj1oYw//+vPwCAAI2ocA== Date: Wed, 9 Nov 2011 12:13:04 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0134A379@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <4EB9ACF5.80805@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FE6@inba-mail01.sonusnet.com> 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.164] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0134A379inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2011 12:13:05.0552 (UTC) FILETIME=[EF855900:01CC9ED8] Cc: "<,rtcweb@ietf.org>," Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of 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: Wed, 09 Nov 2011 12:13:01 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0134A379inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cb, Please read inline. Thanks Partha From: Cameron Byrne [mailto:cb.list6@gmail.com] Sent: Wednesday, November 09, 2011 8:58 AM To: Ravindran Parthasarathi Cc: <,rtcweb@ietf.org>, Subject: RE: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the = purpose of WebRTC) On Nov 8, 2011 6:50 PM, "Ravindran Parthasarathi" > wrote: > > Cameron, > > > > I guess that we are in the same w.r.t IETF privacy policy and it is main = reason, I take back my comment #2. But, Please look into comment #1 for Ent= erprise WebRTC application wherein SRTP is not required to be mandated. > > > > > >> 1) Security could be in the lower layer itself (IPsec, VPN, private > > >MPLS cloud). For Enterprise-only-WebRTC application (no federation& n= o > > >interop), there is no need of security by specific application like > > >WebRTC as it is ensured in the infrastructure. WebRTC security will be > > >duplicated for these infrastructure and may leads double encryption > > >unnecessarily. > > Thanks > > Partha > I don't believe we can assume other crypto measures are in place Bob and Alice work for Toobigtofail Inc. They are on the same LAN segment a= nd using webrtc to communicate about making a large investment. On that sam= e LAN segment there is a compromised host intercepting all traffic (it did = some arp spoofing or something like that ) No problem here since Bob and Alice are using srtp. If they did not, the financial info would have been exposed I guess that your argument is not specific to webRTC but includes = all real-time communication in Enterprise. My point is that this security c= oncern is not generic enough as mentioned in the other mail thread. Cb > > > From: Cameron Byrne [mailto:cb.list6@gmail.com= ] > Sent: Wednesday, November 09, 2011 8:07 AM > To: Ravindran Parthasarathi > Cc: <,rtcweb@ietf.org>, > Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define th= e purpose of WebRTC) > > > > > On Nov 8, 2011 5:21 PM, "Ravindran Parthasarathi" > wrote: > > > > Thanks to Harald/Cullen for pointing out RFC 2804. I take back my #2 co= mment based on RFC 2804 wiretapping policy. > > > > I wish to clarify why I gave this comment before closing on #2: > > > > It is the common practice in India to buy computer to talk/chat with th= e relatives who are outside India by using Skype/Gtalk/Yahoo (avoiding Inte= rnational subscriber dialing charges). Of course, Cell phone is more popula= r than Computer and cheap (~$100) Wi-Fi enabled (Android) Smartphones are a= vailable in market. WebRTC will bring the new innovative way of communicati= ng using Smartphone (like free WebRTC session to street provisional store).= Browser in Smartphone is the platform for making outgoing session towards = provisional store. I really don't want these kind of WebRTC service are for= bidden by Government laws unnecessarily due to security (SRTP) reasons. > > > > > > Getting into murky waters here. > > I believe the ietf values privacy and I would like srtp to be mandatory s= ince I value privacy. > > If not supporting privacy is a requirement for your government, then perh= aps webrtc is not for you. > > Cb > > > >-----Original Message----- > > >From: Harald Alvestrand [mailto:harald@alvestrand.no] > > >Sent: Wednesday, November 09, 2011 3:58 AM > > >To: Ravindran Parthasarathi > > >Cc: Hadriel Kaplan; Eric Rescorla; > > > >Subject: SRTP requirement - wiretapping (Re: [rtcweb] Let's define the > > >purpose of WebRTC) > > > > > >Changing the subject again to mention SRTP.... > > > > > >On 11/08/2011 03:30 PM, Ravindran Parthasarathi wrote: > > >> I agree with Hadriel that it is not required to mandate SRTP for > > >WebRTC. My reasoning are as follows: > > >> > > >> 1) Security could be in the lower layer itself (IPsec, VPN, private > > >MPLS cloud). For Enterprise-only-WebRTC application (no federation& n= o > > >interop), there is no need of security by specific application like > > >WebRTC as it is ensured in the infrastructure. WebRTC security will be > > >duplicated for these infrastructure and may leads double encryption > > >unnecessarily. > > >This argument makes some sense. > > >> > > >> 2) Being in India, I'm interested in avoiding Government restriction > > >on WebRTC proposal (Thanks to Tim for pointing this). I may not surpri= se > > >to see that WebRTC mechanism is banned in India because intelligent > > >agency struggles to break the key in each terrorist WebRTC site. > > >(http://www.pcworld.com/businesscenter/article/235639/india_wants_to_i= nt > > >ercept_skype_google_communications.html) > > >This argument is contrary to stated IETF policy (RFC 2804). > > > > > >I recommend the RFC for background reading. > > >> > > >> In case there is no use case to illustrate in RTCWeb draft, let us > > >discuss in detail. > > >> > > >>> -----Original Message----- > > >>> From: rtcweb-bounces@ietf.org [mail= to:rtcweb-bounces@ietf.org] On > > >Behalf > > >>> Of Hadriel Kaplan > > >>> Sent: Monday, November 07, 2011 9:12 PM > > >>> To: Eric Rescorla > > >>> Cc:> > > >>> Subject: Re: [rtcweb] Let's define the purpose of WebRTC > > >>> > > >>> > > >>> On 11/07/2011 02:50 PM, Eric Rescorla wrote: > > >>>> On Sun, Nov 6, 2011 at 7:20 PM, Hadriel > > >Kaplan> > > >>> wrote: > > >>>>> Who said "too slow"? There *is* an extra round-trip or two > > >involved > > >>> I presume, if we're talking DTLS-SRTP, but no I didn't mean that as= a > > >>> "hit". I just meant the extra computing cycles for SRTP being a > > >"hit". > > >>> For WebRTC-to-WebRTC I don't think that matters at all. For WebRTC= - > > >to- > > >>> media-server it might, for a free game app or greeting card app tha= t > > >>> don't care about it to begin with, and which use plaintext HTTP to > > >begin > > >>> with. > > >>>> Sorry, I didn't mean to put words in your mouth. Performance > > >>> measurements > > >>>> of HTTP versus HTTPS in modern Web environments suggest that the > > >>> additional > > >>>> load for HTTPS is not significant. Do you have evidence that the > > >>> situation is > > >>>> different for SRTP versus RTP? > > >>> Only from the DSP guys, and those would be hardware DSPs not > > >softDSPs. > > >>> It runs them anywhere from 10-25% overhead, they say, depending on > > >the > > >>> vendor and what else their DSPs are doing at the time. > > >>> > > >>> But ultimately even in software I assume it's all relative to what > > >other > > >>> work you're doing. If you have to render a video stream on a scree= n > > >and > > >>> encode camera input into a codec being sent out, then my guess is > > >SRTP > > >>> overhead is a tiny factor not worth talking about. If you're mixin= g > > >>> multiple RTP streams as a conference server, then I assume doing SR= TP > > >>> for thousands of simultaneous audio RTP streams for multiple > > >>> simultaneous conferences becomes noticeable. Or at least so they > > >seem > > >>> to claim - I don't know since I don't build a media server (hardwar= e > > >>> SBCs often offload SRTP onto dedicated hardware). One large softwa= re > > >>> company even created their own proprietary packet format for SRTP > > >that > > >>> they claimed was done for improving performance/scalability, so I > > >assume > > >>> it has some impact they don't want their customers to incur. > > >>> > > >>> -hadriel > > >>> > > >>> _______________________________________________ > > >>> rtcweb mailing list > > >>> rtcweb@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/rtcweb > > >> _______________________________________________ > > >> rtcweb mailing list > > >> rtcweb@ietf.org > > >> https://www.ietf.org/mailman/listinfo/rtcweb > > >> > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb --_000_387F9047F55E8C42850AD6B3A7A03C6C0134A379inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Cb,

 

Please read inline.

 

Thanks

Partha

 

From: Cameron = Byrne [mailto:cb.list6@gmail.com]
Sent: Wednesday, November 09, 2011 8:58 AM
To: Ravindran Parthasarathi
Cc: &lt,rtcweb@ietf.org&gt,
Subject: RE: [rtcweb] SRTP requirement - wiretapping (Re: Let's defi= ne the purpose of WebRTC)

 


On Nov 8, 2011 6:50 PM, "Ravindran Parthasarathi" <pravindran@sonusnet.com> wrote:
>
> Cameron,
>
>  
>
> I guess that we are in the same w.r.t IETF privacy policy and it is ma= in reason, I take back my comment #2. But, Please look into comment #1 for = Enterprise WebRTC application wherein SRTP is not required to be mandated.<= br> >
>  
>
> > >> 1) Security could be in the lower layer itself (IPsec, V= PN, private
> > >MPLS cloud). For Enterprise-only-WebRTC application (no feder= ation&  no
> > >interop), there is no need of security by specific applicatio= n like
> > >WebRTC as it is ensured in the infrastructure. WebRTC securit= y will be
> > >duplicated for these infrastructure and may leads double encr= yption
> > >unnecessarily.
>
> Thanks
>
> Partha
>

I don't believe we can assume other crypto measures are in place

Bob and Alice work for Toobigtofail Inc. They are on the same LAN segmen= t and using webrtc to communicate about making a large investment. On that = same LAN segment there is a compromised host intercepting all traffic (it d= id some arp spoofing or something like that )

No problem here since Bob and Alice are using srtp. 

If they did not, the financial info would have been exposed

<partha> I guess that your argument is = not specific to webRTC but includes all real-time communication in Enterpri= se. My point is that this security concern is not generic enough as mentioned in the other mail thread.  </partha>

Cb
>  
>
> From: Cameron Byrne [mailto:cb.l= ist6@gmail.com]
> Sent: Wednesday, November 09, 2011 8:07 AM
> To: Ravindran Parthasarathi
> Cc: &lt,rtcweb@ietf.org&= ;gt,
> Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define= the purpose of WebRTC)
>
>  
>
>
> On Nov 8, 2011 5:21 PM, "Ravindran Parthasarathi" <pravindran@sonusnet.com> wrote:=
> >
> > Thanks to Harald/Cullen for pointing out RFC 2804. I take back my= #2 comment based on RFC 2804 wiretapping policy.
> >
> > I wish to clarify why I gave this comment before closing on #2: > >
> > It is the common practice in India to buy computer to talk/chat w= ith the relatives who are outside India by using Skype/Gtalk/Yahoo (avoidin= g International subscriber dialing charges). Of course, Cell phone is more = popular than Computer and cheap (~$100) Wi-Fi enabled (Android) Smartphones are available in market. WebRTC will b= ring the new innovative way of communicating using Smartphone (like free We= bRTC session to street provisional store). Browser in Smartphone is the pla= tform for making outgoing session towards provisional store. I really don't want these kind of WebRTC servic= e are forbidden by Government laws unnecessarily due to security (SRTP) rea= sons.
> >
> >
>
> Getting into murky waters here.
>
> I believe the ietf values privacy and I would like srtp to be mandator= y since I value privacy.
>
> If not supporting privacy is a requirement for your government, then p= erhaps webrtc is not for you.
>
> Cb
>
> > >-----Original Message-----
> > >From: Harald Alvestrand [mailto:harald@alvestrand.no]
> > >Sent: Wednesday, November 09, 2011 3:58 AM
> > >To: Ravindran Parthasarathi
> > >Cc: Hadriel Kaplan; Eric Rescorla; <rtcweb@ietf.org>
> > >Subject: SRTP requirement - wiretapping (Re: [rtcweb] Let's d= efine the
> > >purpose of WebRTC)
> > >
> > >Changing the subject again to mention SRTP....
> > >
> > >On 11/08/2011 03:30 PM, Ravindran Parthasarathi wrote:
> > >> I agree with Hadriel that it is not required to mandate = SRTP for
> > >WebRTC. My reasoning are as follows:
> > >>
> > >> 1) Security could be in the lower layer itself (IPsec, V= PN, private
> > >MPLS cloud). For Enterprise-only-WebRTC application (no feder= ation&  no
> > >interop), there is no need of security by specific applicatio= n like
> > >WebRTC as it is ensured in the infrastructure. WebRTC securit= y will be
> > >duplicated for these infrastructure and may leads double encr= yption
> > >unnecessarily.
> > >This argument makes some sense.
> > >>
> > >> 2) Being in India, I'm interested in avoiding Government= restriction
> > >on WebRTC proposal (Thanks to Tim for pointing this). I may n= ot surprise
> > >to see that WebRTC mechanism is banned in India because intel= ligent
> > >agency struggles to break the key in each terrorist WebRTC si= te.
> > >(http://www.pcworld.com/businesscenter/article/23563= 9/india_wants_to_int
> > >ercept_skype_google_communications.html)
> > >This argument is contrary to stated IETF policy (RFC 2804). > > >
> > >I recommend the RFC for background reading.
> > >>
> > >> In case there is no use case to illustrate in RTCWeb dra= ft, let us
> > >discuss in detail.
> > >>
> > >>> -----Original Message-----
> > >>> From: rtc= web-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > >Behalf
> > >>> Of Hadriel Kaplan
> > >>> Sent: Monday, November 07, 2011 9:12 PM
> > >>> To: Eric Rescorla
> > >>> Cc:<rtcweb@iet= f.org>
> > >>> Subject: Re: [rtcweb] Let's define the purpose of We= bRTC
> > >>>
> > >>>
> > >>> On 11/07/2011 02:50 PM, Eric Rescorla wrote:
> > >>>> On Sun, Nov 6, 2011 at 7:20 PM, Hadriel
> > >Kaplan<HKaplan@a= cmepacket.com>
> > >>> wrote:
> > >>>>> Who said "too slow"?  There *= is* an extra round-trip or two
> > >involved
> > >>> I presume, if we're talking DTLS-SRTP, but no I didn= 't mean that as a
> > >>> "hit".  I just meant the extra comput= ing cycles for SRTP being a
> > >"hit".
> > >>> For WebRTC-to-WebRTC I don't think that matters at a= ll.  For WebRTC-
> > >to-
> > >>> media-server it might, for a free game app or greeti= ng card app that
> > >>> don't care about it to begin with, and which use pla= intext HTTP to
> > >begin
> > >>> with.
> > >>>> Sorry, I didn't mean to put words in your mouth.= Performance
> > >>> measurements
> > >>>> of HTTP versus HTTPS in modern Web environments = suggest that the
> > >>> additional
> > >>>> load for HTTPS is not significant. Do you have e= vidence that the
> > >>> situation is
> > >>>> different for SRTP versus RTP?
> > >>> Only from the DSP guys, and those would be hardware = DSPs not
> > >softDSPs.
> > >>> It runs them anywhere from 10-25% overhead, they say= , depending on
> > >the
> > >>> vendor and what else their DSPs are doing at the tim= e.
> > >>>
> > >>> But ultimately even in software I assume it's all re= lative to what
> > >other
> > >>> work you're doing.  If you have to render a vid= eo stream on a screen
> > >and
> > >>> encode camera input into a codec being sent out, the= n my guess is
> > >SRTP
> > >>> overhead is a tiny factor not worth talking about. &= nbsp;If you're mixing
> > >>> multiple RTP streams as a conference server, then I = assume doing SRTP
> > >>> for thousands of simultaneous audio RTP streams for = multiple
> > >>> simultaneous conferences becomes noticeable.  O= r at least so they
> > >seem
> > >>> to claim - I don't know since I don't build a media = server (hardware
> > >>> SBCs often offload SRTP onto dedicated hardware). &n= bsp;One large software
> > >>> company even created their own proprietary packet fo= rmat for SRTP
> > >that
> > >>> they claimed was done for improving performance/scal= ability, so I
> > >assume
> > >>> it has some impact they don't want their customers t= o incur.
> > >>>
> > >>> -hadriel
> > >>>
> > >>> _______________________________________________
> > >>> rtcweb mailing list
> > >>> rtcweb@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/rtcweb
> > >> _______________________________________________
> > >> rtcweb mailing list
> > >> rtcweb@ietf.org > > >> https://www.ietf.org/mailman/listinfo/rtcweb
> > >>
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://= www.ietf.org/mailman/listinfo/rtcweb

--_000_387F9047F55E8C42850AD6B3A7A03C6C0134A379inbamail01sonus_-- From harald@alvestrand.no Wed Nov 9 04:26:26 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CCD21F86F6 for ; Wed, 9 Nov 2011 04:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.552 X-Spam-Level: X-Spam-Status: No, score=-110.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 biAOc8b5Ic+D for ; Wed, 9 Nov 2011 04:26:25 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 656E821F86C3 for ; Wed, 9 Nov 2011 04:26:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B854D39E12B for ; Wed, 9 Nov 2011 13:26:24 +0100 (CET) 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 8YoxJuHCrMqU for ; Wed, 9 Nov 2011 13:26:21 +0100 (CET) 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 ESMTPS id F2FF139E04C for ; Wed, 9 Nov 2011 13:26:20 +0100 (CET) Message-ID: <4EBA716C.5050004@alvestrand.no> Date: Wed, 09 Nov 2011 13:26:20 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4EB26D22.5090000@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 12:26:26 -0000 On 11/09/2011 12:09 AM, Cullen Jennings wrote: > I don't understand the meaning of the sentence > > This part is outside the scope of the RTCWEB standards > suite. Sorry, can you give a better sentence? The point is "you won't find the spec for this protocol in the RTCWEB protocol specifications, and that's because we want it to not be there". but that seems a bit too person-oriented to be put into the spec. > I think we need to construct a solution that can work if domains want to federate with SIP - therefore this should be one our use cases. However, I think domain should be free to choose whatever they want to federate - it just needs to be possible to federate. I'd like to see this clarified. > > > On Nov 3, 2011, at 4:29 AM, Magnus Westerlund wrote: > >> WG, >> >> There has been a number of posts that makes arguments based on >> federation and the federation protocol. This is the protocol used >> between the webservers, called "Signalling path" in the trappzoid >> picture (from draft-ietf-rtcweb-overview-02) below: >> >> +-----------+ +-----------+ >> | Web | | Web | >> | | Signalling | | >> | |-------------| | >> | Server | path | Server | >> | | | | >> +-----------+ +-----------+ >> / \ >> / \ Proprietary over >> / \ HTTP/Websockets >> / \ >> / Proprietary over \ >> / HTTP/Websockets \ >> / \ >> +-----------+ +-----------+ >> |JS/HTML/CSS| |JS/HTML/CSS| >> +-----------+ +-----------+ >> +-----------+ +-----------+ >> | | | | >> | | | | >> | Browser | ------------------------- | Browser | >> | | Media path | | >> | | | | >> +-----------+ +-----------+ >> >> Figure 2: Browser RTC Trapezoid >> >> >> Please consider that the current WG consensus is well captured in the >> overview draft: >> >> If the two Web servers are operated by different entities, the >> signalling path needs to be agreed upon, either by standardization or >> by other means of agreement; for example, both servers might >> implement SIP, and the servers would talk SIP to each other, and each >> would translate between the SIP protocol and their proprietary >> representation for sending to their application running in the >> browser. This part is outside the scope of the RTCWEB standars >> suite. >> >> So, it may be SIP, it doesn't need to be SIP. The important from the >> WG's perspective is that is a possible deployment model we intended to >> support. It is not the only deployment model. We don't define what is >> used on the signalling path and there is freedom here. >> >> Please consider that when writing arguments so that you don't >> misrepresent the current WG consensus or ignore the set of possibilities >> that currently are considered. >> >> If you don't like the WG consensus, then suggest to change it and see if >> you get support for it. >> >> 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 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From harald@alvestrand.no Wed Nov 9 04:37:49 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94D821F8C75 for ; Wed, 9 Nov 2011 04:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.553 X-Spam-Level: X-Spam-Status: No, score=-110.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxqteBfE2FyE for ; Wed, 9 Nov 2011 04:37:48 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9603021F8B50 for ; Wed, 9 Nov 2011 04:37:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E822639E12B for ; Wed, 9 Nov 2011 13:37:47 +0100 (CET) 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 7MSGeftoVGOK for ; Wed, 9 Nov 2011 13:37:47 +0100 (CET) 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 ESMTPS id 0134A39E04C for ; Wed, 9 Nov 2011 13:37:46 +0100 (CET) Message-ID: <4EBA741A.1010307@alvestrand.no> Date: Wed, 09 Nov 2011 13:37:46 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4EB26D22.5090000@ericsson.com>, In-Reply-To: Content-Type: multipart/alternative; boundary="------------050800080602010106050203" Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 12:37:49 -0000 This is a multi-part message in MIME format. --------------050800080602010106050203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/09/2011 01:28 AM, Bernard Aboba wrote: > [BA] I don't understand that sentence either, partly because it's not > clear to me what "this" refers to. The previous sentence talks about > "the signaling path needs to be agreed upon, either by standardization > or by other means of agreement", but also talks about "their > proprietary representation". Is "this" referring to the former or the > latter? > > Here's a rewrite that makes more sense (at least to me): > > "If the two Web servers are operated by different entities, the > inter-domain signalling mechanism needs to be agreed upon, either by > standardization or by other means of agreement. Existing can we avoid using the term "domain" here? It's not used before this point. "inter-server" or "inter-entity" would do, since those words are already present. > protocols that support federation (SIP or XMPP) could be used to > enable inter-domain federation That needs to be "for example SIP or XMPP" - if people want to use something else, that's up to them. "Federation" is another term with lots of implied meanings that isn't otherwise used in the document. can we simply say "Existing protocols (for example SIP or XMPP) could be used between the servers"? > between servers, while either a standards-based or proprietary > protocol could be used between the browser and the web server. > > For example, if both domains implement SIP, SIP could be used for > inter-domain communication between servers, along with either a > standardized signaling mechanism (e.g. SIP over Websockets) or a a > proprietary signaling mechanism used between the application running > in the browser and the web server. > > Similarly, if both domains implement XMPP, XMPP couild be used for > inter-domain communication between XMPP servers, with either a > standardized signaling mechanism (e.g. XMPP over Websockets or BOSH) > or a proprietary signaling mechanism used between the application > running in the browser and the web server." Combined rephrase of the new language: "If the two Web servers are operated by different entities, the inter-server signalling mechanism needs to be agreed upon, either by standardization or by other means of agreement. Existing protocols (for example SIP or XMPP) could be used between servers, while either a standards-based or proprietary protocol could be used between the browser and the web server. For example, if both domains implement SIP, SIP could be used for communication between servers, along with either a standardized signaling mechanism (e.g. SIP over Websockets) or a a proprietary signaling mechanism used between the application running in the browser and the web server. Similarly, if both domains implement XMPP, XMPP couild be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g. XMPP over Websockets or BOSH) or a proprietary signaling mechanism used between the application running in the browser and the web server." I'm happy to use the longer paragraph if we can remove the words "domain" and "federation" from it; I think it says the same thing as what's already there, but if Cullen agrees with Bernard that the words are more easily interpreted than mine, let's switch. > > > > Cullen said: > > "I don't understand the meaning of the sentence > > This part is outside the scope of the RTCWEB standards suite. > > I think we need to construct a solution that can work if domains want > to federate with SIP - therefore this should be one our use cases. > However, I think domain should be free to choose whatever they want to > federate - it just needs to be possible to federate. I'd like to see > this clarified." > > > > ============================================================== > > "If the two Web servers are operated by different entities, the > signalling path needs to be agreed upon, either by standardization or > by other means of agreement; for example, both servers might > implement SIP, and the servers would talk SIP to each other, and each > would translate between the SIP protocol and their proprietary > representation for sending to their application running in the > browser.This part is outside the scope of the RTCWEB standars > suite." > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------050800080602010106050203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/09/2011 01:28 AM, Bernard Aboba wrote:
[BA]  I don't understand that sentence either, partly because it's not clear to me what "this" refers to.  The previous sentence talks about "the signaling path needs to be agreed upon, either by standardization or by other means of agreement", but also talks about "their proprietary representation".  Is "this" referring to the former or the latter? 
 
Here's a rewrite that makes more sense (at least to me):
 
"If the two Web servers are operated by different entities, the inter-domain signalling mechanism needs to be agreed upon, either by standardization or by other means of agreement.  Existing
can we avoid using the term "domain" here? It's not used before this point. "inter-server" or "inter-entity" would do, since those words are already present.
protocols that support federation (SIP or XMPP) could be used to enable inter-domain federation
That needs to be "for example SIP or XMPP" - if people want to use something else, that's up to them.
"Federation" is another term with lots of implied meanings that isn't otherwise used in the document.

can we simply say "Existing protocols (for example SIP or XMPP) could be used between the servers"?
between servers, while either a standards-based or proprietary protocol could be used between the browser and the web server.
 
For example, if both domains implement SIP,  SIP could be used for inter-domain communication between servers, along with either a standardized signaling mechanism (e.g. SIP over Websockets) or a a proprietary signaling mechanism used between the application running in the browser and the web server.  
 
Similarly, if both domains implement XMPP, XMPP couild be used for inter-domain communication between XMPP servers, with either a standardized signaling mechanism (e.g. XMPP over Websockets or BOSH) or a proprietary signaling mechanism used between the application running in the browser and the web server."

Combined rephrase of the new language:

"If the two Web servers are operated by different entities, the inter-server signalling mechanism needs to be agreed upon, either by standardization or by other means of agreement.  Existing protocols (for example SIP or XMPP) could be used between servers, while either a standards-based or proprietary protocol could be used between the browser and the web server.
 
For example, if both domains implement SIP,  SIP could be used for communication between servers, along with either a standardized signaling mechanism (e.g. SIP over Websockets) or a a proprietary signaling mechanism used between the application running in the browser and the web server.  
 
Similarly, if both domains implement XMPP, XMPP couild be used for communication between XMPP servers, with either a standardized signaling mechanism (e.g. XMPP over Websockets or BOSH) or a proprietary signaling mechanism used between the application running in the browser and the web server."

I'm happy to use the longer paragraph if we can remove the words "domain" and "federation" from it; I think it says the same thing as what's already there, but if Cullen agrees with Bernard that the words are more easily interpreted than mine, let's switch.

 
 
 
Cullen said:
 
"I don't understand the meaning of the sentence 

This part is outside the scope of the RTCWEB standards suite.

I think we need to construct a solution that can work if domains want to federate with SIP - therefore this should be one our use cases. However, I think domain should be free to choose whatever they want to federate - it just needs to be possible to federate. I'd like to see this clarified."

 
 
==============================================================
 
"If the two Web servers are operated by different entities, the
signalling path needs to be agreed upon, either by standardization or
by other means of agreement; for example, both servers might
implement SIP, and the servers would talk SIP to each other, and each
would translate between the SIP protocol and their proprietary
representation for sending to their application running in the
browser.This part is outside the scope of the RTCWEB standars
suite."
 
 

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

--------------050800080602010106050203-- From neils@vipadia.com Wed Nov 9 04:53:18 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F5621F8B54 for ; Wed, 9 Nov 2011 04:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_93=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 C4dmZhCBWq1g for ; Wed, 9 Nov 2011 04:53:17 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7480221F8B4E for ; Wed, 9 Nov 2011 04:53:17 -0800 (PST) Received: by ywt2 with SMTP id 2so2031918ywt.31 for ; Wed, 09 Nov 2011 04:53:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.217.195 with SMTP id pa3mr2351327igc.12.1320843195496; Wed, 09 Nov 2011 04:53:15 -0800 (PST) Sender: neils@vipadia.com Received: by 10.231.207.10 with HTTP; Wed, 9 Nov 2011 04:53:15 -0800 (PST) In-Reply-To: References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3B9C1@XMB-BGL-414.cisco.com> Date: Wed, 9 Nov 2011 12:53:15 +0000 X-Google-Sender-Auth: dcMM3tcTaRyq6SnVY5jBkO0Lpik Message-ID: From: Neil Stratford To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=14dae934057778b83204b14cc5cc Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 12:53:18 -0000 --14dae934057778b83204b14cc5cc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Wouldn't it be great if we had an opportunity to start from a clean sheet, carry no legacy baggage and design a platform for the future? Isn't that the opportunity presented by WebRTC? It will always be possible to gateway to legacy SIP devices, even if we have to bridge the media. It seems there is far too much focus on interop and not enough on what is best for the WebRTC platform. Neil On Wed, Nov 9, 2011 at 11:58 AM, I=F1aki Baz Castillo wrote= : > 2011/11/9 Muthu Arul Mozhi Perumal (mperumal) : > > I am thinking we could burn SRTP into the browser such that the decisio= n > of whether or not to use SRTP vests solely with the browser. > > The "browser" cannot decide that. Probably you mean the user, that > person that in 99.999% of cases does not know what "encryption" or > "SRTP" is, and in 85% of cases does not matter about security. > > > > If a WebRTC browser is exchanging media with another WebRTC browser the= y > always do SRTP/SRTCP. > > The browser has NO way to determine whether it's exchanging media with > another browser or not. And what you state is that, in case the peer > does not annouce support for SRTP then the browser should downgrade > security to plain RTP. The user (web visitor) has no way to know > whether the WebRTC application will contact a WebRTC browser or > another device at the media plane. > > > > If either side isn't WebRTC compliant they end up with RTP/RTCP. > > So no security. Bad. > > > > This way we don't need to trust the JS, instead trust only the browser. > > You mean the user. > > > > We can also interoperate with legacy devices without taxing them. > > Sorry, but WebRTC is about "realtime communications for the Web", > rather than "SIP business coming to the Web". SIP uses RTP, including > RFC's about SRTP. If you want SIP interoperability with a WebRTC > device, then make your work as vendor and add security to your SIP > devices rather than asking no-security for WebRTC. > > Please, take a look to XMPP/Jingle !! They implement SRTP and ICE > from the beginning!! *Do* your homeworks as SIP vendor. > > This is a problem of SIP vendors/telcos, this is not a problem of > WebRTC. You should implement SRTP in your legacy and non-secure SIP > devices and make them valid for communication across the open Internet > in which security is a MUST (Internet is not a telco wallen garden). > The main purpose of WebRTC is not to interoperate with insecure > devices, do we all agree here? > > I don't support this kind of arguments in favour of non mandating SRTP. > > > PS: Somebody could argue that, in the Web, neither HTTPS or > WebSocket+TLS is a MUST but optional per website, so why to make SRTP > mandatory? That would be a very different argument I could understand > and discuss about. But forcing a *new* specification to be insecure > just to allow interoperability with non-secure devices is not welcome. > WebRTC is for the Web, not for SIP. > > PS: This kind of discussions give the reason to recent comments like > the one from Tim Parton. This WG is too much focused on SIP > vendors/telcos which are not fully interested in RTC communications in > pure Web/Internet environments, but in making the web browsers a new > SIP phone for integratting them into their telco business. Bad. > > PS: I'm also interested in interoperability between WebRTC browsers > and SIP devices (as much as you), but I assume that just a few SIP > devices MUST be able to interop with WebRTC (those that have done > their homeworks by implementing SRTP and ICE). > > > And those discussions are becoming very boring. There are not new > arguments at all. It seems than within next weeks/months, SIP > telcos/vendors will continue requesting not mandatory SRTP just to > facilitate their business without investing in improving their > non-secure devices. This is a no-go. > > > Regards. > > > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --14dae934057778b83204b14cc5cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Wouldn't it be great if we had an opportunity to start from a clean she= et, carry no legacy baggage and design a platform for the future? Isn't= that the opportunity presented by WebRTC?

It will alway= s be possible to gateway to legacy SIP devices, even if we have to bridge t= he media. It seems there is far too much focus on interop and not enough on= what is best for the WebRTC platform.

Neil

On Wed, Nov= 9, 2011 at 11:58 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2011/11/9 Muthu Arul Mozhi Perumal (mperumal) <mperumal@cisco.com>:
> I am thinking we could burn SRTP into the browser su= ch that the decision of whether or not to use SRTP vests solely with the br= owser.

The "browser" cannot decide that. Probably you mean the use= r, that
person that in 99.999% of cases does not know what "encryption" o= r
"SRTP" is, and in 85% of cases does not matter about security.


> If a WebRTC browser is exchanging media with another WebRTC browser th= ey always do SRTP/SRTCP.

The browser has NO way to determine whether it's exchanging media= with
another browser or not. And what you state is that, in case the peer
does not annouce support for SRTP then the browser should downgrade
security to plain RTP. The user (web visitor) has no way to know
whether the WebRTC application will contact a WebRTC browser or
another device at the media plane.


> If either side isn't WebRTC compliant they end up with RTP/RTCP.
So no security. Bad.


> This way we don't need to trust the JS, instead trust only the bro= wser.

You mean the user.


> We can also interoperate with legacy devices without taxing them.

Sorry, but WebRTC is about "realtime communications for the Web&= quot;,
rather than "SIP business coming to the Web". SIP uses RTP, inclu= ding
RFC's about SRTP. If you want SIP interoperability with a WebRTC
device, then make your work as vendor and add security to your SIP
devices rather than asking no-security for WebRTC.

Please, take a look to XMPP/Jingle !! =A0They implement SRTP and ICE
from the beginning!! *Do* your homeworks as SIP vendor.

This is a problem of SIP vendors/telcos, this is not a problem of
WebRTC. You should implement SRTP in your legacy and non-secure SIP
devices and make them valid for communication across the open Internet
in which security is a MUST (Internet is not a telco wallen garden).
The main purpose of WebRTC is not to interoperate with insecure
devices, do we all agree here?

I don't support this kind of arguments in favour of non mandating SRTP.=


PS: Somebody could argue that, in the Web, neither HTTPS or
WebSocket+TLS is a MUST but optional per website, so why to make SRTP
mandatory? That would be a very different argument I could understand
and discuss about. But forcing a *new* specification to be insecure
just to allow interoperability with non-secure devices is not welcome.
WebRTC is for the Web, not for SIP.

PS: This kind of discussions give the reason to recent comments like
the one from Tim Parton. This WG is too much focused on SIP
vendors/telcos which are not fully interested in RTC communications in
pure Web/Internet environments, but in making the web browsers a new
SIP phone for integratting them into their telco business. Bad.

PS: I'm also interested in interoperability between WebRTC browsers
and SIP devices (as much as you), but I assume that just a few SIP
devices MUST be able to interop with WebRTC (those that have done
their homeworks by implementing SRTP and ICE).


And those discussions are becoming very boring. There are not new
arguments at all. It seems than within next weeks/months, SIP
telcos/vendors will continue requesting not mandatory SRTP just to
facilitate their business without investing in improving their
non-secure devices. This is a no-go.


Regards.


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

--14dae934057778b83204b14cc5cc-- From ibc@aliax.net Wed Nov 9 05:00:32 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D26521F8C4E for ; Wed, 9 Nov 2011 05:00:32 -0800 (PST) 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 mhhs4Sgl1F6O for ; Wed, 9 Nov 2011 05:00:31 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A0CE821F8C1B for ; Wed, 9 Nov 2011 05:00:31 -0800 (PST) Received: by vws5 with SMTP id 5so1640575vws.31 for ; Wed, 09 Nov 2011 05:00:31 -0800 (PST) Received: by 10.52.187.68 with SMTP id fq4mr4438264vdc.32.1320843631145; Wed, 09 Nov 2011 05:00:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Wed, 9 Nov 2011 05:00:10 -0800 (PST) In-Reply-To: References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3B9C1@XMB-BGL-414.cisco.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 9 Nov 2011 14:00:10 +0100 Message-ID: To: Neil Stratford Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 13:00:32 -0000 2011/11/9 Neil Stratford : > Wouldn't it be great if we had an opportunity to start from a clean sheet= , > carry no legacy baggage and design a platform for the future? Isn't that = the > opportunity presented by WebRTC? > It will always be possible to gateway to legacy SIP devices, even if we h= ave > to bridge the media. It seems there is far too much focus on interop and = not > enough on what is best for the WebRTC platform. Hi Neil, IMHO trying to create a "new RTC protocol" is not the best option. IMHO we can learn and reuse existing technologies and specifications. Honestly I don't think it would be positive to reinvent the wheel about RTP and SDP. RTP is the standard media protocol and it's good enough. And SDP is a protocol/format to control such RTP communication. Creating a new like-RTP/SDP would take long years and we would get nothing much better. The point is that WebRTC must define its own requirements rather than implementing RTP in the way SIP telcos desire just to interoperate with their legacy-and-never-secure SIP devices. IMHO SRTP and ICE is the way to go (I would say the same even if SIP or XMPP-Jingle don't exist). Regards. --=20 I=C3=B1aki Baz Castillo From keith.drage@alcatel-lucent.com Wed Nov 9 05:05:18 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C902B21F8C50 for ; Wed, 9 Nov 2011 05:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.725 X-Spam-Level: X-Spam-Status: No, score=-105.725 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, 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 D0eLZQJfa4Hx for ; Wed, 9 Nov 2011 05:05:17 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4B46921F8C4E for ; Wed, 9 Nov 2011 05:05:17 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pA9D5CAI003948 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Nov 2011 14:05:14 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 9 Nov 2011 14:04:56 +0100 From: "DRAGE, Keith (Keith)" To: Neil Stratford , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 9 Nov 2011 14:04:55 +0100 Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: Acye3pUFe/nx9KxRT1Oz4agdkhbsQgAAOcfQ Message-ID: References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3B9C1@XMB-BGL-414.cisco.com> In-Reply-To: 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_EDC0A1AE77C57744B664A310A0B23AE22186AAFDFRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 13:05:18 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE22186AAFDFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you want to be in the world of telecommunications you carry a legacy bag= gage. Your proposal to provide a gateway is just one way of dealing with the lega= cy baggage. It does however carry the downside that you need a player to pr= ovide such gateways in support of interworking to the legacy. Suppose I make an emergency call to a PSAP. The legacy baggage here is that= unless someone volunteers to provide all those PSAPs worldwide with new ki= t, the majority will remain connected to the PSTN (i.e. not even SIP). I ne= ed a guarantee that someone out there will provide a gateway. Which player = provides that in your business model. Keith ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Neil Stratford Sent: 09 November 2011 12:53 To: I=F1aki Baz Castillo Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of WebRTC Wouldn't it be great if we had an opportunity to start from a clean sheet, = carry no legacy baggage and design a platform for the future? Isn't that th= e opportunity presented by WebRTC? It will always be possible to gateway to legacy SIP devices, even if we hav= e to bridge the media. It seems there is far too much focus on interop and = not enough on what is best for the WebRTC platform. Neil On Wed, Nov 9, 2011 at 11:58 AM, I=F1aki Baz Castillo > wrote: 2011/11/9 Muthu Arul Mozhi Perumal (mperumal) >: > I am thinking we could burn SRTP into the browser such that the decision = of whether or not to use SRTP vests solely with the browser. The "browser" cannot decide that. Probably you mean the user, that person that in 99.999% of cases does not know what "encryption" or "SRTP" is, and in 85% of cases does not matter about security. > If a WebRTC browser is exchanging media with another WebRTC browser they = always do SRTP/SRTCP. The browser has NO way to determine whether it's exchanging media with another browser or not. And what you state is that, in case the peer does not annouce support for SRTP then the browser should downgrade security to plain RTP. The user (web visitor) has no way to know whether the WebRTC application will contact a WebRTC browser or another device at the media plane. > If either side isn't WebRTC compliant they end up with RTP/RTCP. So no security. Bad. > This way we don't need to trust the JS, instead trust only the browser. You mean the user. > We can also interoperate with legacy devices without taxing them. Sorry, but WebRTC is about "realtime communications for the Web", rather than "SIP business coming to the Web". SIP uses RTP, including RFC's about SRTP. If you want SIP interoperability with a WebRTC device, then make your work as vendor and add security to your SIP devices rather than asking no-security for WebRTC. Please, take a look to XMPP/Jingle !! They implement SRTP and ICE from the beginning!! *Do* your homeworks as SIP vendor. This is a problem of SIP vendors/telcos, this is not a problem of WebRTC. You should implement SRTP in your legacy and non-secure SIP devices and make them valid for communication across the open Internet in which security is a MUST (Internet is not a telco wallen garden). The main purpose of WebRTC is not to interoperate with insecure devices, do we all agree here? I don't support this kind of arguments in favour of non mandating SRTP. PS: Somebody could argue that, in the Web, neither HTTPS or WebSocket+TLS is a MUST but optional per website, so why to make SRTP mandatory? That would be a very different argument I could understand and discuss about. But forcing a *new* specification to be insecure just to allow interoperability with non-secure devices is not welcome. WebRTC is for the Web, not for SIP. PS: This kind of discussions give the reason to recent comments like the one from Tim Parton. This WG is too much focused on SIP vendors/telcos which are not fully interested in RTC communications in pure Web/Internet environments, but in making the web browsers a new SIP phone for integratting them into their telco business. Bad. PS: I'm also interested in interoperability between WebRTC browsers and SIP devices (as much as you), but I assume that just a few SIP devices MUST be able to interop with WebRTC (those that have done their homeworks by implementing SRTP and ICE). And those discussions are becoming very boring. There are not new arguments at all. It seems than within next weeks/months, SIP telcos/vendors will continue requesting not mandatory SRTP just to facilitate their business without investing in improving their non-secure devices. This is a no-go. Regards. -- I=F1aki Baz Castillo > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_EDC0A1AE77C57744B664A310A0B23AE22186AAFDFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If you want to be in the world of telecommunications you carry a legacy baggage.

 

Your proposal to provide a gateway is = just one way of dealing with the legacy baggage. It does however carry the downs= ide that you need a player to provide such gateways in support of interworking = to the legacy.

 

Suppose I make an emergency call to a PSAP. The legacy baggage here is that unless someone volunteers to provide = all those PSAPs worldwide with new kit, the majority will remain connected to t= he PSTN (i.e. not even SIP). I need a guarantee that someone out there will provide a gateway. Which player provides that in your business model.<= /o:p>

 

Keith

 

From:= rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Neil Stratford
Sent: 09 November 2011 12:53=
To: I=F1aki Baz Castillo
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Let's = define the purpose of WebRTC

 

Wouldn't it be great if we had an opportunity to start from a clean sheet, carry no legacy baggage and design a platform for the future? Isn't = that the opportunity presented by WebRTC?

 

It will always be possible to gateway to legacy SIP devices, even i= f we have to bridge the media. It seems there is far too much focus on interop a= nd not enough on what is best for the WebRTC platform.

 

Neil

 

On Wed, Nov 9, 2011 at 11:58 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:

2011/11/9 Muthu Arul Mozhi Perumal (mperumal) <mperumal@cisco.com>:

> I am thinkin= g we could burn SRTP into the browser such that the decision of whether or not t= o use SRTP vests solely with the browser.

The "browser" cannot decide that. Probably you mean the u= ser, that
person that in 99.999% of cases does not know what "encryption" o= r
"SRTP" is, and in 85% of cases does not matter about security.



> If a WebRTC browser is exchanging media with another WebRTC browser th= ey always do SRTP/SRTCP.

The browser has NO way to determine whether it's exchanging media w= ith
another browser or not. And what you state is that, in case the peer
does not annouce support for SRTP then the browser should downgrade
security to plain RTP. The user (web visitor) has no way to know
whether the WebRTC application will contact a WebRTC browser or
another device at the media plane.



> If either side isn't WebRTC compliant they end up with RTP/RTCP.<= /o:p>

So no security. Bad.



> This way we don't need to trust the JS, instead trust only the browser= .

You mean the user.



> We can also interoperate with legacy devices without taxing them.=

Sorry, but WebRTC is about "realtime communications for the Web",
rather than "SIP business coming to the Web". SIP uses RTP, inclu= ding
RFC's about SRTP. If you want SIP interoperability with a WebRTC
device, then make your work as vendor and add security to your SIP
devices rather than asking no-security for WebRTC.

Please, take a look to XMPP/Jingle !!  They implement SRTP and ICE
from the beginning!! *Do* your homeworks as SIP vendor.

This is a problem of SIP vendors/telcos, this is not a problem of
WebRTC. You should implement SRTP in your legacy and non-secure SIP
devices and make them valid for communication across the open Internet
in which security is a MUST (Internet is not a telco wallen garden).
The main purpose of WebRTC is not to interoperate with insecure
devices, do we all agree here?

I don't support this kind of arguments in favour of non mandating SRTP.


PS: Somebody could argue that, in the Web, neither HTTPS or
WebSocket+TLS is a MUST but optional per website, so why to make SRTP
mandatory? That would be a very different argument I could understand
and discuss about. But forcing a *new* specification to be insecure
just to allow interoperability with non-secure devices is not welcome.
WebRTC is for the Web, not for SIP.

PS: This kind of discussions give the reason to recent comments like
the one from Tim Parton. This WG is too much focused on SIP
vendors/telcos which are not fully interested in RTC communications in
pure Web/Internet environments, but in making the web browsers a new
SIP phone for integratting them into their telco business. Bad.

PS: I'm also interested in interoperability between WebRTC browsers
and SIP devices (as much as you), but I assume that just a few SIP
devices MUST be able to interop with WebRTC (those that have done
their homeworks by implementing SRTP and ICE).


And those discussions are becoming very boring. There are not new
arguments at all. It seems than within next weeks/months, SIP
telcos/vendors will continue requesting not mandatory SRTP just to
facilitate their business without investing in improving their
non-secure devices. This is a no-go.


Regards.



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

 

--_000_EDC0A1AE77C57744B664A310A0B23AE22186AAFDFRMRSSXCHMBSC3d_-- From mperumal@cisco.com Wed Nov 9 05:19:44 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2E121F8C39 for ; Wed, 9 Nov 2011 05:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.857 X-Spam-Level: X-Spam-Status: No, score=-6.857 tagged_above=-999 required=5 tests=[AWL=-0.258, 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 MY482exEYRUy for ; Wed, 9 Nov 2011 05:19:41 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id B95CD21F8C0F for ; Wed, 9 Nov 2011 05:19:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=1856; q=dns/txt; s=iport; t=1320844780; x=1322054380; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=rx+E5b4TRGstctrpiRjddCbYCyM6qKcG642GCxH87T0=; b=Px5Mws9vA+kv8N7gMYIOpy43poXkdmGNpAkBbfqM7AVdIwaLfVY+eKIS LxZFCube6Z0wLHdPab/G4FvObk31ZCQb5h1p6YXpta45770rf9usGEOkI /VKHNbKOJcB0C0iTbviQ25sOT6yEimHx3TyZrTFPvgoUS9GhhDfW8aaLg M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAMN9uk5Io8US/2dsb2JhbABCmiePdoEFgXIBAQEEEgEdSQwEAgEIEQQBAQsGFwEGAUUJCAEBBAsICBqhDgGfIIkcYwSHWy+RWYw8 X-IronPort-AV: E=Sophos;i="4.69,484,1315180800"; d="scan'208";a="2724700" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-4.cisco.com with ESMTP; 09 Nov 2011 13:19:38 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA9DJb8s015859; Wed, 9 Nov 2011 13:19:37 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 18:49:37 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Nov 2011 18:49:35 +0530 Message-ID: <1D062974A4845E4D8A343C653804920206D3BA43@XMB-BGL-414.cisco.com> In-Reply-To: <34771C19-DD51-46B4-97ED-703A93F7329E@edvina.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: Acye0hYRvbMSpMtNRp+JNi/6bl4HrgADtrWQ References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D0 62974A4 845E4D8A343C 653804920206D3B9C1@XMB-BGL-414.cisco.com> <34771C19-DD51-46B4-97ED-703A93F7329E@edvina.net> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Olle E. Johansson" X-OriginalArrivalTime: 09 Nov 2011 13:19:37.0479 (UTC) FILETIME=[3AE51170:01CC9EE2] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 13:19:45 -0000 |That opens up for downgrade attacks and put a lot=20 |of trust on the web browser UI to show what happens |and on the users to understand what the web browser=20 |UA is trying to tell them. It isn't an attack per se (since a malicious JS no control over it), = rather a choice we would have to make whether or not to allow insecure = calling to non-WebRTC clients. Yes, it adds some burden on the UI, but = could be as simple as a red cross you see on https URL when the browser = detects either high-risk insecure content on the page or problems with = the site's certificate. Muthu |-----Original Message----- |From: Olle E. Johansson [mailto:oej@edvina.net] |Sent: Wednesday, November 09, 2011 4:54 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: I=F1aki Baz Castillo; Avasarala, Ranjit; Ravindran Parthasarathi; = Cullen Jennings (fluffy); |rtcweb@ietf.org |Subject: Re: [rtcweb] Let's define the purpose of WebRTC | | |9 nov 2011 kl. 11:57 skrev Muthu Arul Mozhi Perumal (mperumal): | |> |The "application" is untrusted by nature, and we don't want |> |to make the end-user to decide whether to trust it or not. |> |Explained many times in this maillist. |> |> I am thinking we could burn SRTP into the browser such that the = decision of whether or not to use |SRTP vests solely with the browser. If a WebRTC browser is exchanging = media with another WebRTC |browser they always do SRTP/SRTCP. If either side isn't WebRTC = compliant they end up with RTP/RTCP. |This way we don't need to trust the JS, instead trust only the browser. = We can also interoperate with |legacy devices without taxing them. | |That opens up for downgrade attacks and put a lot of trust on the web = browser UI to show what happens |and on the users to understand what the web browser UA is trying to = tell them. | |/O From tim@phonefromhere.com Wed Nov 9 05:24:20 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA62C21F8B2A for ; Wed, 9 Nov 2011 05:24:20 -0800 (PST) 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.034, 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 sSQHN5AGFHT1 for ; Wed, 9 Nov 2011 05:24:16 -0800 (PST) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 71BCE21F8AFA for ; Wed, 9 Nov 2011 05:24:16 -0800 (PST) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 4C18F37A902; Wed, 9 Nov 2011 13:36:59 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: Date: Wed, 9 Nov 2011 13:24:08 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <81E7739C-2C54-465B-B79F-9DC99BFDEAE0@phonefromhere.com> References: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com>, <6CB98137-B2A4-488C-BF5C-D7D87B23C7EC@cisco.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Usecases for innovation. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 13:24:20 -0000 On 9 Nov 2011, at 01:05, Bernard Aboba wrote: > [BA] I'm trying to understand the "generic" issues presented by these = cases. =20 > =20 > For #1, is the generic issue the ability to add support for codecs not = supported natively (e.g. ability to add and use a codec added by a = plugin, for example)? =20 > =20 > For #2, is the generic issue the ability to add support for new types = of devices without standardized APIs, or is the issue being able to = represent the input/output of a non-standard device in terms of a media = stream?=20 Well, in some sense kinect is just a lossy video encoder. So you could = argue that they are the same problem. Both cases point out the fact that tying codecs/networking/negotiation = into one object and only presenting a (somewhat opaque) blob of SDP to represent them limits = what we can do=20 at the javascript end.=20 That may be a limitation we can live with, but at least we need to = acknowledge that it is a limitation. > =20 > =20 > =20 > =20 > Tim said: > =20 > " 1) H264 implementation in Javascript http://yfrog.com/nmng0z=20 > 2) Kinect as an input device for a virtual receptionist in a real = reception area > (Voxeo's as it happens). > =20 > Neither of these are production ready - or indeed necessarily a good = idea, > but the fact that neither (minor) innovation fits at all into our = brand new framework > should give us pause for thought. (but given the pell-mell dash to be = compatible > with last century's deskphones I don't imagine it will)." >=20 From mperumal@cisco.com Wed Nov 9 05:36:57 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7122C21F8B05 for ; Wed, 9 Nov 2011 05:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.642 X-Spam-Level: X-Spam-Status: No, score=-6.642 tagged_above=-999 required=5 tests=[AWL=-0.343, 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 0giHHI4fywo3 for ; Wed, 9 Nov 2011 05:36:53 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id C0EEA21F8AFD for ; Wed, 9 Nov 2011 05:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=6574; q=dns/txt; s=iport; t=1320845812; x=1322055412; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=2FYm84xJUblhnPKKKv0qTKwkUfK5pC0DEzb6XnQfiaE=; b=f44upTn3ywVTFtZ8SavY+rHVtLgwxJRbNOk23Sz7CEBLrLSBfQq+cHhY lZmZ3XsJzfaUyQgKRFs//p1ZVfYeqtgCFoUr3NoC6Nz8OtOKzNFVticlU Gck58ArbIu8GQ6vTeXSATyrMOwH2mI4I+/Xs6W0RPAaiTExHKijsmVZA6 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAAC+Buk5Io8UQ/2dsb2JhbABChH2VK450gQKBBYFyAQEBBBIBEA0ERQwEAgEIEQQBAQMCBgYXAQICAgEBRAkIAQEECwgIEwehDwGMWZJHgTCHOTNjBIgKkVmMPA X-IronPort-AV: E=Sophos;i="4.69,484,1315180800"; d="scan'208";a="2725878" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-4.cisco.com with ESMTP; 09 Nov 2011 13:36:50 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA9DanM4020246; Wed, 9 Nov 2011 13:36:49 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 19:06:49 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 9 Nov 2011 19:06:47 +0530 Message-ID: <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: Acye1vqSklfdvrV6R9+fUrMeoau8SgAC2p3Q References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D0 62974A48 45E4D8A343C6 53804920206D3B9C1@XMB-BGL-414.cisco.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 09 Nov 2011 13:36:49.0537 (UTC) FILETIME=[A20C9F10:01CC9EE4] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 13:36:57 -0000 SSB3YXMgdHJ5aW5nIHRvIGVudmlzaW9uIGEgc29sdXRpb24gZm9yIHRoZSAidW50cnVzdGVkIEpT IiBpc3N1ZSBhbmQgSSBkb24ndCBpbnRlbmQgdG8gYXJndWUgb24gd2hldGhlciBvciBub3Qgd2Ug c2hvdWxkIGFsbG93IGluc2VjdXJlIGNhbGxpbmcgdG8gbm9uLVdlYlJUQyBjbGllbnRzLg0KDQp8 VGhlICJicm93c2VyIiBjYW5ub3QgZGVjaWRlIHRoYXQuIFByb2JhYmx5IHlvdSBtZWFuIHRoZSB1 c2VyDQoNClllcywgYSBkZWNpc2lvbiBtYWRlIGJ5IHRoZSBicm93c2VyIHdpdGggdXNlciBjb25z ZW50IGlmIHJlcXVpcmVkLCB3aXRoIG5vIGFwcGxpY2F0aW9uIGludm9sdmVtZW50Lg0KDQp8QW5k IHdoYXQgeW91IHN0YXRlIGlzIHRoYXQsIGluIGNhc2UgdGhlIHBlZXIgZG9lcyBub3QgYW5ub3Vj ZSANCnxzdXBwb3J0IGZvciBTUlRQIHRoZW4gdGhlIGJyb3dzZXIgc2hvdWxkIGRvd25ncmFkZSBz ZWN1cml0eSANCnx0byBwbGFpbiBSVFAuDQoNCk5vLCBub3QgYmFzZWQgb24gdGhlIFNSVFAgY2Fw YWJpbGl0eSBhZHZlcnRpc2VkIGJ5IHRoZSBwZWVyLCByYXRoZXIgYmFzZWQgb24gd2hldGhlciB0 aGUgcGVlciBjbGFpbXMgaXQgaXMgV2ViUlRDIGNvbXBsaWFudCAodG8gbWFrZSBzdXJlIGNhbGxz IGIvdyBXZWJSVEMgY2xpZW50cyBhcmUgYWx3YXlzIHNlY3VyZSkuDQoNCnxUaGUgdXNlciAod2Vi IHZpc2l0b3IpIGhhcyBubyB3YXkgdG8ga25vdyB3aGV0aGVyIHRoZSBXZWJSVEMgDQp8YXBwbGlj YXRpb24gd2lsbCBjb250YWN0IGEgV2ViUlRDIGJyb3dzZXIgb3IgYW5vdGhlciBkZXZpY2UgDQp8 YXQgdGhlIG1lZGlhIHBsYW5lLg0KDQpXZSBjb3VsZCBhZGQgYSBTVFVOIGV4dGVuc2lvbiB0byBp bmRpY2F0ZSBjb21wbGlhbmNlIHRvIFdlYlJUQywgaW5jbHVkaW5nIHRoZSBzdXBwb3J0ZWQgdmVy c2lvbiBsZXZlbCBpZiB3ZSBldmVyIGNvbWUgdXAgd2l0aCBXZWJSVEMyLjAuDQoNCk11dGh1DQoN CnwtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KfEZyb206IEnDsWFraSBCYXogQ2FzdGlsbG8g W21haWx0bzppYmNAYWxpYXgubmV0XQ0KfFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDksIDIw MTEgNToyOCBQTQ0KfFRvOiBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKQ0KfENj OiBBdmFzYXJhbGEsIFJhbmppdDsgUmF2aW5kcmFuIFBhcnRoYXNhcmF0aGk7IEN1bGxlbiBKZW5u aW5ncyAoZmx1ZmZ5KTsgT2xsZSBFLiBKb2hhbnNzb247DQp8cnRjd2ViQGlldGYub3JnDQp8U3Vi amVjdDogUmU6IFtydGN3ZWJdIExldCdzIGRlZmluZSB0aGUgcHVycG9zZSBvZiBXZWJSVEMNCnwN CnwyMDExLzExLzkgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkgPG1wZXJ1bWFs QGNpc2NvLmNvbT46DQp8PiBJIGFtIHRoaW5raW5nIHdlIGNvdWxkIGJ1cm4gU1JUUCBpbnRvIHRo ZSBicm93c2VyIHN1Y2ggdGhhdCB0aGUgZGVjaXNpb24gb2Ygd2hldGhlciBvciBub3QgdG8gdXNl DQp8U1JUUCB2ZXN0cyBzb2xlbHkgd2l0aCB0aGUgYnJvd3Nlci4NCnwNCnxUaGUgImJyb3dzZXIi IGNhbm5vdCBkZWNpZGUgdGhhdC4gUHJvYmFibHkgeW91IG1lYW4gdGhlIHVzZXIsIHRoYXQNCnxw ZXJzb24gdGhhdCBpbiA5OS45OTklIG9mIGNhc2VzIGRvZXMgbm90IGtub3cgd2hhdCAiZW5jcnlw dGlvbiIgb3INCnwiU1JUUCIgaXMsIGFuZCBpbiA4NSUgb2YgY2FzZXMgZG9lcyBub3QgbWF0dGVy IGFib3V0IHNlY3VyaXR5Lg0KfA0KfA0KfD4gSWYgYSBXZWJSVEMgYnJvd3NlciBpcyBleGNoYW5n aW5nIG1lZGlhIHdpdGggYW5vdGhlciBXZWJSVEMgYnJvd3NlciB0aGV5IGFsd2F5cyBkbyBTUlRQ L1NSVENQLg0KfA0KfFRoZSBicm93c2VyIGhhcyBOTyB3YXkgdG8gZGV0ZXJtaW5lIHdoZXRoZXIg aXQncyBleGNoYW5naW5nIG1lZGlhIHdpdGgNCnxhbm90aGVyIGJyb3dzZXIgb3Igbm90LiBBbmQg d2hhdCB5b3Ugc3RhdGUgaXMgdGhhdCwgaW4gY2FzZSB0aGUgcGVlcg0KfGRvZXMgbm90IGFubm91 Y2Ugc3VwcG9ydCBmb3IgU1JUUCB0aGVuIHRoZSBicm93c2VyIHNob3VsZCBkb3duZ3JhZGUNCnxz ZWN1cml0eSB0byBwbGFpbiBSVFAuIFRoZSB1c2VyICh3ZWIgdmlzaXRvcikgaGFzIG5vIHdheSB0 byBrbm93DQp8d2hldGhlciB0aGUgV2ViUlRDIGFwcGxpY2F0aW9uIHdpbGwgY29udGFjdCBhIFdl YlJUQyBicm93c2VyIG9yDQp8YW5vdGhlciBkZXZpY2UgYXQgdGhlIG1lZGlhIHBsYW5lLg0KfA0K fA0KfD4gSWYgZWl0aGVyIHNpZGUgaXNuJ3QgV2ViUlRDIGNvbXBsaWFudCB0aGV5IGVuZCB1cCB3 aXRoIFJUUC9SVENQLg0KfA0KfFNvIG5vIHNlY3VyaXR5LiBCYWQuDQp8DQp8DQp8PiBUaGlzIHdh eSB3ZSBkb24ndCBuZWVkIHRvIHRydXN0IHRoZSBKUywgaW5zdGVhZCB0cnVzdCBvbmx5IHRoZSBi cm93c2VyLg0KfA0KfFlvdSBtZWFuIHRoZSB1c2VyLg0KfA0KfA0KfD4gV2UgY2FuIGFsc28gaW50 ZXJvcGVyYXRlIHdpdGggbGVnYWN5IGRldmljZXMgd2l0aG91dCB0YXhpbmcgdGhlbS4NCnwNCnxT b3JyeSwgYnV0IFdlYlJUQyBpcyBhYm91dCAicmVhbHRpbWUgY29tbXVuaWNhdGlvbnMgZm9yIHRo ZSBXZWIiLA0KfHJhdGhlciB0aGFuICJTSVAgYnVzaW5lc3MgY29taW5nIHRvIHRoZSBXZWIiLiBT SVAgdXNlcyBSVFAsIGluY2x1ZGluZw0KfFJGQydzIGFib3V0IFNSVFAuIElmIHlvdSB3YW50IFNJ UCBpbnRlcm9wZXJhYmlsaXR5IHdpdGggYSBXZWJSVEMNCnxkZXZpY2UsIHRoZW4gbWFrZSB5b3Vy IHdvcmsgYXMgdmVuZG9yIGFuZCBhZGQgc2VjdXJpdHkgdG8geW91ciBTSVANCnxkZXZpY2VzIHJh dGhlciB0aGFuIGFza2luZyBuby1zZWN1cml0eSBmb3IgV2ViUlRDLg0KfA0KfFBsZWFzZSwgdGFr ZSBhIGxvb2sgdG8gWE1QUC9KaW5nbGUgISEgIFRoZXkgaW1wbGVtZW50IFNSVFAgYW5kIElDRQ0K fGZyb20gdGhlIGJlZ2lubmluZyEhICpEbyogeW91ciBob21ld29ya3MgYXMgU0lQIHZlbmRvci4N CnwNCnxUaGlzIGlzIGEgcHJvYmxlbSBvZiBTSVAgdmVuZG9ycy90ZWxjb3MsIHRoaXMgaXMgbm90 IGEgcHJvYmxlbSBvZg0KfFdlYlJUQy4gWW91IHNob3VsZCBpbXBsZW1lbnQgU1JUUCBpbiB5b3Vy IGxlZ2FjeSBhbmQgbm9uLXNlY3VyZSBTSVANCnxkZXZpY2VzIGFuZCBtYWtlIHRoZW0gdmFsaWQg Zm9yIGNvbW11bmljYXRpb24gYWNyb3NzIHRoZSBvcGVuIEludGVybmV0DQp8aW4gd2hpY2ggc2Vj dXJpdHkgaXMgYSBNVVNUIChJbnRlcm5ldCBpcyBub3QgYSB0ZWxjbyB3YWxsZW4gZ2FyZGVuKS4N CnxUaGUgbWFpbiBwdXJwb3NlIG9mIFdlYlJUQyBpcyBub3QgdG8gaW50ZXJvcGVyYXRlIHdpdGgg aW5zZWN1cmUNCnxkZXZpY2VzLCBkbyB3ZSBhbGwgYWdyZWUgaGVyZT8NCnwNCnxJIGRvbid0IHN1 cHBvcnQgdGhpcyBraW5kIG9mIGFyZ3VtZW50cyBpbiBmYXZvdXIgb2Ygbm9uIG1hbmRhdGluZyBT UlRQLg0KfA0KfA0KfFBTOiBTb21lYm9keSBjb3VsZCBhcmd1ZSB0aGF0LCBpbiB0aGUgV2ViLCBu ZWl0aGVyIEhUVFBTIG9yDQp8V2ViU29ja2V0K1RMUyBpcyBhIE1VU1QgYnV0IG9wdGlvbmFsIHBl ciB3ZWJzaXRlLCBzbyB3aHkgdG8gbWFrZSBTUlRQDQp8bWFuZGF0b3J5PyBUaGF0IHdvdWxkIGJl IGEgdmVyeSBkaWZmZXJlbnQgYXJndW1lbnQgSSBjb3VsZCB1bmRlcnN0YW5kDQp8YW5kIGRpc2N1 c3MgYWJvdXQuIEJ1dCBmb3JjaW5nIGEgKm5ldyogc3BlY2lmaWNhdGlvbiB0byBiZSBpbnNlY3Vy ZQ0KfGp1c3QgdG8gYWxsb3cgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIG5vbi1zZWN1cmUgZGV2aWNl cyBpcyBub3Qgd2VsY29tZS4NCnxXZWJSVEMgaXMgZm9yIHRoZSBXZWIsIG5vdCBmb3IgU0lQLg0K fA0KfFBTOiBUaGlzIGtpbmQgb2YgZGlzY3Vzc2lvbnMgZ2l2ZSB0aGUgcmVhc29uIHRvIHJlY2Vu dCBjb21tZW50cyBsaWtlDQp8dGhlIG9uZSBmcm9tIFRpbSBQYXJ0b24uIFRoaXMgV0cgaXMgdG9v IG11Y2ggZm9jdXNlZCBvbiBTSVANCnx2ZW5kb3JzL3RlbGNvcyB3aGljaCBhcmUgbm90IGZ1bGx5 IGludGVyZXN0ZWQgaW4gUlRDIGNvbW11bmljYXRpb25zIGluDQp8cHVyZSBXZWIvSW50ZXJuZXQg ZW52aXJvbm1lbnRzLCBidXQgaW4gbWFraW5nIHRoZSB3ZWIgYnJvd3NlcnMgYSBuZXcNCnxTSVAg cGhvbmUgZm9yIGludGVncmF0dGluZyB0aGVtIGludG8gdGhlaXIgdGVsY28gYnVzaW5lc3MuIEJh ZC4NCnwNCnxQUzogSSdtIGFsc28gaW50ZXJlc3RlZCBpbiBpbnRlcm9wZXJhYmlsaXR5IGJldHdl ZW4gV2ViUlRDIGJyb3dzZXJzDQp8YW5kIFNJUCBkZXZpY2VzIChhcyBtdWNoIGFzIHlvdSksIGJ1 dCBJIGFzc3VtZSB0aGF0IGp1c3QgYSBmZXcgU0lQDQp8ZGV2aWNlcyBNVVNUIGJlIGFibGUgdG8g aW50ZXJvcCB3aXRoIFdlYlJUQyAodGhvc2UgdGhhdCBoYXZlIGRvbmUNCnx0aGVpciBob21ld29y a3MgYnkgaW1wbGVtZW50aW5nIFNSVFAgYW5kIElDRSkuDQp8DQp8DQp8QW5kIHRob3NlIGRpc2N1 c3Npb25zIGFyZSBiZWNvbWluZyB2ZXJ5IGJvcmluZy4gVGhlcmUgYXJlIG5vdCBuZXcNCnxhcmd1 bWVudHMgYXQgYWxsLiBJdCBzZWVtcyB0aGFuIHdpdGhpbiBuZXh0IHdlZWtzL21vbnRocywgU0lQ DQp8dGVsY29zL3ZlbmRvcnMgd2lsbCBjb250aW51ZSByZXF1ZXN0aW5nIG5vdCBtYW5kYXRvcnkg U1JUUCBqdXN0IHRvDQp8ZmFjaWxpdGF0ZSB0aGVpciBidXNpbmVzcyB3aXRob3V0IGludmVzdGlu ZyBpbiBpbXByb3ZpbmcgdGhlaXINCnxub24tc2VjdXJlIGRldmljZXMuIFRoaXMgaXMgYSBuby1n by4NCnwNCnwNCnxSZWdhcmRzLg0KfA0KfA0KfC0tDQp8ScOxYWtpIEJheiBDYXN0aWxsbw0KfDxp YmNAYWxpYXgubmV0Pg0K From neils@vipadia.com Wed Nov 9 05:42:49 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCB521F8B79 for ; Wed, 9 Nov 2011 05:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.050, 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 qFw5WbHVNMUw for ; Wed, 9 Nov 2011 05:42:49 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8CC21F8B76 for ; Wed, 9 Nov 2011 05:42:49 -0800 (PST) Received: by iaeo4 with SMTP id o4so2254496iae.31 for ; Wed, 09 Nov 2011 05:42:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.20.201 with SMTP id g9mr571882ibb.57.1320846168584; Wed, 09 Nov 2011 05:42:48 -0800 (PST) Sender: neils@vipadia.com Received: by 10.231.207.10 with HTTP; Wed, 9 Nov 2011 05:42:48 -0800 (PST) In-Reply-To: References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3B9C1@XMB-BGL-414.cisco.com> Date: Wed, 9 Nov 2011 13:42:48 +0000 X-Google-Sender-Auth: qBvHkwX_DPJrCA4MAXoF8jSD-o8 Message-ID: From: Neil Stratford To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=0015175ce0d8ae71d504b14d769f Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 13:42:49 -0000 --0015175ce0d8ae71d504b14d769f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 9, 2011 at 1:04 PM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > If you want to be in the world of telecommunications you carry a legacy > baggage. > Only at the point you want to interop with that legacy world. Skype did a pretty good job of avoiding the legacy and changing users expectations of telecommunications. Your proposal to provide a gateway is just one way of dealing with the > legacy baggage. It does however carry the downside that you need a player > to provide such gateways in support of interworking to the legacy.**** > > ** ** > > Suppose I make an emergency call to a PSAP. The legacy baggage here is > that unless someone volunteers to provide all those PSAPs worldwide with > new kit, the majority will remain connected to the PSTN (i.e. not even > SIP). I need a guarantee that someone out there will provide a gateway. > Which player provides that in your business model. > If there is a market for interop (which there clearly is) then multiple vendors will no doubt offer gateways. I'm just concerned that we are talking about imposing legacy requirements on the core API, when WebRTC seems an ideal opportunity to break away from that legacy. Neil --0015175ce0d8ae71d504b14d769f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Nov 9, 2011 at 1:04 PM, DRAGE, Keith (Keith) <= keith.drage@alcatel-lucen= t.com> wrote:

If you want to be = in the world of telecommunications you carry a legacy baggage.


Only at the point you want to interop wit= h that legacy world. Skype did a pretty good job of avoiding the legacy and= changing users expectations of telecommunications.

Your proposal to p= rovide a gateway is just one way of dealing with the legacy baggage. It does however carry the downs= ide that you need a player to provide such gateways in support of interworking = to the legacy.

=A0<= /span>

Suppose I make an = emergency call to a PSAP. The legacy baggage here is that unless someone volunteers to provide = all those PSAPs worldwide with new kit, the majority will remain connected to t= he PSTN (i.e. not even SIP). I need a guarantee that someone out there will provide a gateway. Which player provides that in your business model.


If there is a mark= et for interop (which there clearly is) then multiple vendors will no doubt= offer gateways. I'm just concerned that we are talking about imposing = legacy requirements on the core API, when WebRTC seems an ideal opportunity= to break away from that legacy.

Neil
--0015175ce0d8ae71d504b14d769f-- From ibc@aliax.net Wed Nov 9 05:44:23 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D61F21F8B7E for ; Wed, 9 Nov 2011 05:44:23 -0800 (PST) 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 gbvG-A6Qwsuw for ; Wed, 9 Nov 2011 05:44:22 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C22D21F8B79 for ; Wed, 9 Nov 2011 05:44:22 -0800 (PST) Received: by vws5 with SMTP id 5so1686091vws.31 for ; Wed, 09 Nov 2011 05:44:22 -0800 (PST) Received: by 10.52.113.227 with SMTP id jb3mr4749252vdb.15.1320846262120; Wed, 09 Nov 2011 05:44:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Wed, 9 Nov 2011 05:44:01 -0800 (PST) In-Reply-To: <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 9 Nov 2011 14:44:01 +0100 Message-ID: To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 13:44:23 -0000 2011/11/9 Muthu Arul Mozhi Perumal (mperumal) : > |And what you state is that, in case the peer does not annouce > |support for SRTP then the browser should downgrade security > |to plain RTP. > > No, not based on the SRTP capability advertised by the peer, rather based= on whether the peer claims it is WebRTC compliant (to make sure calls b/w = WebRTC clients are always secure). > > |The user (web visitor) has no way to know whether the WebRTC > |application will contact a WebRTC browser or another device > |at the media plane. > > We could add a STUN extension to indicate compliance to WebRTC, including= the supported version level if we ever come up with WebRTC2.0. And what is the advantage? you still say exactly the same: a WebRTC client "MUST" allow plain RTP if the peer is not a WebRTC client. Why is that an argument in favour of non mandating SRTP? If I'm in a shared WiFi network and receive a call from a non-WebRTC client not supporting SRTP, my neighbors can intercept it. What does such "STUN extension" provides here? just nothing. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Wed Nov 9 05:48:12 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D4621F8B7E for ; Wed, 9 Nov 2011 05:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCC3jgWyhQ00 for ; Wed, 9 Nov 2011 05:48:11 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 78A7E21F8B76 for ; Wed, 9 Nov 2011 05:48:11 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA9Dmjam020470; Wed, 9 Nov 2011 08:48:45 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 08:47:41 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 19:17:49 +0530 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.0339.001; Wed, 9 Nov 2011 19:17:48 +0530 From: "Ravindran, Parthasarathi" To: Neil Stratford , "DRAGE, Keith (Keith)" Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AQHMm7/XxS9yQix74UmCewMPtvNQWZWe2WiAgABcZwCAAFnsgIAA1PQAgACv/gCAAAVogIAAGdwAgAHTzND//7JMAIAAEPMAgAESTSCAAAmSMIAALVkAgAAFPXD//9h2gIAAFyMAgAARBYCAAA9VgIAAA0KAgAAKlgCAAFxwIA== Date: Wed, 9 Nov 2011 13:47:49 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0134A541@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3B9C1@XMB-BGL-414.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.164] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0134A541inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Nov 2011 13:47:49.0224 (UTC) FILETIME=[2B40DE80:01CC9EE6] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 13:48:12 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0134A541inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Neil, Please read inline Thanks Partha From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Neil Stratford Sent: Wednesday, November 09, 2011 7:13 PM To: DRAGE, Keith (Keith) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of WebRTC On Wed, Nov 9, 2011 at 1:04 PM, DRAGE, Keith (Keith) > wrote: If you want to be in the world of telecommunications you carry a legacy bag= gage. Only at the point you want to interop with that legacy world. Skype did a p= retty good job of avoiding the legacy and changing users expectations of te= lecommunications. AFAIK, Skype still interop with legacy telephone devices using SIP= Your proposal to provide a gateway is just one way of dealing with the lega= cy baggage. It does however carry the downside that you need a player to pr= ovide such gateways in support of interworking to the legacy. Suppose I make an emergency call to a PSAP. The legacy baggage here is that= unless someone volunteers to provide all those PSAPs worldwide with new ki= t, the majority will remain connected to the PSTN (i.e. not even SIP). I ne= ed a guarantee that someone out there will provide a gateway. Which player = provides that in your business model. If there is a market for interop (which there clearly is) then multiple ven= dors will no doubt offer gateways. I'm just concerned that we are talking a= bout imposing legacy requirements on the core API, when WebRTC seems an ide= al opportunity to break away from that legacy. In case core API is not defined for it, I agree with Keith that R= TCWeb has to explain or provide the guideline for the server/gateway role a= nd IMO, it is discussed as federation till now in RTCWeb. Neil --_000_387F9047F55E8C42850AD6B3A7A03C6C0134A541inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Neil,

 

Please read inline

 

Thanks

Partha

 

From: rtcweb-b= ounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Neil Stratford
Sent: Wednesday, November 09, 2011 7:13 PM
To: DRAGE, Keith (Keith)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Let's define the purpose of WebRTC<= /span>

 

On Wed, Nov 9, 2011 at 1:04 PM, DRAGE, Keith (Keith)= <keith.drage@alcatel-= lucent.com> wrote:

If you want to be in the worl= d of telecommunications you carry a legacy baggage.

 

Only at the point you want to interop with that lega= cy world. Skype did a pretty good job of avoiding the legacy and changing u= sers expectations of telecommunications.

<partha> AFAIK, Skype still interop with legacy teleph= one devices using SIP </partha>

 

Your proposal to provide a ga= teway is just one way of dealing with the legacy baggage. It does however carry the downside that you need a player to provide such gat= eways in support of interworking to the legacy.=

 

Suppose I make an emergency c= all to a PSAP. The legacy baggage here is that unless someone volunteers to provide all those PSAPs worldwide with new kit, the majority= will remain connected to the PSTN (i.e. not even SIP). I need a guarantee = that someone out there will provide a gateway. Which player provides that i= n your business model.

 

If there is a market for interop (which there clearl= y is) then multiple vendors will no doubt offer gateways. I'm just concerne= d that we are talking about imposing legacy requirements on the core API, w= hen WebRTC seems an ideal opportunity to break away from that legacy.

<partha>  In case core API is not defined for it,= I agree with Keith that RTCWeb has to explain or provide the guideline for= the server/gateway role and IMO, it is discussed as federation till now in RTCWeb.  </partha>

 

Neil

--_000_387F9047F55E8C42850AD6B3A7A03C6C0134A541inbamail01sonus_-- From tim@phonefromhere.com Wed Nov 9 05:55:00 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10C421F8C58 for ; Wed, 9 Nov 2011 05:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 dJ0ZkM3wsEiW for ; Wed, 9 Nov 2011 05:54:56 -0800 (PST) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 8D43B21F8C56 for ; Wed, 9 Nov 2011 05:54:56 -0800 (PST) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 7B7F537A91B; Wed, 9 Nov 2011 14:07:39 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: Date: Wed, 9 Nov 2011 13:54:50 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D0 62974A4845E4D8A343C653804920206D3B9C1@XMB-BGL-414.cisco.com> To: Neil Stratford , "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 13:55:00 -0000 On 9 Nov 2011, at 13:42, Neil Stratford wrote: > On Wed, Nov 9, 2011 at 1:04 PM, DRAGE, Keith (Keith) = wrote: > If you want to be in the world of telecommunications you carry a = legacy baggage. >=20 >=20 > Only at the point you want to interop with that legacy world. Skype = did a pretty good job of avoiding the legacy and changing users = expectations of telecommunications. ViVOX is carrying more wideband minutes than the whole = 'telecommunications' world. g722 has been around so long the patents have expired, but I still don't see the legacy world deploying it. >=20 >=20 > Your proposal to provide a gateway is just one way of dealing with the = legacy baggage. It does however carry the downside that you need a = player to provide such gateways in support of interworking to the = legacy. >=20 > =20 >=20 > Suppose I make an emergency call to a PSAP. The legacy baggage here is = that unless someone volunteers to provide all those PSAPs worldwide with = new kit, the majority will remain connected to the PSTN (i.e. not even = SIP). I need a guarantee that someone out there will provide a gateway. = Which player provides that in your business model. >=20 >=20 > If there is a market for interop (which there clearly is) then = multiple vendors will no doubt offer gateways. I'm just concerned that = we are talking about imposing legacy requirements on the core API, when = WebRTC seems an ideal opportunity to break away from that legacy. We need to be _very_ careful about supporting emergency calls - what is = an emergency in Hobbo hotel or the-simuls-on-line isn't necessarily a case for deployment of real Blue-light vehicles.=20 (A classic game play in The Sims is to burn your house down and call the = (sims) fire brigade - some cool stuff happens - or so Smallest Daughter tells me). >=20 > Neil > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Wed Nov 9 06:00:02 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398CF21F8C6A for ; Wed, 9 Nov 2011 06:00:02 -0800 (PST) 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 YRJ3nba4GZUa for ; Wed, 9 Nov 2011 06:00:01 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8FF21F8C5E for ; Wed, 9 Nov 2011 06:00:01 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so1603703vcb.31 for ; Wed, 09 Nov 2011 06:00:01 -0800 (PST) Received: by 10.52.117.65 with SMTP id kc1mr4750254vdb.66.1320847201058; Wed, 09 Nov 2011 06:00:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Wed, 9 Nov 2011 05:59:40 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0134A541@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3B9C1@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A541@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 9 Nov 2011 14:59:40 +0100 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 14:00:02 -0000 Hi Partha, just as a suggestion it would be great if you could make correct usage of your mail client and configure it to properly generate mail responses (by adding ">" in front of the text you are replying) so you could stop adding to point your own text. Writing mails in plain text (without HTML and colorized text) is also desirable as stated in Netiquette and make easier reading your mails to others. More inline: 2011/11/9 Ravindran, Parthasarathi : > Only at the point you want to interop with that legacy world. Skype did a > pretty good job of avoiding the legacy and changing users expectations of > telecommunications. > > AFAIK, Skype still interop with legacy telephone devices using S= IP > Yes, but they use their own gateways and don't bothers their end users by making Skype software to allow non secure communications. The work is done in their gateways. In the same way, if you want WebRTC to interoperate at media plane with your legacy-non-secure-at-all SIP/RTP infrastructure, then build a gateway or whatever you need. This is not the task of WebRTC nor this WG. > If there is a market for interop (which there clearly is) then multiple > vendors will no doubt offer gateways. I'm just concerned that we are talk= ing > about imposing legacy requirements on the core API, when WebRTC seems an > ideal opportunity to break away from that legacy. > > =C2=A0In case core API is not defined for it, I agree with Keith= that > RTCWeb has to explain or provide the guideline for the server/gateway rol= e > and IMO, it is discussed as federation till now in RTCWeb. =C2=A0 You should forget about "federation in WebRTC". That's a no-go. If a WebRTC scenario wants to interoperate with other WebRTC scenario or with a SIP/H323/Jingle network, they both should agree on the terms of the interoperation between their systems. The only WebRTC can state about that is an "empty" text like "they can use SIP/XMPP or whatever protocol/mechanism they decide in order to interoperate" which is the very same as saying "do whatever you want". Regards. --=20 I=C3=B1aki Baz Castillo From ekr@rtfm.com Wed Nov 9 06:10:31 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8687A21F8C6B for ; Wed, 9 Nov 2011 06:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.94 X-Spam-Level: X-Spam-Status: No, score=-102.94 tagged_above=-999 required=5 tests=[AWL=0.038, 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 zFnfTkYmKoiA for ; Wed, 9 Nov 2011 06:10:31 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB1D21F8B9D for ; Wed, 9 Nov 2011 06:10:24 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so1615069vcb.31 for ; Wed, 09 Nov 2011 06:10:24 -0800 (PST) Received: by 10.52.29.9 with SMTP id f9mr4898664vdh.30.1320847824060; Wed, 09 Nov 2011 06:10:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Wed, 9 Nov 2011 06:09:43 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01349FE6@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <4EB9ACF5.80805@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FE6@inba-mail01.sonusnet.com> From: Eric Rescorla Date: Wed, 9 Nov 2011 06:09:43 -0800 Message-ID: To: Ravindran Parthasarathi Content-Type: text/plain; charset=ISO-8859-1 Cc: "<,rtcweb@ietf.org>," Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of 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: Wed, 09 Nov 2011 14:10:31 -0000 On Tue, Nov 8, 2011 at 6:50 PM, Ravindran Parthasarathi wrote: > Cameron, > > > > I guess that we are in the same w.r.t IETF privacy policy and it is main > reason, I take back my comment #2. But, Please look into comment #1 for > Enterprise WebRTC application wherein SRTP is not required to be mandated. > Partha, I don't understand what resource you are conserving here by avoiding multiple encryption. Even if we stipulate that the enterprise network is secure (which as Cameron has suggested, is often not the case even when people believe it is), the actual cost to encrypt the data on the endpoints is quite low, especially when compared to the added complexity cost of trying to make the (extremely difficult) determination of whether whatever network encryption is in place is sufficient to protect your call. Better to just encrypt all the time. -Ekr From magnus.westerlund@ericsson.com Wed Nov 9 06:17:53 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6CA21F8C44 for ; Wed, 9 Nov 2011 06:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 is58ZVFjrl8d for ; Wed, 9 Nov 2011 06:17:53 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id EA99A21F8C43 for ; Wed, 9 Nov 2011 06:17:52 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-ea-4eba8b8faecd Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 88.58.09514.F8B8ABE4; Wed, 9 Nov 2011 15:17:52 +0100 (CET) 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.137.0; Wed, 9 Nov 2011 15:17:51 +0100 Message-ID: <4EBA8B8A.3020906@ericsson.com> Date: Wed, 9 Nov 2011 15:17:46 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Wolfgang Beck References: <32CC659B-8EBF-4C16-8605-5D823DA22A8D@acmepacket.com> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Layers in draft-jesup-rtcweb-data-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 14:17:53 -0000 On 2011-11-04 15:21, Wolfgang Beck wrote: > On Wed, Oct 26, 2011 at 10:28 PM, Hadriel Kaplan wrote: > .. >> >> +------+ +------+ >> |WEBAPP| |WEBAPP| >> +------+------+------+ +------+------+------+ >> | DTLS | Audio| Video| | SCTP | Audio| Video| >> +---------------------------+ +---------------------------+ >> | STUN | SCTP |S/RTP |S/RTP | | STUN | DTLS |S/RTP |S/RTP | >> +---------------------------+ +---------------------------+ >> | Mux/Demux | | Mux/Demux | >> +---------------------------+ +---------------------------+ >> | UDP | | UDP | >> +---------------------------+ +---------------------------+ >> > Has somebody tried to map the relevant combinations into SDP? We can > exclude Audio, Video[/DTLS]/SCTP, right? > > Do we have to express the contents of the generic data in a similar > way we are describing the contents -- codecs and parameters -- for RTP > streams? I at least expect that something will be defined similar to COMEDIA RFC 4145 or RFC 4572 for TLS. 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 xavier.marjou@gmail.com Wed Nov 9 06:31:05 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE71021F8AAF for ; Wed, 9 Nov 2011 06:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.717, 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 de+Y0z+3HShF for ; Wed, 9 Nov 2011 06:31:05 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCBD21F84D4 for ; Wed, 9 Nov 2011 06:31:05 -0800 (PST) Received: by yenl7 with SMTP id l7so907639yen.31 for ; Wed, 09 Nov 2011 06:31:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=xgWVbfPnqItLT7NvUoNUnBzMlHWlVtJ/qmKxEwT7KXc=; b=NCUsBsEivlcOrrXZ4scUn8ObH0caoH29y5rVf2nifNdv3t2DGWDby6fvnJafTx6vKW xM6+6xIu7h+Yl/63h+2jRnvoEC5zx5+n+d+2dmTPVvS3PPsI7ebHX9TNvX9Ks8/ivX53 loB0TmWPMoINZRgA/7CXnGG4DM+FTduouDSRU= MIME-Version: 1.0 Received: by 10.101.47.6 with SMTP id z6mr1392844anj.66.1320849064820; Wed, 09 Nov 2011 06:31:04 -0800 (PST) Sender: xavier.marjou@gmail.com Received: by 10.236.157.73 with HTTP; Wed, 9 Nov 2011 06:31:04 -0800 (PST) Date: Wed, 9 Nov 2011 15:31:04 +0100 X-Google-Sender-Auth: 0CA99Fw4IzzJtm4quf6_TpEwW90 Message-ID: From: Xavier Marjou To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=001636ed78004f812104b14e23b9 Subject: [rtcweb] Clarification question about rtcweb communications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 14:31:05 -0000 --001636ed78004f812104b14e23b9 Content-Type: text/plain; charset=ISO-8859-1 Hi, In the introduction of draft-ietf-rtcweb-rtp-usage-01, one example of application is "on-demand multimedia streaming". The draft also recommends tools like RFC4588. Looking at the charter and at the draft-ietf-rtcweb-use-cases-and-requirements-06 (sections 4.2 and 4.3), there is no explicit use-case about it. In other-words, there is no use-case like a user/browser downloads a video file from another browser or server. The words "real-time communication" and "communication" look fuzzy, as it is not clear if mono-directional streaming is included or not in the scope of rtcweb communications. So my question is : is the "on-demand multimedia streaming" communication use-case in the scope of the WG or not? Thanks, Xavier --001636ed78004f812104b14e23b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

In the introduction of draft-ietf-rtcweb-rtp-usage-0= 1, one example of application is "on-demand multimedia streaming"= . The draft also recommends tools like RFC4588.

Looking at the charter and at the draft-ietf-rtcweb-use-cases-and-requireme= nts-06 (sections 4.2 and 4.3), there is no explicit use-case about it. In o= ther-words, there is no use-case like a user/browser downloads a video file= from another browser or server.
The words "real-time communication" and "communication&= quot; look fuzzy, as it is not clear if mono-directional streaming is inclu= ded or not in the scope of rtcweb communications.

So my question is : is the=A0"on-demand multimedia streaming"= ; communication=A0use-case in the scope of the WG or not?=A0

=
Thanks,
Xavier

--001636ed78004f812104b14e23b9-- From mperumal@cisco.com Wed Nov 9 06:32:33 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED76B21F8AA8 for ; Wed, 9 Nov 2011 06:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.574 X-Spam-Level: X-Spam-Status: No, score=-8.574 tagged_above=-999 required=5 tests=[AWL=1.725, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 M5EqE-5Q8RAS for ; Wed, 9 Nov 2011 06:32:29 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0979621F8A7D for ; Wed, 9 Nov 2011 06:32:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3442; q=dns/txt; s=iport; t=1320849143; x=1322058743; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=g9YWVem0NPX1qbXiUVu0h0KwlMk8kenje1vALIw2gXA=; b=U+/37QJADb9mx9jFSpHrmeRHtV8O+FNbsyyBwYmAGReJL3PZvqlhCz6q L6TW8q4TAMRMdvO7sF31Naey+eEKTejNvG+UX+23WgpD1XW/pTMkbY0QX c8lCNpQEIDEEYzBcvLoEcU+gOjjd99HOPbsYwHCchBnUBsm8oFTj1fGA3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAAImOuk5Io8US/2dsb2JhbABChH2VK450gQKBBYFyAQEBBBIBEA0ERQwEAgEIEQQBAQMCBgYXAQICAgEBRAkIAQEECwgIGqEKAYxZkkiBMIc5M2MEiAqRWYw8 X-IronPort-AV: E=Sophos;i="4.69,484,1315180800"; d="scan'208";a="121182847" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 09 Nov 2011 14:32:19 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA9EWIK0027042; Wed, 9 Nov 2011 14:32:18 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 20:02:18 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 9 Nov 2011 20:02:16 +0530 Message-ID: <1D062974A4845E4D8A343C653804920206D3BA71@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: Acye5bP4GkdBFI8bRdem3spaqSgpGQAAB0Mw References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 09 Nov 2011 14:32:18.0517 (UTC) FILETIME=[6246A850:01CC9EEC] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 14:32:33 -0000 fEFuZCB3aGF0IGlzIHRoZSBhZHZhbnRhZ2U/IHlvdSBzdGlsbCBzYXkgZXhhY3RseSB0aGUgDQp8 c2FtZTogYSBXZWJSVEMgY2xpZW50ICJNVVNUIiBhbGxvdyBwbGFpbiBSVFAgaWYgdGhlIA0KfHBl ZXIgaXMgbm90IGEgV2ViUlRDIGNsaWVudC4gV2h5IGlzIHRoYXQgYW4gYXJndW1lbnQgDQp8aW4g ZmF2b3VyIG9mIG5vbiBtYW5kYXRpbmcgU1JUUD8NCg0KV2Ugc2VlbSB0byBoYXZlIGEgZ3JvdXAg b2YgcGVvcGxlIGNvbmNlcm5lZCBhYm91dCB0aGUgY29zdCBhc3NvY2lhdGVkIHdpdGggaGF2aW5n IHRvIHVwZ3JhZGUvcmVwbGFjZS9zdXBwbGVtZW50IHRoZWlyIG5vbi1TUlRQIGNhcGFibGUgZ2Vh cnMgc3VjaCBhcyBQU1ROIGdhdGV3YXlzLCBhbmQgSSB3YXMgc3ltcGF0aGV0aWMgdG93YXJkcyB0 aGVtIC06KSANCg0KfElmIEknbSBpbiBhIHNoYXJlZCBXaUZpIG5ldHdvcmsgYW5kIHJlY2VpdmUg YSBjYWxsIGZyb20gDQp8YSBub24tV2ViUlRDIGNsaWVudCBub3Qgc3VwcG9ydGluZyBTUlRQLCBt eSBuZWlnaGJvcnMgY2FuIA0KfGludGVyY2VwdCBpdC4NCg0KSWYgdGhlIHNoYXJlZCBXaUZpIG5l dHdvcmsgaGFzbid0IGVtcGxveWVkIFdpRmkgZW5jcnlwdGlvbiwgdGhlbiB5b3Ugd291bGQgcHJv YmFibHkgYmUgbW9yZSBjb25jZXJuZWQgd2l0aCB5b3VyIG5laWdoYm9ycyBpbnRlcmNlcHRpbmcg YWxsIG9mIHlvdXIgdHJhZmZpYyB0aGFuIGp1c3QgUlRQIC06KQ0KDQp8V2hhdCBkb2VzIHN1Y2gg IlNUVU4gZXh0ZW5zaW9uIiBwcm92aWRlcyBoZXJlPw0KDQpJdCB3b3VsZCB0ZWxsIHRoZSBicm93 c2VyIHRoYXQgdGhlIHBlZXIgKGJyb3dzZXIpIGNsYWltcyBXZWJSVEMgY29tcGxpYW5jZSBhbmQg c28gc2hvdWxkbid0IGFsbG93IGluc2VjdXJlIGNhbGxpbmcgKHRoZSBTVFVOIGV4dGVuc2lvbiBp cyBhZGRlZCBieSB0aGUgYnJvd3NlciBhbmQgdGhlIGFwcGxpY2F0aW9ucyBoYXMgbm8gY29udHJv bCBvdmVyIGl0KS4NCg0KTXV0aHUNCg0KfC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQp8RnJv bTogScOxYWtpIEJheiBDYXN0aWxsbyBbbWFpbHRvOmliY0BhbGlheC5uZXRdDQp8U2VudDogV2Vk bmVzZGF5LCBOb3ZlbWJlciAwOSwgMjAxMSA3OjE0IFBNDQp8VG86IE11dGh1IEFydWwgTW96aGkg UGVydW1hbCAobXBlcnVtYWwpDQp8Q2M6IEF2YXNhcmFsYSwgUmFuaml0OyBSYXZpbmRyYW4gUGFy dGhhc2FyYXRoaTsgQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkpOyBPbGxlIEUuIEpvaGFuc3NvbjsN CnxydGN3ZWJAaWV0Zi5vcmcNCnxTdWJqZWN0OiBSZTogW3J0Y3dlYl0gTGV0J3MgZGVmaW5lIHRo ZSBwdXJwb3NlIG9mIFdlYlJUQw0KfA0KfDIwMTEvMTEvOSBNdXRodSBBcnVsIE1vemhpIFBlcnVt YWwgKG1wZXJ1bWFsKSA8bXBlcnVtYWxAY2lzY28uY29tPjoNCnw+IHxBbmQgd2hhdCB5b3Ugc3Rh dGUgaXMgdGhhdCwgaW4gY2FzZSB0aGUgcGVlciBkb2VzIG5vdCBhbm5vdWNlDQp8PiB8c3VwcG9y dCBmb3IgU1JUUCB0aGVuIHRoZSBicm93c2VyIHNob3VsZCBkb3duZ3JhZGUgc2VjdXJpdHkNCnw+ IHx0byBwbGFpbiBSVFAuDQp8Pg0KfD4gTm8sIG5vdCBiYXNlZCBvbiB0aGUgU1JUUCBjYXBhYmls aXR5IGFkdmVydGlzZWQgYnkgdGhlIHBlZXIsIHJhdGhlciBiYXNlZCBvbiB3aGV0aGVyIHRoZSBw ZWVyIGNsYWltcw0KfGl0IGlzIFdlYlJUQyBjb21wbGlhbnQgKHRvIG1ha2Ugc3VyZSBjYWxscyBi L3cgV2ViUlRDIGNsaWVudHMgYXJlIGFsd2F5cyBzZWN1cmUpLg0KfD4NCnw+IHxUaGUgdXNlciAo d2ViIHZpc2l0b3IpIGhhcyBubyB3YXkgdG8ga25vdyB3aGV0aGVyIHRoZSBXZWJSVEMNCnw+IHxh cHBsaWNhdGlvbiB3aWxsIGNvbnRhY3QgYSBXZWJSVEMgYnJvd3NlciBvciBhbm90aGVyIGRldmlj ZQ0KfD4gfGF0IHRoZSBtZWRpYSBwbGFuZS4NCnw+DQp8PiBXZSBjb3VsZCBhZGQgYSBTVFVOIGV4 dGVuc2lvbiB0byBpbmRpY2F0ZSBjb21wbGlhbmNlIHRvIFdlYlJUQywgaW5jbHVkaW5nIHRoZSBz dXBwb3J0ZWQgdmVyc2lvbg0KfGxldmVsIGlmIHdlIGV2ZXIgY29tZSB1cCB3aXRoIFdlYlJUQzIu MC4NCnwNCnxBbmQgd2hhdCBpcyB0aGUgYWR2YW50YWdlPyB5b3Ugc3RpbGwgc2F5IGV4YWN0bHkg dGhlIHNhbWU6IGEgV2ViUlRDDQp8Y2xpZW50ICJNVVNUIiBhbGxvdyBwbGFpbiBSVFAgaWYgdGhl IHBlZXIgaXMgbm90IGEgV2ViUlRDIGNsaWVudC4gV2h5DQp8aXMgdGhhdCBhbiBhcmd1bWVudCBp biBmYXZvdXIgb2Ygbm9uIG1hbmRhdGluZyBTUlRQPw0KfA0KfElmIEknbSBpbiBhIHNoYXJlZCBX aUZpIG5ldHdvcmsgYW5kIHJlY2VpdmUgYSBjYWxsIGZyb20gYSBub24tV2ViUlRDDQp8Y2xpZW50 IG5vdCBzdXBwb3J0aW5nIFNSVFAsIG15IG5laWdoYm9ycyBjYW4gaW50ZXJjZXB0IGl0LiBXaGF0 IGRvZXMNCnxzdWNoICJTVFVOIGV4dGVuc2lvbiIgcHJvdmlkZXMgaGVyZT8ganVzdCBub3RoaW5n Lg0KfA0KfA0KfA0KfA0KfA0KfC0tDQp8ScOxYWtpIEJheiBDYXN0aWxsbw0KfDxpYmNAYWxpYXgu bmV0Pg0K From roman@telurix.com Wed Nov 9 06:33:15 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424E921F8C0A for ; Wed, 9 Nov 2011 06:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=-0.065, 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 oAkE7XuQOHi9 for ; Wed, 9 Nov 2011 06:33:14 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 67CE721F8B37 for ; Wed, 9 Nov 2011 06:33:14 -0800 (PST) Received: by qyk32 with SMTP id 32so1632317qyk.10 for ; Wed, 09 Nov 2011 06:33:14 -0800 (PST) Received: by 10.224.174.68 with SMTP id s4mr2206840qaz.4.1320849193868; Wed, 09 Nov 2011 06:33:13 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id cd3sm5183827qab.5.2011.11.09.06.33.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Nov 2011 06:33:12 -0800 (PST) Received: by ywt2 with SMTP id 2so2147293ywt.31 for ; Wed, 09 Nov 2011 06:33:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.23.130 with SMTP id m2mr5423157pbf.120.1320849192087; Wed, 09 Nov 2011 06:33:12 -0800 (PST) Received: by 10.68.62.170 with HTTP; Wed, 9 Nov 2011 06:33:11 -0800 (PST) In-Reply-To: References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> Date: Wed, 9 Nov 2011 09:33:11 -0500 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=bcaec5215d37e571ea04b14e2a15 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 14:33:15 -0000 --bcaec5215d37e571ea04b14e2a15 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Nov 9, 2011 at 8:44 AM, I=F1aki Baz Castillo wrote: > And what is the advantage? you still say exactly the same: a WebRTC > client "MUST" allow plain RTP if the peer is not a WebRTC client. Why > is that an argument in favour of non mandating SRTP? > > What I have not seen on this list is why SRTP must be used for all the calls. The things I've seen so far: 1. SRTP must be used everywhere since security is good 2. We are innovative so we must use SRTP everywhere 3. We do not trust the user or the application so we must use SRTP everywhere 4. We must have SRTP in order to have consensus. I think except the fact that security is generally a good thing, non of these arguments are relevant. What I was trying to say that there are number of situations where: 1. SRTP is useless: If we do not trust the application (application is delivered over HTTP), there is no point to encrypt the media. Application can send this media to some box in the middle and record it, without user ever knowing. Requiring SRTP in this case is almost like trying to lock the window when your door is open. 2. SRTP is not required: If we are dealing with a greeting card application or game chat, no one expects security. If security can be provided this will probably not hurt anybody, but in the end it will serve no purpose there. 3. SRTP is undesirable: As I've mentioned before there are places and situations where encryption is either makes things more difficult (like interop with legacy devices, debugging, or building new software). In these cases, having SRTP as a must just introduces a higher barrier to entry the needs to be overcome in order to communicate with WebRTC. This is not something critical, but it will make things more difficult and will work against innovation. 4. SRTP is illegal: I am not talking about wiretapping. I do not propose to create any types of back doors in WebRTC in order to intercept the communications. All I am saying that application developer should have an option not to encrypt its traffic to comply with local laws or regulations. I do not think there is a single user faced communication protocol that does not provide a non secure alternative (HTTP vs HTTPS, SMTP and IMAP over TCP vs TLS, etc). I do not see why WebRTC must be the first protocol not to have an unencrypted option. What I would propose is to allow RTP communications from sessions initiated by HTTP and require SRTP (or a user consent) for sessions started from HTTPS. This should be similar to current HTTPS vs HTTP model for javascript, and will require security where it will do some good vs places where it is going to be useless. _____________ Roman Shpount --bcaec5215d37e571ea04b14e2a15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 9, 2011 at 8:44 AM= , I=F1aki Baz Castillo <ibc@aliax.net> wrote:
And what is the advantage? you still say exactly the same: a WebRTC
client "MUST" allow plain RTP if the peer is not a WebRTC client.= Why
is that an argument in favour of non mandating SRTP?


What I have not seen on this list is why SRTP mu= st be used for all the calls. The things I've seen so far:
1. SRTP m= ust be used everywhere since security is good
2. We are innovative so we= must use SRTP everywhere
3. We do not trust the user or the application so we must use SRTP everywhe= re
4. We must have SRTP in order to have consensus.

I think excep= t the fact that security is generally a good thing, non of these arguments = are relevant.

What I was trying to say that there are number of situations where:
=
1. SRTP is useless: If we do not trust the application (application is = delivered over HTTP), there is no point to encrypt the media. Application c= an send this media to some box in the middle and record it, without user ev= er knowing. Requiring SRTP in this case is almost like trying to lock the w= indow when your door is open.

2. SRTP is not required: If we are dealing with a greeting card applica= tion or game chat, no one expects security. If security can be provided thi= s will probably not hurt anybody, but in the end it will serve no purpose t= here.

3. SRTP is undesirable: As I've mentioned before there are places a= nd situations where encryption is either makes things more difficult (like = interop with legacy devices, debugging, or building new software). In these= cases, having SRTP as a must just introduces a higher barrier to entry the= needs to be overcome in order to communicate with WebRTC. This is not some= thing critical, but it will make things more difficult and will work agains= t innovation.

4. SRTP is illegal: I am not talking about wiretapping. I do not propos= e to create any types of back doors in WebRTC in order to intercept the com= munications. All I am saying that application developer should have an opti= on not to encrypt its traffic to comply with local laws or regulations. I d= o not think there is a single user faced communication protocol that does n= ot provide a non secure alternative (HTTP vs HTTPS, SMTP and IMAP over TCP = vs TLS, etc). I do not see why WebRTC must be the first protocol not to hav= e an unencrypted option.

What I would propose is to allow RTP communications from sessions initi= ated by HTTP and require SRTP (or a user consent) for sessions started from= HTTPS. This should be similar to current HTTPS vs HTTP model for javascrip= t, and will require security where it will do some good vs places where it = is going to be useless.
_____________
Roman Shpount

--bcaec5215d37e571ea04b14e2a15-- From fluffy@cisco.com Wed Nov 9 06:37:48 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E3E21F8A57 for ; Wed, 9 Nov 2011 06:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.453 X-Spam-Level: X-Spam-Status: No, score=-106.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 oCClgmfoYuqd for ; Wed, 9 Nov 2011 06:37:47 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBEF21F8AAA for ; Wed, 9 Nov 2011 06:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1813; q=dns/txt; s=iport; t=1320849467; x=1322059067; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=VDShaCPF03/ahOkfe3LOBnQmJOBWhG+qGzLAMXIEf+0=; b=DVqtZWgVpgZK7xkld68XHYLQ6IczRUcxgB+ZLkEVdMS5C6iYp0ne7NiQ qSEtVBfcDtSgxnBr4H+JaboedHmMT11AeLhQDTDNT1CpbjQ8NuiQ+2Xkw ic8hf+jVzsAb75ZBZcs3q3k22XzViyZh5OKvuSWfHUTCp7JfzgOGhL0Uy I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJSPuk6rRDoI/2dsb2JhbABCqh6BBYFyAQEBAwESASc/EAs7C1cGNYdgmSgBnyGJHGMEiAyMGYU1jF0 X-IronPort-AV: E=Sophos;i="4.69,484,1315180800"; d="scan'208";a="13200305" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 09 Nov 2011 14:37:42 +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 pA9Ebgel000354; Wed, 9 Nov 2011 14:37:42 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852235A07262@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 9 Nov 2011 07:37:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058522341F4AB9@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852235789602@ESESSCMS0356.eemea.ericsson.se> <088367F5-90D3-45B5-939E-904411CF2D7B@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852235A07262@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Jonathan Rosenberg , "rtcweb@ietf.org" Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - More-coming and final answer (Section 5.2.3) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 14:37:48 -0000 On Nov 9, 2011, at 2:14 AM, Christer Holmberg wrote: >=20 > Hi Cullen,=20 >=20 >>>>> Q2. Are there restrictions when it comes to changing=20 >>>>> information in a non-final answer and a final answer? Or, can the = final=20 >>>>> answer be completely different from previously sent non-final=20 >>>>> ANSWERS? In "legacy" O/A there are restrictions. >>>>>=20 >>>> Any answer has to be a valid answer for the offer but other than=20 >>>> that, no restrictions, so the final answer can change=20 >>>> everything from an earlier one. >>>=20 >>> Is there a reason/use-case/requirement why we need to allow=20 >>> that? As far as I know, the reason behind this is ICE. >>>=20 >> There a bunch of use cases but to mention two: In the browser=20 >> to browser case, imagine that you start sending audio in the=20 >> first answer but need to wait for user feedback to find out=20 >> if video can be added or not in the final answer. In a=20 >> browser to SIP use case, the early media for 1-800-go-fedex. >=20 > I think that could cause interoperability issues. >=20 > For example, assume that a gateway would map a more-to-come answer to = a SIP 18x response. >=20 > Then, if the no-more-to-come answer is different, the gateway can't = map it to SIP 200 response - at least not without chaning the SIP dialog = identifier. Seems like it should be able to do this. Lets talk about this in Taipei = - I suspect we are just talking past each other and both mean about the = same thing. I'm not proposing any change to 3264.=20 >=20 > Also, if you map a more-to-come answer to a SIP 18x answer, and then = receives a new SIP offer, the gateway *cannot* map it to a ROAP offer, = as it is still wating waiting for the no-more-to-come answer. >=20 > Regards, >=20 > Christer From fluffy@cisco.com Wed Nov 9 06:41:01 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EB021F8AAA for ; Wed, 9 Nov 2011 06:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.155 X-Spam-Level: X-Spam-Status: No, score=-107.155 tagged_above=-999 required=5 tests=[AWL=0.844, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_55=0.6, 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 wMqL99Tb5Uly for ; Wed, 9 Nov 2011 06:41:00 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4B66521F8A57 for ; Wed, 9 Nov 2011 06:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=10985; q=dns/txt; s=iport; t=1320849660; x=1322059260; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6Cv9uRfGKbmsX5ei3OihY2ITsp4+Vs6sE1gVkp6O4/M=; b=Eg9YCabtL2ZaE9Yia9FkPfGX1aLGI1YBWsgpXuuo/rtzA7WNVDUzklxU RIb8UmRPnZXtnSP5weXAN50YuArGAD+5Xc6LHqCIycips/Ug1F/OM9TVP wcdhUMV5+IsbRl9mGa9jE6KIZev0uQamRdODl8NT/P4RS2TipzeGiF0So g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFALiPuk6rRDoH/2dsb2JhbABCqHeBJ4EFgXIBAQEDAQEBAQkGAVsLBQkCCxgnBxsMHxEGExsHh2AImSABnx0EAokaYwSIDIwZhTWMXQ X-IronPort-AV: E=Sophos;i="4.69,484,1315180800"; d="scan'208";a="13193417" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 09 Nov 2011 14:41:00 +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 pA9Eexjp007028; Wed, 9 Nov 2011 14:40:59 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852235A07275@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 9 Nov 2011 07:40:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EB26945.40607@ericsson.com> <0E287F18-E335-472D-853A-0A1B449D2AD7@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852235A07275@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] State of the Forking discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 14:41:01 -0000 On Nov 9, 2011, at 2:20 AM, Christer Holmberg wrote: >=20 > Hi,=20 >=20 >> >>=20 >> Much of this I don't feel too strongly about but there is one=20 >> thing that I do have a strong opinion on. I don't want to=20 >> require PRACK for legacy SIP support because it is has many problems.=20= >=20 > If you are not using PRACK, you will not be able to receive a "real" = answer before 200 OK, at a point where forking will be no issue anymore = :) >=20 I think it is a little more subtle than this. The UAC are not guarantee = delivery of the 180s without prack but the UAC typically gets them = anyways. Note I am fine with things that do support PRACK, I just don't = want to require it. I also have had good luck with the systems that = send the 180 more than once.=20 > Regards, >=20 > Christer >=20 >=20 >=20 >> On Nov 3, 2011, at 4:13 AM, Magnus Westerlund wrote: >>=20 >>> WG, >>>=20 >>> I just reviewed the last weeks Forking discussion. This=20 >> includes the=20 >>> threads "RTCWeb Forking usecase [was RE: >>> draft-kaplan-rtcweb-sip-interworking-requirements-00]" and "Media=20 >>> forking solution for SIP interoperability (without a media gateway)" >>>=20 >>> As far as I can tell there is not yet even a rough consensus.=20 >>> Therefore I will attempt to summarize what I personally=20 >> believe to be=20 >>> the important points and alternatives in this discussion.=20 >> Keep in mind=20 >>> that my assumptions or understanding may be unclear or have=20 >> errors. So=20 >>> don't hesitate to challenge what I write. >>>=20 >>> I think it is important that there are in fact at least two=20 >> important=20 >>> questions here. >>>=20 >>> 1. Is forking needed to be supported at all? >>>=20 >>> 2. If it is supported in which form would it supported in. >>>=20 >>> so lets start looking into the arguments and possibilities=20 >> for these=20 >>> two questions. And I do hope that you will read to the end of this=20= >>> mail which is quite long. >>>=20 >>> Lets start with the high level functionality part. Is=20 >> forking needed=20 >>> and what usage does it have. So forking is all about sending out an=20= >>> invitation to a media session including an actual media=20 >> configuration=20 >>> offer, i.e. SDP Offer, then get more than a single answer to that=20 >>> offer back. How you deal with these answers as they come in is the=20= >>> difference between serial and parallel forking. So lets=20 >> define those. >>>=20 >>> Parallel forking: For each answer you receive you establish a new=20 >>> actual media session. Thus if you receive two answers you=20 >> will have to=20 >>> different media sessions that are potentially in use at the=20 >> same time. >>>=20 >>> Serial forking: The first answer is received and results the=20 >>> establishment of a media session. At a later point in time a second=20= >>> answer is received. At that point you take the decision if=20 >> that second=20 >>> answer is going to be used to establish a new media session that=20 >>> replaces the first one. In other words at any given time=20 >> you will only=20 >>> have a single media session established based on each offer. >>>=20 >>> So there has been a number of different views on how one can see on=20= >>> forking. And I think I will have to bring in a bit=20 >> reflections on how=20 >>> this can be done with the current PeerConnection API. >>>=20 >>> A) No forking is needed: Between WebRTC end-points there is no need=20= >>> for forking. Instead the application can send out session=20 >> invitations=20 >>> to the peers it wants to talk to. These are without any SDP Offer=20 >>> equivalent, instead end-points that want to communicate they create=20= >>> PeerConnections, which results in SDP Offers. Thus the=20 >> communication=20 >>> initiating end-point becomes the ones that provides SDP answers and=20= >>> get one PeerConnection per remote end-point that actually=20 >> want to communicate. >>>=20 >>> B) We need to have some interworking with SIP: So the=20 >> fundamental here=20 >>> is that it needs to be reasonable to interwork with SIP,=20 >> independent=20 >>> if one uses a SIP in JS in the application running on the WebRTC=20 >>> enabled browser, or have signalling gateway in the=20 >> webserver, or as a=20 >>> remote WebRTC peer. The issue is that A)'s method of=20 >> initiating call=20 >>> doesn't work well with SIP. There is a need to send a SIP=20 >> Invite with=20 >>> an SDP Offer and that can result in multiple answers. >>>=20 >>> To resolve this one could deal with this in a couple of=20 >> different ways: >>>=20 >>> B1) Use I=F1aki's proposal which forces the WebRTC=20 >> application to create=20 >>> a second PeerConnection and then forces an update in the SIP domain=20= >>> with the second peer-connections Offer. However, it was pointed out=20= >>> that this doesn't work with SIP Provisional answers, as used by ICE=20= >>> for example, unless PRACK is supported. The level of PRACK=20 >> support is=20 >>> reasonable but far from universal so this would limit the=20 >> SIP UAs one=20 >>> can interwork with. However, from WebRTC perspective no forking=20 >>> support is needed. A single PeerConnection results in one=20 >> offer and a=20 >>> single answer is processed. >>>=20 >>> B2) Require WebRTC to handle replace Answers: So the idea=20 >> here is that=20 >>> one changes the PeerConnection API and have underlying=20 >> functionality=20 >>> so that at any point in time a new Answer can pushed onto a=20 >>> PeerConnection and that forces the media session to be=20 >> reestablished=20 >>> if needed. So if the ICE candidate list is different an ICE restart=20= >>> happens. This clearly supports serial forking. It also can=20 >> create some=20 >>> complexities in the underlying SDP handling logic if one=20 >> desires to minimize the media impact. >>>=20 >>> B3) Local side shared parameters in multiple=20 >> PeerConnections: The idea=20 >>> in this proposal is that all PeerConnections generated in a browser=20= >>> context, like a tab will implicit share the fundamental parameters=20= >>> like ICE candidates etc for the number of media streams=20 >> added. So if=20 >>> one creates a second PeerConnection with the same audio+video=20 >>> MediaStream object added I will get an offer that is mostly=20 >> identical=20 >>> to the the first PeerConnection, thus I can push in the answer from=20= >>> the first PeerConnection Offer into the second PC object=20 >> and it will still work. >>> The downside of this is that it is implicit and it becomes=20 >> difficult=20 >>> to determine when it works and when it will fail. It will also be=20 >>> highly dependent on the application performing the right process to=20= >>> get it to work. It also causes a sharing of the parameters when not=20= >>> needed or desired, which primarily is an issue from a=20 >> security point=20 >>> of view, especially with SDES keys (see below). The=20 >> positive is this=20 >>> likely requires no API changes. This method would also=20 >> support parallel forking. >>>=20 >>> B4) Cloning/Factory for PeerConnection: On the API level=20 >> there will be=20 >>> explicit support for generating multiple PeerConnections=20 >> from the same=20 >>> base. This could either be a factory for PeerConnections or some=20 >>> Object constructor that clones an existing PeerConnection=20 >> but that is=20 >>> a W3C question. By being explicit some of the B3) issues=20 >> goes away and=20 >>> the applications can choose when this should happen or not.=20 >> This also=20 >>> support parallel forking as the application can deal with=20 >> each media=20 >>> session independently. This clearly will have some impact=20 >> on the API. >>>=20 >>>=20 >>> Additional considerations: >>>=20 >>> Shared SDES keys: B2 to B4 will result in that SDES keys from the=20 >>> Offering party to be used towards all invited parties. This is=20 >>> security risk as any of the invited parties can spoof the offering=20= >>> side towards any of the other invited parties. This threat can be=20 >>> resolved by having the inviter rekey immediately after=20 >> having received an answer. >>>=20 >>> Sharing ICE candidates: B3 and B4 and also B2 to some degree will=20 >>> share the ICE candidates. That has certain implications. One is the=20= >>> positive in that it minimizes the resource consumption as=20 >> additional=20 >>> PeerConnections come at very little extra cost, no need for=20 >> additional=20 >>> ICE gathering candidate phases, and also be very quick as=20 >> no external=20 >>> communication is required. The downside of this is that the=20 >> end-points=20 >>> candidates must always be kept alive as long as some PeerConnection=20= >>> instance exist. Because the browser never knows when the=20 >> application=20 >>> may create an additional PC and expect them to have the=20 >> same ICE candidates. >>> It should also be noted that the answering WebRTC end-point=20 >> will need=20 >>> to gather candidates for each offer. Otherwise it will become=20 >>> impossible to create multiple PeerConnections between the same=20 >>> end-points if that is desired by the application. >>>=20 >>>=20 >>> I know the above doesn't list all of the pro and cons of=20 >> the different=20 >>> alternatives. So please fill in additional arguments. And=20 >> if I missed=20 >>> some proposal please add that also if relevant >>>=20 >>> As you may have noted I the two questions in the above have kind of=20= >>> floated together. The reason for this is that I think the=20 >> majority are=20 >>> fine with having SIP support as long as it doesn't have to=20 >> high cost=20 >>> or complexity associated with it. Thus, the question how=20 >> becomes very=20 >>> intertwined with forking support yes or no. >>>=20 >>> So please continue the discussion >>>=20 >>> Cheers >>>=20 >>> Magnus Westerlund >>>=20 >>>=20 >> = ---------------------------------------------------------------------- >>> Multimedia Technologies, Ericsson Research EAB/TVM >>>=20 >> = ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>>=20 >> = ---------------------------------------------------------------------- >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Wed Nov 9 07:05:34 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5525121F8B64 for ; Wed, 9 Nov 2011 07:05:34 -0800 (PST) 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 HJhDD5iKR0ZJ for ; Wed, 9 Nov 2011 07:05:33 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6C5C21F8B63 for ; Wed, 9 Nov 2011 07:05:33 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so1675274vcb.31 for ; Wed, 09 Nov 2011 07:05:33 -0800 (PST) Received: by 10.52.187.68 with SMTP id fq4mr5235239vdc.32.1320851133157; Wed, 09 Nov 2011 07:05:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Wed, 9 Nov 2011 07:05:12 -0800 (PST) In-Reply-To: <1D062974A4845E4D8A343C653804920206D3BA71@XMB-BGL-414.cisco.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C653804920206D3BA71@XMB-BGL-414.cisco.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 9 Nov 2011 16:05:12 +0100 Message-ID: To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 15:05:34 -0000 2011/11/9 Muthu Arul Mozhi Perumal (mperumal) : > |And what is the advantage? you still say exactly the > |same: a WebRTC client "MUST" allow plain RTP if the > |peer is not a WebRTC client. Why is that an argument > |in favour of non mandating SRTP? > > We seem to have a group of people concerned about the cost associated wit= h having to upgrade/replace/supplement their non-SRTP capable gears such as= PSTN gateways, and I was sympathetic towards them -:) That's *your* problem. But you want to translate *your* problem into WebRTC users by making their communications non secure. Implementing SRTP is really easier and cheap. There is no reason at all not to mandate it in a new specification, even less when it's designed to work in the open (and untrusted) Internet. So bad luck. You, telcos, have the specs and the tools to upgrade your non-secure SIP devices. Do it. > |If I'm in a shared WiFi network and receive a call from > |a non-WebRTC client not supporting SRTP, my neighbors can > |intercept it. > > If the shared WiFi network hasn't employed WiFi encryption, then you woul= d probably be more concerned with your neighbors intercepting all of your t= raffic than just RTP -:) It was just an example. Think about so many open WiFi networks in airports (captive portals with no encryption). > |What does such "STUN extension" provides here? > > It would tell the browser that the peer (browser) claims WebRTC complianc= e and so shouldn't allow insecure calling (the STUN extension is added by t= he browser and the applications has no control over it). I insist: that provides nothing. It just means that me, a WebRTC user, could have a non-secure media session in case the remote peer is not a WebRTC peer (or a peer implementing SRTP). It solves nothing. It makes my communication unsafe regardless I'm a WebRTC client implementing SRTP. *My* security should NOT depend on the security implemented in the peer (since I cannot trust the peer, never). --=20 I=C3=B1aki Baz Castillo From wolfgang.beck01@googlemail.com Wed Nov 9 08:56:00 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6022221F8C3E for ; Wed, 9 Nov 2011 08:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 0R9UG+YReTtv for ; Wed, 9 Nov 2011 08:55:59 -0800 (PST) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id DC81D21F8C34 for ; Wed, 9 Nov 2011 08:55:59 -0800 (PST) Received: by pzk4 with SMTP id 4so2182280pzk.9 for ; Wed, 09 Nov 2011 08:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Q0vZwTQNYJffe42wLSWBb6HBTNuPhoUIbuVCC0FGuxI=; b=JyOKM7hQtzeVjby67eXeQm5jfLLYG0GY6lydD7KQ2uCVRL/I+7fG8KDk+e82KogjXR nk5fmzLP0o76Vwd+fWFVeG7F9qrDGsKmK2QVIWdqZ+POtQPSbxlKK2Z1vUgxlbB7XkFK lfN6nXSkTnQ0KTqyMNkpDbxNy7aNLnNAtwf0s= MIME-Version: 1.0 Received: by 10.68.52.134 with SMTP id t6mr6418883pbo.96.1320857759373; Wed, 09 Nov 2011 08:55:59 -0800 (PST) Received: by 10.68.64.66 with HTTP; Wed, 9 Nov 2011 08:55:59 -0800 (PST) In-Reply-To: <4EBA741A.1010307@alvestrand.no> References: <4EB26D22.5090000@ericsson.com> <4EBA741A.1010307@alvestrand.no> Date: Wed, 9 Nov 2011 17:55:59 +0100 Message-ID: From: Wolfgang Beck To: "" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 16:56:00 -0000 On Wed, Nov 9, 2011 at 1:37 PM, Harald Alvestrand wrote: > [on Bernard's comments] > can we simply say "Existing protocols (for example SIP or XMPP) could be > used between the servers"? > > between servers, while either a standards-based or proprietary protocol > could be used between the browser and the web server. My concern about this trapezoid style connection of servers is this: in order to limit the number protocol translators, RTCWEB providers will use only a small number of server-to-server protocols, most likely SIP and Jingle. This will inevitably have influence on the JS client / server protocol design: why bother with innovative features that don't translate well to SIP and Jingle anyway? Why not just do Jingle/SIP over Websocket? And the opportunity of RTCWEB will be gone. We will just see browser-based SIP, Jingle clients with fancy CSS themes. This has happened with SIP. As most of the interconnection is done through the PSTN, we don't see many exciting new SIP applications in wide use. It's a pity that the VWRAP people are no longer active in the IETF. They really had a fresh view on those issues. Their interconnection requirements where just to complex for the trapezoid and nobody of them had a limiting telephony background. Wolfgang Beck From harald@alvestrand.no Wed Nov 9 09:27:02 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF9C21F8AF9 for ; Wed, 9 Nov 2011 09:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.555 X-Spam-Level: X-Spam-Status: No, score=-110.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 j1mTy4BlPTCt for ; Wed, 9 Nov 2011 09:27:02 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F039D21F8A7E for ; Wed, 9 Nov 2011 09:27:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D037939E149 for ; Wed, 9 Nov 2011 18:26:59 +0100 (CET) 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 5I66G4u1rh+r for ; Wed, 9 Nov 2011 18:26:32 +0100 (CET) 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 ESMTPS id 261F139E04C for ; Wed, 9 Nov 2011 18:26:32 +0100 (CET) Message-ID: <4EBAB7C7.4030702@alvestrand.no> Date: Wed, 09 Nov 2011 18:26:31 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4EB26D22.5090000@ericsson.com> <4EBA741A.1010307@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 17:27:02 -0000 On 11/09/2011 05:55 PM, Wolfgang Beck wrote: > On Wed, Nov 9, 2011 at 1:37 PM, Harald Alvestrand wrote: >> [on Bernard's comments] >> can we simply say "Existing protocols (for example SIP or XMPP) could be >> used between the servers"? >> >> between servers, while either a standards-based or proprietary protocol >> could be used between the browser and the web server. > My concern about this trapezoid style connection of servers is this: > in order to limit the number protocol translators, > RTCWEB providers will use only a small number of server-to-server > protocols, most likely SIP and Jingle. > > This will inevitably have influence on the JS client / server > protocol design: why bother with innovative features that > don't translate well to SIP and Jingle anyway? Why not just do > Jingle/SIP over Websocket? And the opportunity of RTCWEB will be gone. > We will just see browser-based SIP, Jingle clients with fancy CSS > themes. Please!!!!!!!!!!! The trapezoid is ONE possible deployment scenario. As the overview document says: A commonly imagined model of deployment is the one depicted below. It is neither the only possible one nor even a recommended one. It is just commonly imagined. If you want innovative applications ..... go innovate, and come back when you know *exactly why* something in the specs gets in your way! > This has happened with SIP. As most of the interconnection is done > through the PSTN, we don't see many exciting new SIP applications in > wide use. > > It's a pity that the VWRAP people are no longer active in the IETF. > They really had a fresh view on those issues. Their > interconnection requirements where just to complex for the trapezoid > and nobody of them had a limiting telephony background. Without pointers to docs, I can't evaluate this statement. Be specific! From randell-ietf@jesup.org Wed Nov 9 09:30:37 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AA911E8083 for ; Wed, 9 Nov 2011 09:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 q934rjA69YLs for ; Wed, 9 Nov 2011 09:30:36 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id B4CA721F8C2A for ; Wed, 9 Nov 2011 09:30:36 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1ROByt-0007Xj-LQ for rtcweb@ietf.org; Wed, 09 Nov 2011 11:30:35 -0600 Message-ID: <4EBAB896.6080003@jesup.org> Date: Wed, 09 Nov 2011 12:29:58 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D0 62974A4 845E4D8A343C 653804920206D3B9C1@XMB-BGL-414.cisco.com> <34771C19-DD51-46B4-97ED-703A93F7329E@edvina.net> <1D062974A4845E4D8A343C653804920206D3BA43@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920206D3BA43@XMB-BGL-414.cisco.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] Let's define the purpose of 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: Wed, 09 Nov 2011 17:30:37 -0000 On 11/9/2011 8:19 AM, Muthu Arul Mozhi Perumal (mperumal) wrote: > |That opens up for downgrade attacks and put a lot > |of trust on the web browser UI to show what happens > |and on the users to understand what the web browser > |UA is trying to tell them. > > It isn't an attack per se (since a malicious JS no control over it), rather a choice we would have to make whether or not to allow insecure calling to non-WebRTC clients. Yes, it adds some burden on the UI, but could be as simple as a red cross you see on https URL when the browser detects either high-risk insecure content on the page or problems with the site's certificate. It's a network/server-based attack, or it's an attack perpetrated by the JS app by sending the call to an unencrypted MiTM tapping point instead of directly to the intended recipient. ekr and Mozilla (and probably some others) have been working on/thinking about how we can minimize the risk of MiTM attacks, and provide the user with some idea of whom they're talking to (Evil Hacker or My Buddy Jim). -- Randell Jesup randell-ietf@jesup.org From mperumal@cisco.com Wed Nov 9 10:31:55 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BA31F0C36 for ; Wed, 9 Nov 2011 10:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.861 X-Spam-Level: X-Spam-Status: No, score=-6.861 tagged_above=-999 required=5 tests=[AWL=-0.562, 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 bEc0K9OlOV8u for ; Wed, 9 Nov 2011 10:31:54 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id E0BE51F0C34 for ; Wed, 9 Nov 2011 10:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=4866; q=dns/txt; s=iport; t=1320863514; x=1322073114; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Qz5gZ0SagpXNSBhSDUUPUtaiPE7ydJWLHxSYv7Zt/Uo=; b=KqYBirkFf1PAtSXeAtUrxsqBkDmJ5SByONheyNeKXeBsksbJbwYbkEDI UhHd3ESi3fzX+NM5f1sOtTqUU9RUuiuW9Bg4Zmow0EcipP3eHfpi4ZqcB ecGq0Rvy2cFV1OMiLu56HJpXVM8YqNqlQvd5OkE2dH01PEJ5rUIMQG2IT U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwAAEHGuk5Io8UQ/2dsb2JhbABChH2VK456gQKBBYFyAQEBBBIBEA0ERQwEAgEIEQQBAQMCBgYXAQICAgEBRAkIAQEECwgIGqBMAYxZkkSBMIc5M2MEiAqRWYw8 X-IronPort-AV: E=Sophos;i="4.69,484,1315180800"; d="scan'208";a="2745783" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-4.cisco.com with ESMTP; 09 Nov 2011 18:31:51 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA9IVpUt032318; Wed, 9 Nov 2011 18:31:51 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 00:01:50 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 10 Nov 2011 00:01:46 +0530 Message-ID: <1D062974A4845E4D8A343C653804920206D3BAEE@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: Acye8RKyRoxAyb3VSOuH5rCrP9Lw2QAGYKtQ References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D0 62974A48 45E4D8A343C6 53804920206D3BA57@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C653804920206D3BA71@XMB-BGL-414.cisco.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 09 Nov 2011 18:31:50.0810 (UTC) FILETIME=[D8D487A0:01CC9F0D] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 18:31:55 -0000 fFRoYXQncyAqeW91ciogcHJvYmxlbS4gQnV0IHlvdSB3YW50IHRvIHRyYW5zbGF0ZSANCnwqeW91 ciogcHJvYmxlbSBpbnRvIFdlYlJUQyB1c2VycyBieSBtYWtpbmcgdGhlaXIgDQp8Y29tbXVuaWNh dGlvbnMgbm9uIHNlY3VyZS4NCg0KV2VsbCwgbW9zdCBvZnRlbiB5b3UgYXMgYSBXZWJSVEMgdXNl ciB3aWxsIGJlIHRoZSBvbmUgd2hvIHdvdWxkIHdhbnQgdG8gcmVhY2ggc29tZW9uZSBiZWhpbmQg bGVnYWN5IHN5c3RlbXMgb3IgYXMgc29tZW9uZSBvZmZlcmluZyBXZWJSVEMgc2VydmljZSB3b3Vs ZCB3YW50IHlvdXIgdXNlcnMgYmUgYWJsZSB0byByZWFjaCBvdGhlciB1c2VycyBiZWhpbmQgc3Vj aCBzeXN0ZW1zLiBMYXJnZSBvcmdhbml6YXRpb25zIHdvdWxkIHByb2JhYmx5IGJ1aWxkIHRoZWly IG93biBtZWRpYSBnYXRld2F5cywgd2hpbGUgc21hbGxlciBvbmVzIHdvdWxkIHByb2JhYmx5IGdl dCB0YXhlZCBieSBwcm92aWRlcnMgZm9yIG9mZmVyaW5nIHN1Y2ggbWVkaWEgZ2F0ZXdheSBzZXJ2 aWNlLiANCg0KfEltcGxlbWVudGluZyBTUlRQIGlzIHJlYWxseSBlYXNpZXIgYW5kIGNoZWFwLg0K DQpTdXJlLCBpbiBhIGJyb3dzZXIuIEJ1dCwgbWF5IG5vdCBiZSBmb3IgYSBwcm92aWRlci4NCg0K fFlvdSwgdGVsY29zLCBoYXZlIHRoZSBzcGVjcyBhbmQgdGhlIHRvb2xzIHRvIHVwZ3JhZGUgeW91 cg0KfG5vbi1zZWN1cmUgU0lQIGRldmljZXMuIERvIGl0Lg0KDQpJZiB5b3UgYXJlIHdpbGxpbmcg dG8gcGF5IGZvciBpdCwgSSBkb24ndCBzZWUgd2h5IHRoZSB0b2xjb3Mgd29uJ3QgLTopDQoNCnwq TXkqIHNlY3VyaXR5IHNob3VsZCBOT1QgZGVwZW5kIG9uIHRoZSBzZWN1cml0eSANCnxpbXBsZW1l bnRlZCBpbiB0aGUgcGVlciAoc2luY2UgSSBjYW5ub3QgdHJ1c3QgdGhlIA0KfHBlZXIsIG5ldmVy KS4NCg0KR29vZCBsdWNrLiBZb3UgcGVlciBjb3VsZCBiZSBhIG1lZGlhIGdhdGV3YXkgc2l0dGlu ZyBzb21ld2hlcmUgaW4gdGhlIEludGVybmV0IGNvbnZlcnRpbmcgU1JUUCB0byBSVFAgYW5kIHNl bmRpbmcgdG8gdGhlIG90aGVyIHBhcnQgb2YgdGhlIHdvcmxkLg0KDQpNdXRodQ0KDQp8LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCnxGcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86 aWJjQGFsaWF4Lm5ldF0NCnxTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDA5LCAyMDExIDg6MzUg UE0NCnxUbzogTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkNCnxDYzogQXZhc2Fy YWxhLCBSYW5qaXQ7IFJhdmluZHJhbiBQYXJ0aGFzYXJhdGhpOyBDdWxsZW4gSmVubmluZ3MgKGZs dWZmeSk7IE9sbGUgRS4gSm9oYW5zc29uOw0KfHJ0Y3dlYkBpZXRmLm9yZw0KfFN1YmplY3Q6IFJl OiBbcnRjd2ViXSBMZXQncyBkZWZpbmUgdGhlIHB1cnBvc2Ugb2YgV2ViUlRDDQp8DQp8MjAxMS8x MS85IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpIDxtcGVydW1hbEBjaXNjby5j b20+Og0KfD4gfEFuZCB3aGF0IGlzIHRoZSBhZHZhbnRhZ2U/IHlvdSBzdGlsbCBzYXkgZXhhY3Rs eSB0aGUNCnw+IHxzYW1lOiBhIFdlYlJUQyBjbGllbnQgIk1VU1QiIGFsbG93IHBsYWluIFJUUCBp ZiB0aGUNCnw+IHxwZWVyIGlzIG5vdCBhIFdlYlJUQyBjbGllbnQuIFdoeSBpcyB0aGF0IGFuIGFy Z3VtZW50DQp8PiB8aW4gZmF2b3VyIG9mIG5vbiBtYW5kYXRpbmcgU1JUUD8NCnw+DQp8PiBXZSBz ZWVtIHRvIGhhdmUgYSBncm91cCBvZiBwZW9wbGUgY29uY2VybmVkIGFib3V0IHRoZSBjb3N0IGFz c29jaWF0ZWQgd2l0aCBoYXZpbmcgdG8NCnx1cGdyYWRlL3JlcGxhY2Uvc3VwcGxlbWVudCB0aGVp ciBub24tU1JUUCBjYXBhYmxlIGdlYXJzIHN1Y2ggYXMgUFNUTiBnYXRld2F5cywgYW5kIEkgd2Fz IHN5bXBhdGhldGljDQp8dG93YXJkcyB0aGVtIC06KQ0KfA0KfFRoYXQncyAqeW91ciogcHJvYmxl bS4gQnV0IHlvdSB3YW50IHRvIHRyYW5zbGF0ZSAqeW91ciogcHJvYmxlbSBpbnRvDQp8V2ViUlRD IHVzZXJzIGJ5IG1ha2luZyB0aGVpciBjb21tdW5pY2F0aW9ucyBub24gc2VjdXJlLg0KfA0KfElt cGxlbWVudGluZyBTUlRQIGlzIHJlYWxseSBlYXNpZXIgYW5kIGNoZWFwLiBUaGVyZSBpcyBubyBy ZWFzb24gYXQNCnxhbGwgbm90IHRvIG1hbmRhdGUgaXQgaW4gYSBuZXcgc3BlY2lmaWNhdGlvbiwg ZXZlbiBsZXNzIHdoZW4gaXQncw0KfGRlc2lnbmVkIHRvIHdvcmsgaW4gdGhlIG9wZW4gKGFuZCB1 bnRydXN0ZWQpIEludGVybmV0Lg0KfA0KfFNvIGJhZCBsdWNrLiBZb3UsIHRlbGNvcywgaGF2ZSB0 aGUgc3BlY3MgYW5kIHRoZSB0b29scyB0byB1cGdyYWRlIHlvdXINCnxub24tc2VjdXJlIFNJUCBk ZXZpY2VzLiBEbyBpdC4NCnwNCnwNCnwNCnw+IHxJZiBJJ20gaW4gYSBzaGFyZWQgV2lGaSBuZXR3 b3JrIGFuZCByZWNlaXZlIGEgY2FsbCBmcm9tDQp8PiB8YSBub24tV2ViUlRDIGNsaWVudCBub3Qg c3VwcG9ydGluZyBTUlRQLCBteSBuZWlnaGJvcnMgY2FuDQp8PiB8aW50ZXJjZXB0IGl0Lg0KfD4N Cnw+IElmIHRoZSBzaGFyZWQgV2lGaSBuZXR3b3JrIGhhc24ndCBlbXBsb3llZCBXaUZpIGVuY3J5 cHRpb24sIHRoZW4geW91IHdvdWxkIHByb2JhYmx5IGJlIG1vcmUNCnxjb25jZXJuZWQgd2l0aCB5 b3VyIG5laWdoYm9ycyBpbnRlcmNlcHRpbmcgYWxsIG9mIHlvdXIgdHJhZmZpYyB0aGFuIGp1c3Qg UlRQIC06KQ0KfA0KfEl0IHdhcyBqdXN0IGFuIGV4YW1wbGUuIFRoaW5rIGFib3V0IHNvIG1hbnkg b3BlbiBXaUZpIG5ldHdvcmtzIGluDQp8YWlycG9ydHMgKGNhcHRpdmUgcG9ydGFscyB3aXRoIG5v IGVuY3J5cHRpb24pLg0KfA0KfA0KfA0KfD4gfFdoYXQgZG9lcyBzdWNoICJTVFVOIGV4dGVuc2lv biIgcHJvdmlkZXMgaGVyZT8NCnw+DQp8PiBJdCB3b3VsZCB0ZWxsIHRoZSBicm93c2VyIHRoYXQg dGhlIHBlZXIgKGJyb3dzZXIpIGNsYWltcyBXZWJSVEMgY29tcGxpYW5jZSBhbmQgc28gc2hvdWxk bid0IGFsbG93DQp8aW5zZWN1cmUgY2FsbGluZyAodGhlIFNUVU4gZXh0ZW5zaW9uIGlzIGFkZGVk IGJ5IHRoZSBicm93c2VyIGFuZCB0aGUgYXBwbGljYXRpb25zIGhhcyBubyBjb250cm9sIG92ZXIN CnxpdCkuDQp8DQp8SSBpbnNpc3Q6IHRoYXQgcHJvdmlkZXMgbm90aGluZy4gSXQganVzdCBtZWFu cyB0aGF0IG1lLCBhIFdlYlJUQyB1c2VyLA0KfGNvdWxkIGhhdmUgYSBub24tc2VjdXJlIG1lZGlh IHNlc3Npb24gaW4gY2FzZSB0aGUgcmVtb3RlIHBlZXIgaXMgbm90IGENCnxXZWJSVEMgcGVlciAo b3IgYSBwZWVyIGltcGxlbWVudGluZyBTUlRQKS4gSXQgc29sdmVzIG5vdGhpbmcuIEl0IG1ha2Vz DQp8bXkgY29tbXVuaWNhdGlvbiB1bnNhZmUgcmVnYXJkbGVzcyBJJ20gYSBXZWJSVEMgY2xpZW50 IGltcGxlbWVudGluZw0KfFNSVFAuICpNeSogc2VjdXJpdHkgc2hvdWxkIE5PVCBkZXBlbmQgb24g dGhlIHNlY3VyaXR5IGltcGxlbWVudGVkIGluDQp8dGhlIHBlZXIgKHNpbmNlIEkgY2Fubm90IHRy dXN0IHRoZSBwZWVyLCBuZXZlcikuDQp8DQp8DQp8DQp8LS0NCnxJw7Fha2kgQmF6IENhc3RpbGxv DQp8PGliY0BhbGlheC5uZXQ+DQo= From christer.holmberg@ericsson.com Wed Nov 9 11:19:27 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B69521F8A6C for ; Wed, 9 Nov 2011 11:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.041 X-Spam-Level: X-Spam-Status: No, score=-7.041 tagged_above=-999 required=5 tests=[AWL=0.958, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Fznx6XGDXCt for ; Wed, 9 Nov 2011 11:19:26 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C9F0F21F85F1 for ; Wed, 9 Nov 2011 11:19:25 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-22-4ebad23c1739 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 04.5E.09514.C32DABE4; Wed, 9 Nov 2011 20:19:24 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 9 Nov 2011 20:19:24 +0100 From: Christer Holmberg To: Cullen Jennings Date: Wed, 9 Nov 2011 20:15:43 +0100 Thread-Topic: [rtcweb] State of the Forking discussion Thread-Index: Acye7ZtFssqkSE/aSpm6Eaf8TOG4fgAJl7he Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522357173C8@ESESSCMS0356.eemea.ericsson.se> References: <4EB26945.40607@ericsson.com> <0E287F18-E335-472D-853A-0A1B449D2AD7@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852235A07275@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] State of the Forking discussion X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 19:19:27 -0000 Hi, >>> Much of this I don't feel too strongly about but there is one >>> thing that I do have a strong opinion on. I don't want to >>> require PRACK for legacy SIP support because it is has many problems. >> >> If you are not using PRACK, you will not be able to receive a "real" ans= wer before 200 OK, at a point where forking will be no issue anymore :) >> > > I think it is a little more subtle than this. The UAC are not guarantee d= elivery of the 180s without prack but the UAC typically gets them=20 > anyways. Note I am fine with things that do support PRACK, I just don't = want to require it. I also have had good luck with the systems=20 > that send the 180 more than once. I agree. Many systems use SDPs received in unreliable 180s, as if they woul= d have been received in a reliable 180.=20 Of course, a UAC can't send a *new* offer before it has received the SDP re= liably, so a forking solution that is based on sending a new offer (read: a= solution that requires PRACK) would not work. Regards, Christer >> On Nov 3, 2011, at 4:13 AM, Magnus Westerlund wrote: >> >>> WG, >>> >>> I just reviewed the last weeks Forking discussion. This >> includes the >>> threads "RTCWeb Forking usecase [was RE: >>> draft-kaplan-rtcweb-sip-interworking-requirements-00]" and "Media >>> forking solution for SIP interoperability (without a media gateway)" >>> >>> As far as I can tell there is not yet even a rough consensus. >>> Therefore I will attempt to summarize what I personally >> believe to be >>> the important points and alternatives in this discussion. >> Keep in mind >>> that my assumptions or understanding may be unclear or have >> errors. So >>> don't hesitate to challenge what I write. >>> >>> I think it is important that there are in fact at least two >> important >>> questions here. >>> >>> 1. Is forking needed to be supported at all? >>> >>> 2. If it is supported in which form would it supported in. >>> >>> so lets start looking into the arguments and possibilities >> for these >>> two questions. And I do hope that you will read to the end of this >>> mail which is quite long. >>> >>> Lets start with the high level functionality part. Is >> forking needed >>> and what usage does it have. So forking is all about sending out an >>> invitation to a media session including an actual media >> configuration >>> offer, i.e. SDP Offer, then get more than a single answer to that >>> offer back. How you deal with these answers as they come in is the >>> difference between serial and parallel forking. So lets >> define those. >>> >>> Parallel forking: For each answer you receive you establish a new >>> actual media session. Thus if you receive two answers you >> will have to >>> different media sessions that are potentially in use at the >> same time. >>> >>> Serial forking: The first answer is received and results the >>> establishment of a media session. At a later point in time a second >>> answer is received. At that point you take the decision if >> that second >>> answer is going to be used to establish a new media session that >>> replaces the first one. In other words at any given time >> you will only >>> have a single media session established based on each offer. >>> >>> So there has been a number of different views on how one can see on >>> forking. And I think I will have to bring in a bit >> reflections on how >>> this can be done with the current PeerConnection API. >>> >>> A) No forking is needed: Between WebRTC end-points there is no need >>> for forking. Instead the application can send out session >> invitations >>> to the peers it wants to talk to. These are without any SDP Offer >>> equivalent, instead end-points that want to communicate they create >>> PeerConnections, which results in SDP Offers. Thus the >> communication >>> initiating end-point becomes the ones that provides SDP answers and >>> get one PeerConnection per remote end-point that actually >> want to communicate. >>> >>> B) We need to have some interworking with SIP: So the >> fundamental here >>> is that it needs to be reasonable to interwork with SIP, >> independent >>> if one uses a SIP in JS in the application running on the WebRTC >>> enabled browser, or have signalling gateway in the >> webserver, or as a >>> remote WebRTC peer. The issue is that A)'s method of >> initiating call >>> doesn't work well with SIP. There is a need to send a SIP >> Invite with >>> an SDP Offer and that can result in multiple answers. >>> >>> To resolve this one could deal with this in a couple of >> different ways: >>> >>> B1) Use I=F1aki's proposal which forces the WebRTC >> application to create >>> a second PeerConnection and then forces an update in the SIP domain >>> with the second peer-connections Offer. However, it was pointed out >>> that this doesn't work with SIP Provisional answers, as used by ICE >>> for example, unless PRACK is supported. The level of PRACK >> support is >>> reasonable but far from universal so this would limit the >> SIP UAs one >>> can interwork with. However, from WebRTC perspective no forking >>> support is needed. A single PeerConnection results in one >> offer and a >>> single answer is processed. >>> >>> B2) Require WebRTC to handle replace Answers: So the idea >> here is that >>> one changes the PeerConnection API and have underlying >> functionality >>> so that at any point in time a new Answer can pushed onto a >>> PeerConnection and that forces the media session to be >> reestablished >>> if needed. So if the ICE candidate list is different an ICE restart >>> happens. This clearly supports serial forking. It also can >> create some >>> complexities in the underlying SDP handling logic if one >> desires to minimize the media impact. >>> >>> B3) Local side shared parameters in multiple >> PeerConnections: The idea >>> in this proposal is that all PeerConnections generated in a browser >>> context, like a tab will implicit share the fundamental parameters >>> like ICE candidates etc for the number of media streams >> added. So if >>> one creates a second PeerConnection with the same audio+video >>> MediaStream object added I will get an offer that is mostly >> identical >>> to the the first PeerConnection, thus I can push in the answer from >>> the first PeerConnection Offer into the second PC object >> and it will still work. >>> The downside of this is that it is implicit and it becomes >> difficult >>> to determine when it works and when it will fail. It will also be >>> highly dependent on the application performing the right process to >>> get it to work. It also causes a sharing of the parameters when not >>> needed or desired, which primarily is an issue from a >> security point >>> of view, especially with SDES keys (see below). The >> positive is this >>> likely requires no API changes. This method would also >> support parallel forking. >>> >>> B4) Cloning/Factory for PeerConnection: On the API level >> there will be >>> explicit support for generating multiple PeerConnections >> from the same >>> base. This could either be a factory for PeerConnections or some >>> Object constructor that clones an existing PeerConnection >> but that is >>> a W3C question. By being explicit some of the B3) issues >> goes away and >>> the applications can choose when this should happen or not. >> This also >>> support parallel forking as the application can deal with >> each media >>> session independently. This clearly will have some impact >> on the API. >>> >>> >>> Additional considerations: >>> >>> Shared SDES keys: B2 to B4 will result in that SDES keys from the >>> Offering party to be used towards all invited parties. This is >>> security risk as any of the invited parties can spoof the offering >>> side towards any of the other invited parties. This threat can be >>> resolved by having the inviter rekey immediately after >> having received an answer. >>> >>> Sharing ICE candidates: B3 and B4 and also B2 to some degree will >>> share the ICE candidates. That has certain implications. One is the >>> positive in that it minimizes the resource consumption as >> additional >>> PeerConnections come at very little extra cost, no need for >> additional >>> ICE gathering candidate phases, and also be very quick as >> no external >>> communication is required. The downside of this is that the >> end-points >>> candidates must always be kept alive as long as some PeerConnection >>> instance exist. Because the browser never knows when the >> application >>> may create an additional PC and expect them to have the >> same ICE candidates. >>> It should also be noted that the answering WebRTC end-point >> will need >>> to gather candidates for each offer. Otherwise it will become >>> impossible to create multiple PeerConnections between the same >>> end-points if that is desired by the application. >>> >>> >>> I know the above doesn't list all of the pro and cons of >> the different >>> alternatives. So please fill in additional arguments. And >> if I missed >>> some proposal please add that also if relevant >>> >>> As you may have noted I the two questions in the above have kind of >>> floated together. The reason for this is that I think the >> majority are >>> fine with having SIP support as long as it doesn't have to >> high cost >>> or complexity associated with it. Thus, the question how >> becomes very >>> intertwined with forking support yes or no. >>> >>> So please continue the discussion >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> >> ---------------------------------------------------------------------- >>> Multimedia Technologies, Ericsson Research EAB/TVM >>> >> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >>> >> ---------------------------------------------------------------------- >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Wed Nov 9 11:34:19 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1E811E8099 for ; Wed, 9 Nov 2011 11:34:19 -0800 (PST) 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 9e1RzlI3NEpc for ; Wed, 9 Nov 2011 11:34:18 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B443D11E8091 for ; Wed, 9 Nov 2011 11:34:18 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so1972494vcb.31 for ; Wed, 09 Nov 2011 11:34:18 -0800 (PST) Received: by 10.52.187.68 with SMTP id fq4mr6912007vdc.32.1320867258121; Wed, 09 Nov 2011 11:34:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Wed, 9 Nov 2011 11:33:56 -0800 (PST) In-Reply-To: <1D062974A4845E4D8A343C653804920206D3BAEE@XMB-BGL-414.cisco.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA71@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C653804920206D3BAEE@XMB-BGL-414.cisco.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 9 Nov 2011 20:33:56 +0100 Message-ID: To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 19:34:19 -0000 2011/11/9 Muthu Arul Mozhi Perumal (mperumal) : > |That's *your* problem. But you want to translate > |*your* problem into WebRTC users by making their > |communications non secure. > > Well, most often you as a WebRTC user will be the one who would want to r= each someone behind legacy systems You could consider that people in internet is not so excited with the possibility of making a legacy PSTN from the browser. In fact, calling a PSTN number from a web has no added value at all. Users already have their legacy PSTN phones. > |Implementing SRTP is really easier and cheap. > > Sure, in a browser. But, may not be for a provider. Sure they can scale their systems. > |You, telcos, have the specs and the tools to upgrade your > |non-secure SIP devices. Do it. > > If you are willing to pay for it, I don't see why the tolcos won't -:) I should not pay a telco for making my call safe. The telco should do it. > |*My* security should NOT depend on the security > |implemented in the peer (since I cannot trust the > |peer, never). > > Good luck. You peer could be a media gateway sitting somewhere in the Int= ernet converting SRTP to RTP and sending to the other part of the world. Of course, but at least, I will know that the call is secure within my local network. Imagine I open my laptop in an airport, connect to a open WiFi (cautive portal) and make a call to another user via web, but the server must route it (via a SIP gateway) to a SIP softswitch, and that makes my call to use plain RTP. I'm in an airport, in an open WiFi network. Bad. But if my call uses SRTP until the SIP media gateway, then it could use plain RTP in the PSTN network. That's not so dangerous. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Nov 9 11:38:13 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C390711E808B for ; Wed, 9 Nov 2011 11:38:13 -0800 (PST) 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 RiMQ-jibhNCP for ; Wed, 9 Nov 2011 11:38:13 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC59211E8083 for ; Wed, 9 Nov 2011 11:38:08 -0800 (PST) Received: by vws5 with SMTP id 5so2083137vws.31 for ; Wed, 09 Nov 2011 11:38:08 -0800 (PST) Received: by 10.52.113.227 with SMTP id jb3mr6952238vdb.15.1320867488063; Wed, 09 Nov 2011 11:38:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Wed, 9 Nov 2011 11:37:47 -0800 (PST) In-Reply-To: References: <4EB26D22.5090000@ericsson.com> <4EBA741A.1010307@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 9 Nov 2011 20:37:47 +0100 Message-ID: To: Wolfgang Beck Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 19:38:13 -0000 2011/11/9 Wolfgang Beck : > This has happened with SIP. As most of the interconnection is done > through the PSTN, we don't see many exciting new SIP applications in > wide use. I don't fully understand why some SIP folks try to "export" the SIP trapezoid model to WebRTC taking into account that such trapezoid has never succeeded in pure SIP networks. Anyhow, reading the last mails in this thread... what are we discussing about? IHMO all of us (at least in this thread) agree on the fact that mandating/defining a server-to-server interconnection model is a no-go. Is it just about the exact text for the draft? It's easy, just say "two WebRTC sites can federate by using any mechanism they desire for such interconnection. It could be pure SIP, XMPP or whatever protocol/mechanism they agree." --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed Nov 9 11:54:52 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0121021F84AF for ; Wed, 9 Nov 2011 11:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.095, 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 k-i67os9tQ9f for ; Wed, 9 Nov 2011 11:54:51 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 34D9611E808B for ; Wed, 9 Nov 2011 11:54:51 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-bb-4ebada8a1caa Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BC.20.09514.A8ADABE4; Wed, 9 Nov 2011 20:54:50 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 9 Nov 2011 20:54:49 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "Muthu Arul Mozhi Perumal (mperumal)" Date: Wed, 9 Nov 2011 20:54:50 +0100 Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AcyfFpZDvdoy5yfaQ66OoD4ViYDyoQAAM7Fr Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522357173CA@ESESSCMS0356.eemea.ericsson.se> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA71@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C653804920206D3BAEE@XMB-BGL-414.cisco.com>, 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== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 19:54:52 -0000 Hi, >> |That's *your* problem. But you want to translate >> |*your* problem into WebRTC users by making their >> |communications non secure. >> >> Well, most often you as a WebRTC user will be the one who would want to = reach someone behind legacy systems > > You could consider that people in internet is not so excited with the > possibility of making a legacy PSTN from the browser. In fact, calling > a PSTN number from a web has no added value at all. Users already have > their legacy PSTN phones. I don't think we shall speculate in how people will use, and to whom the wi= ll call, using their browser apps. AFAIK, most SIP calls today end up in PSTN, and the browser technology will= allow people to access "SIP phones" from more or less any computer connect= ed to the internet. >>> |*My* security should NOT depend on the security >>> |implemented in the peer (since I cannot trust the >>> |peer, never). >>> >> Good luck. You peer could be a media gateway sitting somewhere in the In= ternet converting SRTP to RTP and sending to the other part of the world. > > Of course, but at least, I will know that the call is secure within my > local network. Imagine I open my laptop in an airport, connect to a > open WiFi (cautive portal) and make a call to another user via web, > but the server must route it (via a SIP gateway) to a SIP softswitch, > and that makes my call to use plain RTP. I'm in an airport, in an open > WiFi network. Bad. > > But if my call uses SRTP until the SIP media gateway, then it could > use plain RTP in the PSTN network. That's not so dangerous. So, in your example you are basically talking about "access network securit= y", because you don't really care what happens (with regards to media secur= ity) after the WiFi access leg? Regards, Christer From ibc@aliax.net Wed Nov 9 12:19:12 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305D61F0C6F for ; Wed, 9 Nov 2011 12:19:12 -0800 (PST) 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 2GNN8dC2O9Dx for ; Wed, 9 Nov 2011 12:19:11 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3C41F0C5D for ; Wed, 9 Nov 2011 12:19:11 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so2015971vcb.31 for ; Wed, 09 Nov 2011 12:19:11 -0800 (PST) Received: by 10.52.33.239 with SMTP id u15mr7097798vdi.49.1320869951051; Wed, 09 Nov 2011 12:19:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Wed, 9 Nov 2011 12:18:50 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522357173CA@ESESSCMS0356.eemea.ericsson.se> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA71@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C653804920206D3BAEE@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058522357173CA@ESESSCMS0356.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 9 Nov 2011 21:18:50 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Let's define the purpose of 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: Wed, 09 Nov 2011 20:19:12 -0000 2011/11/9 Christer Holmberg : >> But if my call uses SRTP until the SIP media gateway, then it could >> use plain RTP in the PSTN network. That's not so dangerous. > > So, in your example you are basically talking about "access network secur= ity", because you don't really care what happens (with regards to media sec= urity) after the WiFi access leg? No. I said that, in case the other end is a PSTN peer, most *probably* the call would end in a PSTN gateway which routes the call via PSTN, so more or less "trusted". --=20 I=C3=B1aki Baz Castillo From bernard_aboba@hotmail.com Wed Nov 9 15:11:25 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA8911E809A for ; Wed, 9 Nov 2011 15:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 J8z1IXdV7b61 for ; Wed, 9 Nov 2011 15:11:24 -0800 (PST) Received: from blu0-omc3-s14.blu0.hotmail.com (blu0-omc3-s14.blu0.hotmail.com [65.55.116.89]) by ietfa.amsl.com (Postfix) with ESMTP id 6317311E8087 for ; Wed, 9 Nov 2011 15:11:24 -0800 (PST) Received: from BLU152-DS12 ([65.55.116.74]) by blu0-omc3-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 15:11:24 -0800 X-Originating-IP: [131.107.0.98] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Tim Panton'" References: <084BA945-E5AB-480D-8608-1340E8C8125F@phonefromhere.com>, <6CB98137-B2A4-488C-BF5C-D7D87B23C7EC@cisco.com> <81E7739C-2C54-465B-B79F-9DC99BFDEAE0@phonefromhere.com> In-Reply-To: <81E7739C-2C54-465B-B79F-9DC99BFDEAE0@phonefromhere.com> Date: Wed, 9 Nov 2011 15:11:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK3klpE9bh0syVZ9dPKHFC+bqO2DQKnvd6zAfyFwKQBGc1qBJOhUjRw Content-Language: en-us X-OriginalArrivalTime: 09 Nov 2011 23:11:24.0173 (UTC) FILETIME=[E6889BD0:01CC9F34] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Usecases for innovation. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Nov 2011 23:11:25 -0000 Tim said: "Both cases point out the fact that tying codecs/networking/negotiation into one object and only presenting a (somewhat opaque) blob of SDP to represent them limits what we can do at the javascript end. That may be a limitation we can live with, but at least we need to acknowledge that it is a limitation." [BA] For webcams with hardware encode/decode, this is an issue. Given the performance/power issues, it is important to enable the device capabilities/codec support to be integrated. It's one thing to talk about what codecs a browser needs to support, but it should be recognized that hardware could supplement those capabilities, and the browser shouldn't be a bottleneck preventing the hardware from being utilized. From pravindran@sonusnet.com Wed Nov 9 21:19:21 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCB921F87C2 for ; Wed, 9 Nov 2011 21:19:21 -0800 (PST) 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.021, 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 NGIEjF3ALh9S for ; Wed, 9 Nov 2011 21:19:20 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1B721F8797 for ; Wed, 9 Nov 2011 21:19:20 -0800 (PST) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pAA5JsWw012364; Thu, 10 Nov 2011 00:19:54 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 00:19:14 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 10:49:23 +0530 Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by inba-hub01.sonusnet.com (10.70.51.86) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 10 Nov 2011 10:49:23 +0530 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.0339.001; Thu, 10 Nov 2011 10:49:23 +0530 From: "Ravindran, Parthasarathi" To: Eric Rescorla Thread-Topic: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of WebRTC) Thread-Index: AQHMnoiMLXoobGtfx0Kkx8oSZTnrRJWj1oYwgABiqoCAAVQz4A== Date: Thu, 10 Nov 2011 05:19:23 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0134A6B5@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <4EB9ACF5.80805@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FE6@inba-mail01.sonusnet.com> 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.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Nov 2011 05:19:23.0995 (UTC) FILETIME=[4F2212B0:01CC9F68] Cc: "<,rtcweb@ietf.org>," Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of 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: Thu, 10 Nov 2011 05:19:21 -0000 Eric, I agree with you about performance in case of desktop as I'm able to execut= e Skype video call and other application simultaneously without any perform= ance impact. AFAIK in case of telepresence or equivalent endpoint, it requi= res the special hardware to encrypt/decrypt the whole bunch of media from i= t. WebRTC browser could be executed on any of these kind of endpoint as wel= l. As you mentioned, I often heard that Enterprise is not secure which require= s different level of security but this argument is not well accepted in the= deployment so far :-(=20 Thanks Partha >-----Original Message----- >From: Eric Rescorla [mailto:ekr@rtfm.com] >Sent: Wednesday, November 09, 2011 7:40 PM >To: Ravindran, Parthasarathi >Cc: Cameron Byrne; <,rtcweb@ietf.org>, >Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define >the purpose of WebRTC) > >On Tue, Nov 8, 2011 at 6:50 PM, Ravindran Parthasarathi > wrote: >> Cameron, >> >> >> >> I guess that we are in the same w.r.t IETF privacy policy and it is >main >> reason, I take back my comment #2. But, Please look into comment #1 >for >> Enterprise WebRTC application wherein SRTP is not required to be >mandated. >> > >Partha, > >I don't understand what resource you are conserving here by avoiding >multiple encryption. > >Even if we stipulate that the enterprise network is secure (which as >Cameron has suggested, is often not the case even when people believe it >is), >the actual cost to encrypt the data on the endpoints is quite low, >especially when compared to the added complexity cost of trying to make >the >(extremely difficult) determination of whether whatever network >encryption >is in place is sufficient to protect your call. Better to just encrypt >all >the time. > >-Ekr From ekr@rtfm.com Wed Nov 9 21:21:30 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568B821F8485 for ; Wed, 9 Nov 2011 21:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=0.035, 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 emWK0WFf8Ysc for ; Wed, 9 Nov 2011 21:21:29 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 96BEC21F8484 for ; Wed, 9 Nov 2011 21:21:29 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so2361966vcb.31 for ; Wed, 09 Nov 2011 21:21:29 -0800 (PST) Received: by 10.220.2.19 with SMTP id 19mr707328vch.161.1320902489114; Wed, 09 Nov 2011 21:21:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Wed, 9 Nov 2011 21:20:48 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> From: Eric Rescorla Date: Wed, 9 Nov 2011 21:20:48 -0800 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Thu, 10 Nov 2011 05:21:30 -0000 On Wed, Nov 9, 2011 at 6:33 AM, Roman Shpount wrote: > On Wed, Nov 9, 2011 at 8:44 AM, I=F1aki Baz Castillo wrot= e > 2. SRTP is not required: If we are dealing with a greeting card applicati= on > or game chat, no one expects security. If security can be provided this w= ill > probably not hurt anybody, but in the end it will serve no purpose there. I'm focusing solely on this point because I think it does such a good job of demonstrating the limitations of this kind of "who would ever want secur= ity for application X" thinking. I can envision situations on which security would be desirable in both of these applications. In the case of a "greeting card application" (whatever that is) my greeting card might contain sensitive personal or medical information (congratulations on your pregnancy, sorry to hear you have cancer etc.) Surely I do in fact want that information secured. Similarly, it might not be important to have my Farmville chats secure, but if the purpose of an in-game chat is for me and my co-player to cooperate in a game where money is on the line (e.g., a tournament), then suddenlu security becomesmuch more important. Not to mention that the players may simply be using in-game chat to discuss personal stuff. The point is that it's very hard to anticipate which communications media will be used for sensitive information. To say "we don't need security in this application because nobody will ever use it to discuss sensitive stuff" is short-sighted. Better simply to be secure all the time. -Ekr From ekr@rtfm.com Wed Nov 9 21:24:47 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F7F21F8488 for ; Wed, 9 Nov 2011 21:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.945 X-Spam-Level: X-Spam-Status: No, score=-102.945 tagged_above=-999 required=5 tests=[AWL=0.032, 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 w9GPbJsfbgWS for ; Wed, 9 Nov 2011 21:24:47 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE5921F848B for ; Wed, 9 Nov 2011 21:24:45 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so2363434vcb.31 for ; Wed, 09 Nov 2011 21:24:45 -0800 (PST) Received: by 10.52.29.9 with SMTP id f9mr10185889vdh.30.1320902685103; Wed, 09 Nov 2011 21:24:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Wed, 9 Nov 2011 21:24:04 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0134A6B5@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <4EB9ACF5.80805@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FE6@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A6B5@inba-mail01.sonusnet.com> From: Eric Rescorla Date: Wed, 9 Nov 2011 21:24:04 -0800 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "<,rtcweb@ietf.org>," Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of 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: Thu, 10 Nov 2011 05:24:47 -0000 On Wed, Nov 9, 2011 at 9:19 PM, Ravindran, Parthasarathi wrote: > Eric, > > I agree with you about performance in case of desktop as I'm able to exec= ute Skype video call and other application simultaneously without any perfo= rmance impact. AFAIK in case of telepresence or equivalent endpoint, it req= uires the special hardware to encrypt/decrypt the whole bunch of media from= it. WebRTC browser could be executed on any of these kind of endpoint as w= ell. I'd be interested in any measurements you have to offer here. My Macbook Air does on the order of 100 MB/s of AES-128 on a single core. What's the bandwidth of a telepresence system? -Ekr > As you mentioned, I often heard that Enterprise is not secure which requi= res different level of security but this argument is not well accepted in t= he deployment so far :-( > > Thanks > Partha > >>-----Original Message----- >>From: Eric Rescorla [mailto:ekr@rtfm.com] >>Sent: Wednesday, November 09, 2011 7:40 PM >>To: Ravindran, Parthasarathi >>Cc: Cameron Byrne; <,rtcweb@ietf.org>, >>Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define >>the purpose of WebRTC) >> >>On Tue, Nov 8, 2011 at 6:50 PM, Ravindran Parthasarathi >> wrote: >>> Cameron, >>> >>> >>> >>> I guess that we are in the same w.r.t IETF privacy policy and it is >>main >>> reason, I take back my comment #2. But, Please look into comment #1 >>for >>> Enterprise WebRTC application wherein SRTP is not required to be >>mandated. >>> >> >>Partha, >> >>I don't understand what resource you are conserving here by avoiding >>multiple encryption. >> >>Even if we stipulate that the enterprise network is secure (which as >>Cameron has suggested, is often not the case even when people believe it >>is), >>the actual cost to encrypt the data on the endpoints is quite low, >>especially when compared to the added complexity cost of trying to make >>the >>(extremely difficult) determination of whether whatever network >>encryption >>is in place is sufficient to protect your call. Better to just encrypt >>all >>the time. >> >>-Ekr > From roman@telurix.com Wed Nov 9 21:48:53 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B68821F84A7 for ; Wed, 9 Nov 2011 21:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.889 X-Spam-Level: X-Spam-Status: No, score=-2.889 tagged_above=-999 required=5 tests=[AWL=0.087, 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 gK5sCOtVELOE for ; Wed, 9 Nov 2011 21:48:52 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0B921F87FA for ; Wed, 9 Nov 2011 21:48:52 -0800 (PST) Received: by ggnr4 with SMTP id r4so1156765ggn.31 for ; Wed, 09 Nov 2011 21:48:51 -0800 (PST) Received: by 10.101.171.34 with SMTP id y34mr2681655ano.8.1320904130934; Wed, 09 Nov 2011 21:48:50 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id o64sm11034430yhk.3.2011.11.09.21.48.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Nov 2011 21:48:50 -0800 (PST) Received: by ywt34 with SMTP id 34so345842ywt.31 for ; Wed, 09 Nov 2011 21:48:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.16.3 with SMTP id b3mr11390714pbd.86.1320904129099; Wed, 09 Nov 2011 21:48:49 -0800 (PST) Received: by 10.68.62.170 with HTTP; Wed, 9 Nov 2011 21:48:48 -0800 (PST) In-Reply-To: References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> Date: Thu, 10 Nov 2011 00:48:48 -0500 Message-ID: From: Roman Shpount To: Eric Rescorla Content-Type: multipart/alternative; boundary=bcaec5215f7365b79904b15af543 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Thu, 10 Nov 2011 05:48:53 -0000 --bcaec5215f7365b79904b15af543 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 10, 2011 at 12:20 AM, Eric Rescorla wrote: > The point is that it's very hard to anticipate which communications media > will be used for sensitive information. To say "we don't need security > in this application because nobody will ever use it to discuss sensitive > stuff" is short-sighted. Better simply to be secure all the time. > > So why is 99% of the web traffic is HTTP? Do you want to force everybody to use HTTPS? I think your argument is simply stating encryption is good, no encryption bad, even if it is not needed or if it does not protect anything (WebRTC application delivered over HTTP). _____________ Roman Shpount --bcaec5215f7365b79904b15af543 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 10, 2011 at 12:20 = AM, Eric Rescorla <ekr= @rtfm.com> wrote:
The point is that it's very hard to anticipate which communications med= ia
will be used for sensitive information. To say "we don't need secu= rity
in this application because nobody will ever use it to discuss sensitive stuff" is short-sighted. Better simply to be secure all the time.


So why is 99% of the web traffic is HTTP? Do you= want to force everybody to use HTTPS? I think your argument is simply stat= ing encryption is good, no encryption bad, even if it is not needed or if i= t does not protect anything (WebRTC application delivered over HTTP).
_____________
Roman Shpount


--bcaec5215f7365b79904b15af543-- From pravindran@sonusnet.com Wed Nov 9 21:50:08 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF56E21F8880 for ; Wed, 9 Nov 2011 21:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 heWFRLClllk7 for ; Wed, 9 Nov 2011 21:50:08 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 20B7221F8801 for ; Wed, 9 Nov 2011 21:50:08 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pAA5ohuX000328; Thu, 10 Nov 2011 00:50:43 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 00:40:46 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 11:10:56 +0530 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.0339.001; Thu, 10 Nov 2011 11:10:56 +0530 From: "Ravindran, Parthasarathi" To: Eric Rescorla Thread-Topic: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of WebRTC) Thread-Index: AQHMnoiMLXoobGtfx0Kkx8oSZTnrRJWj1oYwgABiqoCAAVQz4P//q0QAgABeqYA= Date: Thu, 10 Nov 2011 05:40:55 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0134A6DF@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <4EB9ACF5.80805@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FE6@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A6B5@inba-mail01.sonusnet.com> 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.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Nov 2011 05:40:56.0776 (UTC) FILETIME=[51B0CC80:01CC9F6B] Cc: "<,rtcweb@ietf.org>," Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of 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: Thu, 10 Nov 2011 05:50:09 -0000 Eric, Of course, the bandwidth requirement is range from 4MB/s to 16MB/s based on= deployment but the point to be noted is that the device is not doing encry= ption/decryption alone. Thanks Partha >-----Original Message----- >From: Eric Rescorla [mailto:ekr@rtfm.com] >Sent: Thursday, November 10, 2011 10:54 AM >To: Ravindran, Parthasarathi >Cc: Cameron Byrne; <,rtcweb@ietf.org>, >Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define >the purpose of WebRTC) > >On Wed, Nov 9, 2011 at 9:19 PM, Ravindran, Parthasarathi > wrote: >> Eric, >> >> I agree with you about performance in case of desktop as I'm able to >execute Skype video call and other application simultaneously without >any performance impact. AFAIK in case of telepresence or equivalent >endpoint, it requires the special hardware to encrypt/decrypt the whole >bunch of media from it. WebRTC browser could be executed on any of these >kind of endpoint as well. > >I'd be interested in any measurements you have to offer here. >My Macbook Air does on the order of 100 MB/s of AES-128 >on a single core. What's the bandwidth of a telepresence >system? > >-Ekr > >> As you mentioned, I often heard that Enterprise is not secure which >requires different level of security but this argument is not well >accepted in the deployment so far :-( >> >> Thanks >> Partha >> >>>-----Original Message----- >>>From: Eric Rescorla [mailto:ekr@rtfm.com] >>>Sent: Wednesday, November 09, 2011 7:40 PM >>>To: Ravindran, Parthasarathi >>>Cc: Cameron Byrne; <,rtcweb@ietf.org>, >>>Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define >>>the purpose of WebRTC) >>> >>>On Tue, Nov 8, 2011 at 6:50 PM, Ravindran Parthasarathi >>> wrote: >>>> Cameron, >>>> >>>> >>>> >>>> I guess that we are in the same w.r.t IETF privacy policy and it is >>>main >>>> reason, I take back my comment #2. But, Please look into comment #1 >>>for >>>> Enterprise WebRTC application wherein SRTP is not required to be >>>mandated. >>>> >>> >>>Partha, >>> >>>I don't understand what resource you are conserving here by avoiding >>>multiple encryption. >>> >>>Even if we stipulate that the enterprise network is secure (which as >>>Cameron has suggested, is often not the case even when people believe >it >>>is), >>>the actual cost to encrypt the data on the endpoints is quite low, >>>especially when compared to the added complexity cost of trying to >make >>>the >>>(extremely difficult) determination of whether whatever network >>>encryption >>>is in place is sufficient to protect your call. Better to just encrypt >>>all >>>the time. >>> >>>-Ekr >> From ekr@rtfm.com Wed Nov 9 21:54:28 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6705811E8097 for ; Wed, 9 Nov 2011 21:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.030, 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 EOrMy2B008sw for ; Wed, 9 Nov 2011 21:54:27 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 89B2B21F86FF for ; Wed, 9 Nov 2011 21:54:27 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so2377671vcb.31 for ; Wed, 09 Nov 2011 21:54:27 -0800 (PST) Received: by 10.220.2.19 with SMTP id 19mr717360vch.161.1320904467068; Wed, 09 Nov 2011 21:54:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Wed, 9 Nov 2011 21:53:46 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0134A6DF@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <4EB9ACF5.80805@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FE6@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A6B5@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A6DF@inba-mail01.sonusnet.com> From: Eric Rescorla Date: Wed, 9 Nov 2011 21:53:46 -0800 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=ISO-8859-1 Cc: "<,rtcweb@ietf.org>," Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of 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: Thu, 10 Nov 2011 05:54:28 -0000 On Wed, Nov 9, 2011 at 9:40 PM, Ravindran, Parthasarathi wrote: > Eric, > > Of course, the bandwidth requirement is range from 4MB/s to 16MB/s based on deployment but the point to be noted is that the device is not doing encryption/decryption alone. Of course not, but based on the data I just provided and these bandwidth estimates, encryption would consume on the order of 5-10% of a relatively modest machine. Again, do you have any actual measurements that show that crypto is a serious performance problem? -Ekr From ekr@rtfm.com Wed Nov 9 21:58:10 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2EF21F899F for ; Wed, 9 Nov 2011 21:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=0.028, 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 Ja3EeDa+RdAL for ; Wed, 9 Nov 2011 21:58:10 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8920E21F8A4B for ; Wed, 9 Nov 2011 21:58:08 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so2379285vcb.31 for ; Wed, 09 Nov 2011 21:58:08 -0800 (PST) Received: by 10.220.187.136 with SMTP id cw8mr680719vcb.266.1320904688087; Wed, 09 Nov 2011 21:58:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Wed, 9 Nov 2011 21:57:26 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> From: Eric Rescorla Date: Wed, 9 Nov 2011 21:57:26 -0800 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Let's define the purpose of 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: Thu, 10 Nov 2011 05:58:10 -0000 On Wed, Nov 9, 2011 at 9:48 PM, Roman Shpount wrote: > > On Thu, Nov 10, 2011 at 12:20 AM, Eric Rescorla wrote: >> >> The point is that it's very hard to anticipate which communications media >> will be used for sensitive information. To say "we don't need security >> in this application because nobody will ever use it to discuss sensitive >> stuff" is short-sighted. Better simply to be secure all the time. >> > > So why is 99% of the web traffic is HTTP? Do you want to force everybody to > use HTTPS? I think your argument is simply stating encryption is good, no > encryption bad, even if it is not needed or if it does not protect anything > (WebRTC application delivered over HTTP). My argument is that it's extremely hard to determine a priori when encryption is needed and when it is not, as evidenced by the fact that even in the examples *you* suggested, there are settings when encryption is needed. As for the question of whether encryption should be used when WebRTC applications are used over HTTP, as Matthew Kaufman, Alan Johnston, and myself have all observed, there are technical mechanisms (albeit suboptimal ones) which can provide security even if the application is delivered over HTTP (though of course this is still not advisable for other reasons.) -Ekr From mperumal@cisco.com Wed Nov 9 23:42:48 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CCD1F0C3F for ; Wed, 9 Nov 2011 23:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.781 X-Spam-Level: X-Spam-Status: No, score=-8.781 tagged_above=-999 required=5 tests=[AWL=1.518, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 bcECZdtR2a+H for ; Wed, 9 Nov 2011 23:42:47 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB3821F845D for ; Wed, 9 Nov 2011 23:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3078; q=dns/txt; s=iport; t=1320910961; x=1322120561; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=fPG5H8u/+8Cvcj8J1l6/40WoVdCxTOh2UqpgViSEpig=; b=U+dYiQrKJO6m1+dV4VodZJBEno0q4NF4HQhewkwQnMMt9yoLL7VGNSjf /7sVnrYsbtSjgKsNd8ilBH59YwisnTfQIFeUFzWMvxNJYxICk0oy+hjUt J/QsXu4xzrlEHmeTTHhdY4vWPiq0n2MhOqQsoDmLQo/m2MSkjiL8nAfVL s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswAAGp/u05Io8UT/2dsb2JhbABCmiyPfoEFgXIBAQEEAQEBDwEdPgsMBAIBCBEEAQELBhMEAQYBJh8JCAEBBAEJAQgIEweHaJlyAZ5nBIkbYwSHXi+RWYw8 X-IronPort-AV: E=Sophos;i="4.69,488,1315180800"; d="scan'208";a="59558764" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 10 Nov 2011 07:42:36 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAA7gZuh010484; Thu, 10 Nov 2011 07:42:35 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 13:12:35 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Nov 2011 13:09:40 +0530 Message-ID: <1D062974A4845E4D8A343C653804920206D3BC60@XMB-BGL-414.cisco.com> In-Reply-To: <4EB79FC2.10400@alvestrand.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SRTP - mandatory to implement vs mandatory to use (Re: Let's define the purpose of WebRTC) Thread-Index: AcydLKmPjjNtVhmLQauOSPGkAXDjEACTTMuQ References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB79FC2.10400@alvestrand.no> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Harald Alvestrand" , =?iso-8859-1?Q?Jos=E9_Luis_Mill=E1n?= X-OriginalArrivalTime: 10 Nov 2011 07:42:35.0131 (UTC) FILETIME=[4FD964B0:01CC9F7C] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP - mandatory to implement vs mandatory to use (Re: Let's define the purpose of 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: Thu, 10 Nov 2011 07:42:48 -0000 |At the moment, draft-ietf-rtcweb-rtp-usage does not contain any |requirement on SRTP usage (the security section says "A mandatory=20 |to implement media security solution will be required to be picked",=20 |which I think is a bit weak), and the discussion at the time did not=20 |seem to indicate consensus that SRTP must be used always, so I=20 |decided to document what we seemed to have consensus on - that SRTP=20 |MUST be implemented. Does it mean: a. The WebRTC browser MUST implement SRTP, but the WebRTC service/JS = needn't use it OR b. The WebRTC browser and the service/JS MUST implement SRTP, but the = user needn't have to use it? thanks, Muthu |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Harald Alvestrand |Sent: Monday, November 07, 2011 2:37 PM |To: Jos=E9 Luis Mill=E1n |Cc: |Subject: [rtcweb] SRTP - mandatory to implement vs mandatory to use = (Re: Let's define the purpose of |WebRTC) | |On 11/06/2011 10:16 AM, Jos=E9 Luis Mill=E1n wrote: |> draft-ietf-rtcweb-overview-02 downgraded the SRTP concerns from |> mandatory-to-use to mandatory-to-implement. So if it does not |> downgrade anymore, a WebRTC implementation (game app, greeting cards |> website..) will have to implement SRTP. |> |> IMHO, if a web service doesn't want to take, or cannot take, the hit |> for SRTP, WebRTC is not the appropriate solution for such a service. |> |Forking this thread, since it's actually about a line in the = documents.... | |in draft-ietf-rtcweb-overview-02, I changed this section: | |5. Data framing and securing | | SRTP [RFC3550] is used for transport of all real-time media. | | The detailed considerations for usage of functions from RTP and = SRTP, | as well as for non-media real-time data, are given in . | |into this section: | |5. Data framing and securing | | The format for media transport is RTP [RFC3550]. Implementation of | SRTP [RFC3711] is required for all implementations. | | The detailed considerations for usage of functions from RTP and = SRTP | are given in [I-D.ietf-rtcweb-rtp-usage]. Key negotiation for SRTP | is described in . Transfer of data that is not in RTP | format is described in . | |At the moment, draft-ietf-rtcweb-rtp-usage does not contain any |requirement on SRTP usage (the security section says "A mandatory to |implement media security solution will be required to be picked", which |I think is a bit weak), and the discussion at the time did not seem to |indicate consensus that SRTP must be used always, so I decided to |document what we seemed to have consensus on - that SRTP MUST be |implemented. | |If we have consensus to make it stronger again, I'm happy to change it = back. | | Harald | | | |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Thu Nov 10 00:02:52 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1DE1F0C48 for ; Thu, 10 Nov 2011 00:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 3SKAppRxXcEg for ; Thu, 10 Nov 2011 00:02:52 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 09EF91F0C44 for ; Thu, 10 Nov 2011 00:02:51 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1ROPb1-00013H-6M for rtcweb@ietf.org; Thu, 10 Nov 2011 02:02:51 -0600 Message-ID: <4EBB8504.4050402@jesup.org> Date: Thu, 10 Nov 2011 03:02:12 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <4EB9ACF5.80805@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FE6@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A6B5@inba-mail01.sonusnet.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] SRTP requirement - wiretapping (Re: Let's define the purpose of 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: Thu, 10 Nov 2011 08:02:52 -0000 On 11/10/2011 12:24 AM, Eric Rescorla wrote: > On Wed, Nov 9, 2011 at 9:19 PM, Ravindran, Parthasarathi > wrote: >> Eric, >> >> I agree with you about performance in case of desktop as I'm able to execute Skype video call and other application simultaneously without any performance impact. AFAIK in case of telepresence or equivalent endpoint, it requires the special hardware to encrypt/decrypt the whole bunch of media from it. WebRTC browser could be executed on any of these kind of endpoint as well. > I'd be interested in any measurements you have to offer here. > My Macbook Air does on the order of 100 MB/s of AES-128 > on a single core. What's the bandwidth of a telepresence > system? I don't have a good benchmark source, but stuff I'm seeing rooting around implies that tablet/phone cores like Tegras with AES accelerators can run AES-128 at somewhere in the <16MB/s rate, rather lower (1/2? 1/4? 1/10?) on the CPU (which is likely what we'd be using). These are horribly rough numbers, and might even be optimistic. If we're down in low single-digit MB/s AES in SW, we might be using a noticeable amount of CPU (5, 10%, more) on a tablet or phone in some use cases (where we might be pushing around a few 1Mbps streams). I should note that I don't feel that's likely to influence my opinion; I don't think performance on the browser/phone is a significant reason to make it optional. Performance on a low-end webrtc "PBX" box or media gateway or mixing server handling a lot of these streams - maybe. I'm not including dedicated custom SBC-like solutions; I'm assuming generic HW or cloud services used by a website/service. But making SRTP optional-to-use is fraught with dangers of bid-down attacks; we would need to be sure that reducing costs for some services (and thus users) doesn't endanger other users. -- Randell Jesup randell-ietf@jesup.org From harald@alvestrand.no Thu Nov 10 00:34:29 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829F121F8770 for ; Thu, 10 Nov 2011 00:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.557 X-Spam-Level: X-Spam-Status: No, score=-110.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 OgRhk6-FZaeK for ; Thu, 10 Nov 2011 00:34:29 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D93ED21F86A0 for ; Thu, 10 Nov 2011 00:34:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3CC0339E0FC; Thu, 10 Nov 2011 09:34:27 +0100 (CET) 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 XT5HK-il8SPj; Thu, 10 Nov 2011 09:34:26 +0100 (CET) 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 ESMTPS id 95C7F39E089; Thu, 10 Nov 2011 09:34:26 +0100 (CET) Message-ID: <4EBB8C92.50706@alvestrand.no> Date: Thu, 10 Nov 2011 09:34:26 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: "Muthu Arul Mozhi Perumal (mperumal)" References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB79FC2.10400@alvestrand.no> <1D062974A4845E4D8A343C653804920206D3BC60@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920206D3BC60@XMB-BGL-414.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP - mandatory to implement vs mandatory to use (Re: Let's define the purpose of 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: Thu, 10 Nov 2011 08:34:29 -0000 On 11/10/2011 08:39 AM, Muthu Arul Mozhi Perumal (mperumal) wrote: > |At the moment, draft-ietf-rtcweb-rtp-usage does not contain any > |requirement on SRTP usage (the security section says "A mandatory > |to implement media security solution will be required to be picked", > |which I think is a bit weak), and the discussion at the time did not > |seem to indicate consensus that SRTP must be used always, so I > |decided to document what we seemed to have consensus on - that SRTP > |MUST be implemented. > > Does it mean: > a. The WebRTC browser MUST implement SRTP, but the WebRTC service/JS needn't use it OR > b. The WebRTC browser and the service/JS MUST implement SRTP, but the user needn't have to use it? > For this group: a, I think. I haven't seen it realistic to impose restrictions in RTCWEB on the Javascript that people write. The language and the APIs are subjects of standardization; the code written isn't. If someone claims to implement a protocol in Javascript, of course the restrictions apply - if they implement a protocol in Javascript where crypto is mandatory to implement, and don't implement crypto, their claim to have implemented the protocol is false advertising. But the IETF has no protocol police. From magnus.westerlund@ericsson.com Thu Nov 10 02:01:51 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D0721F8AE6 for ; Thu, 10 Nov 2011 02:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 yLIAgxHcdbQC for ; Thu, 10 Nov 2011 02:01:50 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id CCD3721F88B7 for ; Thu, 10 Nov 2011 02:01:49 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-5b-4ebba10cab89 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 66.DC.13753.C01ABBE4; Thu, 10 Nov 2011 11:01:48 +0100 (CET) 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.137.0; Thu, 10 Nov 2011 11:01:47 +0100 Message-ID: <4EBBA102.2030600@ericsson.com> Date: Thu, 10 Nov 2011 11:01:38 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Bernard Aboba References: <4EB26945.40607@ericsson.com>, <4EB2A58E.1040000@jesup.org> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP mandatory to implement versus mandatory to use X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Nov 2011 10:01:51 -0000 Hi, Regarding the srtp-not-mandatory draft. In the discussion I have so far had with for example the security ADs one conclusion is that when we get into something that is actually an application or class of applications and when that is specified by IETF, IETF do need to pick at least one mandatory to implement solution. As WebRTC is an application using RTP this becomes very applicable to the WebRTC work. We do need to pick at least one mandatory to implement keying mechanism. We might pick additional mandatory ones if we think that is necessary to address the space of usages we see. I think that is what the WG must come to consensus on. Cheers Magnus On 2011-11-09 02:25, Bernard Aboba wrote: > I support SRTP being "mandatory to implement" but not "mandatory to use". > > With respect to mandating a keying mechanism, I would point out the > arguments in the following document: > > http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory > > It appears that the arguments made in this document also apply to RTCWEB > in that many (though not all) of the use cases mentioned there are also > to be supported by RTCWEB, potentially leading to disparate keying > requirements. > > > 2. RTP Applications and Deployment Scenarios > > The range of application and deployment scenarios where RTP has been > Perkins & Westerlund Expires May 3, 2012 [Page 3] > > used includes, but is not limited to, the following: > > o Point-to-point voice telephony (fixed and wireless networks) > > o Point-to-point voice and video conferencing > > o Centralised group video conferencing with a multipoint conference > unit (MCU) > > o Any Source Multicast video conferencing (light-weight sessions; > Mbone conferencing) > > o Point-to-point streaming audio and/or video > > o Source-specific multicast (SSM) streaming to large group (IPTV and > 3GPP Multimedia Broadcast Multicast Service (MBMS) [MBMS ]) > > o Replicated unicast streaming to a group > > o Interconnecting components in music production studios and video > editing suites > > o Interconnecting components of distributed simulation systems > > o Streaming real-time sensor data > > As can be seen, these scenarios vary from point-to-point to very > large multicast groups, from interactive to non-interactive, and from > low bandwidth (kilobits per second) to very high bandwidth (multiple > gigabits per second). While most of these applications run over UDP > [RFC0768 ], some use TCP [RFC0793 ], [RFC4614 ] or DCCP [RFC4340 ] as > their underlying transport. Some run on highly reliable optical > networks, others use low rate unreliable wireless networks. Some > applications of RTP operate entirely within a single trust domain, > others are inter-domain, with untrusted (and potentially unknown) > users. The range of scenarios is wide, and growing both in number > and in heterogeneity. > > > > > 3. Implications for RTP Security > > > > The wide range of application scenarios where RTP is used has led to > the development of multiple solutions for securing RTP media streams > and RTCP control messages, considering different requirements. > Perhaps the most widely applicable of these solutions is the Secure > RTP (SRTP) framework [RFC3711 ]. This is an application-level media > security solution, encrypting the media payload data (but not the RTP > headers) to provide some degree of confidentiality, and providing > > optional source origin authentication. It was carefully designed to > be both low overhead, and to support the group communication features > of RTP, across a range of networks. > > SRTP is not the only media security solution in use, however, and > alternatives are more appropriate for some scenarios. For example, > many client-server streaming media applications can run over a single > TCP connection, multiplexing media data with control information on > that connection (RTSP [I-D.ietf-mmusic-rfc2326bis ] is a widely used > example of such a protocol). One way to provide media security for > such client-server media applications is to use TLS [RFC5246 ] to > protect the TCP connection, sending the RTP media data over the TLS > connection. Using the SRTP framework in addition to TLS is > unnecessary, and would result in double encryption of the media, and > SRTP cannot be used instead of TLS since it is RTP-specific, and so > cannot protect the control traffic. > > Other RTP use cases work over networks which provide security at the > network layer, using IPsec. For example, certain 3GPP networks need > IPsec security associations for other purposes, and can reuse those > to secure the RTP session [TS-33210 ]. SRTP is, again, unnecessary in > such environments, and its use would only introduce overhead for no > gain. > > For some applications it is sufficient to protect the RTP payload > data while leaving RTP, transport, and network layer headers > unprotected. An example of this is RTP broadcast over DVB-H > [ETSI.TS.102.474 ], where one mode of operation uses ISMA Cryp 2.0 > [ISMA ] to encrypt the RTP payload data only. > > All these are application scenarios where RTP has seen commercial > deployment. Other use cases exist, with additional requirements. > For example, if the media transport is done over UDP [RFC0768 ], DCCP > [RFC4340 ] or SCTP [RFC4960 ], then using DTLS [RFC4347 ] to protect the > whole RTP packets is an option. There is no media security protocol > that is appropriate for all these environments. Accordingly, > multiple RTP media security protocols can be expected to remain in > wide use. > > > > > 4. Implications for Key Management > > > > With such a diverse range of use cases come a range of different > protocols for RTP session establishment. Mechanisms used to provide > security keying for these different session establishment protocols > can basically be put into two categories: inband and out-of-band in > relation to the session establishment mechanism. The requirements > for these solutions are highly varying. Thus a wide range of > > solutions have been developed in this space: > > o A common use case for RTP is probably point-to-point voice calls > or centralised group conferences, negotiated using SIP [RFC3261 ] > with the SDP offer/answer model [RFC3264 ], operating on a trusted > infrastructure. In such environments, SDP security descriptions > [RFC4568 ], or the MIKEY [RFC3830 ] protocol using the Key > Management Extensions for SDP [RFC4567 ], are appropriate keying > mechanisms, where the keying messages/material are embedded in the > SDP [RFC4566 ] exchange. The infrastructure may be secured by > protecting the SDP exchange in SIP using TLS or S/MIME, for > example [RFC3261 ]. Protocols such as DTLS-SRTP [RFC5764 ] or ZRTP > [RFC6189 ] are also appropriate in such environments. > > o Point-to-point RTP sessions may be negotiated using SIP with the > offer/answer model, but operating over a network with untrusted > infrastructure. In such environments, the key management protocol > can be run on the media path, bypassing the untrusted > infrastructure. Protocols such as DTLS-SRTP [RFC5764 ] or ZRTP > [RFC6189 ] are useful here, as are inband mechanism that protect > the keying material such as MIKEY [RFC3830 ] using the Key > Management Extensions for SDP [RFC4567 ]. It should be noted that > the end-points for all the above mechanisms must prevent total > downgrade to no security for the RTP media streams. > > o For point-to-point client-server streaming of RTP over RTSP, a TLS > association is appropriate to manage keying material, in much the > same manner as would be used to secure an HTTP session. But also > using SRTP with DTLS-SRTP keying or DTLS are appropriate choices. > > o A session description may be sent by email, secured using S/MIME > or PGP, or retrieved from a web page, using HTTP with TLS. > > o A session description may be distributed to a multicast group > using SAP or FLUTE secured with S/MIME. > > o A session description may be distributed using the Open Mobile > Alliance DRM key management specification [OMA-DRM ] when using a > point-to-point streaming session setup with RTSP in the 3GPP PSS > environment [PSS ]. > > o In the 3GPP Multimedia Broadcast Multicast Service (MBMS) system, > HTTP and MIKEY are used for key management [MBMS-SEC ]. > > A more detailed survey of requirements for media security management > protocols can be found in [RFC5479 ]. As can be seen, the range of > use cases is wide, and there is no single protocol that is > appropriate for all scenarios. These solutions have been further > > diversified by the existence of infrastructure elements such as > authentication solutions that are tied into the key management. > > > > > > Magnus said: > > > "Yes, we haven't spent much time on the security consideration section > yet. "A mandatory to implement media security solution will be required > to be picked" is pointer at this WG not the implementor. > > I would also point at our Charter that in its last paragraph says: > "The products of the working group will support security and keying as > required by BCP 61" > > If you haven't read BCP 61 you probably should. It is basically says two > things. IETF should pick strong security and it shall be MANDATORY to > IMPLEMENT. I at least as chair will ensure that we have fulfilled this. > And that means for RTP not only encryption and integrity protection, > probably SRTP, but also a keying method. > > Yes, we (authors of draft-ietf-rtcweb-rtp-usage) will write that SRTP is > a MUST implement as soon as we have that consensus established. But we > will need a keying scheme also and determine where it should be documented. > > 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 pravindran@sonusnet.com Thu Nov 10 03:13:26 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D294D21F8593 for ; Thu, 10 Nov 2011 03:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpevzPAWJZIo for ; Thu, 10 Nov 2011 03:13:26 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA0D21F8430 for ; Thu, 10 Nov 2011 03:13:26 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pAABE0L0015565; Thu, 10 Nov 2011 06:14:00 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 06:06:32 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 16:36:42 +0530 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.0339.001; Thu, 10 Nov 2011 16:36:41 +0530 From: "Ravindran, Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Wolfgang Beck Thread-Topic: [rtcweb] Regarding Federation Arguments Thread-Index: AQHMmhOSpaBQnqnn3Ea06PkOYAyRWJWjRo+AgAAV/ACAAMveAIAASCWAgAAtNYCAAVuUAA== Date: Thu, 10 Nov 2011 11:06:40 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0134A992@inba-mail01.sonusnet.com> References: <4EB26D22.5090000@ericsson.com> <4EBA741A.1010307@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.164] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 10 Nov 2011 11:06:42.0056 (UTC) FILETIME=[D395D880:01CC9F98] Cc: "" Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Nov 2011 11:13:26 -0000 SXQgaXMgYSBiYWQgc2l0dWF0aW9uIHRvIGltcGxlbWVudCAibiIgcHJvdG9jb2xzIGluIEdhdGV3 YXlzIGZvciBmZWRlcmF0aW9uIA0KYXMgdGhlcmUgaXMgbm8gc3RhbmRhcmQgdG8gcmVmZXIuIEF0 bGVhc3QgaW4gY2FzZSBvZiBJUCB0ZWxlcGhvbnksIHRoZXJlIGlzIA0KYSBjb252ZXJnZW5jZSB0 aGF0IFNJUCB3aWxsIGJlIHVzZWQgYXMgYSBkZS1mYWN0byBwcm90b2NvbCAobm8gSC4zMjMvTWVn YWNvKS4gDQpJdCBpcyByZWFsbHkgdG91Z2ggdG8gbWFuYWdlIGluIGNhc2UgdGhlcmUgaXMgbm8g Z3VpZGVsaW5lcyBmb3IgUlRDV2ViIHNlcnZlci4NCg0KQXMgSSBlYXJsaWVyIG1lbnRpb25lZCwg dGhlcmUgaXMgbm8gbmVlZCB0byBtYW5kYXRlIGFueSBzcGVjaWZpYyBwcm90b2NvbCBidXQNCkd1 aWRlbGluZXMgaXMgaW1wb3J0YW50LiBBbHNvLCBJIGFncmVlIHdpdGggeW91ciBlYXJsaWVyIG1h aWwgdGhhdCBGZWRlcmF0aW9uIHdvcmsNCml0ZW0gbWF5IG5vdCByZXF1aXJlIHRvIGJlIGNvbXBs ZXRlZCBpbiB0aGUgbm9ybWFsIFdlYlJUQyB0aW1lLXRvLW1hcmtldCBtYW5uZXIuDQoNClRoYW5r cw0KUGFydGhhDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IHJ0Y3dlYi1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs Zg0KPk9mIEnDsWFraSBCYXogQ2FzdGlsbG8NCj5TZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMTAs IDIwMTEgMTowOCBBTQ0KPlRvOiBXb2xmZ2FuZyBCZWNrDQo+Q2M6IDxydGN3ZWJAaWV0Zi5vcmc+ DQo+U3ViamVjdDogUmU6IFtydGN3ZWJdIFJlZ2FyZGluZyBGZWRlcmF0aW9uIEFyZ3VtZW50cw0K Pg0KPjIwMTEvMTEvOSBXb2xmZ2FuZyBCZWNrIDx3b2xmZ2FuZy5iZWNrMDFAZ29vZ2xlbWFpbC5j b20+Og0KPj4gVGhpcyBoYXMgaGFwcGVuZWQgd2l0aCBTSVAuIEFzIG1vc3Qgb2YgdGhlIGludGVy Y29ubmVjdGlvbiBpcyBkb25lDQo+PiB0aHJvdWdoIHRoZSBQU1ROLCB3ZSBkb24ndCBzZWUgbWFu eSBleGNpdGluZyBuZXcgU0lQIGFwcGxpY2F0aW9ucyBpbg0KPj4gd2lkZSB1c2UuDQo+DQo+SSBk b24ndCBmdWxseSB1bmRlcnN0YW5kIHdoeSBzb21lIFNJUCBmb2xrcyB0cnkgdG8gImV4cG9ydCIg dGhlIFNJUA0KPnRyYXBlem9pZCBtb2RlbCB0byBXZWJSVEMgdGFraW5nIGludG8gYWNjb3VudCB0 aGF0IHN1Y2ggdHJhcGV6b2lkIGhhcw0KPm5ldmVyIHN1Y2NlZWRlZCBpbiBwdXJlIFNJUCBuZXR3 b3Jrcy4NCj4NCj5Bbnlob3csIHJlYWRpbmcgdGhlIGxhc3QgbWFpbHMgaW4gdGhpcyB0aHJlYWQu Li4gd2hhdCBhcmUgd2UNCj5kaXNjdXNzaW5nIGFib3V0PyBJSE1PIGFsbCBvZiB1cyAoYXQgbGVh c3QgaW4gdGhpcyB0aHJlYWQpIGFncmVlIG9uDQo+dGhlIGZhY3QgdGhhdCBtYW5kYXRpbmcvZGVm aW5pbmcgYSBzZXJ2ZXItdG8tc2VydmVyIGludGVyY29ubmVjdGlvbg0KPm1vZGVsIGlzIGEgbm8t Z28uIElzIGl0IGp1c3QgYWJvdXQgdGhlIGV4YWN0IHRleHQgZm9yIHRoZSBkcmFmdD8gSXQncw0K PmVhc3ksIGp1c3Qgc2F5ICJ0d28gV2ViUlRDIHNpdGVzIGNhbiBmZWRlcmF0ZSBieSB1c2luZyBh bnkgbWVjaGFuaXNtDQo+dGhleSBkZXNpcmUgZm9yIHN1Y2ggaW50ZXJjb25uZWN0aW9uLiBJdCBj b3VsZCBiZSBwdXJlIFNJUCwgWE1QUCBvcg0KPndoYXRldmVyIHByb3RvY29sL21lY2hhbmlzbSB0 aGV5IGFncmVlLiINCj4NCj4tLQ0KPknDsWFraSBCYXogQ2FzdGlsbG8NCj48aWJjQGFsaWF4Lm5l dD4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnJ0 Y3dlYiBtYWlsaW5nIGxpc3QNCj5ydGN3ZWJAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K From ibc@aliax.net Thu Nov 10 08:33:19 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46F421F87D6 for ; Thu, 10 Nov 2011 08:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml-azwRMM6aq for ; Thu, 10 Nov 2011 08:33:19 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id F3D2421F8672 for ; Thu, 10 Nov 2011 08:33:18 -0800 (PST) Received: by wwh12 with SMTP id 12so1898785wwh.13 for ; Thu, 10 Nov 2011 08:33:18 -0800 (PST) Received: by 10.52.65.36 with SMTP id u4mr13958051vds.58.1320942797147; Thu, 10 Nov 2011 08:33:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Thu, 10 Nov 2011 08:32:56 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0134A992@inba-mail01.sonusnet.com> References: <4EB26D22.5090000@ericsson.com> <4EBA741A.1010307@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C0134A992@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 10 Nov 2011 17:32:56 +0100 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Nov 2011 16:33:19 -0000 2011/11/10 Ravindran, Parthasarathi : > It is a bad situation to implement "n" protocols in Gateways for federati= on > as there is no standard to refer. Atleast in case of IP telephony, there = is > a convergence that SIP will be used as a de-facto protocol (no H.323/Mega= co). > It is really tough to manage in case there is no guidelines for RTCWeb se= rver. Hi Ravindran, WebRTC is not SIP nor a protocol to be mapped to SIP. It's something different which "could" offer features similar to SIP or a really different experience. A WebRTC scenario could offer just multiconference calls (let's say a poker game in which every participant talk and listens to all the participants), or could offer just video calls, or just audio. This is not about legacy telephony anymore, so there is no chance to make a "guideline" for interoperability between WebRTC and SIP. Of course some WebRTC scenarios could offer capabilities like VoIP so interoperability with SIP networks would make sense, but we should not assume that this is the main purpose of WebRTC. IMHO we should stop talking about SIP in this WG. > As I earlier mentioned, there is no need to mandate any specific protocol= but > Guidelines is important. Also, I agree with your earlier mail that Federa= tion work > item may not require to be completed in the normal WebRTC time-to-market = manner. I agree. The document you propose could be useful for some scenarios, sure, but it should not make the WG to spent time on it for now. First priority is to define WebRTC regardless federation with other specific networks. Regards. --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Thu Nov 10 11:47:22 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D093821F8ACE for ; Thu, 10 Nov 2011 11:47:22 -0800 (PST) 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.016, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0l72wJcgCTW for ; Thu, 10 Nov 2011 11:47:22 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E2FD221F84FB for ; Thu, 10 Nov 2011 11:47:21 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Nov 2011 14:47:19 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 10 Nov 2011 14:47:20 -0500 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AQHMn+GOqLofpooW1EaoUUdNIhGp3Q== Date: Thu, 10 Nov 2011 19:47:19 +0000 Message-ID: <8C3CF53E-7DAC-4E87-9C00-7884A01B29BA@acmepacket.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C653804920206D3BA71@XMB-BGL-414.cisco.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="iso-8859-1" Content-ID: <93DD87B2A25BD040933C3FC3D62E0DAC@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Thu, 10 Nov 2011 19:47:22 -0000 On Nov 9, 2011, at 10:05 AM, I=F1aki Baz Castillo wrote: > Implementing SRTP is really easier and cheap. There is no reason at > all not to mandate it in a new specification, even less when it's > designed to work in the open (and untrusted) Internet. >=20 > So bad luck. You, telcos, have the specs and the tools to upgrade your > non-secure SIP devices. Do it. Several people have made this SRTP discussion into a "Telco" issue, and I d= on't think it is. First, because if a Telco doesn't care about securing th= e media, they'll likely put the burden of making it plaintext RTP on the We= bRTC domain owner, so it still won't be "their problem". But more importan= tly, because I expect a lot of Telco's to actually *require* WebRTC media c= ommunications to/from them be secure in some fashion or other, specifically= because it can be run to/from anywhere on the public Internet. [they won't= do SRTP all the way to their own SIP endpoints, but that doesn't matter] = =20 So for Telco's I don't think mandating SRTP be used is a non-starter, thoug= h the form of key exchange might be a big sticking point. But something to consider is if doing SRTP is a burden or not on web applic= ations that know a priori that they don't need it. In particular I mean on= es that need to use media servers so it's not simply browser-to-browser, an= d they use HTTP because their use-case isn't one of a sensitive nature. =20 -hadriel p.s. BTW, I didn't mean to start a religious war on this topic - I was just= pointing out that a requirement to use ICE and a requirement to use SRTP a= ren't tied together, and that we need to still get consensus on mandating S= RTP to-use vs. only to-implement. From oej@edvina.net Thu Nov 10 12:08:08 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624EC21F84AC for ; Thu, 10 Nov 2011 12:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_SE=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 fViU5LqJlMCB for ; Thu, 10 Nov 2011 12:08:08 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 06F9A21F8AAA for ; Thu, 10 Nov 2011 12:07:58 -0800 (PST) Received: from [192.168.40.76] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id F09F6754BD1C; Thu, 10 Nov 2011 20:07:53 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <8C3CF53E-7DAC-4E87-9C00-7884A01B29BA@acmepacket.com> Date: Thu, 10 Nov 2011 21:07:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <75402D40-69AE-44EF-B39C-F8D4F177D64F@edvina.net> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D0 62974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C653804920206D3BA71@XMB-BGL-414.cisco.com> <8C3CF53E-7DAC-4E87-9C00-7884A01B29BA@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1251.1) Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Thu, 10 Nov 2011 20:08:08 -0000 10 nov 2011 kl. 20:47 skrev Hadriel Kaplan: > But something to consider is if doing SRTP is a burden or not on web = applications that know a priori that they don't need it. In particular = I mean ones that need to use media servers so it's not simply = browser-to-browser, and they use HTTP because their use-case isn't one = of a sensitive nature. =20 I think Eric has killed that kind of use-cases. You simply don't know if = the use case isn't of a sensitive nature. Ever. /O= From harald@alvestrand.no Thu Nov 10 12:30:49 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C99921F8B03 for ; Thu, 10 Nov 2011 12:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LfRb6UTCPZy for ; Thu, 10 Nov 2011 12:30:48 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B1A7E21F8ACE for ; Thu, 10 Nov 2011 12:30:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C71F739E148 for ; Thu, 10 Nov 2011 21:30:46 +0100 (CET) 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 24Pd2UHbadMn for ; Thu, 10 Nov 2011 21:30:45 +0100 (CET) Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C82A639E089 for ; Thu, 10 Nov 2011 21:30:45 +0100 (CET) Message-ID: <4EBC3475.90706@alvestrand.no> Date: Thu, 10 Nov 2011 21:30:45 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040608040904070905000500" Subject: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Thu, 10 Nov 2011 20:30:49 -0000 This is a multi-part message in MIME format. --------------040608040904070905000500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/10/2011 06:48 AM, Roman Shpount wrote: > > On Thu, Nov 10, 2011 at 12:20 AM, Eric Rescorla > wrote: > > The point is that it's very hard to anticipate which > communications media > will be used for sensitive information. To say "we don't need security > in this application because nobody will ever use it to discuss > sensitive > stuff" is short-sighted. Better simply to be secure all the time. > > > So why is 99% of the web traffic is HTTP? Do you want to force > everybody to use HTTPS? I think your argument is simply stating > encryption is good, no encryption bad, even if it is not needed or if > it does not protect anything (WebRTC application delivered over HTTP). Since you asked.... Working, but not speaking, for the company that just decided that open Web search results should go over HTTPS: yes. http://googleblog.blogspot.com/2011/10/making-search-more-secure.html Having the default Web scheme be nonencrypted and nonsecured was a reasonable choice given the cost (and regulatory hassle) of crypto at that time. Long term, it was a mistake. (BTW, Google searches did not immediately bring up verification for that claim of 99% of Web traffic being HTTP.... do you have a citation for that?) Harald --------------040608040904070905000500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/10/2011 06:48 AM, Roman Shpount wrote:

On Thu, Nov 10, 2011 at 12:20 AM, Eric Rescorla <ekr@rtfm.com> wrote:
The point is that it's very hard to anticipate which communications media
will be used for sensitive information. To say "we don't need security
in this application because nobody will ever use it to discuss sensitive
stuff" is short-sighted. Better simply to be secure all the time.


So why is 99% of the web traffic is HTTP? Do you want to force everybody to use HTTPS? I think your argument is simply stating encryption is good, no encryption bad, even if it is not needed or if it does not protect anything (WebRTC application delivered over HTTP).

Since you asked....

Working, but not speaking, for the company that just decided that open Web search results should go over HTTPS: yes.

http://googleblog.blogspot.com/2011/10/making-search-more-secure.html

Having the default Web scheme be nonencrypted and nonsecured was a reasonable choice given the cost (and regulatory hassle) of crypto at that time. Long term, it was a mistake.

(BTW, Google searches did not immediately bring up verification for that claim of 99% of Web traffic being HTTP.... do you have a citation for that?)

                 Harald





--------------040608040904070905000500-- From roman@telurix.com Thu Nov 10 12:51:41 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D0C21F8549 for ; Thu, 10 Nov 2011 12:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.892 X-Spam-Level: X-Spam-Status: No, score=-2.892 tagged_above=-999 required=5 tests=[AWL=0.084, 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 kRDF6EoqnrR1 for ; Thu, 10 Nov 2011 12:51:40 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3A46721F8545 for ; Thu, 10 Nov 2011 12:51:40 -0800 (PST) Received: by ywt34 with SMTP id 34so1429184ywt.31 for ; Thu, 10 Nov 2011 12:51:39 -0800 (PST) Received: by 10.147.166.17 with SMTP id t17mr3863522yao.28.1320958299587; Thu, 10 Nov 2011 12:51:39 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id t62sm7969513yht.0.2011.11.10.12.51.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Nov 2011 12:51:38 -0800 (PST) Received: by yenq4 with SMTP id q4so26341yen.31 for ; Thu, 10 Nov 2011 12:51:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.72.103 with SMTP id c7mr17758099pbv.1.1320958297363; Thu, 10 Nov 2011 12:51:37 -0800 (PST) Received: by 10.68.62.170 with HTTP; Thu, 10 Nov 2011 12:51:37 -0800 (PST) In-Reply-To: <4EBC3475.90706@alvestrand.no> References: <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> Date: Thu, 10 Nov 2011 15:51:37 -0500 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=f46d041b47f613d41204b16792d5 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Thu, 10 Nov 2011 20:51:41 -0000 --f46d041b47f613d41204b16792d5 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 10, 2011 at 3:30 PM, Harald Alvestrand wrote: > (BTW, Google searches did not immediately bring up verification for that > claim of 99% of Web traffic being HTTP.... do you have a citation for that?) > Not really, this is just an estimate. Some fact point for you -- facebook is HTTP and that is about 25% of web page visits. Youtube is HTTP also and that's about 7%. ( http://weblogs.hitwise.com/heather-dougherty/2010/11/facebookcom_generates_nearly_1_1.html ) I think the whole discussion degraded to the point of being pointless. You say that you need mandatory encryption regardless of what I am saying. I would not agree to mandatory encryption unless you explain to me why this is not something that WebRTC application developer should not control. Application developer can circumvent media security in any way he wants (by sending it to a middle box and recording for example), so I really do not understand why he cannot just turn the encryption off. On the web, where origin of applications can be unknown, their integrity uncertain, delivery un-secure, and purpose unpredictable, I do not understand why you insist on mandatory encryption. It will not provide more security, will just restrict things for no real gain. _____________ Roman Shpount --f46d041b47f613d41204b16792d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 10, 2011 at 3:30 P= M, Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
(BTW, Google searches did not immediately bring up verification for that claim of 99% of Web traffic being HTTP.... do you have a citation for that?)

Not really, this is just an estimate. Some fact point for you -= - facebook is HTTP and that is about 25% of web page visits. Youtube is HTT= P also and that's about 7%. (http://weblogs= .hitwise.com/heather-dougherty/2010/11/facebookcom_generates_nearly_1_1.htm= l)

I think the whole discussion degraded to the point of being pointless. = You say that you need mandatory encryption regardless of what I am saying. = I would not agree to mandatory encryption unless you explain to me why this= is not something that WebRTC application developer should not control. App= lication developer can circumvent media security in any way he wants (by se= nding it to a middle box and recording for example), so I really do not und= erstand why he cannot just turn the encryption off. On the web, where origi= n of applications can be unknown, their integrity uncertain, delivery un-se= cure, and purpose unpredictable, I do not understand why you insist on mand= atory encryption. It will not provide more security, will just restrict thi= ngs for no real gain.
_____________
Roman Shpount


--f46d041b47f613d41204b16792d5-- From HKaplan@acmepacket.com Thu Nov 10 13:07:16 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C52B11E8083 for ; Thu, 10 Nov 2011 13:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, J_CHICKENPOX_42=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 byo3BF8xOkcy for ; Thu, 10 Nov 2011 13:07:16 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E16B111E807F for ; Thu, 10 Nov 2011 13:07:15 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Nov 2011 16:07:14 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 10 Nov 2011 16:07:14 -0500 From: Hadriel Kaplan To: Eric Rescorla Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AQHMn+y34GF827+x8UmM90+XdaVv7A== Date: Thu, 10 Nov 2011 21:07:13 +0000 Message-ID: <228696DD-CAF5-4D50-AA5A-11F62DFD01EE@acmepacket.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.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="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Thu, 10 Nov 2011 21:07:16 -0000 On Nov 10, 2011, at 12:20 AM, Eric Rescorla wrote: > I can envision situations on which security would be desirable in both of > these applications. In the case of a "greeting card application" (whateve= r > that is) my greeting card might contain sensitive personal or medical > information (congratulations on your pregnancy, sorry to hear you have > cancer etc.) Surely I do in fact want that information secured. Similarly= , > it might not be important to have my Farmville chats secure, but if the > purpose of an in-game chat is for me and my co-player to cooperate > in a game where money is on the line (e.g., a tournament), then suddenlu > security becomesmuch more important. Not to mention that the players > may simply be using in-game chat to discuss personal stuff. I think that's a red herring. Just because you as a user could post your s= ocial security number on a forum website, for example, does not mean all fo= rum websites should use HTTPS "just in case". Because even if they used HT= TPS it's not going to secure your social security number from being read by= anyone else, nor does the forum website claim to provide any such form of = confidentiality to begin with.=20 The greeting card case, for example, is going to record your media on some = server somewhere - just because they use SRTP from you to do so doesn't mea= n they're going to prevent everyone on the planet from being able to access= the greeting card; or even if they only allow authorized users to listen t= o the greeting card, it doesn't mean that they won't simply use an HTTP'ed = wav file to deliver it to them. Obviously if a greeting card app *wants* t= o provide that sort of confidentiality/privacy, then it can and should use = SRTP as well as encrypt everything else, control authorization, etc. That'= s their choice, based on what type of application they want to provide. We= don't need to create a nanny state. >=20 > The point is that it's very hard to anticipate which communications media > will be used for sensitive information. To say "we don't need security > in this application because nobody will ever use it to discuss sensitive > stuff" is short-sighted. Better simply to be secure all the time. And one could argue this the exact opposite - if the browser shows some loc= k-icon thing for SRTP, then it's better for them to use RTP instead for suc= h apps, so as not to make you think the service as a whole is secure if it = really isn't. The only one who knows the type of application service securi= ty model being offered is the Web server admin/developer, not the IETF.=20 -hadriel From ekr@rtfm.com Thu Nov 10 13:35:39 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7586F21F8A80 for ; Thu, 10 Nov 2011 13:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.651 X-Spam-Level: X-Spam-Status: No, score=-102.651 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=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 Zgq-pZmM7FnY for ; Thu, 10 Nov 2011 13:35:39 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id BFBBF21F8A7E for ; Thu, 10 Nov 2011 13:35:38 -0800 (PST) Received: by yenq4 with SMTP id q4so75074yen.31 for ; Thu, 10 Nov 2011 13:35:38 -0800 (PST) Received: by 10.146.68.21 with SMTP id q21mr3901688yaa.32.1320960938259; Thu, 10 Nov 2011 13:35:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.146.151.3 with HTTP; Thu, 10 Nov 2011 13:34:57 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <228696DD-CAF5-4D50-AA5A-11F62DFD01EE@acmepacket.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <228696DD-CAF5-4D50-AA5A-11F62DFD01EE@acmepacket.com> From: Eric Rescorla Date: Thu, 10 Nov 2011 13:34:57 -0800 Message-ID: To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Thu, 10 Nov 2011 21:35:39 -0000 On Thu, Nov 10, 2011 at 1:07 PM, Hadriel Kaplan wr= ote: > > On Nov 10, 2011, at 12:20 AM, Eric Rescorla wrote: > >> I can envision situations on which security would be desirable in both o= f >> these applications. In the case of a "greeting card application" (whatev= er >> that is) my greeting card might contain sensitive personal or medical >> information (congratulations on your pregnancy, sorry to hear you have >> cancer etc.) Surely I do in fact want that information secured. Similarl= y, >> it might not be important to have my Farmville chats secure, but if the >> purpose of an in-game chat is for me and my co-player to cooperate >> in a game where money is on the line (e.g., a tournament), then suddenlu >> security becomesmuch more important. Not to mention that the players >> may simply be using in-game chat to discuss personal stuff. > > I think that's a red herring. =A0Just because you as a user could post yo= ur social security number on a forum website, for example, does not mean al= l forum websites should use HTTPS "just in case". =A0Because even if they u= sed HTTPS it's not going to secure your social security number from being r= ead by anyone else, nor does the forum website claim to provide any such fo= rm of confidentiality to begin with. This isn't my point: Roman offered a set of use cases he claimed didn't require confidentiality. But in fact, many such cases do. The fact that there are also overlapping cases which do not is an argument for erring on the side of confidentiality, not the other way around. > The greeting card case, for example, is going to record your media on som= e server somewhere - just because they use SRTP from you to do so doesn't m= ean they're going to prevent everyone on the planet from being able to acce= ss the greeting card; or even if they only allow authorized users to listen= to the greeting card, it doesn't mean that they won't simply use an HTTP'e= d wav file to deliver it to them. =A0Obviously if a greeting card app *want= s* to provide that sort of confidentiality/privacy, then it can and should = use SRTP as well as encrypt everything else, control authorization, etc. = =A0That's their choice, based on what type of application they want to prov= ide. Would that this were in fact true. But I don't think history supports this argument. Quite the contrary: we have a whole array of protocols which really should be secure all the time (e-mail is a good example) but aren't because they were initially deployed insecure and it's hard to convert. The good news, however, is that WebRTC can be done securely from the beginning in a way that (unlike HTTPS) doesn't impose significant inconvenience on the site operato= r. >> The point is that it's very hard to anticipate which communications medi= a >> will be used for sensitive information. To say "we don't need security >> in this application because nobody will ever use it to discuss sensitive >> stuff" is short-sighted. Better simply to be secure all the time. > > > And one could argue this the exact opposite - if the browser shows some l= ock-icon thing for SRTP, then it's better for them to use RTP instead for s= uch apps, so as not to make you think the service as a whole is secure if i= t really isn't. Obviously, UI confusion is a real problem, but I don't really buy the argument that Facebook shouldn't use HTTPS because people will be confused about what happens when they post on their wall. -Ekr From harald@alvestrand.no Thu Nov 10 13:37:08 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8081F0C3E for ; Thu, 10 Nov 2011 13:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qypXY3npNztP for ; Thu, 10 Nov 2011 13:37:07 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3E09A1F0C38 for ; Thu, 10 Nov 2011 13:37:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 84D2539E148; Thu, 10 Nov 2011 22:37:06 +0100 (CET) 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 c31scDj5NldO; Thu, 10 Nov 2011 22:37:05 +0100 (CET) Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id ACEF539E089; Thu, 10 Nov 2011 22:37:05 +0100 (CET) Message-ID: <4EBC4401.2090703@alvestrand.no> Date: Thu, 10 Nov 2011 22:37:05 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Roman Shpount References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030108050907080104020901" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Thu, 10 Nov 2011 21:37:08 -0000 This is a multi-part message in MIME format. --------------030108050907080104020901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/10/2011 09:51 PM, Roman Shpount wrote: > > On Thu, Nov 10, 2011 at 3:30 PM, Harald Alvestrand > > wrote: > > (BTW, Google searches did not immediately bring up verification > for that claim of 99% of Web traffic being HTTP.... do you have a > citation for that?) > > > Not really, this is just an estimate. Some fact point for you -- > facebook is HTTP and that is about 25% of web page visits. Facts are slippery things. Facebook offers an option to have HTTPS always, so every hit from my account on Facebook is HTTPS, not HTTP. > Youtube is HTTP also and that's about 7%. > (http://weblogs.hitwise.com/heather-dougherty/2010/11/facebookcom_generates_nearly_1_1.html) > I think the whole discussion degraded to the point of being pointless. > You say that you need mandatory encryption regardless of what I am saying. Not really what I was saying. Since you dragged in the division of traffic between HTTP and HTTPS as an argument, I thought I'd state an absolutist position too. That's different from what I am looking for when seeking consensus. For some reasons why I hold that position, I recommend "Little Brother" by Cory Doctorow. It's a fun read. > I would not agree to mandatory encryption unless you explain to me why > this is not something that WebRTC application developer should not > control. I am still waiting for a compelling argument for why the application developer *needs* to be able to run without encryption. So far, we've heard arguments that: - encryption uses more CPU (true, but arguably not significant compared to media processing) - It is needed for legacy interoperability (may be true for some, but not necessarily compelling) - It helps debugging (which has been disputed by people who debug systems) Did I miss some? The ability to turn off encryption increases the opportunity for attacks on services that *want* to be secure (bid-down attacks); I think that's uncontroversial. > Application developer can circumvent media security in any way he > wants (by sending it to a middle box and recording for example), so I > really do not understand why he cannot just turn the encryption off. > On the web, where origin of applications can be unknown, their > integrity uncertain, delivery un-secure, and purpose unpredictable, I > do not understand why you insist on mandatory encryption. It will not > provide more security, will just restrict things for no real gain. And I pursue the argument from the other end: Given that encryption is available, and the cost mostly negligible, what is the value of turning it *off*? All that said .... I'm able to live with having the RTCWEB standard suite say "mandatory to implement, not mandatory to use". I just think the arguments for doing so are weak. --------------030108050907080104020901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/10/2011 09:51 PM, Roman Shpount wrote:

On Thu, Nov 10, 2011 at 3:30 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
(BTW, Google searches did not immediately bring up verification for that claim of 99% of Web traffic being HTTP.... do you have a citation for that?)

Not really, this is just an estimate. Some fact point for you -- facebook is HTTP and that is about 25% of web page visits.
Facts are slippery things. Facebook offers an option to have HTTPS always, so every hit from my account on Facebook is HTTPS, not HTTP.
Youtube is HTTP also and that's about 7%. (http://weblogs.hitwise.com/heather-dougherty/2010/11/facebookcom_generates_nearly_1_1.html)
I think the whole discussion degraded to the point of being pointless. You say that you need mandatory encryption regardless of what I am saying.
Not really what I was saying.

Since you dragged in the division of traffic between HTTP and HTTPS as an argument, I thought I'd state an absolutist position too. That's different from what I am looking for when seeking consensus. For some reasons why I hold that position, I recommend "Little Brother" by Cory Doctorow. It's a fun read.
I would not agree to mandatory encryption unless you explain to me why this is not something that WebRTC application developer should not control.
I am still waiting for a compelling argument for why the application developer *needs* to be able to run without encryption.
So far, we've heard arguments that:

- encryption uses more CPU (true, but arguably not significant compared to media processing)
- It is needed for legacy interoperability (may be true for some, but not necessarily compelling)
- It helps debugging (which has been disputed by people who debug systems)

Did I miss some?

The ability to turn off encryption increases the opportunity for attacks on services that *want* to be secure (bid-down attacks); I think that's uncontroversial.

Application developer can circumvent media security in any way he wants (by sending it to a middle box and recording for example), so I really do not understand why he cannot just turn the encryption off. On the web, where origin of applications can be unknown, their integrity uncertain, delivery un-secure, and purpose unpredictable, I do not understand why you insist on mandatory encryption. It will not provide more security, will just restrict things for no real gain.
And I pursue the argument from the other end: Given that encryption is available, and the cost mostly negligible, what is the value of turning it *off*?

All that said .... I'm able to live with having the RTCWEB standard suite say "mandatory to implement, not mandatory to use". I just think the arguments for doing so are weak.


--------------030108050907080104020901-- From roman@telurix.com Thu Nov 10 14:07:44 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8278121F86A1 for ; Thu, 10 Nov 2011 14:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.894 X-Spam-Level: X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=0.082, 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 D21ZTHFvoDP6 for ; Thu, 10 Nov 2011 14:07:44 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80ADA21F867F for ; Thu, 10 Nov 2011 14:07:43 -0800 (PST) Received: by eyg24 with SMTP id 24so3383023eyg.31 for ; Thu, 10 Nov 2011 14:07:41 -0800 (PST) Received: by 10.213.34.74 with SMTP id k10mr2286149ebd.140.1320962861317; Thu, 10 Nov 2011 14:07:41 -0800 (PST) Received: from mail-dy0-f44.google.com (mail-dy0-f44.google.com [209.85.220.44]) by mx.google.com with ESMTPS id f36sm26350628eef.4.2011.11.10.14.07.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Nov 2011 14:07:39 -0800 (PST) Received: by dyl37 with SMTP id 37so188048dyl.31 for ; Thu, 10 Nov 2011 14:07:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.31.170 with SMTP id b10mr18437032pbi.18.1320962856964; Thu, 10 Nov 2011 14:07:36 -0800 (PST) Received: by 10.68.62.170 with HTTP; Thu, 10 Nov 2011 14:07:36 -0800 (PST) In-Reply-To: <4EBC4401.2090703@alvestrand.no> References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> <4EBC4401.2090703@alvestrand.no> Date: Thu, 10 Nov 2011 17:07:36 -0500 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=bcaec520f2afd9d1cc04b168a1a0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Thu, 10 Nov 2011 22:07:44 -0000 --bcaec520f2afd9d1cc04b168a1a0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 10, 2011 at 4:37 PM, Harald Alvestrand wrote: > So far, we've heard arguments that: > > - encryption uses more CPU (true, but arguably not significant compared to > media processing) > - It is needed for legacy interoperability (may be true for some, but not > necessarily compelling) > - It helps debugging (which has been disputed by people who debug systems) > > Did I miss some? > > Encryption being illegal in some situations is yet another reason (I know about the IETF position on wiretapping, but I would still argue that this is a valid reason.) Higher barrier to entry for building new services -- for instance if you are building a media server to work with WebRTC client. Having one more thing to implement before something works is not critical, but makes a difference. Debugging is actually not a decided issues since we have not reached consensus on the key exchange protocol. Depending on it, debugging can be a lot more or much less difficult. We do provide an SIPS/SRTP/HTTPS enabled systems and services to our customers, but we are regularly being asked to turn security off for debugging. These arguments are not very strong and would not prevent WebRTC from being used (except the illegal part). My main problem is that mandatory encryption is not serving any useful purpose. I strongly oppose the illusion of security when communications are not secure. If an application is delivered over HTTP, the fact that media is encrypted is irrelevant and provides no useful security. There is a duality about web based applications with HTTP and HTTPS. I think WebRTC should reflect this. There is a working model present for HTTP applications already (secure document -- secure communications, insecure document -- insecure communications), so I do not see the reason to break it. _____________ Roman Shpount --bcaec520f2afd9d1cc04b168a1a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Nov 10, 2011 at 4:= 37 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
=20 =20 =20
So far, we've heard arguments that:

- encryption uses more CPU (true, but arguably not significant compared to media processing)
- It is needed for legacy interoperability (may be true for some, but not necessarily compelling)
- It helps debugging (which has been disputed by people who debug systems)

Did I miss some?


Encryption being illegal in some situa= tions is yet another reason (I know about the IETF position on wiretapping,= but I would still argue that this is a valid reason.)

Higher barrie= r to entry for building new services -- for instance if you are building a = media server to work with WebRTC client. Having one more thing to implement= before something works is not critical, but makes a difference.

Debugging is actually not a decided issues since we have not reached co= nsensus on=20 the key exchange protocol. Depending on it, debugging can be a lot more=20 or much less difficult. We do provide an SIPS/SRTP/HTTPS enabled systems an= d services to our customers, but we are regularly being asked to turn secur= ity off for debugging.

These arguments are not very strong and would not prevent WebRTC from b= eing used (except the illegal part). My main problem is that mandatory encr= yption is not serving any useful purpose. I strongly oppose the illusion of= security when communications are not secure. If an application is delivere= d over HTTP, the fact that media is encrypted is irrelevant and provides no= useful security. There is a duality about web based applications with HTTP= and HTTPS. I think WebRTC should reflect this. There is a working model pr= esent for HTTP applications already (secure document -- secure communicatio= ns, insecure document -- insecure communications), so I do not see the reas= on to break it.
_____________
Roman Shpount

--bcaec520f2afd9d1cc04b168a1a0-- From ekr@rtfm.com Thu Nov 10 14:19:07 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C2421F8B29 for ; Thu, 10 Nov 2011 14:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.935 X-Spam-Level: X-Spam-Status: No, score=-102.935 tagged_above=-999 required=5 tests=[AWL=0.042, 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 4R91ob+i9HiO for ; Thu, 10 Nov 2011 14:19:07 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 02C1121F8ABD for ; Thu, 10 Nov 2011 14:19:06 -0800 (PST) Received: by ggnr4 with SMTP id r4so2329898ggn.31 for ; Thu, 10 Nov 2011 14:19:06 -0800 (PST) Received: by 10.146.72.7 with SMTP id u7mr1200962yaa.9.1320963544137; Thu, 10 Nov 2011 14:19:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.146.151.3 with HTTP; Thu, 10 Nov 2011 14:18:24 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> <4EBC4401.2090703@alvestrand.no> From: Eric Rescorla Date: Thu, 10 Nov 2011 14:18:24 -0800 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Thu, 10 Nov 2011 22:19:07 -0000 On Thu, Nov 10, 2011 at 2:07 PM, Roman Shpount wrote: > > > On Thu, Nov 10, 2011 at 4:37 PM, Harald Alvestrand > These arguments are not very strong and would not prevent WebRTC from being > used (except the illegal part). My main problem is that mandatory encryption > is not serving any useful purpose. But it is serving a useful purpose. It's setting a default floor on how the systems behave, as well as reducing implementation complexity and concerns about bid-down attacks. >I strongly oppose the illusion of > security when communications are not secure. I'd be happy to recommend a less secure-looking UI when the JS was served over HTTP. Did you have some other concern? > If an application is delivered > over HTTP, the fact that media is encrypted is irrelevant and provides no > useful security. As I've observed before, this isn't in fact correct. Yes, our currently existing mechanisms for providing secure communications with completely insecure signaling are less than optimal, but they do exist, and as my document makes clear, there are potential approaches that could make this significantly easier. > There is a duality about web based applications with HTTP > and HTTPS. I think WebRTC should reflect this. There is a working model > present for HTTP applications already (secure document -- secure > communications, insecure document -- insecure communications), so I do not > see the reason to break it. Characterizing this model as "working" seems at best an exaggeration, as anyone who has had to deal with mixed content, SOP conflicts, or "secure" cookies can attest. -Ekr From HKaplan@acmepacket.com Thu Nov 10 17:15:56 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8F61F0C55 for ; Thu, 10 Nov 2011 17:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 D7rWiKr7Hy3J for ; Thu, 10 Nov 2011 17:15:56 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id ED9CC1F0C3C for ; Thu, 10 Nov 2011 17:15:55 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Nov 2011 20:15:54 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 10 Nov 2011 20:15:54 -0500 From: Hadriel Kaplan To: Eric Rescorla Thread-Topic: [rtcweb] Let's define the purpose of WebRTC Thread-Index: AQHMoA91VkgmsgEwCUGv+NsxP/Ew4g== Date: Fri, 11 Nov 2011 01:15:54 +0000 Message-ID: References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <228696DD-CAF5-4D50-AA5A-11F62DFD01EE@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="iso-8859-1" Content-ID: <73305F9A8952C1499E0DD1ACDD51C424@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Fri, 11 Nov 2011 01:15:56 -0000 On Nov 10, 2011, at 4:34 PM, Eric Rescorla wrote: > This isn't my point: Roman offered a set of use cases he claimed didn't > require confidentiality. But in fact, many such cases do. The fact that > there are also overlapping cases which do not is an argument for erring > on the side of confidentiality, not the other way around. But the argument isn't about a generic "game-app" or generic "greeting card= " WebRTC use-case - it's about a specific "game-app" or "greeting card" app= lication instance. In other words, of course for a "game-app" use-case we = can imagine games which involve money that need media security; but there a= re "Farmville" and Scrabble and so on games as well, and those are the spec= ific applications that're being proposed don't need it and may not want it.= Likewise, of course there could be greeting-card application sites that p= urport to provide strong privacy, but there are free ones that do not claim= that today. The subtle difference, I think, is that you're viewing it like WebRTC is a = generic application that can be used by different hosting sites for differe= nt purposes, whereas I view WebRTC as a toolkit to build different applicat= ions - like a library included with my OS or compiler. So saying "well sin= ce someone could use WebRTC for something sensitive we have to assume the w= orst case" sounds rather odd to me - it's like a compiler removing a librar= y because some programs made for sensitive data could be accidentally using= it. No? -hadriel p.s. it's hard to convey emotion/emphasis/conviction in email, so I'd like = to mention I'd also be ok with SRTP being mandatory-to-use. I just think t= he arguments used so far for doing so have been weak. ;) =20 Personally I think a better argument for making it mandatory-to-use is publ= ic/press perception. (and no I'm not joking) From ekr@rtfm.com Thu Nov 10 17:30:50 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281361F0C5E for ; Thu, 10 Nov 2011 17:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.938 X-Spam-Level: X-Spam-Status: No, score=-102.938 tagged_above=-999 required=5 tests=[AWL=0.039, 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 9HPl-f2NJNBo for ; Thu, 10 Nov 2011 17:30:49 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 925A31F0C3C for ; Thu, 10 Nov 2011 17:30:49 -0800 (PST) Received: by yenq4 with SMTP id q4so295157yen.31 for ; Thu, 10 Nov 2011 17:30:49 -0800 (PST) Received: by 10.146.25.2 with SMTP id 2mr1204485yay.20.1320975049084; Thu, 10 Nov 2011 17:30:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.146.151.3 with HTTP; Thu, 10 Nov 2011 17:30:08 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <228696DD-CAF5-4D50-AA5A-11F62DFD01EE@acmepacket.com> From: Eric Rescorla Date: Thu, 10 Nov 2011 17:30:08 -0800 Message-ID: To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Fri, 11 Nov 2011 01:30:50 -0000 On Thu, Nov 10, 2011 at 5:15 PM, Hadriel Kaplan wr= ote: > > On Nov 10, 2011, at 4:34 PM, Eric Rescorla wrote: > >> This isn't my point: Roman offered a set of use cases he claimed didn't >> require confidentiality. But in fact, many such cases do. The fact that >> there are also overlapping cases which do not is an argument for erring >> on the side of confidentiality, not the other way around. > > But the argument isn't about a generic "game-app" or generic "greeting ca= rd" WebRTC use-case - it's about a specific "game-app" or "greeting card" a= pplication instance. =A0In other words, of course for a "game-app" use-case= we can imagine games which involve money that need media security; but the= re are "Farmville" and Scrabble and so on games as well, and those are the = specific applications that're being proposed don't need it and may not want= it. I get that that's the argument you're offering, but my point is that people= 's intuitions about what's needed are generally wrong. To take the specific examples you've chosen, why do you think Scrabble doesn't require security? If people are playing a scrabble tournament, then certainly there is something riding on the outcome and so security is appropriate. (This is, for instance, an issue for first person shooters, where tournamen= ts can have high stakes). > The subtle difference, I think, is that you're viewing it like WebRTC is = a generic application that can be used by different hosting sites for diffe= rent purposes, whereas I view WebRTC as a toolkit to build different applic= ations - like a library included with my OS or compiler. =A0So saying "well= since someone could use WebRTC for something sensitive we have to assume t= he worst case" sounds rather odd to me - it's like a compiler removing a li= brary because some programs made for sensitive data could be accidentally u= sing it. No? I would say a better analogy is a system declining to offer APIS which are = known to be extremely dangerous (since we are building a new system it's not real= ly a question of removing.) And indeed this is good practice. Imagine all the security vulnerabilities which could have been avoided if the C standard li= brary had not included strcpy(). -Ekr From pravindran@sonusnet.com Thu Nov 10 21:21:35 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1011F0C3D for ; Thu, 10 Nov 2011 21:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 Qj-Sa4LXOP-e for ; Thu, 10 Nov 2011 21:21:34 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id C26E21F0C35 for ; Thu, 10 Nov 2011 21:21:34 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pAB5M8ol013443; Fri, 11 Nov 2011 00:22:08 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Nov 2011 00:20:42 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Nov 2011 10:50:52 +0530 Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by inba-hub01.sonusnet.com (10.70.51.86) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 11 Nov 2011 10:50:52 +0530 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.0339.001; Fri, 11 Nov 2011 10:50:52 +0530 From: "Ravindran, Parthasarathi" To: Cullen Jennings Thread-Topic: Comment on draft-jennings-rtcweb-signaling-01 Thread-Index: Acyf7zUuadnwodmgQL6L/8CdxQMr2A== Date: Fri, 11 Nov 2011 05:20:51 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01CE7093@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Nov 2011 05:20:52.0838 (UTC) FILETIME=[AE803060:01CCA031] Cc: "" Subject: [rtcweb] Comment on draft-jennings-rtcweb-signaling-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 05:21:35 -0000 Cullen, On the last RTCWeb call (http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg02260.html), you have mentioned that " I will clarify ROAP is over-the= -wire protocol" as per note but it does not reflect in draft-jennings-rtcwe= b-signaling-01. Could you please let me know the reason for this change. Thanks Partha=20 From pravindran@sonusnet.com Thu Nov 10 21:23:02 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E174E1F0C3D for ; Thu, 10 Nov 2011 21:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 BOLRc1LyuNs2 for ; Thu, 10 Nov 2011 21:23:02 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC3C1F0C35 for ; Thu, 10 Nov 2011 21:23:02 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pAB5Nbaw014033; Fri, 11 Nov 2011 00:23:37 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Nov 2011 00:20:38 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Nov 2011 10:50:45 +0530 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.0339.001; Fri, 11 Nov 2011 10:50:44 +0530 From: "Ravindran, Parthasarathi" To: Eric Rescorla Thread-Topic: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of WebRTC) Thread-Index: AQHMnoiMLXoobGtfx0Kkx8oSZTnrRJWj1oYwgABiqoCAAVQz4P//q0QAgABeqYD//6mjAIABYdXw Date: Fri, 11 Nov 2011 05:20:44 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01CE7066@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <4EB9ACF5.80805@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FE6@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A6B5@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A6DF@inba-mail01.sonusnet.com> 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.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Nov 2011 05:20:45.0698 (UTC) FILETIME=[AA3EB620:01CCA031] Cc: "<,rtcweb@ietf.org>," Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of 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: Fri, 11 Nov 2011 05:23:03 -0000 Eric, 10% performance impact due to (security) service is a impact on the system.= In case of walled garden (Enterprise) network, there is no need to design = the system which always requires of 10% performance w.r.t general purpose h= ardware and obvious choice is to come up with custom build hardware which r= educes the cost of system and solution. But your proposal of "mandatory to = implement" forces these kind of solution to increase the cost unnecessarily= . So, I argue for "mandatory to implement" in browser but against "mandator= y to use" which breaks these kind of deployment model. Thanks Partha >-----Original Message----- >From: Eric Rescorla [mailto:ekr@rtfm.com] >Sent: Thursday, November 10, 2011 11:24 AM >To: Ravindran, Parthasarathi >Cc: Cameron Byrne; <,rtcweb@ietf.org>, >Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define >the purpose of WebRTC) > >On Wed, Nov 9, 2011 at 9:40 PM, Ravindran, Parthasarathi > wrote: >> Eric, >> >> Of course, the bandwidth requirement is range from 4MB/s to 16MB/s >based on deployment but the point to be noted is that the device is not >doing encryption/decryption alone. > >Of course not, but based on the data I just provided and these >bandwidth estimates, >encryption would consume on the order of 5-10% of a relatively modest >machine. >Again, do you have any actual measurements that show that crypto is a >serious >performance problem? > >-Ekr From pravindran@sonusnet.com Thu Nov 10 21:23:06 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD42A1F0C5F for ; Thu, 10 Nov 2011 21:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt3GpXyAcaX1 for ; Thu, 10 Nov 2011 21:23:05 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id EDC791F0C5A for ; Thu, 10 Nov 2011 21:23:04 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pAB5Nbb2014033; Fri, 11 Nov 2011 00:23:37 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Nov 2011 00:20:36 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Nov 2011 10:50:45 +0530 Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by inba-hub01.sonusnet.com (10.70.51.86) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 11 Nov 2011 10:50:44 +0530 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.0339.001; Fri, 11 Nov 2011 10:50:44 +0530 From: "Ravindran, Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [rtcweb] Regarding Federation Arguments Thread-Index: AQHMmhOSpaBQnqnn3Ea06PkOYAyRWJWbBmeQ//+xdQCAC+0LMA== Date: Fri, 11 Nov 2011 05:20:43 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01CE7059@inba-mail01.sonusnet.com> References: <4EB26D22.5090000@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6CD2FA@inba-mail01.sonusnet.com> 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.164] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 11 Nov 2011 05:20:45.0479 (UTC) FILETIME=[AA1D4B70:01CCA031] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Nov 2011 05:23:06 -0000 SW5ha2ksDQoNClBsZWFzZSByZWFkIGlubGluZQ0KDQpUaGFua3MNClBhcnRoYQ0KDQo+LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86 aWJjQGFsaWF4Lm5ldF0NCj5TZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMDMsIDIwMTEgNTo1OSBQ TQ0KPlRvOiBSYXZpbmRyYW4gUGFydGhhc2FyYXRoaQ0KPkNjOiBNYWdudXMgV2VzdGVybHVuZDsg cnRjd2ViQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtydGN3ZWJdIFJlZ2FyZGluZyBGZWRlcmF0 aW9uIEFyZ3VtZW50cw0KPg0KPjIwMTEvMTEvMyBSYXZpbmRyYW4gUGFydGhhc2FyYXRoaSA8cHJh dmluZHJhbkBzb251c25ldC5jb20+Og0KPj4gSSBhZ3JlZSB3aXRoIHRoZSBjb25zZW5zdXMgdGhh dCB0aGVyZSBpcyBubyBuZWVkIHRvIG1hbmRhdGUgYW55DQo+c2lnbmFsaW5nIHByb3RvY29sIGFz IEZlZGVyYXRpb24gcHJvdG9jb2wgZm9yIFdlYlJUQy4NCj4NCj5EbyB5b3U/IEkgY291bGQgZmlu ZCB+MTAwIG1haWxzIGZyb20geW91IChpbmNsdWRpbmcgYSBkcmFmdCBhbmQNCj5zbGlkZXMpIGlu IHdoaWNoIHlvdSBhZHZvY2F0ZSBmb3IgdGhlIG9wcG9zaXRlLCBhbmQgbm90IGp1c3QgYWJvdXQg dGhlDQo+ZmVkZXJhdGlvbiBwcm90b2NvbCwgYnV0IGFsc28gYWJvdXQgbWFuZGF0aW5nIHRoZSBp bi10aGUtd2lyZSBwcm90b2NvbA0KPmluIGJyb3dzZXIgdG8gc2VydmVyIGNvbW11bmljYXRpb24u DQo+DQo8cGFydGhhPiBJIHRob3VnaHQgdGhhdCB5b3Ugd291bGQgaGF2ZSBjbGVhciBhZnRlciBs b29raW5nIGF0IG15IHNsaWRlIA0Kb24gdGhlIGxhc3QgUlRDV2ViIGNhbGwgd2hlcmVpbiBwcm92 aWRpbmcgdGhlIHN0YW5kYXJkIG1lY2hhbmlzbSB2cyBsb3cgbGV2ZWwgDQptZWNoYW5pc20uIElN TywgeW91ciBMb3cgKGZyZWVkb20pIGJhc2VkIGxldmVsIEFQSSBhbmQgc3RhbmRhcmQgb24td2ly ZSANCnByb3RvY29sIGFyZSBjb21wbGVtZW50YXJ5IGJlY2F1c2UgYm90aCBzZXJ2ZSB0d28gZGlm ZmVyZW50IHB1cnBvc2UuDQpGcmVlZG9tIGJhc2VkIEFQSSBoZWxwcyB0byBidWlsZCBTSVAgb3Zl ciB3ZWJzb2NrZXQga2luZCBvZiBhcHBsaWNhdGlvbiBvcg0KUHJvcHJpZXRhcnkgRmFjZWJvb2sg b3IgR29vZ2xlIGJhc2VkIFdlYlJUQyBtZWNoYW5pc20uDQpCdXQgc3RhbmRhcmQgb24td2lyZSAo c2F5IFJPQVAgb3ZlciBKU09OKSBoZWxwcyBmb2xrcyBub3QgdG8gbG9vayBpbnRvDQpQcm90b2Nv bCBpbnRyaWNhY2llcyBpbiB0aGUgYnJvd3Nlci4gSXQgaXMgdmVyeSBtdWNoIHBvc3NpYmxlIHRv IGNvLWV4aXN0LiANCkkgcmVhbGx5IGRvbid0IHdoZXJlIGlzIHlvdXIgY29uY2VybiA8L3BhcnRo YT4NCg0KPlNvIEkgY2VsZWJyYXRlIHlvdSBhZ3JlZSBub3cgd2l0aCB0aGUgY29uc2Vuc3VzIDop DQo8cGFydGhhPiBHb29kIHRoYXQgd2UgaGF2ZSBzb21lIGNvbW1vbiB1bmRlcnN0YW5kaW5nIGFm dGVyIHRoZSBsb25nIGRpc2N1c3Npb24NCiA8L3BhcnRoYT4NCj4NCj4NCj4+IExldCBGZWRlcmF0 aW9uIHByb3RvY29sIGJlIFNJUCBvciBKaW5nbGUgb3IgYW55IHNpZ25hbGluZyBwcm90b2NvbCBm b3INCj50aGF0IG1hdHRlci4NCj4+DQo+PiBJJ20gaW50ZXJlc3RlZCBpbiBhc2tpbmcgdGhlIGZv bGtzIHdoZXRoZXIgV0cgd2lsbCBiZSBpbnRlcmVzdGVkIHRvDQo+c2VlIHRoZSAiaW5mb3JtYXRp b25hbCIgZHJhZnQgb24gbWFwcGluZyB3aXRoIFdlYlJUQyBzaWduYWxpbmcgKFJPQVAgKw0KPm90 aGVyIG1lY2hhbmlzbSkgdG8gc3RhbmRhcmQgZmVkZXJhdGlvbiBwcm90b2NvbCBsaWtlIFNJUCwg SmluZ2xlLg0KPmRyYWZ0LWthcGxhbi1ydGN3ZWItc2lwLWludGVyd29ya2luZy1yZXF1aXJlbWVu dHMtMDAgZm9jdXMgb24gdGhlDQo+aW50ZXJ3b3JraW5nIHdpdGggZGVwbG95ZWQgU0lQIGRldmlj ZXMuIE15IHByb3Bvc2FsIGlzIHRvIGV4dGVuZCB0aGUNCj5kcmFmdCB0byDCoGFjY29tbW9kYXRl IG90aGVyIHN0YW5kYXJkIGZlZGVyYXRpb24gcHJvdG9jb2wgYW5kIGFsc28NCj5jb25zaWRlciB0 aGUgcG9zc2libGUgb3RoZXIgZGVwbG95bWVudCBzY2VuYXJpby4gVGhlIGludGVudGlvbiBvZiB0 aGUNCj5kcmFmdCBpcyB0byBwcm92aWRlIHRoZSBpbXBsZW1lbnRhdGlvbiBndWlkZWxpbmVzIGZv ciB0aGUgV2ViUlRDDQo+RmVkZXJhdGlvbi4NCj4NCj5JTUhPIGdpdmVuIHRoYXQgdGhlIGNvbnNl bnN1cyBpcyBub3QgdG8gZGVmaW5lIGJyb3dzZXItdG8tc2VydmVyIG5vcg0KPnNlcnZlci10by1z ZXJ2ZXIgcHJvdG9jb2xzLCB3ZSBzaG91bGQgZm9jdXMgb24gcmVtYWluaW5nIGl0ZW1zIHJhdGhl cg0KPnRoYW4gc3BlbmRpbmcgdGltZSBpbiBpbmZvcm1hdGlvbmFsIHRvcGljcy4gT3IgYXQgbGVh c3QsIEkgd291bGQgd2FpdA0KPnVudGlsIHJlbWFpbmluZyBpdGVtcyBhcmUgbW9yZSBkZWZpbmVk IChpdCBjb3VsZCBoZWxwIGluIHRoZSBkb2N1bWVudA0KPnlvdSBoYXZlIGluIG1pbmQpLiBPZiBj b3Vyc2UgeW91IGFyZSBmcmVlIHRvIHdyaXRlIGl0IHdoZW5ldmVyIHlvdQ0KPndhbnQuDQo+DQo+ UmVnYXJkcy4NCj4NCj4NCj4tLQ0KPknDsWFraSBCYXogQ2FzdGlsbG8NCj48aWJjQGFsaWF4Lm5l dD4NCg== From christer.holmberg@ericsson.com Thu Nov 10 23:13:19 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8A01F0C5F for ; Thu, 10 Nov 2011 23:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=0.094, 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 Y9dqCkFRKoDP for ; Thu, 10 Nov 2011 23:13:19 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B47A31F0C35 for ; Thu, 10 Nov 2011 23:13:15 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-d6-4ebccb0ab6f7 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 11.4F.13753.A0BCCBE4; Fri, 11 Nov 2011 08:13:14 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.197]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Fri, 11 Nov 2011 08:13:14 +0100 From: Christer Holmberg To: "Ravindran, Parthasarathi" , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Fri, 11 Nov 2011 08:11:14 +0100 Thread-Topic: [rtcweb] Regarding Federation Arguments Thread-Index: AQHMmhOSpaBQnqnn3Ea06PkOYAyRWJWbBmeQ//+xdQCAC+0LMIAAqSVB Message-ID: <7F2072F1E0DE894DA4B517B93C6A058524DBFEE653@ESESSCMS0356.eemea.ericsson.se> References: <4EB26D22.5090000@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6CD2FA@inba-mail01.sonusnet.com> , <387F9047F55E8C42850AD6B3A7A03C6C01CE7059@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01CE7059@inba-mail01.sonusnet.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Nov 2011 07:13:19 -0000 Hi, >So I celebrate you agree now with the consensus :) I would appretiate if we don't use the word "consensus", unless it has actu= ally been declared by the WG chairs. Regards, Christer From harald@alvestrand.no Thu Nov 10 23:14:12 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895E11F0C5F for ; Thu, 10 Nov 2011 23:14:12 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWs1SwtOTmQa for ; Thu, 10 Nov 2011 23:14:12 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id DE8031F0C35 for ; Thu, 10 Nov 2011 23:14:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 022EB39E12F; Fri, 11 Nov 2011 08:14:11 +0100 (CET) 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 NaXsBPpPKN+b; Fri, 11 Nov 2011 08:14:10 +0100 (CET) Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 6E10B39E048; Fri, 11 Nov 2011 08:14:10 +0100 (CET) Message-ID: <4EBCCB42.8040100@alvestrand.no> Date: Fri, 11 Nov 2011 08:14:10 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Roman Shpount References: <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> <4EBC4401.2090703@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] Traffic should be encrypted. (Re: Let's define the purpose of 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: Fri, 11 Nov 2011 07:14:12 -0000 On 11/10/2011 11:07 PM, Roman Shpount wrote: > > These arguments are not very strong and would not prevent WebRTC from > being used (except the illegal part). My main problem is that > mandatory encryption is not serving any useful purpose. I strongly > oppose the illusion of security when communications are not secure. If > an application is delivered over HTTP, the fact that media is > encrypted is irrelevant and provides no useful security. There is a > duality about web based applications with HTTP and HTTPS. I think > WebRTC should reflect this. I still don't get this. The same logic would say that there's no reason to use WPA for your home wireless network as long as you're only sending HTTP. Firesheep to the rescue. Encryption of the media path protects you against *some* of the attackers *some* of the time. Only a solidly designed end-to-end-protected mechanism, including safe storage of keying materials in locations where zero-day exploits can't get at them, will protect you against *all* the attackers *all* of the time (as long as the attackers didn't make your hardware, OS or application). > There is a working model present for HTTP applications already (secure > document -- secure communications, insecure document -- insecure > communications), so I do not see the reason to break it. I don't see that one working, either. Witness the number of HTTP sites that use HTTPS form submission (the document's vulnerable to attacker, yet sent over a trusted path), or the number of times my Chrome warns me about mixed content from well-renowned sites. The current ecosystem is an out-and-out muddle, not a clean model. And the exploits are rife. From oej@edvina.net Fri Nov 11 00:49:43 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8D721F84AC for ; Fri, 11 Nov 2011 00:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_SE=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 H-NDnxX5jtaM for ; Fri, 11 Nov 2011 00:49:43 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 52A9921F84AA for ; Fri, 11 Nov 2011 00:49:43 -0800 (PST) Received: from [192.168.20.63] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp7.webway.se (Postfix) with ESMTPA id 6D04C754BD08; Fri, 11 Nov 2011 08:49:39 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Fri, 11 Nov 2011 09:49:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> <4EBC4401.20 90703@alvestrand.no> To: Roman Shpount X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Fri, 11 Nov 2011 08:49:44 -0000 10 nov 2011 kl. 23:07 skrev Roman Shpount: >=20 >=20 > On Thu, Nov 10, 2011 at 4:37 PM, Harald Alvestrand = wrote: > So far, we've heard arguments that: >=20 > - encryption uses more CPU (true, but arguably not significant = compared to media processing) > - It is needed for legacy interoperability (may be true for some, but = not necessarily compelling) > - It helps debugging (which has been disputed by people who debug = systems) >=20 > Did I miss some? >=20 >=20 > Encryption being illegal in some situations is yet another reason (I = know about the IETF position on wiretapping, but I would still argue = that this is a valid reason.) >=20 > Higher barrier to entry for building new services -- for instance if = you are building a media server to work with WebRTC client. Having one = more thing to implement before something works is not critical, but = makes a difference. If you support DTMF in RTP you already have a requirement that you = SHOULD only do that over SRTP. If rtcweb supports telephony-events, we = are already on the SRTP side as almost mandatory. I think it's easier to = reach an agreement on SRTP being mandatory than DTMF being dis-allowed. Appendix A of RFC 4733: "The Security Considerations section is updated to mention the requirement for protection of integrity. More importantly, it makes implementation of SRTP [7] mandatory for compliant implementations, without specifying a mandatory-to-implement method of key distribution." "The telephone-event payload defined in this specification is highly compressed. A change in value of just one bit can result in a major change in meaning as decoded at the receiver. Thus, message integrity MUST be provided for the telephone-event payload type. To meet the need for protection both of confidentiality and integrity, compliant implementations SHOULD implement the Secure Real-time Transport Protocol (SRTP) [7]." Section 6 of RFC 4733 - an RFC that makes 2833 obsolete. /O From oej@edvina.net Fri Nov 11 01:01:24 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A31E21F87D9 for ; Fri, 11 Nov 2011 01:01:24 -0800 (PST) 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.115, BAYES_00=-2.599, HELO_EQ_SE=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 rhsfhBUWvneC for ; Fri, 11 Nov 2011 01:01:24 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 011A521F87D6 for ; Fri, 11 Nov 2011 01:01:24 -0800 (PST) Received: from [192.168.20.63] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp7.webway.se (Postfix) with ESMTPA id 4DD64754BD1C; Fri, 11 Nov 2011 09:01:22 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: Date: Fri, 11 Nov 2011 10:01:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <845C03B2-1975-4145-8F52-8CEC9E360AF3@edvina.net> <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <228696DD-CAF5-4D50-AA5A-11F62DFD01EE@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1251.1) Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Fri, 11 Nov 2011 09:01:24 -0000 11 nov 2011 kl. 02:15 skrev Hadriel Kaplan: > But the argument isn't about a generic "game-app" or generic "greeting = card" WebRTC use-case - it's about a specific "game-app" or "greeting = card" application instance. In other words, of course for a "game-app" = use-case we can imagine games which involve money that need media = security; but there are "Farmville" and Scrabble and so on games as = well, and those are the specific applications that're being proposed = don't need it and may not want it. Likewise, of course there could be = greeting-card application sites that purport to provide strong privacy, = but there are free ones that do not claim that today. Let's use scrabbel as an example. In Sweden, there's a very popular app = for iPhone and Android called WordFeud, which is scrabble. It recently = added chat. Now, that chat is not protected at all. The application = moved from being "harmless" in your view, to being "potentially in need = of confidentiality".=20 If we avoid having to classify applications and access networks and just = provide the security, applications may glide. They may add audio and = video and chat without risking stuff. /O= From harald@alvestrand.no Fri Nov 11 01:11:15 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14DE21F8880 for ; Fri, 11 Nov 2011 01:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.541 X-Spam-Level: X-Spam-Status: No, score=-110.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 rjG0ngUgqopG for ; Fri, 11 Nov 2011 01:11:14 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 540DD21F84C1 for ; Fri, 11 Nov 2011 01:11:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9F81D39E12F; Fri, 11 Nov 2011 10:11:13 +0100 (CET) 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 8LIuebja4Aei; Fri, 11 Nov 2011 10:11:12 +0100 (CET) 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 ESMTPS id 8F35D39E048; Fri, 11 Nov 2011 10:11:12 +0100 (CET) Message-ID: <4EBCE6AF.9090208@alvestrand.no> Date: Fri, 11 Nov 2011 10:11:11 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Hadriel Kaplan References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <228696DD-CAF5-4D50-AA5A-11F62DFD01EE@acmepacket.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [rtcweb] Let's define the purpose of 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: Fri, 11 Nov 2011 09:11:15 -0000 On 11/11/2011 02:15 AM, Hadriel Kaplan wrote: > On Nov 10, 2011, at 4:34 PM, Eric Rescorla wrote: > >> This isn't my point: Roman offered a set of use cases he claimed didn't >> require confidentiality. But in fact, many such cases do. The fact that >> there are also overlapping cases which do not is an argument for erring >> on the side of confidentiality, not the other way around. > But the argument isn't about a generic "game-app" or generic "greeting card" WebRTC use-case - it's about a specific "game-app" or "greeting card" application instance. In other words, of course for a "game-app" use-case we can imagine games which involve money that need media security; but there are "Farmville" and Scrabble and so on games as well, and those are the specific applications that're being proposed don't need it and may not want it. Likewise, of course there could be greeting-card application sites that purport to provide strong privacy, but there are free ones that do not claim that today. > > The subtle difference, I think, is that you're viewing it like WebRTC is a generic application that can be used by different hosting sites for different purposes, whereas I view WebRTC as a toolkit to build different applications - like a library included with my OS or compiler. So saying "well since someone could use WebRTC for something sensitive we have to assume the worst case" sounds rather odd to me - it's like a compiler removing a library because some programs made for sensitive data could be accidentally using it. No? I'd prefer the analogy of Java deciding to not support raw pointers. Sure, it reduces the expressive power of the language compared to C++, but it has certain benefits. From bernard_aboba@hotmail.com Fri Nov 11 03:44:20 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC1421F84AD for ; Fri, 11 Nov 2011 03:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.885 X-Spam-Level: X-Spam-Status: No, score=-99.885 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, 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 b8KbhOMKYkju for ; Fri, 11 Nov 2011 03:44:20 -0800 (PST) Received: from blu0-omc3-s20.blu0.hotmail.com (blu0-omc3-s20.blu0.hotmail.com [65.55.116.95]) by ietfa.amsl.com (Postfix) with ESMTP id 568CE21F848D for ; Fri, 11 Nov 2011 03:44:20 -0800 (PST) Received: from BLU0-SMTP109 ([65.55.116.74]) by blu0-omc3-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Nov 2011 03:44:15 -0800 X-Originating-IP: [203.69.99.17] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Received: from [172.20.1.192] ([203.69.99.17]) by BLU0-SMTP109.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Nov 2011 03:44:15 -0800 References: <4EB26D22.5090000@ericsson.com> <4EBA741A.1010307@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C0134A992@inba-mail01.sonusnet.com> In-Reply-To: MIME-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: iPad Mail (9A334) From: Bernard Aboba Date: Fri, 11 Nov 2011 19:44:17 +0800 To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= X-OriginalArrivalTime: 11 Nov 2011 11:44:15.0638 (UTC) FILETIME=[3D3CEB60:01CCA067] Cc: "" Subject: Re: [rtcweb] RTCWEB is not SIP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Nov 2011 11:44:21 -0000 +1 I=C3=B1aki Baz Castillo said: >=20 > WebRTC is not SIP... >=20 > IMHO we should stop talking about SIP in this WG.... > First priority is to define WebRTC regardless of federation... From roman@telurix.com Fri Nov 11 04:02:36 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D3321F8593 for ; Fri, 11 Nov 2011 04:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[AWL=0.079, 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 BNvp1757YShB for ; Fri, 11 Nov 2011 04:02:35 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 596D621F8548 for ; Fri, 11 Nov 2011 04:02:35 -0800 (PST) Received: by gye5 with SMTP id 5so3382694gye.31 for ; Fri, 11 Nov 2011 04:02:35 -0800 (PST) Received: by 10.101.4.20 with SMTP id g20mr5666387ani.73.1321012954603; Fri, 11 Nov 2011 04:02:34 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id f32sm33149203ani.20.2011.11.11.04.02.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Nov 2011 04:02:33 -0800 (PST) Received: by ywt34 with SMTP id 34so2215119ywt.31 for ; Fri, 11 Nov 2011 04:02:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.31.170 with SMTP id b10mr24056389pbi.18.1321012951954; Fri, 11 Nov 2011 04:02:31 -0800 (PST) Received: by 10.68.62.170 with HTTP; Fri, 11 Nov 2011 04:02:31 -0800 (PST) In-Reply-To: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> Date: Fri, 11 Nov 2011 07:02:31 -0500 Message-ID: From: Roman Shpount To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=bcaec520f2afbeb61904b1744be8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Fri, 11 Nov 2011 12:02:36 -0000 --bcaec520f2afbeb61904b1744be8 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 11, 2011 at 3:49 AM, Olle E. Johansson wrote: > If you support DTMF in RTP you already have a requirement that you SHOULD > only do that over SRTP. If rtcweb supports telephony-events, we are > already on the SRTP side as almost mandatory. I think it's easier to reach > an agreement on SRTP being mandatory than DTMF being dis-allowed. > > Well, this is a perfect example when specifying mandatory security for wrong reasons is simply being ignored. All the reactions I've seen to this so far were "this is only a SHOULD, let's disregard this for now". Getting security requirements in the standard which are too high too be practical usually produces products which disregard security completely, reaching the exactly opposite effect. I think, in this particular case, the right course of action is to use AVT tones in RTP as the rest of the industry is doing now. Also, I wanted expand on the debug requirements: I do hope we will make key exchange mechanism, different from SDES, mandatory for WebRTC. Passing actual encryption keys through JavaScript makes media encryption to easy to circumvent. This means some type of public/private key encryption used for key exchange. If we do this right, getting to the actual key used for media session encryption will be very difficult, so most of the tools currently used for SRTP debugging will stop working. We will also end up with something new, which will mean extensive need for debugging. Ability to turn this component on and off will be very helpful for implementation debugging. Once again, this will probably be not a critical point, but making something easier for developers usually goes a long way in driving the adoption. One more benefit of having RTP as fallback for legacy interop is that it will allow us to specify something that will be more secure for WebRTC. If SDES support would no longer be needed, we can concentrate on using key exchange mechanism that is actually secure. Finally, (going slightly off topic here) it would probably be a good idea to make key exchange part of the initial ICE transaction. This way we can use this key exchange as an additional verification of the remote party, and reduce the number of round trips required before the media flow is established. _____________ Roman Shpount --bcaec520f2afbeb61904b1744be8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 11, 2011 at 3:49 AM, Olle E. Johanss= on <oej@edvina.net> wrote:
If you support DTMF in RTP you already have a requirement that you SHOULD = =A0only do that over SRTP. If rtcweb supports telephony-events, we are alre= ady on the SRTP side as almost mandatory. I think it's easier to reach = an agreement on SRTP being mandatory than DTMF being dis-allowed.


Well, this is a perfect example when specifying = mandatory security for wrong reasons is simply being ignored. All the react= ions I've seen to this so far were "this is only a SHOULD, let'= ;s disregard this for now". Getting security requirements in the stand= ard which are too high too be practical usually produces products which dis= regard security completely, reaching the exactly opposite effect. I think, = in this particular case, the right course of action is to use AVT tones in = RTP as the rest of the industry is doing now.

Also, I wanted expand on the debug requirements: I do hope we will make= key exchange mechanism, different from SDES, mandatory for WebRTC. Passing= actual encryption keys through JavaScript makes media encryption to easy t= o circumvent. This means some type of public/private key encryption used fo= r key exchange. If we do this right, getting to the actual key used for med= ia session encryption will be very difficult, so most of the tools currentl= y used for SRTP debugging will stop working. We will also end up with somet= hing new, which will mean extensive need for debugging. Ability to turn thi= s component on and off will be very helpful for implementation debugging. O= nce again, this will probably be not a critical point, but making something= easier for developers usually goes a long way in driving the adoption.
One more benefit of having RTP as fallback for legacy interop is that i= t will allow us to specify something that will be more secure for WebRTC. I= f SDES support would no longer be needed, we can concentrate on using key e= xchange mechanism that is actually secure.

Finally, (going slightly off topic here) it would probably be a good id= ea to make key exchange part of the initial ICE transaction. This way we ca= n use this key exchange as an additional verification of the remote party, = and reduce the number of round trips required before the media flow is esta= blished.
_____________
Roman Shpount

--bcaec520f2afbeb61904b1744be8-- From Michael.Tuexen@lurchi.franken.de Fri Nov 11 05:15:42 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A39021F8532 for ; Fri, 11 Nov 2011 05:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.413, 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 v8cpXU8DB2cz for ; Fri, 11 Nov 2011 05:15:41 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id D12F221F8515 for ; Fri, 11 Nov 2011 05:15:40 -0800 (PST) Received: from [192.168.1.124] (p508FD391.dip.t-dialin.net [80.143.211.145]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 1E8771C0C0BCE; Fri, 11 Nov 2011 14:15:38 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> Date: Fri, 11 Nov 2011 14:15:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <474200CA-F509-438B-A9CD-71742F4AF6B7@lurchi.franken.de> References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> To: Michael Thornburgh X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 13:15:42 -0000 Hi Michael, see my comments in-line. Best regards Michael On Nov 3, 2011, at 2:12 AM, Michael Thornburgh wrote: > comments on this draft: >=20 > section 3.2: reliable streams would be fairly simple to layer on top = of any reliable and in-order datagram delivery service, not just SCTP's. >=20 > section 4.1: DCCP is not a good choice when any kind of reliability is = desired. i've seen people on this list suggest that some kind of = reliability/retransmission scheme can be layered on top of DCCP, and = while that's certainly true, it's very un-optimal. DCCP already uses its = own sequence numbers and acknowledgements to detect loss events and = trigger congestion response, but that information is semantically hidden = from higher-level users of DCCP. additional application-layer sequencing = AND acknowledgement information must be implemented to 1) recover the = original transmission order at the receiver (including waiting for gaps = to be repaired, if in-order delivery is desired); and 2) duplicate = application-layer loss detection at the sender (driven by the = application-layer acks) must be performed to re-determine which segments = were lost so they can be retransmitted. that sucks because, under the = covers, DCCP already knew exactly which segments were lost and was in = the best posit > ion to trigger (fast-) retransmission if appropriate. >=20 > general comments on SCTP: >=20 > Matthew and i examined SCTP when we were designing MFP (the = predecessor of RTMFP). in fact, if you look at the MFP protocol spec in = the Internet Archive, you might notice a suspicious similarity to SCTP's = chunk scheme. :) >=20 > we rejected SCTP as inappropriate for real-time communication and our = other use cases for several reasons. some of these have been at least = partially addressed since our initial dismissal of SCTP in 2004 (in = particular, DTLS in SCTP addresses the limitations of using TLS in SCTP = [RFC3436], which at the time was the only way to "secure" SCTP messages; = that mechanism meant that all secure messages/streams had to be fully = reliable and in-order, which was unacceptable for real-time = communication). >=20 > issues with SCTP that remain, and which i believe make it undesirable = for WebRTC, include: >=20 > o as you point out in section 5.3, running SCTP over DTLS, rather = than DTLS over SCTP, is desired so that all SCTP fields, not just the = user data, are secured. however, this configuration is currently not = defined by IETF and would have to be specified. >=20 > o DTLS and SCTP handshakes must be performed serially (no matter = which order they happen in), which increases the number of round-trips = necessary to establish communication. That is correct. SCTP adds one RTT to whatever DTLS is requiring. So when using SCTP/DTLS/UDP, DTLS needs 3 RTTs (including the initial RTT required for the Cookie exchange). When using DTLS/SCTP/UDP DTLS needs 2 RTTs (since there is no need for the DTLS Cookie). I'm not sure how many RTTs ICE takes. >=20 > o (most important for real-time communication): each user data = fragment/chunk is assigned an SCTP Transmission Sequence Number (TSN) at = the time of first transmission. that means even if your SCTP = implementation supported stream prioritization somehow, the priority = decision is only made at first transmission time. since there's just one = TSN space and the Gap Ack structure only talks about TSNs, it's = undesirable for gaps to persist (else the Gap Ack structure will = continue to grow as more losses naturally happen). therefore it's = desirable to repair gaps as quickly as possible. this may = inappropriately increase the priority of a low priority = fragment/chunk/stream during periods of congestion, which is exactly = when priority matters (this is a "priority inversion"). What might help is that messages have priorities and the sender is = allowed to abandon messages with low priorities in case of congestion (timer based retransmissions). = Something which is supported by PR-SCTP. >=20 > o (second most important for real-time communication): there's only = one receive window advertisement for all of the streams, rather than one = receive window per stream. this means there's no per-stream flow = control. so if you're receiving (for example) a bulk file transfer and = real-time player position updates and text chat messages, and you need = to suspend the file transfer stream for a time, that means you must also = suspend the player position updates and text chat messages. unless you = spin up an entirely separate SCTP for each flow control domain, which is = lame and defeats the purpose of stream multiplexing. You can use priorities tied to streams at the sender side. >=20 > o SCTP specifies the maximum number of streams in each direction at = association startup. web applications may not know the number of streams = needed up front; in fact, the number of streams needed in any real-world = non-SS7 data application is very likely to evolve over the lifetime of = that application, naturally increasing and decreasing. You don't need a lot of resources for the receive side of a stream. So = you could either negotiate a number large enough or use the extension http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-strrst-12 which is currently in IETF LC. It enables you to add streams on the fly. >=20 > o the semantics of unordered messages are confusing and not a good = map to WebRTC. they are semantically equivalent to an entirely separate = stream loosely associated to the ordered stream of the same number. = there's no way to tell (without application layer sequencing) if an = unordered message has been lost/abandoned by the sender. at the protocol = level, TSNs can be used to recover the queuing order of received = unordered messages, but the TSNs are semantically disconnected from the = SCTP user. recovering the original queuing order over a short = reorder/reassembly window period is desirable in some real-time = applications. The concept of PR-SCTP is that the receiver can handle this. Since the = sender decided that the sequencing is not important, why should be receiver care? >=20 > o an SCTP receiver should be able to choose to receive stream = messages in originally-queued order or as-received-on-the-network order = on a per-stream basis, and be able to recover the original queuing order = to whatever extent desired (potentially limited by real-time = constraints) when receiving in network order. SCTP's unordered message = semantics are designed for "out-of-band" messages, and are not a good = fit for general "real-time" data. transmission order should be = determined by the sender, reception order should be determined by the = receiver. It is a sender side thing. If the sender requires in-sequence delivery, = you want the receiver to ignore this requirement? If there is not sequencing constraint, the sender = should not send it ordered. >=20 > o the stream sequence number being only 16 bits limits the maximum = message rate through high delay networks where message gaps can be = reliably detected at the receiver, when the sender uses = limited-reliability, to 32767 messages/RTT. that sounds large, but could = be easily reached even today in moderately high bandwidth*delay paths if = messages are small. I don't understand this limitation. The is a 32-bit sequence number = space (TSNs) which limits you 2**31 - 1 DATA chunks being in flight (as indicated by the last sentence of = Section 6.1 of RFC 4960), but the 16-bit per stream sequence numbering (SSNs) does not have this = restriction. The receiver will recover the sequencing based on SSN and TSN. At least = this is=20 >=20 > specifying and implementing SCTP over DTLS over ICE over UDP is = probably nearly as much work as specifying and implementing a new = network protocol that actually solves the problems cleanly and = holistically. having done that It would be good to have a clean understanding of the problems. I agree = with that. > before a few times, i'm in favor of the clean holistic approach. :) >=20 > -mike >=20 >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Randell Jesup > Sent: Monday, October 31, 2011 8:18 PM >=20 > A new version of I-D, draft-jesup-rtcweb-data-01.txt has been = successfully > submitted by Randell Jesup and posted to the IETF repository. >=20 > [...] >=20 > http://www.ietf.org/id/draft-jesup-rtcweb-data-01.txt >=20 > [...] > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From HKaplan@acmepacket.com Fri Nov 11 05:38:09 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F117F21F86A0 for ; Fri, 11 Nov 2011 05:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 ukB1KyNqynCw for ; Fri, 11 Nov 2011 05:38:08 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4B19921F863E for ; Fri, 11 Nov 2011 05:38:07 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 11 Nov 2011 08:38:05 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 11 Nov 2011 08:38:05 -0500 From: Hadriel Kaplan To: Roman Shpount Thread-Topic: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC) Thread-Index: AQHMoHck3wWZ3aEzb0OPm0277r540g== Date: Fri, 11 Nov 2011 13:38:05 +0000 Message-ID: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> 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="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Fri, 11 Nov 2011 13:38:09 -0000 On Nov 11, 2011, at 7:02 AM, Roman Shpount wrote: > Well, this is a perfect example when specifying mandatory security for wr= ong reasons is simply being ignored. All the reactions I've seen to this so= far were "this is only a SHOULD, let's disregard this for now". Getting se= curity requirements in the standard which are too high too be practical usu= ally produces products which disregard security completely, reaching the ex= actly opposite effect. I think, in this particular case, the right course o= f action is to use AVT tones in RTP as the rest of the industry is doing no= w. I think using in-band tones in RTP for DTMF instead of 4733 would be a real= ly bad idea. =20 It's not the case that "the rest of the industry" does this. It's true tha= t many media-servers/PSTN-gateways *also* support in-band tones, but I don'= t think I've ever seen one that didn't support either RFC 2833/4733 or some= SIP-based message indication method, or both. Have you seen such? What k= ind of devices were they? The only devices I've seen which support *only* in-band tones have been som= e MTA endpoints and some old gateways for the inbound-direction for media c= oming from PSTN into SIP. Both of those aren't a use-case for WebRTC. Web= RTC browsers need to be able to send DTMF out, but they don't need to recei= ve DTMF; and they only need to send it out to media servers/gateways, not t= o far-end MTA endpoints. Conversely, I have seen gateways which do NOT support in-band tones, and on= ly support 2833/4733 or SIP-based message indications or both. > Finally, (going slightly off topic here) it would probably be a good idea= to make key exchange part of the initial ICE transaction. This way we can = use this key exchange as an additional verification of the remote party, an= d reduce the number of round trips required before the media flow is establ= ished. That's an interesting idea. The extra round trips of DTLS-SRTP, added to t= hose of ICE, have had me worried about clipping when the user answers the c= all. It's been an advantage of SDES not to worry about that. -hadriel From ekr@rtfm.com Fri Nov 11 06:52:06 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EBD21F863E for ; Fri, 11 Nov 2011 06:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.94 X-Spam-Level: X-Spam-Status: No, score=-102.94 tagged_above=-999 required=5 tests=[AWL=0.037, 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 L86KdE+R8ve5 for ; Fri, 11 Nov 2011 06:52:05 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99E7A21F8548 for ; Fri, 11 Nov 2011 06:52:05 -0800 (PST) Received: by vws5 with SMTP id 5so4163265vws.31 for ; Fri, 11 Nov 2011 06:52:05 -0800 (PST) Received: by 10.52.65.14 with SMTP id t14mr21408475vds.47.1321023125100; Fri, 11 Nov 2011 06:52:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Fri, 11 Nov 2011 06:51:23 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <474200CA-F509-438B-A9CD-71742F4AF6B7@lurchi.franken.de> References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> <474200CA-F509-438B-A9CD-71742F4AF6B7@lurchi.franken.de> From: Eric Rescorla Date: Fri, 11 Nov 2011 06:51:23 -0800 Message-ID: To: Michael Tuexen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 14:52:06 -0000 On Fri, Nov 11, 2011 at 5:15 AM, Michael Tuexen wrote: > Hi Michael, >> =A0o DTLS and SCTP handshakes must be performed serially (no matter whic= h order they happen in), which increases the number of round-trips necessar= y to establish communication. > That is correct. SCTP adds one RTT to whatever DTLS is requiring. > So when using SCTP/DTLS/UDP, DTLS needs 3 RTTs (including the initial > RTT required for the Cookie exchange). > When using DTLS/SCTP/UDP DTLS needs 2 RTTs (since there is no need for > the DTLS Cookie). There's no need for the DTLS cookie in either case, actually, since ICE pro= vides the appropriate proof of return routability. Also, DTLS should probably be used with False Start here, so you can reduce to one RTT. -Ekr From roman@telurix.com Fri Nov 11 06:58:48 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C4521F863E for ; Fri, 11 Nov 2011 06:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=0.077, 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 2ohr5rf4yDpJ for ; Fri, 11 Nov 2011 06:58:48 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3732B21F8548 for ; Fri, 11 Nov 2011 06:58:48 -0800 (PST) Received: by ywt34 with SMTP id 34so2411542ywt.31 for ; Fri, 11 Nov 2011 06:58:47 -0800 (PST) Received: by 10.100.55.24 with SMTP id d24mr1366792ana.158.1321023527635; Fri, 11 Nov 2011 06:58:47 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id f32sm34342592ani.20.2011.11.11.06.58.44 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Nov 2011 06:58:44 -0800 (PST) Received: by yenq4 with SMTP id q4so1009619yen.31 for ; Fri, 11 Nov 2011 06:58:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.17.3 with SMTP id k3mr24718060pbd.69.1321023523523; Fri, 11 Nov 2011 06:58:43 -0800 (PST) Received: by 10.68.62.170 with HTTP; Fri, 11 Nov 2011 06:58:43 -0800 (PST) In-Reply-To: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> Date: Fri, 11 Nov 2011 09:58:43 -0500 Message-ID: From: Roman Shpount To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=bcaec51f99dddc0cb804b176c14b Cc: "" Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Fri, 11 Nov 2011 14:58:49 -0000 --bcaec51f99dddc0cb804b176c14b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 11, 2011 at 8:38 AM, Hadriel Kaplan wrote: > > I think using in-band tones in RTP for DTMF instead of 4733 would be a > really bad idea. > > This is not what I've said. What I said was that the rest of the industry is using AVT tones (RFC 2833/4733) compliant DTMF tones without SRTP and normally does not force SRTP if you plan to use RFC 2833 tones. Even though there is a SHOULD requirement for SRTP in conjunction with RFC 4733, the industry ignores it as being excessive and uses RFC 4733 tones in plain RTP, which is what I am suggesting. Not using SRTP does not mean that we need to switch to in band tones. _____________ Roman Shpount --bcaec51f99dddc0cb804b176c14b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 11, 2011 at 8:38 AM, Hadriel Kap= lan <HKaplan= @acmepacket.com> wrote:

I think using in-band tones in RTP for DTMF instead of 4733 would be a real= ly bad idea.


This is not what I've said. What I said was = that the rest of the industry is using AVT tones (RFC 2833/4733) compliant = DTMF tones without SRTP and normally does not force SRTP if you plan to use= RFC 2833 tones. Even though there is a SHOULD requirement for SRTP in conj= unction with RFC 4733, the industry ignores it as being excessive and uses = RFC 4733 tones in plain RTP, which is what I am suggesting. Not using SRTP = does not mean that we need to switch to in band tones.
_____________
Roman Shpount

--bcaec51f99dddc0cb804b176c14b-- From fluffy@cisco.com Fri Nov 11 06:59:03 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D8C21F8A64 for ; Fri, 11 Nov 2011 06:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.974 X-Spam-Level: X-Spam-Status: No, score=-105.974 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 VybpjgOI9HAc for ; Fri, 11 Nov 2011 06:59:02 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 734B121F863E for ; Fri, 11 Nov 2011 06:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=457; q=dns/txt; s=iport; t=1321023542; x=1322233142; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=MWfHR3GxFiCElOcaW8CideKqfQTUR0YQKrOF8BBrPa8=; b=jBfkMB9FqYcsiArXA7x8QzxtUa05qs6B8eOmcVATg6sQLcS4R7qdcQ5V i7z/WV9m24n1H25/6kcPgFfSAeU0WfMjtkr8h1D5jIprGtgPCaf8joQsF 6Ey9Y/wS0o+MC7Kz6Lt1BWJspD9Rq5r1Box/i1EdhwXSzsn/BT4Cth7X5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAB43vU6rRDoJ/2dsb2JhbABDqh2BBYFyAQEBAwESASc/BQsLRlcGNYdgm0IBnkOJG2MEiA6MH5IF X-IronPort-AV: E=Sophos;i="4.69,495,1315180800"; d="scan'208";a="13661743" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 11 Nov 2011 14:59:02 +0000 Received: from tky-vpn-client-230-146.cisco.com (tky-vpn-client-230-146.cisco.com [10.70.230.146]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pABEwvun030161; Fri, 11 Nov 2011 14:59:01 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0134A6B5@inba-mail01.sonusnet.com> Date: Fri, 11 Nov 2011 07:14:40 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4368BF50-2B50-4C9A-9CF4-E7D87705E4BF@cisco.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <4EB9ACF5.80805@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FE6@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A6B5@inba-mail01.sonusnet.com> To: "Ravindran, Parthasarathi" X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of 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: Fri, 11 Nov 2011 14:59:03 -0000 On Nov 10, 2011, at 13:19 , Ravindran, Parthasarathi wrote: > AFAIK in case of telepresence or equivalent endpoint, it requires the = special hardware to encrypt/decrypt the whole bunch of media from it.=20 Really? For a fairly high end 3 screenTP systems, it's like a 6 mbps = stream. I seem to recall a linksys router with VPN could do crypto at = that rate. Been awhile since I looked at the numbers so perhaps I have = this all wrong. =20= From ekr@rtfm.com Fri Nov 11 06:59:55 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEAB21F8A71 for ; Fri, 11 Nov 2011 06:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.941 X-Spam-Level: X-Spam-Status: No, score=-102.941 tagged_above=-999 required=5 tests=[AWL=0.036, 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 OYBpuu2cDehT for ; Fri, 11 Nov 2011 06:59:54 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AFAF121F8A6F for ; Fri, 11 Nov 2011 06:59:54 -0800 (PST) Received: by vws5 with SMTP id 5so4171110vws.31 for ; Fri, 11 Nov 2011 06:59:54 -0800 (PST) Received: by 10.52.65.14 with SMTP id t14mr21457063vds.47.1321023594145; Fri, 11 Nov 2011 06:59:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Fri, 11 Nov 2011 06:59:13 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> From: Eric Rescorla Date: Fri, 11 Nov 2011 06:59:13 -0800 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Fri, 11 Nov 2011 14:59:55 -0000 On Fri, Nov 11, 2011 at 4:02 AM, Roman Shpount wrote: > On Fri, Nov 11, 2011 at 3:49 AM, Olle E. Johansson wrote: o, I wanted expand on the debug requirements: I do hope we will make key > exchange mechanism, different from SDES, mandatory for WebRTC. Passing > actual encryption keys through JavaScript makes media encryption to easy to > circumvent. This means some type of public/private key encryption used for > key exchange. If we do this right, getting to the actual key used for media > session encryption will be very difficult, so most of the tools currently > used for SRTP debugging will stop working. This simply isn't "very difficult". There are existing tools for doing SSL/TLS diagnostics and for recovering the encrypted data (e.g., ssldump, wireshark) and it's not going to be hard to adapt them to this application. > One more benefit of having RTP as fallback for legacy interop is that it > will allow us to specify something that will be more secure for WebRTC. If > SDES support would no longer be needed, we can concentrate on using key > exchange mechanism that is actually secure. I think it's important to distinguish between legacy interop and WebRTC-WebRTC cases. I'm more positive (though still not exactly thrilled) about the claim that we should support RTP for interop modes provided that WebRTC-WebRTC calls are secure. > Finally, (going slightly off topic here) it would probably be a good idea to > make key exchange part of the initial ICE transaction. This way we can use > this key exchange as an additional verification of the remote party, and > reduce the number of round trips required before the media flow is > established. There's no real need for additional verification of the remote party at the ICE level. My suspicion is that the RTTs won't be a significant factor here, but certainly it would be possible to embed the DTLS messages into the ICE exchange if it turned out to be. -Ekr From oscar.ohlsson@ericsson.com Fri Nov 11 07:42:31 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26EB21F8663 for ; Fri, 11 Nov 2011 07:42:31 -0800 (PST) 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 C3vlWnwQWdWG for ; Fri, 11 Nov 2011 07:42:31 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E86DF21F85A4 for ; Fri, 11 Nov 2011 07:42:30 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-ba-4ebd42658ed0 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 60.48.09514.5624DBE4; Fri, 11 Nov 2011 16:42:29 +0100 (CET) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.198]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 11 Nov 2011 16:42:29 +0100 From: Oscar Ohlsson To: Eric Rescorla Date: Fri, 11 Nov 2011 16:42:28 +0100 Thread-Topic: Regarding the assertion mechanism in the new security draft Thread-Index: AcygiISIjTUjgjZwQQGfNsTsERaztw== Message-ID: 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== Cc: "rtcweb@ietf.org" Subject: [rtcweb] Regarding the assertion mechanism in the new security 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: Fri, 11 Nov 2011 15:42:31 -0000 Eric, I read through your latest security draft and I found the the assertion mec= hanism described in the Appendix very interesting. One thing I didn't quite= understand though is why the ROAP session ID needs to be included in the a= ssertion. As far as I can tell you only need to assert the fingerprint. I w= ould appreciate if you could explain your reasoning here. Regards, Oscar Ohlsson= From ibc@aliax.net Fri Nov 11 08:22:27 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F0221F8A7B for ; Fri, 11 Nov 2011 08:22:27 -0800 (PST) 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.039, 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 FI48ZwN-SGpV for ; Fri, 11 Nov 2011 08:22:27 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACD321F8A35 for ; Fri, 11 Nov 2011 08:22:26 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so4130219vcb.31 for ; Fri, 11 Nov 2011 08:22:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.94.18 with SMTP id cy18mr22078301vdb.24.1321028546132; Fri, 11 Nov 2011 08:22:26 -0800 (PST) Received: by 10.220.107.206 with HTTP; Fri, 11 Nov 2011 08:22:26 -0800 (PST) Received: by 10.220.107.206 with HTTP; Fri, 11 Nov 2011 08:22:26 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01CE7093@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C01CE7093@inba-mail01.sonusnet.com> Date: Fri, 11 Nov 2011 17:22:26 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=20cf307cff763afce004b177ed8c Cc: "<,rtcweb@ietf.org>," Subject: Re: [rtcweb] Comment on draft-jennings-rtcweb-signaling-01 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 16:22:27 -0000 --20cf307cff763afce004b177ed8c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It is explained in some mails. That just means that ROAP JSON objects can be sent verbatim in the wire as part of the media protocol. But nobody mandates that. Also remeber that ROAP is just about media information. It is not a call control/signaling protocol (which is also free per website has the recent consensus in this WG stated). Regards. El 11/11/2011 06:21, "Ravindran, Parthasarathi" escribi=C3=B3: > Cullen, > > On the last RTCWeb call ( > http://www.ietf.org/mail-archive/web/rtcweb/current/msg02260.html), you > have mentioned that " I will clarify ROAP is over-the-wire protocol" as p= er > note but it does not reflect in draft-jennings-rtcweb-signaling-01. Could > you please let me know the reason for this change. > > Thanks > Partha > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf307cff763afce004b177ed8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It is explained in some mails. That just means that ROAP JSON objects ca= n be sent verbatim in the wire as part of the media protocol. But nobody ma= ndates that.

Also remeber that ROAP is just about media information. It is not a call= control/signaling protocol (which is also free per website has the recent = consensus in this WG stated).

Regards.

El 11/11/2011 06:21, "Ravindran, Parthasara= thi" <pravindran@sonusne= t.com> escribi=C3=B3:
Cullen,

On the last RTCWeb call (http://www.ietf.org/mail-arch= ive/web/rtcweb/current/msg02260.html), you have mentioned that " I= will clarify ROAP is over-the-wire protocol" as per note but it does = not reflect in draft-jennings-rtcweb-signaling-01. Could you please let me = know the reason for this change.

Thanks
Partha
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--20cf307cff763afce004b177ed8c-- From ibc@aliax.net Fri Nov 11 08:41:12 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F3621F8A35 for ; Fri, 11 Nov 2011 08:41:12 -0800 (PST) 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.039, 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 kI0MlXxnv+VX for ; Fri, 11 Nov 2011 08:41:12 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD5521F87FA for ; Fri, 11 Nov 2011 08:41:12 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so4148202vcb.31 for ; Fri, 11 Nov 2011 08:41:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.100.74 with SMTP id ew10mr22162793vdb.7.1321029671622; Fri, 11 Nov 2011 08:41:11 -0800 (PST) Received: by 10.220.107.206 with HTTP; Fri, 11 Nov 2011 08:41:10 -0800 (PST) Received: by 10.220.107.206 with HTTP; Fri, 11 Nov 2011 08:41:10 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01CE7059@inba-mail01.sonusnet.com> References: <4EB26D22.5090000@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6CD2FA@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01CE7059@inba-mail01.sonusnet.com> Date: Fri, 11 Nov 2011 17:41:10 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=20cf3071c69450981104b1783099 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Nov 2011 16:41:12 -0000 --20cf3071c69450981104b1783099 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El 11/11/2011 06:23, "Ravindran, Parthasarathi" escribi=C3=B3: > > IMO, your Low (freedom) based level API I've never proposed an API. > and standard on-wire > protocol are complementary because both serve two different purpose. > Freedom based API helps to build SIP over websocket kind of application o= r > Proprietary Facebook or Google based WebRTC mechanism. > But standard on-wire (say ROAP over JSON) helps folks not to look into > Protocol intricacies in the browser. It is very much possible to co-exist= . > I really don't where is your concern This is the very same argument again. IMHO it is time for you to assume that this WG has decided by consensus that there will be no standard in-the-wire protocol in WebRTC, nor a suggested proposal by this WG. IMHO the only reason for having a "standard" WebrTC signaling protocol is to make a business for gateway vendors building "standard WebRTC-to-SIP gateways". I cannot imagine other reasons. That is not a legitime argument in a IETF specification. Anyhow I will not discuss again about this subject. There is consensus. Time to move on. Please spend your time in helping with open subjects rather than trying to reopen the discussion about the standard protocol. Regards. --20cf3071c69450981104b1783099 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

El 11/11/2011 06:23, "Ravindran, Parthasarathi" <pravindran@sonusnet.com> escribi=C3= =B3:
>
>=C2=A0 IMO, your Low (freedom) based level API

I've never proposed an API.

> and standard on-wire
> protocol are complementary because both serve two different purpose. > Freedom based API helps to build SIP over websocket kind of applicatio= n or
> Proprietary Facebook or Google based WebRTC mechanism.
> But standard on-wire (say ROAP over JSON) helps folks not to look into=
> Protocol intricacies in the browser. It is very much possible to co-ex= ist.
> I really don't where is your concern

This is the very same argument again. IMHO it is time for you to assume = that this WG has decided by consensus that there will be no standard in-the= -wire protocol in WebRTC, nor a suggested proposal by this WG.

IMHO the only reason for having a "standard" WebrTC signaling = protocol is to make a business for gateway vendors building "standard = WebRTC-to-SIP gateways". I cannot imagine other reasons. That is not a= legitime argument in a IETF specification.

Anyhow I will not discuss again about this subject. There is consensus. = Time to move on. Please spend your time in helping with open subjects rathe= r than trying to reopen the discussion about the standard protocol.

Regards.

--20cf3071c69450981104b1783099-- From ekr@rtfm.com Fri Nov 11 08:45:15 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A7221F88AB for ; Fri, 11 Nov 2011 08:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.943 X-Spam-Level: X-Spam-Status: No, score=-102.943 tagged_above=-999 required=5 tests=[AWL=0.034, 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 pHtjisNgXS0m for ; Fri, 11 Nov 2011 08:45:14 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1E321F87FA for ; Fri, 11 Nov 2011 08:45:14 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so4152066vcb.31 for ; Fri, 11 Nov 2011 08:45:14 -0800 (PST) Received: by 10.220.187.136 with SMTP id cw8mr1483287vcb.266.1321029914084; Fri, 11 Nov 2011 08:45:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Fri, 11 Nov 2011 08:44:32 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Fri, 11 Nov 2011 08:44:32 -0800 Message-ID: To: Oscar Ohlsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding the assertion mechanism in the new security 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: Fri, 11 Nov 2011 16:45:15 -0000 On Fri, Nov 11, 2011 at 7:42 AM, Oscar Ohlsson wrote: > Eric, > > I read through your latest security draft and I found the the assertion m= echanism described in the Appendix very interesting. One thing I didn't qui= te understand though is why the ROAP session ID needs to be included in the= assertion. As far as I can tell you only need to assert the fingerprint. I= would appreciate if you could explain your reasoning here. Thanks! I should probably admit at this point that I haven't done a complete security analysis of the assertion-based system, so exactly what fields need to be signed is, I think a bit of an open question. I tried to make the level of maturity clear in my draft, but I'm not certain I did. With that said, my theory there was that it would be a good idea to cryptographically bind the assertion to this specific session rather than just to the identity in general. This prevents replay style attacks. However, as you suggest, it's not entir= ely clear how one would go about mounting such an attack without simultaneously controlling enough keying material so you could do anything. Do you see a downside to signing this data? Best, -Ekr From ibc@aliax.net Fri Nov 11 08:48:29 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B3F21F87D3 for ; Fri, 11 Nov 2011 08:48:29 -0800 (PST) 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.039, 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 d2veJ8Dc-CFh for ; Fri, 11 Nov 2011 08:48:28 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD3F121F861E for ; Fri, 11 Nov 2011 08:48:28 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so4154951vcb.31 for ; Fri, 11 Nov 2011 08:48:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.65.36 with SMTP id u4mr22201278vds.58.1321030108251; Fri, 11 Nov 2011 08:48:28 -0800 (PST) Received: by 10.220.107.206 with HTTP; Fri, 11 Nov 2011 08:48:28 -0800 (PST) Received: by 10.220.107.206 with HTTP; Fri, 11 Nov 2011 08:48:28 -0800 (PST) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058524DBFEE653@ESESSCMS0356.eemea.ericsson.se> References: <4EB26D22.5090000@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6CD2FA@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01CE7059@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A058524DBFEE653@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 11 Nov 2011 17:48:28 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: multipart/alternative; boundary=20cf307f312457068404b1784a04 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Nov 2011 16:48:29 -0000 --20cf307f312457068404b1784a04 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I expected that this means consensus: http://www.ietf.org/mail-archive/web/rtcweb/current/msg02509.html Regards. El 11/11/2011 08:13, "Christer Holmberg" escribi=C3=B3: > > Hi, > > >So I celebrate you agree now with the consensus :) > > I would appretiate if we don't use the word "consensus", unless it has > actually been declared by the WG chairs. > > Regards, > > Christer > > --20cf307f312457068404b1784a04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi, I expected that this means consensus:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg02509.html

Regards.

El 11/11/2011 08:13, "Christer Holmberg&quo= t; <christer.holmberg@= ericsson.com> escribi=C3=B3:

Hi,

>So I celebrate you agree now with the consensus :)

I would appretiate if we don't use the word "consensus", unle= ss it has actually been declared by the WG chairs.

Regards,

Christer

--20cf307f312457068404b1784a04-- From HKaplan@acmepacket.com Fri Nov 11 08:52:23 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221C721F8A57 for ; Fri, 11 Nov 2011 08:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X55b9DMh9IM4 for ; Fri, 11 Nov 2011 08:52:22 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6D48C21F86AA for ; Fri, 11 Nov 2011 08:52:22 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 11 Nov 2011 11:52:21 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 11 Nov 2011 11:52:20 -0500 From: Hadriel Kaplan To: Roman Shpount Thread-Topic: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC) Thread-Index: AQHMoIJroPY+iIKWa0aledDcjGopdJWn44lg Date: Fri, 11 Nov 2011 16:52:20 +0000 Message-ID: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_BD09C7C17286476DB967D6F409A10348acmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Fri, 11 Nov 2011 16:52:23 -0000 --_000_BD09C7C17286476DB967D6F409A10348acmepacketcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think it's a SHOULD implement, but that's not the same as MUST *use*. ( = though it may have meant SHOULD use) Regardless, I don't see what that has to do with this SRTP topic. Clearly = DTMF is used in cases where privacy is important since it often represents = PINs. -Hadriel Sent from my iPhone On Nov 11, 2011, at 9:58 AM, "Roman Shpount" > wrote: On Fri, Nov 11, 2011 at 8:38 AM, Hadriel Kaplan > wrote: I think using in-band tones in RTP for DTMF instead of 4733 would be a real= ly bad idea. This is not what I've said. What I said was that the rest of the industry i= s using AVT tones (RFC 2833/4733) compliant DTMF tones without SRTP and nor= mally does not force SRTP if you plan to use RFC 2833 tones. Even though th= ere is a SHOULD requirement for SRTP in conjunction with RFC 4733, the indu= stry ignores it as being excessive and uses RFC 4733 tones in plain RTP, wh= ich is what I am suggesting. Not using SRTP does not mean that we need to s= witch to in band tones. _____________ Roman Shpount --_000_BD09C7C17286476DB967D6F409A10348acmepacketcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I think it's a SHOULD implement, but that's not the same as MUST *use*= .  ( though it may have meant SHOULD use)

Regardless, I don't see what that has to do with this SRTP topic. &nbs= p;Clearly DTMF is used in cases where privacy is important since it often r= epresents PINs.  

-Hadriel 

Sent from my iPhone

On Nov 11, 2011, at 9:58 AM, "Roman Shpount" <roman@telurix.com> wrote:


On Fri, Nov 11, 2011 at 8:38 AM, Hadriel Kaplan = <HKaplan@acmepacket.com>= ; wrote:

I think using in-band tones in RTP for DTMF instead of 4733 would be a real= ly bad idea.


This is not what I've said. What I said was that the rest of the industry i= s using AVT tones (RFC 2833/4733) compliant DTMF tones without SRTP and nor= mally does not force SRTP if you plan to use RFC 2833 tones. Even though th= ere is a SHOULD requirement for SRTP in conjunction with RFC 4733, the industry ignores it as being excess= ive and uses RFC 4733 tones in plain RTP, which is what I am suggesting. No= t using SRTP does not mean that we need to switch to in band tones.
_____________
Roman Shpount

--_000_BD09C7C17286476DB967D6F409A10348acmepacketcom_-- From Michael.Tuexen@lurchi.franken.de Fri Nov 11 09:02:00 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B88D21F84AA for ; Fri, 11 Nov 2011 09:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsrIAozEUC9f for ; Fri, 11 Nov 2011 09:02:00 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id C681221F84A7 for ; Fri, 11 Nov 2011 09:01:59 -0800 (PST) Received: from [192.168.1.200] (p508FD391.dip.t-dialin.net [80.143.211.145]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 840991C0C0BCE; Fri, 11 Nov 2011 18:01:58 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Fri, 11 Nov 2011 18:01:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <20483DC8-9370-47C1-9C99-03624EB9C281@lurchi.franken.de> References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> <474200CA-F509-438B-A9CD-71742F4AF6B7@lurchi.franken.de> To: Eric Rescorla X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 17:02:00 -0000 On Nov 11, 2011, at 3:51 PM, Eric Rescorla wrote: > On Fri, Nov 11, 2011 at 5:15 AM, Michael Tuexen > wrote: >> Hi Michael, >>> o DTLS and SCTP handshakes must be performed serially (no matter = which order they happen in), which increases the number of round-trips = necessary to establish communication. >> That is correct. SCTP adds one RTT to whatever DTLS is requiring. >> So when using SCTP/DTLS/UDP, DTLS needs 3 RTTs (including the initial >> RTT required for the Cookie exchange). >> When using DTLS/SCTP/UDP DTLS needs 2 RTTs (since there is no need = for >> the DTLS Cookie). >=20 > There's no need for the DTLS cookie in either case, actually, since = ICE provides > the appropriate proof of return routability. I don't know much about ICE.... So assume that the endpoint willing to accept DTLS connections. Can't I just send an ClientHello via plain UDP to the endpoint (assuming = that I can reach it)? Best regards Michael >=20 > Also, DTLS should probably be used with False Start here, so you can = reduce > to one RTT. >=20 > -Ekr >=20 From ekr@rtfm.com Fri Nov 11 09:15:04 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5E121F8AD9 for ; Fri, 11 Nov 2011 09:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.794 X-Spam-Level: X-Spam-Status: No, score=-102.794 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CRYuD+jgnyZ for ; Fri, 11 Nov 2011 09:15:03 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C707821F8ABB for ; Fri, 11 Nov 2011 09:15:03 -0800 (PST) Received: by vws5 with SMTP id 5so4307270vws.31 for ; Fri, 11 Nov 2011 09:15:02 -0800 (PST) Received: by 10.52.29.9 with SMTP id f9mr22324831vdh.30.1321031702097; Fri, 11 Nov 2011 09:15:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Fri, 11 Nov 2011 09:14:21 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <20483DC8-9370-47C1-9C99-03624EB9C281@lurchi.franken.de> References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> <474200CA-F509-438B-A9CD-71742F4AF6B7@lurchi.franken.de> <20483DC8-9370-47C1-9C99-03624EB9C281@lurchi.franken.de> From: Eric Rescorla Date: Fri, 11 Nov 2011 09:14:21 -0800 Message-ID: To: =?ISO-8859-1?Q?Michael_T=FCxen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 17:15:04 -0000 On Fri, Nov 11, 2011 at 9:01 AM, Michael T=FCxen wrote: > On Nov 11, 2011, at 3:51 PM, Eric Rescorla wrote: > >> On Fri, Nov 11, 2011 at 5:15 AM, Michael Tuexen >> wrote: >>> Hi Michael, >>>> =A0o DTLS and SCTP handshakes must be performed serially (no matter wh= ich order they happen in), which increases the number of round-trips necess= ary to establish communication. >>> That is correct. SCTP adds one RTT to whatever DTLS is requiring. >>> So when using SCTP/DTLS/UDP, DTLS needs 3 RTTs (including the initial >>> RTT required for the Cookie exchange). >>> When using DTLS/SCTP/UDP DTLS needs 2 RTTs (since there is no need for >>> the DTLS Cookie). >> >> There's no need for the DTLS cookie in either case, actually, since ICE = provides >> the appropriate proof of return routability. > I don't know much about ICE.... > So assume that the endpoint willing to accept DTLS connections. > Can't I just send an ClientHello via plain UDP to the endpoint (assuming = that I can reach it)? When ICE is involved, there's no real concept of "an endpoint willing to accept DTLS connections". At a high level, the way that ICE works is that the communicating parties establish a session out of band and then use the ICE handshake to bind one or valid 5-tuple flows to the the session. Packets that arrive at one endpoint that aren't part of one of these flows can more or less be discarded. (At least at this stage). Since the purpose of the DTLS cookie is to prevent blind resource consumption DoS attacks, and ICE inherently that you're not going to be doing handshakes with random remote IP addresses, I don't think there's much of an issue here. -Ekr From Michael.Tuexen@lurchi.franken.de Fri Nov 11 09:31:29 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC7421F8AF3 for ; Fri, 11 Nov 2011 09:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EseUJAQz9Bf2 for ; Fri, 11 Nov 2011 09:31:29 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 7A27121F8AD3 for ; Fri, 11 Nov 2011 09:31:28 -0800 (PST) Received: from [192.168.1.200] (p508FD391.dip.t-dialin.net [80.143.211.145]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 71D611C0C0BCE; Fri, 11 Nov 2011 18:31:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Fri, 11 Nov 2011 18:31:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <360EF6F3-E5E6-4690-BAA2-211F3CAFDF1F@lurchi.franken.de> References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> <474200CA-F509-438B-A9CD-71742F4AF6B7@lurchi.franken.de> <20483DC8-9370-47C1-9C99-03624EB9C281@lurchi.franken.de> To: Eric Rescorla X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 17:31:29 -0000 On Nov 11, 2011, at 6:14 PM, Eric Rescorla wrote: > On Fri, Nov 11, 2011 at 9:01 AM, Michael T=FCxen > wrote: >> On Nov 11, 2011, at 3:51 PM, Eric Rescorla wrote: >>=20 >>> On Fri, Nov 11, 2011 at 5:15 AM, Michael Tuexen >>> wrote: >>>> Hi Michael, >>>>> o DTLS and SCTP handshakes must be performed serially (no matter = which order they happen in), which increases the number of round-trips = necessary to establish communication. >>>> That is correct. SCTP adds one RTT to whatever DTLS is requiring. >>>> So when using SCTP/DTLS/UDP, DTLS needs 3 RTTs (including the = initial >>>> RTT required for the Cookie exchange). >>>> When using DTLS/SCTP/UDP DTLS needs 2 RTTs (since there is no need = for >>>> the DTLS Cookie). >>>=20 >>> There's no need for the DTLS cookie in either case, actually, since = ICE provides >>> the appropriate proof of return routability. >> I don't know much about ICE.... >> So assume that the endpoint willing to accept DTLS connections. >> Can't I just send an ClientHello via plain UDP to the endpoint = (assuming that I can reach it)? >=20 > When ICE is involved, there's no real concept of "an endpoint willing = to > accept DTLS connections". At a high level, the way that ICE works is > that the communicating parties establish a session out of band and > then use the ICE handshake to bind one or valid 5-tuple flows to the > the session. Packets that arrive at one endpoint that aren't part of = one > of these flows can more or less be discarded. (At least at this = stage). OK, you you only pass those packets to DTLS, which belong to the 5 tuple which you have already communicated with, and discard the others, it is = OK. So SCTP needs one RTT, DTLS two. Thanks for the clarification. Best regards Michael >=20 > Since the purpose of the DTLS cookie is to prevent blind resource > consumption DoS attacks, and ICE inherently that you're not going > to be doing handshakes with random remote IP addresses, I don't > think there's much of an issue here. >=20 > -Ekr >=20 From ekr@rtfm.com Fri Nov 11 09:34:50 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0727C21F85B1 for ; Fri, 11 Nov 2011 09:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.79 X-Spam-Level: X-Spam-Status: No, score=-102.79 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJR8kY9zqFLe for ; Fri, 11 Nov 2011 09:34:49 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6941821F85A8 for ; Fri, 11 Nov 2011 09:34:49 -0800 (PST) Received: by ggnr4 with SMTP id r4so3402391ggn.31 for ; Fri, 11 Nov 2011 09:34:49 -0800 (PST) Received: by 10.146.110.21 with SMTP id i21mr2469032yac.26.1321032874319; Fri, 11 Nov 2011 09:34:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.146.88.36 with HTTP; Fri, 11 Nov 2011 09:33:53 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <360EF6F3-E5E6-4690-BAA2-211F3CAFDF1F@lurchi.franken.de> References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> <474200CA-F509-438B-A9CD-71742F4AF6B7@lurchi.franken.de> <20483DC8-9370-47C1-9C99-03624EB9C281@lurchi.franken.de> <360EF6F3-E5E6-4690-BAA2-211F3CAFDF1F@lurchi.franken.de> From: Eric Rescorla Date: Fri, 11 Nov 2011 09:33:53 -0800 Message-ID: To: =?ISO-8859-1?Q?Michael_T=FCxen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 17:34:50 -0000 On Fri, Nov 11, 2011 at 9:31 AM, Michael T=FCxen wrote: > On Nov 11, 2011, at 6:14 PM, Eric Rescorla wrote: > >> On Fri, Nov 11, 2011 at 9:01 AM, Michael T=FCxen >> wrote: >>> On Nov 11, 2011, at 3:51 PM, Eric Rescorla wrote: >>> >>>> On Fri, Nov 11, 2011 at 5:15 AM, Michael Tuexen >>>> wrote: >>>>> Hi Michael, >>>>>> =A0o DTLS and SCTP handshakes must be performed serially (no matter = which order they happen in), which increases the number of round-trips nece= ssary to establish communication. >>>>> That is correct. SCTP adds one RTT to whatever DTLS is requiring. >>>>> So when using SCTP/DTLS/UDP, DTLS needs 3 RTTs (including the initial >>>>> RTT required for the Cookie exchange). >>>>> When using DTLS/SCTP/UDP DTLS needs 2 RTTs (since there is no need fo= r >>>>> the DTLS Cookie). >>>> >>>> There's no need for the DTLS cookie in either case, actually, since IC= E provides >>>> the appropriate proof of return routability. >>> I don't know much about ICE.... >>> So assume that the endpoint willing to accept DTLS connections. >>> Can't I just send an ClientHello via plain UDP to the endpoint (assumin= g that I can reach it)? >> >> When ICE is involved, there's no real concept of "an endpoint willing to >> accept DTLS connections". At a high level, the way that ICE works is >> that the communicating parties establish a session out of band and >> then use the ICE handshake to bind one or valid 5-tuple flows to the >> the session. Packets that arrive at one endpoint that aren't part of one >> of these flows can more or less be discarded. (At least at this stage). > OK, you you only pass those packets to DTLS, which belong to the 5 tuple > which you have already communicated with, and discard the others, it is O= K. > So SCTP needs one RTT, DTLS two. Possibly < two for DTLS, because of resumption and False Start. So, somewhe= re between 1 and 2. Best, -Ekr From Michael.Tuexen@lurchi.franken.de Fri Nov 11 10:17:53 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874C721F85AA for ; Fri, 11 Nov 2011 10:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5i1nAqN5e3G for ; Fri, 11 Nov 2011 10:17:53 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id C357321F8538 for ; Fri, 11 Nov 2011 10:17:52 -0800 (PST) Received: from [192.168.1.200] (p508FD391.dip.t-dialin.net [80.143.211.145]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B47F21C0C0BCE; Fri, 11 Nov 2011 19:17:51 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: Date: Fri, 11 Nov 2011 19:17:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2B536B77-515B-4954-B164-A098638AC69C@lurchi.franken.de> References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> <474200CA-F509-438B-A9CD-71742F4AF6B7@lurchi.franken.de> <20483DC8-9370-47C1-9C99-03624EB9C281@lurchi.franken.de> <360EF6F3-E5E6-4690-BAA2-211F3CAFDF1F@lurchi.franken.de> To: Eric Rescorla X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 18:17:53 -0000 On Nov 11, 2011, at 6:33 PM, Eric Rescorla wrote: > On Fri, Nov 11, 2011 at 9:31 AM, Michael T=FCxen > wrote: >> On Nov 11, 2011, at 6:14 PM, Eric Rescorla wrote: >>=20 >>> On Fri, Nov 11, 2011 at 9:01 AM, Michael T=FCxen >>> wrote: >>>> On Nov 11, 2011, at 3:51 PM, Eric Rescorla wrote: >>>>=20 >>>>> On Fri, Nov 11, 2011 at 5:15 AM, Michael Tuexen >>>>> wrote: >>>>>> Hi Michael, >>>>>>> o DTLS and SCTP handshakes must be performed serially (no = matter which order they happen in), which increases the number of = round-trips necessary to establish communication. >>>>>> That is correct. SCTP adds one RTT to whatever DTLS is requiring. >>>>>> So when using SCTP/DTLS/UDP, DTLS needs 3 RTTs (including the = initial >>>>>> RTT required for the Cookie exchange). >>>>>> When using DTLS/SCTP/UDP DTLS needs 2 RTTs (since there is no = need for >>>>>> the DTLS Cookie). >>>>>=20 >>>>> There's no need for the DTLS cookie in either case, actually, = since ICE provides >>>>> the appropriate proof of return routability. >>>> I don't know much about ICE.... >>>> So assume that the endpoint willing to accept DTLS connections. >>>> Can't I just send an ClientHello via plain UDP to the endpoint = (assuming that I can reach it)? >>>=20 >>> When ICE is involved, there's no real concept of "an endpoint = willing to >>> accept DTLS connections". At a high level, the way that ICE works is >>> that the communicating parties establish a session out of band and >>> then use the ICE handshake to bind one or valid 5-tuple flows to the >>> the session. Packets that arrive at one endpoint that aren't part of = one >>> of these flows can more or less be discarded. (At least at this = stage). >> OK, you you only pass those packets to DTLS, which belong to the 5 = tuple >> which you have already communicated with, and discard the others, it = is OK. >> So SCTP needs one RTT, DTLS two. >=20 > Possibly < two for DTLS, because of resumption and False Start. So, = somewhere > between 1 and 2. Correct. Best regards Michael >=20 > Best, > -Ekr >=20 From dan-ietf@danyork.org Fri Nov 11 10:24:15 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B99D21F8AD2 for ; Fri, 11 Nov 2011 10:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=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 25J+nLKpiXJX for ; Fri, 11 Nov 2011 10:24:14 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 83E6821F8ABB for ; Fri, 11 Nov 2011 10:24:14 -0800 (PST) Received: by vws5 with SMTP id 5so4370681vws.31 for ; Fri, 11 Nov 2011 10:24:14 -0800 (PST) Received: by 10.52.178.163 with SMTP id cz3mr22682281vdc.43.1321035853584; Fri, 11 Nov 2011 10:24:13 -0800 (PST) Received: from pc-00141.lodestar2.local (cpe-66-65-247-87.mass.res.rr.com. [66.65.247.87]) by mx.google.com with ESMTPS id ey9sm18083298vdc.19.2011.11.11.10.24.12 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Nov 2011 10:24:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_306B0571-A55E-4768-85F6-BAAE1DA35FD8" From: Dan York In-Reply-To: Date: Fri, 11 Nov 2011 13:24:11 -0500 Message-Id: References: <4EB26D22.5090000@ericsson.com> <4EBA741A.1010307@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C0134A992@inba-mail01.sonusnet.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1251.1) Cc: "" Subject: Re: [rtcweb] RTCWEB is not SIP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Nov 2011 18:24:15 -0000 --Apple-Mail=_306B0571-A55E-4768-85F6-BAAE1DA35FD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 +1 On Nov 11, 2011, at 6:44 AM, Bernard Aboba wrote: > +1 >=20 > I=F1aki Baz Castillo said: >>=20 >> WebRTC is not SIP... >>=20 >> IMHO we should stop talking about SIP in this WG.... >=20 >> First priority is to define WebRTC regardless of federation... > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Dan York dyork@lodestar2.com http://www.danyork.com/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork -------------------------------------------------------- All comments and opinions are entirely my own and have no connection = whatsoever to any employer, past or present. Indeed, by tomorrow even I = might be disavowing these comments. -------------------------------------------------------- --Apple-Mail=_306B0571-A55E-4768-85F6-BAAE1DA35FD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
+1

I=F1aki Baz Castillo said:

WebRTC is not = SIP...

IMHO we should = stop talking about SIP in this WG....

First priority is to define WebRTC regardless of = federation...
____________________________________________= ___
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb

-- 
Dan York  dyork@lodestar2.com
http://www.danyork.com/  &n= bsp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork
All comments and opinions are = entirely my own and have no connection whatsoever to any employer, past = or present. Indeed, by tomorrow even I might be disavowing these = comments.
I think using in-band tones in RTP for DTMF instead of 4733 would be a really bad idea. +10. Let's not even discuss that option further. >> Finally, (going slightly off topic here) it would probably be a good idea to make key exchange part of the initial ICE transaction. This way we can use this key exchange as an additional verification of the remote party, and reduce the number of round trips required before the media flow is established. > That's an interesting idea. The extra round trips of DTLS-SRTP, added to those of ICE, have had me worried about clipping when the user answers the call. It's been an advantage of SDES not to worry about that. Anything we can do to minimize clipping and reduce startup RTTs is a *very* good thing. We should start seriously analyzing this as we're getting down to more specifics. And recent privacy breaches have shown that otherwise-good pre-warming of connections and pre-negotiation of codecs may be problematic from a security point of view - exchanging ICE candidates with an incoming OFFER from your abusive ex-boyfriend might tell them where you are (local IP), though it would be possible for people not wanting to disclose their address to *require* a TURN proxy be in use and not offer local IP, limiting the leaked information. This does require proactive selection of safety by the user, a risky proposition. As a possible compromise, you could force TURN for the pre-start of the call and if accepted, renegotiate with real local addresses. Might cause a glitch though if you're not careful. -- Randell Jesup randell-ietf@jesup.org From kpfleming@digium.com Fri Nov 11 10:55:45 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B5121F8A97 for ; Fri, 11 Nov 2011 10:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.084 X-Spam-Level: X-Spam-Status: No, score=-106.084 tagged_above=-999 required=5 tests=[AWL=0.515, 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 7lpzGVCnuvGe for ; Fri, 11 Nov 2011 10:55:45 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id EA86221F8A95 for ; Fri, 11 Nov 2011 10:55:44 -0800 (PST) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1ROwGN-0007s3-Qf for rtcweb@ietf.org; Fri, 11 Nov 2011 12:55:43 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id CDD1BD8005 for ; Fri, 11 Nov 2011 12:55:43 -0600 (CST) 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 6oIH46W7A5cT for ; Fri, 11 Nov 2011 12:55:43 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 57B51D8002 for ; Fri, 11 Nov 2011 12:55:43 -0600 (CST) Message-ID: <4EBD6FAF.5020109@digium.com> Date: Fri, 11 Nov 2011 12:55:43 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> <4EBD6D63.4090209@jesup.org> In-Reply-To: <4EBD6D63.4090209@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Fri, 11 Nov 2011 18:55:45 -0000 On 11/11/2011 12:45 PM, Randell Jesup wrote: > As a possible compromise, you could force TURN for the pre-start of the > call and if accepted, renegotiate with real local addresses. Might cause > a glitch though if you're not careful. Given that the new 'standard' for voice communications quality appears to be whatever a CDMA/GSM/etc. cellular network can provide, this sort of glitch would probably go unnoticed by a large percentage of users :-) -- 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 christer.holmberg@ericsson.com Fri Nov 11 11:18:00 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B942321F84AF for ; Fri, 11 Nov 2011 11:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.093, 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 Ve6qjBkrooPq for ; Fri, 11 Nov 2011 11:18:00 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCDB21F84A9 for ; Fri, 11 Nov 2011 11:17:59 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-5a-4ebd74e6d365 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9C.9E.13753.6E47DBE4; Fri, 11 Nov 2011 20:17:59 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.197]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 11 Nov 2011 20:17:58 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Fri, 11 Nov 2011 20:16:25 +0100 Thread-Topic: [rtcweb] Regarding Federation Arguments Thread-Index: Acygkb1OlegZfPy4Qie1iZu+ALZdaAAFKqn2 Message-ID: <7F2072F1E0DE894DA4B517B93C6A058524DBFEE65F@ESESSCMS0356.eemea.ericsson.se> References: <4EB26D22.5090000@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6CD2FA@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01CE7059@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A058524DBFEE653@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Nov 2011 19:18:00 -0000 Hi, > Hi, I expected that this means consensus: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg02509.html That e-mail is about browser-to-server protocol. I thought you were talking= about a server-to-server protocol. My appologies if I missunderstood. Regards, Christer Regards. El 11/11/2011 08:13, "Christer Holmberg" > escribi=F3: Hi, >So I celebrate you agree now with the consensus :) I would appretiate if we don't use the word "consensus", unless it has actu= ally been declared by the WG chairs. Regards, Christer From mthornbu@adobe.com Fri Nov 11 11:53:37 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E08F21F8560 for ; Fri, 11 Nov 2011 11:53:37 -0800 (PST) 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 THQ-t1JdVqA8 for ; Fri, 11 Nov 2011 11:53:36 -0800 (PST) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id A5D1D21F84AF for ; Fri, 11 Nov 2011 11:53:35 -0800 (PST) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKTr19NokevdQE76caYhMdvBVRxfaE7Smk@postini.com; Fri, 11 Nov 2011 11:53:35 PST Received: from inner-relay-1.corp.adobe.com (ms-exchange.macromedia.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pABJrNQB029723; Fri, 11 Nov 2011 11:53:25 -0800 (PST) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id pABJrN5R011352; Fri, 11 Nov 2011 11:53:23 -0800 (PST) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Fri, 11 Nov 2011 11:53:22 -0800 From: Michael Thornburgh To: Michael Tuexen , "rtcweb@ietf.org" Date: Fri, 11 Nov 2011 11:52:32 -0800 Thread-Topic: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt Thread-Index: AcygdFGNq3bifgSfQ7u1JN6yBGevMAAMaBuw Message-ID: <02485FF93524F8408ECA9608E47D9F2007CAE80473@nambx05.corp.adobe.com> References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> <474200CA-F509-438B-A9CD-71742F4AF6B7@lurchi.franken.de> In-Reply-To: <474200CA-F509-438B-A9CD-71742F4AF6B7@lurchi.franken.de> 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 Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 19:53:37 -0000 hi Michael. my comments also inline. > -----Original Message----- > From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20 > Sent: Friday, November 11, 2011 5:16 AM > Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-dat= a-01.txt >=20 > Hi Michael, >=20 > see my comments in-line. >=20 > Best regards > Michael > On Nov 3, 2011, at 2:12 AM, Michael Thornburgh wrote: >=20 [...] > > o (most important for real-time communication): each user data fragmen= t/chunk is assigned an SCTP Transmission Sequence Number (TSN) at the time = of first transmission. that means even if your SCTP implementation supporte= d stream prioritization somehow, the priority decision is only made at firs= t transmission time. since there's just one TSN space and the Gap Ack struc= ture only talks about TSNs, it's undesirable for gaps to persist (else the = Gap Ack structure will continue to grow as more losses naturally happen). t= herefore it's desirable to repair gaps as quickly as possible. this may ina= ppropriately increase the priority of a low priority fragment/chunk/stream = during periods of congestion, which is exactly when priority matters (this = is a "priority inversion"). >=20 > What might help is that messages have priorities and the sender is allowe= d to abandon messages > with low priorities in case of congestion (timer based retransmissions). = Something which is supported by PR-SCTP. sure. but the problem here is the low priority stream is likely to be one t= hat needs full reliability (like a bulk data transfer that you want to use = "background" bandwidth but still eventually get delivered). in that case yo= u don't want the sender to abandon the low priority message, and that's wha= t leads to the priority inversion. > > o (second most important for real-time communication): there's only on= e receive window advertisement for all of the streams, rather than one rece= ive window per stream. this means there's no per-stream flow control. so if= you're receiving (for example) a bulk file transfer and real-time player p= osition updates and text chat messages, and you need to suspend the file tr= ansfer stream for a time, that means you must also suspend the player posit= ion updates and text chat messages. unless you spin up an entirely separate= SCTP for each flow control domain, which is lame and defeats the purpose o= f stream multiplexing. >=20 > You can use priorities tied to streams at the sender side. priority doesn't solve the problem at all. the issue is that if the receive= r needs to stop accepting data on one stream, the only indication of revers= e pressure to the sender is the association-wide receive window advertiseme= nt. the only in-protocol flow control is association-wide. the only solutio= n is to not have the receiver suspend reading any stream and to use applica= tion-layer flow control to signal the sender to stop sending data on one st= ream or another. > > o SCTP specifies the maximum number of streams in each direction at as= sociation startup. web applications may not know the number of streams need= ed up front; in fact, the number of streams needed in any real-world non-SS= 7 data application is very likely to evolve over the lifetime of that appli= cation, naturally increasing and decreasing. >=20 > You don't need a lot of resources for the receive side of a stream. So yo= u could either negotiate a number > large enough or use the extension > http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-strrst-12 > which is currently in IETF LC. It enables you to add streams on the fly. ok. i'm glad someone thought of that. > > o the semantics of unordered messages are confusing and not a good map= to WebRTC. they are semantically equivalent to an entirely separate stream= loosely associated to the ordered stream of the same number. there's no wa= y to tell (without application layer sequencing) if an unordered message ha= s been lost/abandoned by the sender. at the protocol level, TSNs can be use= d to recover the queuing order of received unordered messages, but the TSNs= are semantically disconnected from the SCTP user. recovering the original = queuing order over a short reorder/reassembly window period is desirable in= some real-time applications. >=20 > The concept of PR-SCTP is that the receiver can handle this. Since the se= nder decided that the sequencing > is not important, why should be receiver care? my main point was that, specifically in the case of PR-SCTP, since unordere= d messages don't have a stream sequence number there's no way to tell at th= e receiver if one (or more) has been abandoned. gaps in the ordered message= space can be detected. > > o an SCTP receiver should be able to choose to receive stream messages= in originally-queued order or as-received-on-the-network order on a per-st= ream basis, and be able to recover the original queuing order to whatever e= xtent desired (potentially limited by real-time constraints) when receiving= in network order. SCTP's unordered message semantics are designed for "out= -of-band" messages, and are not a good fit for general "real-time" data. tr= ansmission order should be determined by the sender, reception order should= be determined by the receiver. >=20 > It is a sender side thing. If the sender requires in-sequence delivery, y= ou want the receiver to ignore > this requirement? If there is not sequencing constraint, the sender shoul= d not send it ordered. it's natural to use unordered messages for real-time data, since they can b= e delivered to the user as soon as they arrive even if there are gaps. howe= ver, in exactly these real-time scenarios, it's still often useful to know = the original queuing order of the messages, and to allow the receiver to pa= rtially recover the original queuing order in, for example, a jitter/reorde= r buffer. this can be accomplished with application-layer sequence numbers,= but it seems silly to have to duplicate existing protocol-level functional= ity (see my point about flow control above). > > o the stream sequence number being only 16 bits limits the maximum mes= sage rate through high delay networks where message gaps can be reliably de= tected at the receiver, when the sender uses limited-reliability, to 32767 = messages/RTT. that sounds large, but could be easily reached even today in = moderately high bandwidth*delay paths if messages are small. >=20 > I don't understand this limitation. The is a 32-bit sequence number space= (TSNs) which limits you 2**31 - 1 > DATA chunks being in flight (as indicated by the last sentence of Section= 6.1 of RFC 4960), > but the 16-bit per stream sequence numbering (SSNs) does not have this re= striction. > The receiver will recover the sequencing based on SSN and TSN. At least t= his is=20 this is only a problem with PR-SCTP. if stream sequence numbers can be aban= doned, then there's ambiguity in the stream sequence number space when you = receive a FORWARD TSN chunk if there were more than 32768 stream sequence n= umbers in flight. [...] -mike From Michael.Tuexen@lurchi.franken.de Fri Nov 11 13:14:53 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF3421F85A4 for ; Fri, 11 Nov 2011 13:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.304, 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 gyVy4y8OIYGA for ; Fri, 11 Nov 2011 13:14:52 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 18AEA21F8573 for ; Fri, 11 Nov 2011 13:14:51 -0800 (PST) Received: from [192.168.1.124] (p508FD391.dip.t-dialin.net [80.143.211.145]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 42E6C1C0C0BCF; Fri, 11 Nov 2011 22:14:50 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <02485FF93524F8408ECA9608E47D9F2007CAE80473@nambx05.corp.adobe.com> Date: Fri, 11 Nov 2011 22:14:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> <474200CA-F509-438B-A9CD-71742F4AF6B7@lurchi.franken.de> <02485FF93524F8408ECA9608E47D9F2007CAE80473@nambx05.corp.adobe.com> To: Michael Thornburgh X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 21:14:53 -0000 On Nov 11, 2011, at 8:52 PM, Michael Thornburgh wrote: > hi Michael. my comments also inline. >=20 >> -----Original Message----- >> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20 >> Sent: Friday, November 11, 2011 5:16 AM >> Subject: Re: [rtcweb] New Version Notification for = draft-jesup-rtcweb-data-01.txt >>=20 >> Hi Michael, >>=20 >> see my comments in-line. >>=20 >> Best regards >> Michael >> On Nov 3, 2011, at 2:12 AM, Michael Thornburgh wrote: >>=20 > [...] >>> o (most important for real-time communication): each user data = fragment/chunk is assigned an SCTP Transmission Sequence Number (TSN) at = the time of first transmission. that means even if your SCTP = implementation supported stream prioritization somehow, the priority = decision is only made at first transmission time. since there's just one = TSN space and the Gap Ack structure only talks about TSNs, it's = undesirable for gaps to persist (else the Gap Ack structure will = continue to grow as more losses naturally happen). therefore it's = desirable to repair gaps as quickly as possible. this may = inappropriately increase the priority of a low priority = fragment/chunk/stream during periods of congestion, which is exactly = when priority matters (this is a "priority inversion"). >>=20 >> What might help is that messages have priorities and the sender is = allowed to abandon messages >> with low priorities in case of congestion (timer based = retransmissions). Something which is supported by PR-SCTP. >=20 > sure. but the problem here is the low priority stream is likely to be = one that needs full reliability (like a bulk data transfer that you want = to use "background" bandwidth but still eventually get delivered). in = that case you don't want the sender to abandon the low priority message, = and that's what leads to the priority inversion. So you want to send the bulk transfer with low priority but full = reliability? And have some other messages, for example with high priority, but only = limited reliability? You could do this. The only point: You need something to drop to improve = things. Or do you want everything with full reliability? >=20 >>> o (second most important for real-time communication): there's only = one receive window advertisement for all of the streams, rather than one = receive window per stream. this means there's no per-stream flow = control. so if you're receiving (for example) a bulk file transfer and = real-time player position updates and text chat messages, and you need = to suspend the file transfer stream for a time, that means you must also = suspend the player position updates and text chat messages. unless you = spin up an entirely separate SCTP for each flow control domain, which is = lame and defeats the purpose of stream multiplexing. >>=20 >> You can use priorities tied to streams at the sender side. >=20 > priority doesn't solve the problem at all. the issue is that if the = receiver needs to stop accepting data on one stream, the only indication = of reverse pressure to the sender is the association-wide receive window = advertisement. the only in-protocol flow control is association-wide. = the only solution is to not have the receiver suspend reading any stream = and to use application-layer flow control to signal the sender to stop = sending data on one stream or another. We have looked into this. Providing per stream flow control is hard to = do as an extension to SCTP without introducing deadlocks. Looking at the SCTP socket API, = there is a socket per association, so you can't read per stream. If you want signaling = from the receiver, it must be done at the application layer. You can't use the flow control = mechanism for that. >=20 >>> o SCTP specifies the maximum number of streams in each direction at = association startup. web applications may not know the number of streams = needed up front; in fact, the number of streams needed in any real-world = non-SS7 data application is very likely to evolve over the lifetime of = that application, naturally increasing and decreasing. >>=20 >> You don't need a lot of resources for the receive side of a stream. = So you could either negotiate a number >> large enough or use the extension >> http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-strrst-12 >> which is currently in IETF LC. It enables you to add streams on the = fly. >=20 > ok. i'm glad someone thought of that. >=20 >>> o the semantics of unordered messages are confusing and not a good = map to WebRTC. they are semantically equivalent to an entirely separate = stream loosely associated to the ordered stream of the same number. = there's no way to tell (without application layer sequencing) if an = unordered message has been lost/abandoned by the sender. at the protocol = level, TSNs can be used to recover the queuing order of received = unordered messages, but the TSNs are semantically disconnected from the = SCTP user. recovering the original queuing order over a short = reorder/reassembly window period is desirable in some real-time = applications. >>=20 >> The concept of PR-SCTP is that the receiver can handle this. Since = the sender decided that the sequencing >> is not important, why should be receiver care? >=20 > my main point was that, specifically in the case of PR-SCTP, since = unordered messages don't have a stream sequence number there's no way to = tell at the receiver if one (or more) has been abandoned. gaps in the = ordered message space can be detected. Conceptual question: Why does unordered data need some ordering = information. It sounds to me that you don't have unordered stuff in mind, but ordered = unreliable stuff. >=20 >>> o an SCTP receiver should be able to choose to receive stream = messages in originally-queued order or as-received-on-the-network order = on a per-stream basis, and be able to recover the original queuing order = to whatever extent desired (potentially limited by real-time = constraints) when receiving in network order. SCTP's unordered message = semantics are designed for "out-of-band" messages, and are not a good = fit for general "real-time" data. transmission order should be = determined by the sender, reception order should be determined by the = receiver. >>=20 >> It is a sender side thing. If the sender requires in-sequence = delivery, you want the receiver to ignore >> this requirement? If there is not sequencing constraint, the sender = should not send it ordered. >=20 > it's natural to use unordered messages for real-time data, since they = can be delivered to the user as soon as they arrive even if there are = gaps. however, in exactly these real-time scenarios, it's still often = useful to know the original queuing order of the messages, and to allow = the receiver to partially recover the original queuing order in, for = example, a jitter/reorder buffer. this can be accomplished with = application-layer sequence numbers, but it seems silly to have to = duplicate existing protocol-level functionality (see my point about flow = control above). Hmm. Looking at the service you want doesn't seem be unordered. For me = this looks like an ordered unreliable service, taking some timing requirements into = account. So the problem is not, that SCTP does not provide a SSN for unordered = DATA chunks, but that you use unordered messages instead of ordered and that = currently you can't tell SCTP to deliver messages if they stayed for some time in the = receive buffer. However, this is a receiver side only thing which could be done. This = would be a local receiver side only modification supporting partial reliability. = It could be done. It is more an API issue. However, I would assume that this applies mostly to multi media stuff. = Isn't RTP the protocol being considered for that? >=20 >>> o the stream sequence number being only 16 bits limits the maximum = message rate through high delay networks where message gaps can be = reliably detected at the receiver, when the sender uses = limited-reliability, to 32767 messages/RTT. that sounds large, but could = be easily reached even today in moderately high bandwidth*delay paths if = messages are small. >>=20 >> I don't understand this limitation. The is a 32-bit sequence number = space (TSNs) which limits you 2**31 - 1 >> DATA chunks being in flight (as indicated by the last sentence of = Section 6.1 of RFC 4960), >> but the 16-bit per stream sequence numbering (SSNs) does not have = this restriction. >> The receiver will recover the sequencing based on SSN and TSN. At = least this is=20 >=20 > this is only a problem with PR-SCTP. if stream sequence numbers can be = abandoned, then there's ambiguity in the stream sequence number space = when you receive a FORWARD TSN chunk if there were more than 32768 = stream sequence numbers in flight. Hmm. Interesting point. I think you don't need to limit the number of = outstanding user messages per stream to 32768. The crucial point is that you can only FORWARD-TSN the = 64K lowest TSN per stream in a single FORWARD-TSN chunk. So you might need multiple FORWARD-TSN = chunks if you need to FORWARD-TSN a lot of messages per stream. But it doesn't limit the throughput, I = think. >=20 > [...] >=20 > -mike >=20 From randell-ietf@jesup.org Fri Nov 11 16:15:11 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FC821F84A7 for ; Fri, 11 Nov 2011 16:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 amzwpRMEjU7Q for ; Fri, 11 Nov 2011 16:15:10 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 1A36221F84A1 for ; Fri, 11 Nov 2011 16:15:09 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RP1FV-0007Qs-I6 for rtcweb@ietf.org; Fri, 11 Nov 2011 18:15:09 -0600 Message-ID: <4EBDBA63.7010809@jesup.org> Date: Fri, 11 Nov 2011 19:14:27 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> <474200CA-F509-438B-A9CD-71742F4AF6B7@lurchi.franken.de> <02485FF93524F8408ECA9608E47D9F2007CAE80473@nambx05.corp.adobe.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] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 00:15:11 -0000 On 11/11/2011 4:14 PM, Michael Tuexen wrote: > On Nov 11, 2011, at 8:52 PM, Michael Thornburgh wrote: > >>>> o (most important for real-time communication): each user data fragment/chunk is assigned an SCTP Transmission Sequence Number (TSN) at the time of first transmission. that means even if your SCTP implementation supported stream prioritization somehow, the priority decision is only made at first transmission time. since there's just one TSN space and the Gap Ack structure only talks about TSNs, it's undesirable for gaps to persist (else the Gap Ack structure will continue to grow as more losses naturally happen). therefore it's desirable to repair gaps as quickly as possible. this may inappropriately increase the priority of a low priority fragment/chunk/stream during periods of congestion, which is exactly when priority matters (this is a "priority inversion"). >>> What might help is that messages have priorities and the sender is allowed to abandon messages >>> with low priorities in case of congestion (timer based retransmissions). Something which is supported by PR-SCTP. >> sure. but the problem here is the low priority stream is likely to be one that needs full reliability (like a bulk data transfer that you want to use "background" bandwidth but still eventually get delivered). in that case you don't want the sender to abandon the low priority message, and that's what leads to the priority inversion. > So you want to send the bulk transfer with low priority but full reliability? Yes, this would be quite common for things like background file transfers and data synchronization. > And have some other messages, for example with high priority, but only limited reliability? > You could do this. The only point: You need something to drop to improve things. Yes, the background reliable flow *should* slow down, but it must remain reliable. It would probably be ok if the background flow slowed down, and the high-priority flow also slowed down. Note that we're talking about interactions with congestion-control here, and the algorithm can be modified (and we're talking about integrated congestion control between media and data anyways). > Or do you want everything with full reliability? No. >> priority doesn't solve the problem at all. the issue is that if the receiver needs to stop accepting data on one stream, the only indication of reverse pressure to the sender is the association-wide receive window advertisement. the only in-protocol flow control is association-wide. the only solution is to not have the receiver suspend reading any stream and to use application-layer flow control to signal the sender to stop sending data on one stream or another. > We have looked into this. Providing per stream flow control is hard to do as an extension > to SCTP without introducing deadlocks. Looking at the SCTP socket API, there is a socket > per association, so you can't read per stream. If you want signaling from the receiver, > it must be done at the application layer. You can't use the flow control mechanism for that. We can probably state that the app must deal with getting data for all streams; it can't decide not to service one stream of data, or implement application-level flow control. > >>>> o the semantics of unordered messages are confusing and not a good map to WebRTC. they are semantically equivalent to an entirely separate stream loosely associated to the ordered stream of the same number. there's no way to tell (without application layer sequencing) if an unordered message has been lost/abandoned by the sender. at the protocol level, TSNs can be used to recover the queuing order of received unordered messages, but the TSNs are semantically disconnected from the SCTP user. recovering the original queuing order over a short reorder/reassembly window period is desirable in some real-time applications. >>> The concept of PR-SCTP is that the receiver can handle this. Since the sender decided that the sequencing >>> is not important, why should be receiver care? >> my main point was that, specifically in the case of PR-SCTP, since unordered messages don't have a stream sequence number there's no way to tell at the receiver if one (or more) has been abandoned. gaps in the ordered message space can be detected. > Conceptual question: Why does unordered data need some ordering information. > It sounds to me that you don't have unordered stuff in mind, but ordered unreliable stuff. Because of state: If you have datagrams A, B, C, and it's delivered B, A, C, you may throw away A *if* the data in A was already provided or updated in B, but not throw it away if B and A are independent. You need to know the original ordering to know that. Games will do stuff like this. Also, with datagrams you may need to know about losses when in-order (gaps), to change how you process data (simple example: PR-SCTP for lossy audio; on a missing packet you synthesize a replacement instead of ignoring the loss.) Yes, these can be done with application sequence numbers (so long as out-of-order delivery is allowed). It's moderately inefficient to do so if the sequence data is available in the protocol. >>>> o an SCTP receiver should be able to choose to receive stream messages in originally-queued order or as-received-on-the-network order on a per-stream basis, and be able to recover the original queuing order to whatever extent desired (potentially limited by real-time constraints) when receiving in network order. SCTP's unordered message semantics are designed for "out-of-band" messages, and are not a good fit for general "real-time" data. transmission order should be determined by the sender, reception order should be determined by the receiver. >>> It is a sender side thing. If the sender requires in-sequence delivery, you want the receiver to ignore >>> this requirement? If there is not sequencing constraint, the sender should not send it ordered. >> it's natural to use unordered messages for real-time data, since they can be delivered to the user as soon as they arrive even if there are gaps. however, in exactly these real-time scenarios, it's still often useful to know the original queuing order of the messages, and to allow the receiver to partially recover the original queuing order in, for example, a jitter/reorder buffer. this can be accomplished with application-layer sequence numbers, but it seems silly to have to duplicate existing protocol-level functionality (see my point about flow control above). > Hmm. Looking at the service you want doesn't seem be unordered. For me this looks like > an ordered unreliable service, taking some timing requirements into account. A jitter buffer is in fact inherently an in-order partial-reliability service, true - but with different characteristics from SCTP partial-reliability (adaptive to the jitter level, perhaps to appearance of spikes or bulk-delay changes, concealment, whether it's isochronous in output, etc). As mentioned before, there are other uses of true out-of-order delivery. > So the problem is not, that SCTP does not provide a SSN for unordered DATA chunks, > but that you use unordered messages instead of ordered and that currently you can't > tell SCTP to deliver messages if they stayed for some time in the receive buffer. > However, this is a receiver side only thing which could be done. This would be > a local receiver side only modification supporting partial reliability. It could be > done. It is more an API issue. Right: After reading a datagram, do GetLastSerialNum() or some such. > However, I would assume that this applies mostly to multi media stuff. Isn't RTP > the protocol being considered for that? Yes, and *we* don't plan to operate RTP jitter buffers through SCTP. But an application built on webrtc might, and certainly they may do the B, A, C stuff I mentioned above (and react in their app to whether there was any loss). -- Randell Jesup randell-ietf@jesup.org From Tina.Tsou.Zouting@huawei.com Sun Nov 6 16:15:45 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAD921F849D; Sun, 6 Nov 2011 16:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.229 X-Spam-Level: * X-Spam-Status: No, score=1.229 tagged_above=-999 required=5 tests=[AWL=1.724, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iUWb2kWcxuK; Sun, 6 Nov 2011 16:15:44 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6274D21F86DD; Sun, 6 Nov 2011 16:15:44 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU900K5EKQ0PY@szxga03-in.huawei.com>; Mon, 07 Nov 2011 08:15:36 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU900GS0KQ035@szxga03-in.huawei.com>; Mon, 07 Nov 2011 08:15:36 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEW52680; Mon, 07 Nov 2011 08:15:31 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 07 Nov 2011 08:15:29 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.40]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0270.001; Mon, 07 Nov 2011 08:15:26 +0800 Date: Mon, 07 Nov 2011 00:15:25 +0000 From: Tina TSOU In-reply-to: <01O83GWH5W5I00XBUL@mauve.mrochek.com> X-Originating-IP: [10.212.245.75] To: Ned Freed , Harald Alvestrand Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [BEHAVE] [rtcweb] URI schemes for TURN and STUN Thread-index: AQHMl91zEzXUT2d8NU6B4cA/vnFGMZWWDw6AgAD8coCAAOy2gIAE7c64//94soCAAIxrgIAA7hCAgAAJcoCAAALfAIABqZQAgAEE/CuAAACG4A== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EAC6BF4.2000604@alvestrand.no> <4EAC8AE0.3020307@acm.org> <4EACD558.1050003@alvestrand.no> <4EAE157F.5020901@it.aoyama.ac.jp> <4EAEB76B.9090304@acm.org> <8B0C4061-D362-4DFE-9677-7E64515A6E1C@network-heretics.com> <4EAF9391.5040209@it.aoyama.ac.jp> <4EB05A23.3060101@alvestrand.no> <01O80L7NM7N000RCTX@mauve.mrochek.com> <4EB480E7.1010200@alvestrand.no> <48690B43-422C-4B65-8A70-B01F01F8FD97@cisco.com> <4EB552F0.6050800@acm.org> <4EB6B7F0.4040001@alvestrand.no> <01O83GWH5W5I00XBUL@mauve.mrochek.com> X-Mailman-Approved-At: Fri, 11 Nov 2011 20:47:10 -0800 Cc: Behave WG , Keith Moore , "rtcweb@ietf.org" , Keith Moore Subject: Re: [rtcweb] [BEHAVE] URI schemes for TURN and STUN X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Nov 2011 00:15:45 -0000 Ned, In line... Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Ned Freed Sent: Sunday, November 06, 2011 9:59 AM To: Harald Alvestrand Cc: Eric Rescorla; Ned Freed; Keith Moore; Gonzalo Salgueiro; Keith Moore; Behave WG; rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] URI schemes for TURN and STUN > On 11/05/2011 04:14 PM, Marc Petit-Huguenin wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 11/05/2011 08:04 AM, Gonzalo Salgueiro wrote: > >> On Nov 5, 2011, at 10:30 AM, Eric Rescorla wrote: > >> > >>> On Fri, Nov 4, 2011 at 5:18 PM, Harald Alvestrand >>> > wrote: > >>>> On 11/04/2011 04:56 PM, Eric Rescorla wrote: > >>>>> I don't have any commitment to the scheme. What's the best place? > >>>> I like parameters, like this: > >>>> > >>>> turn://user@host?proto=tcp > >>>> > >>>> Quite hard to misunderstand, and quite easy to extend. > >>>> > >>>> (Note: // is only allowed if what follows is [user[:pass]@]host - I don't > >>>> recommend using the password, for the obvious reasons, but the syntax will > >>>> allow it.) > >>> I don't see any security problem with that. The "break old > >>> implementations" rationale > >>> doesn't apply when we are defining a new URI scheme. > >> I agree with this as well. If we can get some consensus with this, I will > >> update the next version of both the STUN and TURN URI Scheme drafts to include > >> this format. > > Or you can look at draft-petithuguenin-behave-turn-uri-bis, which is already > > doing it right (and had a lot of reviews back in 2008, before I split the > > resolution mechanism and the syntax in two separate documents). > > > > I know my email address does not contain the magical "cisco.com", but this is > > getting ridiculous. > Second opinion: draft-petithuguenin uses TURN and TURNS as scheme names. > I still think this is doing it wrong. I concur, especially since two different security layers could be used for some transports in addition to none at all. The security layer needs to be specified as a parameter. [TT] Using two different security layers at the same time? Or one or the other? Ned _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave From elagerway@gmail.com Fri Nov 11 19:07:40 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8F111E8088 for ; Fri, 11 Nov 2011 19:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, 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 d6Exlt0bqKpm for ; Fri, 11 Nov 2011 19:07:40 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB7D511E8087 for ; Fri, 11 Nov 2011 19:07:39 -0800 (PST) Received: by gye5 with SMTP id 5so4218245gye.31 for ; Fri, 11 Nov 2011 19:07:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=ocMHS55032zukfrn7FfAS0ET8vMBTAy1RAMIC8ZcVc0=; b=K2qSiL8FtZnyVIqJsmUxlpifKZpIos/tZwiktlXKNRC0x1HtpPXf/KLkQRFQ3APAg+ 9JD+ZTisKKIKGXstQ+v2gi725ic9Xav/TcmpSeZJ9TZbdgltCO7Ek30d62qDZJgW1jNZ O+CgP/M5zy4zVJ9PNSHRYq76V0GyDCEnt65TI= Received: by 10.236.131.72 with SMTP id l48mr900179yhi.90.1321067259573; Fri, 11 Nov 2011 19:07:39 -0800 (PST) Received: from [10.95.81.124] ([70.28.245.124]) by mx.google.com with ESMTPS id 33sm23747147ano.1.2011.11.11.19.07.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Nov 2011 19:07:37 -0800 (PST) References: <4EB26D22.5090000@ericsson.com> <4EBA741A.1010307@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C0134A992@inba-mail01.sonusnet.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1--837328236 Message-Id: <1E43243C-4BF3-4E5A-98DD-9720558A0FAF@gmail.com> X-Mailer: iPhone Mail (8L1) From: Erik Lagerway Date: Fri, 11 Nov 2011 19:07:31 -0800 To: Dan York X-Mailman-Approved-At: Fri, 11 Nov 2011 20:47:10 -0800 Cc: "" Subject: Re: [rtcweb] RTCWEB is not SIP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2011 03:07:40 -0000 --Apple-Mail-1--837328236 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes, I agree. SIP should take a back seat in this WG, as should jingle etc. On 2011-11-11, at 10:24 AM, Dan York wrote: > +1 >=20 > On Nov 11, 2011, at 6:44 AM, Bernard Aboba wrote: >=20 >> +1 >>=20 >> I=C3=B1aki Baz Castillo said: >>>=20 >>> WebRTC is not SIP... >>>=20 >>> IMHO we should stop talking about SIP in this WG.... >>=20 >>> First priority is to define WebRTC regardless of federation... >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > --=20 > Dan York dyork@lodestar2.com > http://www.danyork.com/ skype:danyork > Phone: +1-802-735-1624 > Twitter - http://twitter.com/danyork > -------------------------------------------------------- > All comments and opinions are entirely my own and have no connection whats= oever to any employer, past or present. Indeed, by tomorrow even I might be d= isavowing these comments. > -------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-1--837328236 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Yes, I agree. SIP should take a back se= at in this WG, as should jingle etc.

On 2011-11-11, at 10:24 A= M, Dan York <dan-ietf@danyork.org= > wrote:

+1
On Nov 11, 2011, at 6:44 AM, Bernard Aboba wrote:

+1

= I=C3=B1aki Baz Castillo said:

=
WebRTC is not SIP...

IMHO we should stop t= alking about SIP in this WG....

First priority is to define WebRTC regardless of federation...
_______________________________________________
rtcweb mailing list<= br>rtc= web@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
=

-= - 
Dan York  dyork@lodestar2.com
http://www.danyork.co= m/   skype:danyork
P= hone: +1-802-735-1624
Twitter - http://twitter.com/danyork=
------------------------------------------= --------------
All comments and opinions are= entirely my own and have no connection whatsoever to any employer, past or p= resent. Indeed, by tomorrow even I might be disavowing these comments.
=
------------------------------------------------= --------

__________= _____________________________________
rtcweb mailing list
rtcweb@ietf.org<= br>https://ww= w.ietf.org/mailman/listinfo/rtcweb
<= /html>= --Apple-Mail-1--837328236-- From miguelecasassanchez@gmail.com Thu Nov 10 09:14:47 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576BB21F8B95 for ; Thu, 10 Nov 2011 09:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_VISITOURSITE=2, 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 ef79kjqsdcjP for ; Thu, 10 Nov 2011 09:14:46 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4027B21F8B89 for ; Thu, 10 Nov 2011 09:14:46 -0800 (PST) Received: by wyf28 with SMTP id 28so1229455wyf.31 for ; Thu, 10 Nov 2011 09:14:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=A/1hKTKhw+asGGafQ9T0n7uSeCMHdSZcFTn8MDzMxC4=; b=LaxLteg0em3r5autzFfNU+lhd34E536MLzPN4OSSap4qdm3fy1rcBqeMmCy4pzA4N4 7hnYw7y6J+WMr3c7+TalHLXiGWV/VrbHwXeaLTMULURjNySqS7yDqhgE8qlX8tAeUxt8 JXxWZ4HZNfFGTHBVXzwv5NBEFnzoxBqQj8ia8= MIME-Version: 1.0 Received: by 10.216.135.37 with SMTP id t37mr1551008wei.44.1320945283982; Thu, 10 Nov 2011 09:14:43 -0800 (PST) Received: by 10.216.179.17 with HTTP; Thu, 10 Nov 2011 09:14:43 -0800 (PST) In-Reply-To: References: Date: Thu, 10 Nov 2011 18:14:43 +0100 Message-ID: From: Miguel Casas-Sanchez To: "Bran, Cary" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 11 Nov 2011 20:47:31 -0800 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Codec 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: Thu, 10 Nov 2011 17:15:23 -0000 Cary, Cullen, if I can add my two pennies: - on the audio codec requirements sec 3.1 , you could be adding as optional mp3 (MPEG-2 layer III). I'm sure a large part of the audience would like to beat me up after writing this, but WebRTC is about interoperability, and there's a whole bunch of servers out there cranking mp3. I'm not too sure if this would not suffer of the same problems as g.729 with licensing. MPEG is easier on licensing than ITU. Or perhaps this is not the document to discuss this optional reqs. - on the video codec req. sec 3.2, the frame rate attainable by the codec is in no way dependent on the codec itself when streaming, as far as I know. Same goes for the resolutions. It might be better to specify a range? The sentence " MUST support a minimum resolution of 320X240" --> might have been "MUST support at least 320x240 pixels resolution"? Shouldn't we add something on supporting/not supporting vbr/cbr? - on the WebRTC client requirements, you go a long way in the SHOULD requirements such as agc etc, but=A0 there is a real chance that those things might be offered in software either compulsorily either de facto. Shouldnt it be a "MAY"? And perhaps we could add some nice-to-have on video requirements, such as "if you want video..." then camera must support QCIF res, >10fps, etc.? - section 5, pp4, interoperability, I read " The codec requirements above will ensure, at a minimum, voice interoperability capabilities between WebRTC client applications and legacy phone systems." Really? since when is WebRTC targeted at interoperability with older phone systems?? Please correct me if I'm wrong. Cheers Miguel On 4 November 2011 18:07, Bran, Cary wrote: > > I=F1aki, > > > > I agree with you with regards to WebRTC needs to embrace a web paradigm a= nd I am a little confused how the latest version of our document implies a = telco paradigm. > > > > The 01 version can be found here: =A0http://tools.ietf.org/id/draft-cbran= -rtcweb-codec-01.txt > > > > Currently the documents lists two video codec candidates (VP8/H.264) , an= d three audio codec candidates, PCMA/PCMU, Telephone Event and Opus. > > > > If you have anything codecs to add that would be considered more web cent= ric, please let us know and we can add it to the open issues list. > > > > Cheers, > > > > -Cary > > > > From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] > Sent: Friday, November 04, 2011 9:31 AM > To: Xavier Marjou > Cc: Bran, Cary; rtcweb@ietf.org > > Subject: Re: [rtcweb] Codec Draft > > > > El 04/11/2011 15:20, "Xavier Marjou" escribi= =F3: > > > > > http://tools.ietf.org/html/draft-kaplan-rtcweb-sip-interworking-require= ments-00,=A0which I fully support by the way. > > Xavier, such draft does not propose that Webrtc must implement all the re= quirements in the draft. It just lists all the requirements needed in order= to fully interoperate with current SIP deployments and opens the door for = discussion about it. > > So if you "fully support" this draft it means that you are just intereste= d in making Webrtc to work with current SIP, regardless security requiremen= ts in the Web. > > So let me know: do you support that browsers must implement g729? Do you = support that webrtc requires not security at all in the media plane (like l= egacy SIP)? > > If so, I dont think you care about Webrtc for the Web, but just for telco= s. Behaviors like this one makes this WG to seem a telco party rather than = a WG working for the Web. WebRTC means RTC for the Web, rather than Web for= telcos, or that is what I hope. > > Regards. > > ________________________________ > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, file= s or previous e-mail messages attached to it, may contain information that = is confidential and/or legally privileged. If you are not the intended reci= pient, or a person responsible for delivering it to the intended recipient,= please DO NOT disclose the contents to another person, store or copy the i= nformation in any medium, or use any of the information contained in or att= ached to this transmission for any purpose. If you have received this trans= mission in error, please immediately notify the sender by reply email or at= privacy@plantronics.com, and destroy the original transmission and its att= achments without reading or saving in any manner. > > For further information about Plantronics - the Company, its products, br= ands, partners, please visit our website www.plantronics.com. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From bernard_aboba@hotmail.com Fri Nov 11 21:19:23 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C711F0C3C for ; Fri, 11 Nov 2011 21:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.571 X-Spam-Level: X-Spam-Status: No, score=-101.571 tagged_above=-999 required=5 tests=[AWL=1.027, 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 KzwyLlnyp0Xv for ; Fri, 11 Nov 2011 21:19:20 -0800 (PST) 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 10DF41F0C3E for ; Fri, 11 Nov 2011 21:19:19 -0800 (PST) Received: from BLU152-W53 ([65.55.116.73]) by blu0-omc3-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Nov 2011 21:19:14 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_06e128e6-0076-409b-bedd-98521432edb6_" X-Originating-IP: [203.69.99.16] From: Bernard Aboba To: Magnus Westerlund Date: Fri, 11 Nov 2011 21:19:13 -0800 Importance: Normal In-Reply-To: <4EBBA102.2030600@ericsson.com> References: <4EB26945.40607@ericsson.com>,<4EB2A58E.1040000@jesup.org> , <4EBBA102.2030600@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Nov 2011 05:19:14.0237 (UTC) FILETIME=[9E249ED0:01CCA0FA] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SRTP mandatory to implement versus mandatory to use X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Nov 2011 05:19:23 -0000 --_06e128e6-0076-409b-bedd-98521432edb6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The problem is that WebRTC is not actually a single use case or "applicatio= n" --=20 it is a framework that could be used to implement applications=2C including= =20 many of the unicast use cases described in the srtp-not-mandatory draft.=20 As the srtp-not-mandatory draft points out=2C it is hard for one keying sch= eme to=20 handle a wide range of scenarios. Even if we exclude the multicast cases= =2C=20 there is enough diversity in the unicast scenarios described in the use cas= e=20 document (e.g. point-to-point and conferencing) for the logic to still hold= up.=20 > Date: Thu=2C 10 Nov 2011 11:01:38 +0100 > From: magnus.westerlund@ericsson.com > To: bernard_aboba@hotmail.com > CC: rtcweb@ietf.org > Subject: Re: [rtcweb] SRTP mandatory to implement versus mandatory to use >=20 > Hi=2C >=20 > Regarding the srtp-not-mandatory draft. In the discussion I have so far=20 > had with for example the security ADs one conclusion is that when we get= =20 > into something that is actually an application or class of applications=20 > and when that is specified by IETF=2C IETF do need to pick at least one=20 > mandatory to implement solution. >=20 > As WebRTC is an application using RTP this becomes very applicable to=20 > the WebRTC work. We do need to pick at least one mandatory to implement=20 > keying mechanism. We might pick additional mandatory ones if we think=20 > that is necessary to address the space of usages we see. I think that is= =20 > what the WG must come to consensus on. >=20 > Cheers >=20 > Magnus >=20 > On 2011-11-09 02:25=2C Bernard Aboba wrote: > > I support SRTP being "mandatory to implement" but not "mandatory to use= ". > > > > With respect to mandating a keying mechanism=2C I would point out the > > arguments in the following document: > > > > http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory > > > > It appears that the arguments made in this document also apply to RTCWE= B > > in that many (though not all) of the use cases mentioned there are also > > to be supported by RTCWEB=2C potentially leading to disparate keying > > requirements. > > > > > > 2. RTP Applications and Deployment Scenarios > > > > The range of application and deployment scenarios where RTP has been > > Perkins & Westerlund Expires May 3=2C 2012 [Page 3] > > > > used includes=2C but is not limited to=2C the following: > > > > o Point-to-point voice telephony (fixed and wireless networks) > > > > o Point-to-point voice and video conferencing > > > > o Centralised group video conferencing with a multipoint conferenc= e > > unit (MCU) > > > > o Any Source Multicast video conferencing (light-weight sessions= =3B > > Mbone conferencing) > > > > o Point-to-point streaming audio and/or video > > > > o Source-specific multicast (SSM) streaming to large group (IPTV a= nd > > 3GPP Multimedia Broadcast Multicast Service (MBMS) [MBMS ]) > > > > o Replicated unicast streaming to a group > > > > o Interconnecting components in music production studios and video > > editing suites > > > > o Interconnecting components of distributed simulation systems > > > > o Streaming real-time sensor data > > > > As can be seen=2C these scenarios vary from point-to-point to very > > large multicast groups=2C from interactive to non-interactive=2C an= d from > > low bandwidth (kilobits per second) to very high bandwidth (multipl= e > > gigabits per second). While most of these applications run over UD= P > > [RFC0768 ]=2C some use TCP [RF= C0793 ]=2C [RFC4614 ] or DCCP [RFC4340 = ] as > > their underlying transport. Some run on highly reliable optical > > networks=2C others use low rate unreliable wireless networks. Some > > applications of RTP operate entirely within a single trust domain= =2C > > others are inter-domain=2C with untrusted (and potentially unknown) > > users. The range of scenarios is wide=2C and growing both in numbe= r > > and in heterogeneity. > > > > > > > > > > 3. Implications for RTP Security > > > > > > > > The wide range of application scenarios where RTP is used has led t= o > > the development of multiple solutions for securing RTP media stream= s > > and RTCP control messages=2C considering different requirements. > > Perhaps the most widely applicable of these solutions is the Secure > > RTP (SRTP) framework [RFC3711 = ]. This is an application-level media > > security solution=2C encrypting the media payload data (but not the= RTP > > headers) to provide some degree of confidentiality=2C and providing > > > > optional source origin authentication. It was carefully designed t= o > > be both low overhead=2C and to support the group communication feat= ures > > of RTP=2C across a range of networks. > > > > SRTP is not the only media security solution in use=2C however=2C a= nd > > alternatives are more appropriate for some scenarios. For example= =2C > > many client-server streaming media applications can run over a sing= le > > TCP connection=2C multiplexing media data with control information = on > > that connection (RTSP [I-D.ietf-mmusic-rfc2326bis ] is a widely used > > example of such a protocol). One way to provide media security for > > such client-server media applications is to use TLS [RFC5246 ] to > > protect the TCP connection=2C sending the RTP media data over the T= LS > > connection. Using the SRTP framework in addition to TLS is > > unnecessary=2C and would result in double encryption of the media= =2C and > > SRTP cannot be used instead of TLS since it is RTP-specific=2C and = so > > cannot protect the control traffic. > > > > Other RTP use cases work over networks which provide security at th= e > > network layer=2C using IPsec. For example=2C certain 3GPP networks= need > > IPsec security associations for other purposes=2C and can reuse tho= se > > to secure the RTP session [TS-33210 ]. SRTP is=2C again=2C unn= ecessary in > > such environments=2C and its use would only introduce overhead for = no > > gain. > > > > For some applications it is sufficient to protect the RTP payload > > data while leaving RTP=2C transport=2C and network layer headers > > unprotected. An example of this is RTP broadcast over DVB-H > > [ETSI.TS.102.474 ]=2C where one mode of operation uses I= SMA Cryp 2.0 > > [ISMA ] to encrypt the RTP payload data only. > > > > All these are application scenarios where RTP has seen commercial > > deployment. Other use cases exist=2C with additional requirements. > > For example=2C if the media transport is done over UDP [RFC0768 ]=2C DCCP > > [RFC4340 ] or SCTP [RFC4960 <= http://tools.ietf.org/html/rfc4960>]=2C then using DTLS [RFC4347 ] to protect the > > whole RTP packets is an option. There is no media security protoco= l > > that is appropriate for all these environments. Accordingly=2C > > multiple RTP media security protocols can be expected to remain in > > wide use. > > > > > > > > > > 4. Implications for Key Management > > > > > > > > With such a diverse range of use cases come a range of different > > protocols for RTP session establishment. Mechanisms used to provid= e > > security keying for these different session establishment protocols > > can basically be put into two categories: inband and out-of-band in > > relation to the session establishment mechanism. The requirements > > for these solutions are highly varying. Thus a wide range of > > > > solutions have been developed in this space: > > > > o A common use case for RTP is probably point-to-point voice calls > > or centralised group conferences=2C negotiated using SIP [RFC326= 1 ] > > with the SDP offer/answer model [RFC3264 ]=2C operating on a trusted > > infrastructure. In such environments=2C SDP security descriptio= ns > > [RFC4568 ]=2C or the MIKEY = [RFC3830 ] protocol using the Key > > Management Extensions for SDP [RFC4567 ]=2C are appropriate keying > > mechanisms=2C where the keying messages/material are embedded in= the > > SDP [RFC4566 ] exchange. T= he infrastructure may be secured by > > protecting the SDP exchange in SIP using TLS or S/MIME=2C for > > example [RFC3261 ]. Protoc= ols such as DTLS-SRTP [RFC5764 ] or ZR= TP > > [RFC6189 ] are also appropr= iate in such environments. > > > > o Point-to-point RTP sessions may be negotiated using SIP with the > > offer/answer model=2C but operating over a network with untruste= d > > infrastructure. In such environments=2C the key management prot= ocol > > can be run on the media path=2C bypassing the untrusted > > infrastructure. Protocols such as DTLS-SRTP [RFC5764 ] or ZRTP > > [RFC6189 ] are useful here= =2C as are inband mechanism that protect > > the keying material such as MIKEY [RFC3830 ] using the Key > > Management Extensions for SDP [RFC4567 ]. It should be noted that > > the end-points for all the above mechanisms must prevent total > > downgrade to no security for the RTP media streams. > > > > o For point-to-point client-server streaming of RTP over RTSP=2C a= TLS > > association is appropriate to manage keying material=2C in much = the > > same manner as would be used to secure an HTTP session. But als= o > > using SRTP with DTLS-SRTP keying or DTLS are appropriate choices= . > > > > o A session description may be sent by email=2C secured using S/MI= ME > > or PGP=2C or retrieved from a web page=2C using HTTP with TLS. > > > > o A session description may be distributed to a multicast group > > using SAP or FLUTE secured with S/MIME. > > > > o A session description may be distributed using the Open Mobile > > Alliance DRM key management specification [OMA-DRM ] when usi= ng a > > point-to-point streaming session setup with RTSP in the 3GPP PSS > > environment [PSS ]. > > > > o In the 3GPP Multimedia Broadcast Multicast Service (MBMS) system= =2C > > HTTP and MIKEY are used for key management [MBMS-SEC ]. > > > > A more detailed survey of requirements for media security managemen= t > > protocols can be found in [RFC5479 ]. As can be seen=2C the range of > > use cases is wide=2C and there is no single protocol that is > > appropriate for all scenarios. These solutions have been further > > > > diversified by the existence of infrastructure elements such as > > authentication solutions that are tied into the key management. > > > > > > > > > > > > Magnus said: > > > > > > "Yes=2C we haven't spent much time on the security consideration sectio= n > > yet. "A mandatory to implement media security solution will be required > > to be picked" is pointer at this WG not the implementor. > > > > I would also point at our Charter that in its last paragraph says: > > "The products of the working group will support security and keying as > > required by BCP 61" > > > > If you haven't read BCP 61 you probably should. It is basically says tw= o > > things. IETF should pick strong security and it shall be MANDATORY to > > IMPLEMENT. I at least as chair will ensure that we have fulfilled this. > > And that means for RTP not only encryption and integrity protection=2C > > probably SRTP=2C but also a keying method. > > > > Yes=2C we (authors of draft-ietf-rtcweb-rtp-usage) will write that SRTP= is > > a MUST implement as soon as we have that consensus established. But we > > will need a keying scheme also and determine where it should be documen= ted. > > > > Cheers > > > > Magnus Westerlund > > " > > > > >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > 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 = --_06e128e6-0076-409b-bedd-98521432edb6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The problem is that WebRTC is not actually a single use case or "applicatio= n" --
it is a framework that could be used to implement applications=2C= including
many of the unicast use cases described in the srtp-not-mand= atory draft.

As the srtp-not-mandatory draft points out=2C it is ha= rd for one keying scheme to
handle a wide range of scenarios. =3B E= ven if we exclude the multicast cases=2C
there is enough diversity in t= he unicast scenarios described in the use case
document (e.g. point-to-= point and conferencing) for the logic to still hold up.

>=3B= Date: Thu=2C 10 Nov 2011 11:01:38 +0100
>=3B From: magnus.westerlund@= ericsson.com
>=3B To: bernard_aboba@hotmail.com
>=3B CC: rtcweb@i= etf.org
>=3B Subject: Re: [rtcweb] SRTP mandatory to implement versus = mandatory to use
>=3B
>=3B Hi=2C
>=3B
>=3B Regarding = the srtp-not-mandatory draft. In the discussion I have so far
>=3B ha= d with for example the security ADs one conclusion is that when we get
= >=3B into something that is actually an application or class of applicati= ons
>=3B and when that is specified by IETF=2C IETF do need to pick a= t least one
>=3B mandatory to implement solution.
>=3B
>= =3B As WebRTC is an application using RTP this becomes very applicable to <= br>>=3B the WebRTC work. We do need to pick at least one mandatory to imp= lement
>=3B keying mechanism. We might pick additional mandatory ones= if we think
>=3B that is necessary to address the space of usages we= see. I think that is
>=3B what the WG must come to consensus on.
= >=3B
>=3B Cheers
>=3B
>=3B Magnus
>=3B
>=3B O= n 2011-11-09 02:25=2C Bernard Aboba wrote:
>=3B >=3B I support SRTP = being "mandatory to implement" but not "mandatory to use".
>=3B >=3B=
>=3B >=3B With respect to mandating a keying mechanism=2C I would p= oint out the
>=3B >=3B arguments in the following document:
>= =3B >=3B
>=3B >=3B http://tools.ietf.org/html/draft-ietf-avt-srtp-= not-mandatory
>=3B >=3B
>=3B >=3B It appears that the argumen= ts made in this document also apply to RTCWEB
>=3B >=3B in that many= (though not all) of the use cases mentioned there are also
>=3B >= =3B to be supported by RTCWEB=2C potentially leading to disparate keying>=3B >=3B requirements.
>=3B >=3B
>=3B >=3B
>=3B &g= t=3B 2. RTP Applications and Deployment Scenarios
>=3B >=3B
&= gt=3B >=3B The range of application and deployment scenarios where RTP ha= s been
>=3B >=3B Perkins &=3B Westerlund Expires May 3=2C 2012 [P= age 3]
>=3B >=3B
>=3B >=3B used includes=2C but is not l= imited to=2C the following:
>=3B >=3B
>=3B >=3B o Point-= to-point voice telephony (fixed and wireless networks)
>=3B >=3B
= >=3B >=3B o Point-to-point voice and video conferencing
>=3B = >=3B
>=3B >=3B o Centralised group video conferencing with a = multipoint conference
>=3B >=3B unit (MCU)
>=3B >=3B>=3B >=3B o Any Source Multicast video conferencing (light-weigh= t sessions=3B
>=3B >=3B Mbone conferencing)
>=3B >=3B<= br>>=3B >=3B o Point-to-point streaming audio and/or video
>= =3B >=3B
>=3B >=3B o Source-specific multicast (SSM) streamin= g to large group (IPTV and
>=3B >=3B 3GPP Multimedia Broadcas= t Multicast Service (MBMS) [MBMS <=3Bhttp://tools.ietf.org/html/draft-ie= tf-avt-srtp-not-mandatory-08#ref-MBMS>=3B])
>=3B >=3B
>=3B &g= t=3B o Replicated unicast streaming to a group
>=3B >=3B
>= =3B >=3B o Interconnecting components in music production studios an= d video
>=3B >=3B editing suites
>=3B >=3B
>=3B &= gt=3B o Interconnecting components of distributed simulation systems>=3B >=3B
>=3B >=3B o Streaming real-time sensor data
= >=3B >=3B
>=3B >=3B As can be seen=2C these scenarios vary f= rom point-to-point to very
>=3B >=3B large multicast groups=2C f= rom interactive to non-interactive=2C and from
>=3B >=3B low ban= dwidth (kilobits per second) to very high bandwidth (multiple
>=3B >= =3B gigabits per second). While most of these applications run over UD= P
>=3B >=3B [RFC0768 <=3Bhttp://tools.ietf.org/html/rfc0768&g= t=3B]=2C some use TCP [RFC0793 <=3Bhttp://tools.ietf.org/html/rfc0793>= =3B]=2C [RFC4614 <=3Bhttp://tools.ietf.org/html/rfc4614>=3B] or DCCP [= RFC4340 <=3Bhttp://tools.ietf.org/html/rfc4340>=3B] as
>=3B >= =3B their underlying transport. Some run on highly reliable optical>=3B >=3B networks=2C others use low rate unreliable wireless netw= orks. Some
>=3B >=3B applications of RTP operate entirely withi= n a single trust domain=2C
>=3B >=3B others are inter-domain=2C = with untrusted (and potentially unknown)
>=3B >=3B users. The r= ange of scenarios is wide=2C and growing both in number
>=3B >=3B = and in heterogeneity.
>=3B >=3B
>=3B >=3B
>=3B >=3B<= br>>=3B >=3B
>=3B >=3B 3. Implications for RTP Security
&= gt=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B The wid= e range of application scenarios where RTP is used has led to
>=3B >= =3B the development of multiple solutions for securing RTP media stream= s
>=3B >=3B and RTCP control messages=2C considering different r= equirements.
>=3B >=3B Perhaps the most widely applicable of the= se solutions is the Secure
>=3B >=3B RTP (SRTP) framework [RFC37= 11 <=3Bhttp://tools.ietf.org/html/rfc3711>=3B]. This is an applicatio= n-level media
>=3B >=3B security solution=2C encrypting the medi= a payload data (but not the RTP
>=3B >=3B headers) to provide so= me degree of confidentiality=2C and providing
>=3B >=3B
>=3B &g= t=3B optional source origin authentication. It was carefully designed = to
>=3B >=3B be both low overhead=2C and to support the group co= mmunication features
>=3B >=3B of RTP=2C across a range of netwo= rks.
>=3B >=3B
>=3B >=3B SRTP is not the only media secur= ity solution in use=2C however=2C and
>=3B >=3B alternatives are= more appropriate for some scenarios. For example=2C
>=3B >=3B = many client-server streaming media applications can run over a single
&g= t=3B >=3B TCP connection=2C multiplexing media data with control info= rmation on
>=3B >=3B that connection (RTSP [I-D.ietf-mmusic-rfc2= 326bis <=3Bhttp://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-= 08#ref-I-D.ietf-mmusic-rfc2326bis>=3B] is a widely used
>=3B >=3B = example of such a protocol). One way to provide media security for
= >=3B >=3B such client-server media applications is to use TLS [RFC5= 246 <=3Bhttp://tools.ietf.org/html/rfc5246>=3B] to
>=3B >=3B = protect the TCP connection=2C sending the RTP media data over the TLS
= >=3B >=3B connection. Using the SRTP framework in addition to TLS = is
>=3B >=3B unnecessary=2C and would result in double encryptio= n of the media=2C and
>=3B >=3B SRTP cannot be used instead of T= LS since it is RTP-specific=2C and so
>=3B >=3B cannot protect t= he control traffic.
>=3B >=3B
>=3B >=3B Other RTP use cas= es work over networks which provide security at the
>=3B >=3B ne= twork layer=2C using IPsec. For example=2C certain 3GPP networks need
&= gt=3B >=3B IPsec security associations for other purposes=2C and can = reuse those
>=3B >=3B to secure the RTP session [TS-33210 <= =3Bhttp://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-TS-3= 3210>=3B]. SRTP is=2C again=2C unnecessary in
>=3B >=3B such = environments=2C and its use would only introduce overhead for no
>=3B = >=3B gain.
>=3B >=3B
>=3B >=3B For some application= s it is sufficient to protect the RTP payload
>=3B >=3B data whi= le leaving RTP=2C transport=2C and network layer headers
>=3B >=3B = unprotected. An example of this is RTP broadcast over DVB-H
>=3B &= gt=3B [ETSI.TS.102.474 <=3Bhttp://tools.ietf.org/html/draft-ietf-avt= -srtp-not-mandatory-08#ref-ETSI.TS.102.474>=3B]=2C where one mode of oper= ation uses ISMA Cryp 2.0
>=3B >=3B [ISMA <=3Bhttp://tools.iet= f.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-ISMA>=3B] to encrypt = the RTP payload data only.
>=3B >=3B
>=3B >=3B All these = are application scenarios where RTP has seen commercial
>=3B >=3B = deployment. Other use cases exist=2C with additional requirements.
&g= t=3B >=3B For example=2C if the media transport is done over UDP [RFC= 0768 <=3Bhttp://tools.ietf.org/html/rfc0768>=3B]=2C DCCP
>=3B >= =3B [RFC4340 <=3Bhttp://tools.ietf.org/html/rfc4340>=3B] or SCTP [= RFC4960 <=3Bhttp://tools.ietf.org/html/rfc4960>=3B]=2C then using DTLS= [RFC4347 <=3Bhttp://tools.ietf.org/html/rfc4347>=3B] to protect the>=3B >=3B whole RTP packets is an option. There is no media secu= rity protocol
>=3B >=3B that is appropriate for all these enviro= nments. Accordingly=2C
>=3B >=3B multiple RTP media security pr= otocols can be expected to remain in
>=3B >=3B wide use.
>= =3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >= =3B 4. Implications for Key Management
>=3B >=3B
>=3B >= =3B
>=3B >=3B
>=3B >=3B With such a diverse range of use = cases come a range of different
>=3B >=3B protocols for RTP sess= ion establishment. Mechanisms used to provide
>=3B >=3B securit= y keying for these different session establishment protocols
>=3B >= =3B can basically be put into two categories: inband and out-of-band in=
>=3B >=3B relation to the session establishment mechanism. The= requirements
>=3B >=3B for these solutions are highly varying. = Thus a wide range of
>=3B >=3B
>=3B >=3B solutions have b= een developed in this space:
>=3B >=3B
>=3B >=3B o A com= mon use case for RTP is probably point-to-point voice calls
>=3B >= =3B or centralised group conferences=2C negotiated using SIP [RFC326= 1 <=3Bhttp://tools.ietf.org/html/rfc3261>=3B]
>=3B >=3B = with the SDP offer/answer model [RFC3264 <=3Bhttp://tools.ietf.org/html/= rfc3264>=3B]=2C operating on a trusted
>=3B >=3B infrastruc= ture. In such environments=2C SDP security descriptions
>=3B >=3B = [RFC4568 <=3Bhttp://tools.ietf.org/html/rfc4568>=3B]=2C or the M= IKEY [RFC3830 <=3Bhttp://tools.ietf.org/html/rfc3830>=3B] protocol usi= ng the Key
>=3B >=3B Management Extensions for SDP [RFC4567 = <=3Bhttp://tools.ietf.org/html/rfc4567>=3B]=2C are appropriate keying>=3B >=3B mechanisms=2C where the keying messages/material are= embedded in the
>=3B >=3B SDP [RFC4566 <=3Bhttp://tools.i= etf.org/html/rfc4566>=3B] exchange. The infrastructure may be secured by=
>=3B >=3B protecting the SDP exchange in SIP using TLS or S/= MIME=2C for
>=3B >=3B example [RFC3261 <=3Bhttp://tools.ie= tf.org/html/rfc3261>=3B]. Protocols such as DTLS-SRTP [RFC5764 <=3Bht= tp://tools.ietf.org/html/rfc5764>=3B] or ZRTP
>=3B >=3B [RF= C6189 <=3Bhttp://tools.ietf.org/html/rfc6189>=3B] are also appropriate= in such environments.
>=3B >=3B
>=3B >=3B o Point-to-po= int RTP sessions may be negotiated using SIP with the
>=3B >=3B = offer/answer model=2C but operating over a network with untrusted
>= =3B >=3B infrastructure. In such environments=2C the key manageme= nt protocol
>=3B >=3B can be run on the media path=2C bypassi= ng the untrusted
>=3B >=3B infrastructure. Protocols such as= DTLS-SRTP [RFC5764 <=3Bhttp://tools.ietf.org/html/rfc5764>=3B] or ZRT= P
>=3B >=3B [RFC6189 <=3Bhttp://tools.ietf.org/html/rfc618= 9>=3B] are useful here=2C as are inband mechanism that protect
>=3B = >=3B the keying material such as MIKEY [RFC3830 <=3Bhttp://tool= s.ietf.org/html/rfc3830>=3B] using the Key
>=3B >=3B Manage= ment Extensions for SDP [RFC4567 <=3Bhttp://tools.ietf.org/html/rfc4567&= gt=3B]. It should be noted that
>=3B >=3B the end-points for= all the above mechanisms must prevent total
>=3B >=3B downgr= ade to no security for the RTP media streams.
>=3B >=3B
>=3B &g= t=3B o For point-to-point client-server streaming of RTP over RTSP=2C = a TLS
>=3B >=3B association is appropriate to manage keying m= aterial=2C in much the
>=3B >=3B same manner as would be used= to secure an HTTP session. But also
>=3B >=3B using SRTP wi= th DTLS-SRTP keying or DTLS are appropriate choices.
>=3B >=3B
&g= t=3B >=3B o A session description may be sent by email=2C secured us= ing S/MIME
>=3B >=3B or PGP=2C or retrieved from a web page= =2C using HTTP with TLS.
>=3B >=3B
>=3B >=3B o A session= description may be distributed to a multicast group
>=3B >=3B = using SAP or FLUTE secured with S/MIME.
>=3B >=3B
>=3B >=3B= o A session description may be distributed using the Open Mobile
&= gt=3B >=3B Alliance DRM key management specification [OMA-DRM <= =3Bhttp://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-OMA-= DRM>=3B] when using a
>=3B >=3B point-to-point streaming se= ssion setup with RTSP in the 3GPP PSS
>=3B >=3B environment [= PSS <=3Bhttp://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08#= ref-PSS>=3B].
>=3B >=3B
>=3B >=3B o In the 3GPP Multim= edia Broadcast Multicast Service (MBMS) system=2C
>=3B >=3B H= TTP and MIKEY are used for key management [MBMS-SEC <=3Bhttp://tools.iet= f.org/html/draft-ietf-avt-srtp-not-mandatory-08#ref-MBMS-SEC>=3B].
>= =3B >=3B
>=3B >=3B A more detailed survey of requirements for = media security management
>=3B >=3B protocols can be found in [R= FC5479 <=3Bhttp://tools.ietf.org/html/rfc5479>=3B]. As can be seen=2C= the range of
>=3B >=3B use cases is wide=2C and there is no sin= gle protocol that is
>=3B >=3B appropriate for all scenarios. T= hese solutions have been further
>=3B >=3B
>=3B >=3B diver= sified by the existence of infrastructure elements such as
>=3B >=3B= authentication solutions that are tied into the key management.
>= =3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >= =3B
>=3B >=3B Magnus said:
>=3B >=3B
>=3B >=3B
>= =3B >=3B "Yes=2C we haven't spent much time on the security consideration= section
>=3B >=3B yet. "A mandatory to implement media security sol= ution will be required
>=3B >=3B to be picked" is pointer at this WG= not the implementor.
>=3B >=3B
>=3B >=3B I would also point = at our Charter that in its last paragraph says:
>=3B >=3B "The produ= cts of the working group will support security and keying as
>=3B >= =3B required by BCP 61"
>=3B >=3B
>=3B >=3B If you haven't re= ad BCP 61 you probably should. It is basically says two
>=3B >=3B th= ings. IETF should pick strong security and it shall be MANDATORY to
>= =3B >=3B IMPLEMENT. I at least as chair will ensure that we have fulfille= d this.
>=3B >=3B And that means for RTP not only encryption and int= egrity protection=2C
>=3B >=3B probably SRTP=2C but also a keying me= thod.
>=3B >=3B
>=3B >=3B Yes=2C we (authors of draft-ietf-rt= cweb-rtp-usage) will write that SRTP is
>=3B >=3B a MUST implement a= s soon as we have that consensus established. But we
>=3B >=3B will = need a keying scheme also and determine where it should be documented.
&= gt=3B >=3B
>=3B >=3B Cheers
>=3B >=3B
>=3B >=3B Magn= us Westerlund
>=3B >=3B "
>=3B >=3B
>=3B >=3B
>= =3B
>=3B
>=3B --
>=3B
>=3B Magnus Westerlund
>= =3B
>=3B ------------------------------------------------------------= ----------
>=3B Multimedia Technologies=2C Ericsson Research EAB/TVM>=3B ------------------------------------------------------------------= ----
>=3B Ericsson AB | Phone +46 10 7148287
>=3B= F=E4r=F6gatan 6 | Mobile +46 73 0949079
>=3B SE-164 80= Stockholm=2C Sweden| mailto: magnus.westerlund@ericsson.com
>=3B ----= ------------------------------------------------------------------
>= =3B
= --_06e128e6-0076-409b-bedd-98521432edb6_-- From giles@thaumas.net Fri Nov 11 21:25:19 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260AF1F0C47 for ; Fri, 11 Nov 2011 21:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 zP3R0RssUqbS for ; Fri, 11 Nov 2011 21:25:18 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8644B1F0C44 for ; Fri, 11 Nov 2011 21:25:12 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so4611789vcb.31 for ; Fri, 11 Nov 2011 21:25:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.26.9 with SMTP id h9mr25125445vdg.99.1321075512017; Fri, 11 Nov 2011 21:25:12 -0800 (PST) Received: by 10.220.194.72 with HTTP; Fri, 11 Nov 2011 21:25:11 -0800 (PST) X-Originating-IP: [66.183.19.247] In-Reply-To: References: Date: Fri, 11 Nov 2011 21:25:11 -0800 Message-ID: From: Ralph Giles To: Miguel Casas-Sanchez Content-Type: text/plain; charset=UTF-8 Cc: "rtcweb@ietf.org" , "Bran, Cary" Subject: Re: [rtcweb] Codec 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: Sat, 12 Nov 2011 05:25:19 -0000 On 10 November 2011 09:14, Miguel Casas-Sanchez wrote: > - on the audio codec requirements sec 3.1 , you could be adding as > optional mp3 (MPEG-2 layer III). I'm sure a large part of the audience > would like to beat me up after writing this, but WebRTC is about > interoperability, and there's a whole bunch of servers out there > cranking mp3. As has been mentioned before, mp3's fixed frame size of 1152 samples makes it unsuitable for interactive applications, especially when combined with the usual 2 or 3 frame encoder latency. > I'm not too sure if this would not suffer of the same > problems as g.729 with licensing. MPEG is easier on licensing than > ITU. Or perhaps this is not the document to discuss this optional > reqs. The mp3 format is also believed to be covered by patents through the end of 2017[1]. While it might be possible to find an encoder profile which will be free before then, it will be at least 2013 before even that subset can be considered royalty free. Unfortunate, I agree, but mp3 and several other more established audio codecs were considered and discarded prior to this draft. -r [1] http://en.wikipedia.org/wiki/Mp3#Licensing_and_patent_issues From stefan.lk.hakansson@ericsson.com Sat Nov 12 05:46:46 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1504621F8497 for ; Sat, 12 Nov 2011 05:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.224 X-Spam-Level: X-Spam-Status: No, score=-5.224 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, GB_VISITOURSITE=2, 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 3CI1sy+vHe4C for ; Sat, 12 Nov 2011 05:46:45 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1A821F8494 for ; Sat, 12 Nov 2011 05:46:44 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-35-4ebe78c3c9e6 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EE.7B.09514.3C87EBE4; Sat, 12 Nov 2011 14:46:43 +0100 (CET) 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.137.0; Sat, 12 Nov 2011 14:46:43 +0100 Message-ID: <4EBE78C2.4020103@ericsson.com> Date: Sat, 12 Nov 2011 14:46:42 +0100 From: =?windows-1252?Q?Stefan_H=E5kansson?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Codec 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: Sat, 12 Nov 2011 13:46:46 -0000 On 10/31/2011 11:25 PM, Bran, Cary wrote: > Hello WebRTC chairs, > > I have updated and submitted a 02 version of the WebRTC Codec draft: > http://tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt Cary, in the -00 version there was also a list of OPTIONAL or RECOMMENDED codecs to implement if I remember correctly. Was there a specific reason for removing that part? Listing codecs that would be "good to implement" for e.g. interoperablity with legacy has some value I think. > > I believe that this draft is representative of areas where the working > group has achieved consensus and at this time I would like to ask that > the 01 draft be adopted as a working group document. > > I look forward to your feedback. > > Regards, > > *Cary Bran* > > Senior Director Advanced Software Technology and Architecture > > Office: +1 831-458-7737 Cell: +1 206-661-2398 > > *Plantronics*Simply Smarter Communications™ > > 345 Encinal St., Santa Cruz, CA 95060 > > > ------------------------------------------------------------------------ > > CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, > files or previous e-mail messages attached to it, may contain > information that is confidential and/or legally privileged. If you are > not the intended recipient, or a person responsible for delivering it to > the intended recipient, please DO NOT disclose the contents to another > person, store or copy the information in any medium, or use any of the > information contained in or attached to this transmission for any > purpose. If you have received this transmission in error, please > immediately notify the sender by reply email or at > privacy@plantronics.com, and destroy the original transmission and its > attachments without reading or saving in any manner. > > For further information about Plantronics - the Company, its products, > brands, partners, please visit our website www.plantronics.com. From Michael.Tuexen@lurchi.franken.de Sat Nov 12 13:00:08 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA61321F8A35 for ; Sat, 12 Nov 2011 13:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSpolB09rf+A for ; Sat, 12 Nov 2011 13:00:07 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 4563721F8922 for ; Sat, 12 Nov 2011 13:00:06 -0800 (PST) Received: from [192.168.1.200] (p508FD1CB.dip.t-dialin.net [80.143.209.203]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 9D6F91C0C0BCF; Sat, 12 Nov 2011 22:00:04 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <4EBDBA63.7010809@jesup.org> Date: Sat, 12 Nov 2011 22:00:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> <474200CA-F509-438B-A9CD-71742F4AF6B7@lurchi.franken.de> <02485FF93524F8408ECA9608E47D9F2007CAE80473@nambx05.corp.adobe.com> <4EBDBA63.7010809@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1251.1) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 21:00:08 -0000 On Nov 12, 2011, at 1:14 AM, Randell Jesup wrote: > On 11/11/2011 4:14 PM, Michael Tuexen wrote: >> On Nov 11, 2011, at 8:52 PM, Michael Thornburgh wrote: >>=20 >>>>> o (most important for real-time communication): each user data = fragment/chunk is assigned an SCTP Transmission Sequence Number (TSN) at = the time of first transmission. that means even if your SCTP = implementation supported stream prioritization somehow, the priority = decision is only made at first transmission time. since there's just one = TSN space and the Gap Ack structure only talks about TSNs, it's = undesirable for gaps to persist (else the Gap Ack structure will = continue to grow as more losses naturally happen). therefore it's = desirable to repair gaps as quickly as possible. this may = inappropriately increase the priority of a low priority = fragment/chunk/stream during periods of congestion, which is exactly = when priority matters (this is a "priority inversion"). >>>> What might help is that messages have priorities and the sender is = allowed to abandon messages >>>> with low priorities in case of congestion (timer based = retransmissions). Something which is supported by PR-SCTP. >>> sure. but the problem here is the low priority stream is likely to = be one that needs full reliability (like a bulk data transfer that you = want to use "background" bandwidth but still eventually get delivered). = in that case you don't want the sender to abandon the low priority = message, and that's what leads to the priority inversion. >> So you want to send the bulk transfer with low priority but full = reliability? >=20 >=20 > Yes, this would be quite common for things like background file = transfers and data synchronization. >=20 >> And have some other messages, for example with high priority, but = only limited reliability? >> You could do this. The only point: You need something to drop to = improve things. >=20 >=20 > Yes, the background reliable flow *should* slow down, but it must = remain reliable. It would probably be ok if the background flow slowed = down, and the high-priority flow also slowed down. >=20 > Note that we're talking about interactions with congestion-control = here, and the algorithm can be modified (and we're talking about = integrated congestion control between media and data anyways). OK, I see. >=20 >> Or do you want everything with full reliability? >=20 > No. >=20 >>> priority doesn't solve the problem at all. the issue is that if the = receiver needs to stop accepting data on one stream, the only indication = of reverse pressure to the sender is the association-wide receive window = advertisement. the only in-protocol flow control is association-wide. = the only solution is to not have the receiver suspend reading any stream = and to use application-layer flow control to signal the sender to stop = sending data on one stream or another. >> We have looked into this. Providing per stream flow control is hard = to do as an extension >> to SCTP without introducing deadlocks. Looking at the SCTP socket = API, there is a socket >> per association, so you can't read per stream. If you want signaling = from the receiver, >> it must be done at the application layer. You can't use the flow = control mechanism for that. >=20 > We can probably state that the app must deal with getting data for all = streams; it can't decide not to service one stream of data, or implement = application-level flow control. That is a good idea. >=20 >>=20 >>>>> o the semantics of unordered messages are confusing and not a good = map to WebRTC. they are semantically equivalent to an entirely separate = stream loosely associated to the ordered stream of the same number. = there's no way to tell (without application layer sequencing) if an = unordered message has been lost/abandoned by the sender. at the protocol = level, TSNs can be used to recover the queuing order of received = unordered messages, but the TSNs are semantically disconnected from the = SCTP user. recovering the original queuing order over a short = reorder/reassembly window period is desirable in some real-time = applications. >>>> The concept of PR-SCTP is that the receiver can handle this. Since = the sender decided that the sequencing >>>> is not important, why should be receiver care? >>> my main point was that, specifically in the case of PR-SCTP, since = unordered messages don't have a stream sequence number there's no way to = tell at the receiver if one (or more) has been abandoned. gaps in the = ordered message space can be detected. >> Conceptual question: Why does unordered data need some ordering = information. >> It sounds to me that you don't have unordered stuff in mind, but = ordered unreliable stuff. >=20 >=20 > Because of state: If you have datagrams A, B, C, and it's delivered = B, A, C, you may throw away A *if* the data in A was already provided or = updated in B, but not throw it away if B and A are independent. You = need to know the original ordering to know that. Games will do stuff = like this. This means that there are sequencing constraints... So it is not = unordered. I think the service is ordered, unreliable what is used... >=20 > Also, with datagrams you may need to know about losses when in-order = (gaps), to change how you process data (simple example: PR-SCTP for = lossy audio; on a missing packet you synthesize a replacement instead of = ignoring the loss.) >=20 > Yes, these can be done with application sequence numbers (so long as = out-of-order delivery is allowed). It's moderately inefficient to do so = if the sequence data is available in the protocol. >=20 >>>>> o an SCTP receiver should be able to choose to receive stream = messages in originally-queued order or as-received-on-the-network order = on a per-stream basis, and be able to recover the original queuing order = to whatever extent desired (potentially limited by real-time = constraints) when receiving in network order. SCTP's unordered message = semantics are designed for "out-of-band" messages, and are not a good = fit for general "real-time" data. transmission order should be = determined by the sender, reception order should be determined by the = receiver. >>>> It is a sender side thing. If the sender requires in-sequence = delivery, you want the receiver to ignore >>>> this requirement? If there is not sequencing constraint, the sender = should not send it ordered. >>> it's natural to use unordered messages for real-time data, since = they can be delivered to the user as soon as they arrive even if there = are gaps. however, in exactly these real-time scenarios, it's still = often useful to know the original queuing order of the messages, and to = allow the receiver to partially recover the original queuing order in, = for example, a jitter/reorder buffer. this can be accomplished with = application-layer sequence numbers, but it seems silly to have to = duplicate existing protocol-level functionality (see my point about flow = control above). >> Hmm. Looking at the service you want doesn't seem be unordered. For = me this looks like >> an ordered unreliable service, taking some timing requirements into = account. >=20 >=20 > A jitter buffer is in fact inherently an in-order partial-reliability = service, true - but with different characteristics from SCTP = partial-reliability (adaptive to the jitter level, perhaps to appearance = of spikes or bulk-delay changes, concealment, whether it's isochronous = in output, etc). As mentioned before, there are other uses of true = out-of-order delivery. I think the point is: The service used us unreliable, ordered. And the application want to do = the ordering by itself. So it should do so. Which includes providing the = necessary information for it. >=20 >> So the problem is not, that SCTP does not provide a SSN for unordered = DATA chunks, >> but that you use unordered messages instead of ordered and that = currently you can't >> tell SCTP to deliver messages if they stayed for some time in the = receive buffer. >> However, this is a receiver side only thing which could be done. This = would be >> a local receiver side only modification supporting partial = reliability. It could be >> done. It is more an API issue. >=20 >=20 > Right: After reading a datagram, do GetLastSerialNum() or some such. >=20 >> However, I would assume that this applies mostly to multi media = stuff. Isn't RTP >> the protocol being considered for that? >=20 >=20 > Yes, and *we* don't plan to operate RTP jitter buffers through SCTP. = But an application built on webrtc might, and certainly they may do the = B, A, C stuff I mentioned above (and react in their app to whether there = was any loss). It can do whatever it wants using unordered, but it has to provide the = information needed for it by itself. It might be a sequence number, some timing = information,... Best regards Michael >=20 >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 From randell-ietf@jesup.org Sat Nov 12 17:50:36 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2780711E8095 for ; Sat, 12 Nov 2011 17:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 xAfgC7q97nd0 for ; Sat, 12 Nov 2011 17:50:34 -0800 (PST) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA0511E8091 for ; Sat, 12 Nov 2011 17:50:34 -0800 (PST) Received: from pool-173-49-135-74.phlapa.fios.verizon.net ([173.49.135.74] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RPPDN-0004dG-Dg for rtcweb@ietf.org; Sat, 12 Nov 2011 19:50:33 -0600 Message-ID: <4EBF223C.50107@jesup.org> Date: Sat, 12 Nov 2011 20:49:48 -0500 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <02485FF93524F8408ECA9608E47D9F2007CACFFAC2@nambx05.corp.adobe.com> <474200CA-F509-438B-A9CD-71742F4AF6B7@lurchi.franken.de> <02485FF93524F8408ECA9608E47D9F2007CAE80473@nambx05.corp.adobe.com> <4EBDBA63.7010809@jesup.org> 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] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 01:50:38 -0000 On 11/12/2011 4:00 PM, Michael Tüxen wrote: > On Nov 12, 2011, at 1:14 AM, Randell Jesup wrote: >>>>>> o the semantics of unordered messages are confusing and not a good map to WebRTC. they are semantically equivalent to an entirely separate stream loosely associated to the ordered stream of the same number. there's no way to tell (without application layer sequencing) if an unordered message has been lost/abandoned by the sender. at the protocol level, TSNs can be used to recover the queuing order of received unordered messages, but the TSNs are semantically disconnected from the SCTP user. recovering the original queuing order over a short reorder/reassembly window period is desirable in some real-time applications. >>>>> The concept of PR-SCTP is that the receiver can handle this. Since the sender decided that the sequencing >>>>> is not important, why should be receiver care? >>>> my main point was that, specifically in the case of PR-SCTP, since unordered messages don't have a stream sequence number there's no way to tell at the receiver if one (or more) has been abandoned. gaps in the ordered message space can be detected. >>> Conceptual question: Why does unordered data need some ordering information. >>> It sounds to me that you don't have unordered stuff in mind, but ordered unreliable stuff. >> >> >> Because of state: If you have datagrams A, B, C, and it's delivered B, A, C, you may throw away A *if* the data in A was already provided or updated in B, but not throw it away if B and A are independent. You need to know the original ordering to know that. Games will do stuff like this. > This means that there are sequencing constraints... So it is not unordered. I think > the service is ordered, unreliable what is used... To be utterly clear: the game example I gave requires unordered, unreliable (though unordered reliable and unordered partial-reliability would work too). It also needs to know the original sequence to know if there are gaps or out-of-order deliveries. If it doesn't get the original sequence information from the stack (i.e. know if a packet has a gap in delivery, or a packet is out-of-order (and ideally where in the sequence it belonged), then it must add it's own message serial numbers to the application data. Any sequence constraints as described might apply to parts of the message, not only to the message as a whole. How to handle this is entirely in the application domain. >> >> Also, with datagrams you may need to know about losses when in-order (gaps), to change how you process data (simple example: PR-SCTP for lossy audio; on a missing packet you synthesize a replacement instead of ignoring the loss.) >> >> Yes, these can be done with application sequence numbers (so long as out-of-order delivery is allowed). It's moderately inefficient to do so if the sequence data is available in the protocol. >> >>>>>> o an SCTP receiver should be able to choose to receive stream messages in originally-queued order or as-received-on-the-network order on a per-stream basis, and be able to recover the original queuing order to whatever extent desired (potentially limited by real-time constraints) when receiving in network order. SCTP's unordered message semantics are designed for "out-of-band" messages, and are not a good fit for general "real-time" data. transmission order should be determined by the sender, reception order should be determined by the receiver. >>>>> It is a sender side thing. If the sender requires in-sequence delivery, you want the receiver to ignore >>>>> this requirement? If there is not sequencing constraint, the sender should not send it ordered. >>>> it's natural to use unordered messages for real-time data, since they can be delivered to the user as soon as they arrive even if there are gaps. however, in exactly these real-time scenarios, it's still often useful to know the original queuing order of the messages, and to allow the receiver to partially recover the original queuing order in, for example, a jitter/reorder buffer. this can be accomplished with application-layer sequence numbers, but it seems silly to have to duplicate existing protocol-level functionality (see my point about flow control above). >>> Hmm. Looking at the service you want doesn't seem be unordered. For me this looks like >>> an ordered unreliable service, taking some timing requirements into account. >> >> >> A jitter buffer is in fact inherently an in-order partial-reliability service, true - but with different characteristics from SCTP partial-reliability (adaptive to the jitter level, perhaps to appearance of spikes or bulk-delay changes, concealment, whether it's isochronous in output, etc). As mentioned before, there are other uses of true out-of-order delivery. > I think the point is: > The service used us unreliable, ordered. And the application want to do the > ordering by itself. So it should do so. Which includes providing the necessary > information for it. Sure it can provide the information itself. It is a waste of bits since the stack knows the information, but it's only a minor waste (16 or 32 bits per datagram). We certainly can deal with that if the stack doesn't supply it. -- Randell Jesup randell-ietf@jesup.org From ted.ietf@gmail.com Sun Nov 13 01:04:51 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFA621F8B43 for ; Sun, 13 Nov 2011 01:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.161 X-Spam-Level: X-Spam-Status: No, score=-3.161 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlwPBpIMiGiR for ; Sun, 13 Nov 2011 01:04:50 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8366421F8B3F for ; Sun, 13 Nov 2011 01:04:50 -0800 (PST) Received: by ywt34 with SMTP id 34so3754268ywt.31 for ; Sun, 13 Nov 2011 01:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vzMzs68XgESX8yJQkvXBlqm+GMxa8kZpufy2/VR/N1s=; b=JEGW0251mdGlskIUQtcejw0MfGUHTd9Vlcr6QhZtCE1YcVn0Esfptg9WDWwvansgPd 6GwWSHojWvH7V0m5Ou3vkyvH7AUwD+PtM0D1fwnphr1avYj/Ad5z5EpamabX7987otHZ vgAYnHOWIgozVqCGYSdNdW8udT+toTa0ixl74= MIME-Version: 1.0 Received: by 10.236.197.72 with SMTP id s48mr7235955yhn.81.1321175089360; Sun, 13 Nov 2011 01:04:49 -0800 (PST) Received: by 10.236.110.33 with HTTP; Sun, 13 Nov 2011 01:04:49 -0800 (PST) Received: by 10.236.110.33 with HTTP; Sun, 13 Nov 2011 01:04:49 -0800 (PST) In-Reply-To: References: <4EB26D22.5090000@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6CD2FA@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01CE7059@inba-mail01.sonusnet.com> Date: Sun, 13 Nov 2011 01:04:49 -0800 Message-ID: From: Ted Hardie To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=20cf303f6c80e3305704b19a0b82 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding Federation Arguments X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Nov 2011 09:04:51 -0000 --20cf303f6c80e3305704b19a0b82 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Nov 11, 2011 8:41 AM, "I=F1aki Baz Castillo" wrote: > > El 11/11/2011 06:23, "Ravindran, Parthasarathi" escribi=F3: > > > > This is the very same argument again. IMHO it is time for you to assume that this WG has decided by consensus that there will be no standard in-the-wire protocol in WebRTC, nor a suggested proposal by this WG. I must ask you not to call consensus for this working group. If you feel strongly that a matter has reached consensus, contact the chairs and discuss with us the timing. Ted Hardie > > IMHO the only reason for having a "standard" WebrTC signaling protocol is to make a business for gateway vendors building "standard WebRTC-to-SIP gateways". I cannot imagine other reasons. That is not a legitime argument in a IETF specification. > > Anyhow I will not discuss again about this subject. There is consensus. Time to move on. Please spend your time in helping with open subjects rather than trying to reopen the discussion about the standard protocol. > > Regards. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf303f6c80e3305704b19a0b82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 11, 2011 8:41 AM, "I=F1aki Baz Castillo" <ibc@aliax.net> wrote:
>
> El 11/11/2011 06:23, "Ravindran, Parthasarathi" <pravindran@sonusnet.com> escribi= =F3:
>
>
>
> This is the very same argument again. IMHO it is time for you to assum= e that this WG has decided by consensus that there will be no standard in-t= he-wire protocol in WebRTC, nor a suggested proposal by this WG.


I must ask you not to call consensus for this working group. If you feel= strongly that a matter has reached consensus, contact the chairs and discu= ss with us the timing.

Ted Hardie

>
> IMHO the only reason for having a "standard" WebrTC signalin= g protocol is to make a business for gateway vendors building "standar= d WebRTC-to-SIP gateways". I cannot imagine other reasons. That is not= a legitime argument in a IETF specification.
>
> Anyhow I will not discuss again about this subject. There is consensus= . Time to move on. Please spend your time in helping with open subjects rat= her than trying to reopen the discussion about the standard protocol.
>
> Regards.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb
>

--20cf303f6c80e3305704b19a0b82-- From neils@vipadia.com Sun Nov 13 01:26:19 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C37621F8B5A for ; Sun, 13 Nov 2011 01:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_57=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 vY8twHdcKWYr for ; Sun, 13 Nov 2011 01:26:18 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B46C721F8B59 for ; Sun, 13 Nov 2011 01:26:18 -0800 (PST) Received: by iaeo4 with SMTP id o4so7746632iae.31 for ; Sun, 13 Nov 2011 01:26:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.60.76 with SMTP id o12mr4304560ibh.83.1321176377800; Sun, 13 Nov 2011 01:26:17 -0800 (PST) Sender: neils@vipadia.com Received: by 10.231.207.10 with HTTP; Sun, 13 Nov 2011 01:26:17 -0800 (PST) In-Reply-To: <1E43243C-4BF3-4E5A-98DD-9720558A0FAF@gmail.com> References: <4EB26D22.5090000@ericsson.com> <4EBA741A.1010307@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C0134A992@inba-mail01.sonusnet.com> <1E43243C-4BF3-4E5A-98DD-9720558A0FAF@gmail.com> Date: Sun, 13 Nov 2011 09:26:17 +0000 X-Google-Sender-Auth: M2ZkGF_HW3Bg9QARVOfcB4XmV8s Message-ID: From: Neil Stratford To: Erik Lagerway Content-Type: multipart/alternative; boundary=0015176f0c88af389d04b19a581e Cc: "" Subject: Re: [rtcweb] RTCWEB is not SIP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Nov 2011 09:26:19 -0000 --0015176f0c88af389d04b19a581e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 On Sat, Nov 12, 2011 at 3:07 AM, Erik Lagerway wrote: > Yes, I agree. SIP should take a back seat in this WG, as should jingle et= c. > > On 2011-11-11, at 10:24 AM, Dan York wrote: > > +1 > > On Nov 11, 2011, at 6:44 AM, Bernard Aboba wrote: > > +1 > > I=F1aki Baz Castillo said: > > > WebRTC is not SIP... > > > IMHO we should stop talking about SIP in this WG.... > > > First priority is to define WebRTC regardless of federation... > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > -- > Dan York dyork@lodestar2.com > http://www.danyork.com/ skype:danyork > Phone: +1-802-735-1624 > Twitter - http://twitter.com/danyork > -------------------------------------------------------- > All comments and opinions are entirely my own and have no connection > whatsoever to any employer, past or present. Indeed, by tomorrow even I > might be disavowing these comments. > -------------------------------------------------------- > > _______________________________________________ > 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 > > --0015176f0c88af389d04b19a581e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

On Sat, Nov 12, 2011 at 3:07 AM, Erik = Lagerway <elage= rway@gmail.com> wrote:
Yes, I agree. SIP should take a back seat in = this WG, as should jingle etc.
=
On 2011-11-11, at 10:24 AM, Dan York <dan-ietf@danyork.org> wrote:

+1

On= Nov 11, 2011, at 6:44 AM, Bernard Aboba wrote:

+1

I=F1aki Baz Castillo said:

WebRTC is not SIP...

I= MHO we should stop talking about SIP in this WG....

First priority is to define WebRTC regardless of federation...
_______________________________________________
rtcweb mailing list<= br>rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--=A0
Dan York =A0dyork@lodes= tar2.com
<= a href=3D"http://www.danyork.com/" target=3D"_blank">http://www.danyork.com= /=A0=A0=A0skype:danyork
Phone: +1-802-735-1624
Twitter -=A0http://twitter.com/danyork
---------------------------------------= -----------------
All comments and= opinions are entirely my own and have no connection whatsoever to any empl= oyer, past or present. Indeed, by tomorrow even I might be disavowing these= comments.
---------------------------------------= -----------------

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

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


--0015176f0c88af389d04b19a581e-- From ibc@aliax.net Sun Nov 13 03:38:44 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB5D21F8B98 for ; Sun, 13 Nov 2011 03:38:44 -0800 (PST) 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.039, 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 GgPjdmsRJqim for ; Sun, 13 Nov 2011 03:38:44 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E812321F8B89 for ; Sun, 13 Nov 2011 03:38:43 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so5204221vcb.31 for ; Sun, 13 Nov 2011 03:38:43 -0800 (PST) Received: by 10.52.94.18 with SMTP id cy18mr29886064vdb.24.1321184323056; Sun, 13 Nov 2011 03:38:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Sun, 13 Nov 2011 03:38:22 -0800 (PST) In-Reply-To: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 13 Nov 2011 12:38:22 +0100 Message-ID: To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Sun, 13 Nov 2011 11:38:45 -0000 2011/11/11 Hadriel Kaplan : > WebRTC browsers need to be able to send DTMF out Why??? WebRTC is not SIP, this is not about legacy telephony. If somebody creates a NEW RTC protocol it would not include like-DTMF's-over-RTP anymore. DTMF is an ugly and annoying mechanism from the past, there is no need at all to incorporate it in a new specification (unless the only "innovation" telcos have in mind are "calls from the Web to a PSTN IVR sytem"). DMTF's are symbols (0-9, *, #, A-F) to be sent over the media flow. It's really ugly and just a reminiscence from the old PSTN. No, please, forget DTMF's. No more "SIP" nor "PSTN" in this WG. Regards. --=20 I=C3=B1aki Baz Castillo From tim@phonefromhere.com Sun Nov 13 03:48:18 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F75B21F8B67 for ; Sun, 13 Nov 2011 03:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=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 vVgjUbITLaXK for ; Sun, 13 Nov 2011 03:48:18 -0800 (PST) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id AED3721F8B44 for ; Sun, 13 Nov 2011 03:48:17 -0800 (PST) Received: from [192.168.157.49] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 1012D37A902; Sun, 13 Nov 2011 12:01:06 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_C206DC4B-85B1-41C5-B54D-D013232C98FC" From: Tim Panton In-Reply-To: Date: Sun, 13 Nov 2011 11:48:26 +0000 Message-Id: References: <4EB26D22.5090000@ericsson.com> <4EBA741A.1010307@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C0134A992@inba-mail01.sonusnet.com> <1E43243C-4BF3-4E5A-98DD-9720558A0FAF@gmail.com> To: "" X-Mailer: Apple Mail (2.1251.1) Cc: Erik Lagerway Subject: Re: [rtcweb] RTCWEB is not SIP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Nov 2011 11:48:18 -0000 --Apple-Mail=_C206DC4B-85B1-41C5-B54D-D013232C98FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 +1 (as if you hadn't guessed) On 13 Nov 2011, at 09:26, Neil Stratford wrote: > +1 >=20 > On Sat, Nov 12, 2011 at 3:07 AM, Erik Lagerway = wrote: > Yes, I agree. SIP should take a back seat in this WG, as should jingle = etc. >=20 > On 2011-11-11, at 10:24 AM, Dan York wrote: >=20 >> +1 >>=20 >> On Nov 11, 2011, at 6:44 AM, Bernard Aboba wrote: >>=20 >>> +1 >>>=20 >>> I=F1aki Baz Castillo said: >>>>=20 >>>> WebRTC is not SIP... >>>>=20 >>>> IMHO we should stop talking about SIP in this WG.... >>>=20 >>>> First priority is to define WebRTC regardless of federation... >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >> --=20 >> Dan York dyork@lodestar2.com >> http://www.danyork.com/ skype:danyork >> Phone: +1-802-735-1624 >> Twitter - http://twitter.com/danyork >> -------------------------------------------------------- >> All comments and opinions are entirely my own and have no connection = whatsoever to any employer, past or present. Indeed, by tomorrow even I = might be disavowing these comments. >> -------------------------------------------------------- >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_C206DC4B-85B1-41C5-B54D-D013232C98FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
+1

On Sat, Nov 12, 2011 = at 3:07 AM, Erik Lagerway <elagerway@gmail.com> = wrote:
Yes, I agree. SIP should take a back seat = in this WG, as should jingle etc.

On 2011-11-11, at 10:24 AM, Dan York <dan-ietf@danyork.org> wrote:

+1

On Nov 11, 2011, at 6:44 AM, = Bernard Aboba wrote:

+1

I=F1aki Baz Castillo said:

WebRTC is not = SIP...

IMHO we should = stop talking about SIP in this WG....

First priority is to define WebRTC regardless of = federation...
____________________________________________= ___
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

-------------------------------------------= -------------
All comments and = opinions are entirely my own and have no connection whatsoever to any = employer, past or present. Indeed, by tomorrow even I might be = disavowing these comments.
-------------------------------------------= -------------

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

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


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

= --Apple-Mail=_C206DC4B-85B1-41C5-B54D-D013232C98FC-- From HKaplan@acmepacket.com Sun Nov 13 04:02:43 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEF221F8B98 for ; Sun, 13 Nov 2011 04:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXzqnK596ZjO for ; Sun, 13 Nov 2011 04:02:43 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 247B721F8B9B for ; Sun, 13 Nov 2011 04:02:43 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 13 Nov 2011 07:02:41 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sun, 13 Nov 2011 07:02:41 -0500 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC) Thread-Index: AQHMofwkoPY+iIKWa0aledDcjGopdA== Date: Sun, 13 Nov 2011 12:02:40 +0000 Message-ID: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> 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="iso-8859-1" Content-ID: <8157D4A3A88C1F46B6E9F3A8CE910A79@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Sun, 13 Nov 2011 12:02:43 -0000 On Nov 13, 2011, at 6:38 AM, I=F1aki Baz Castillo wrote: > No, please, forget DTMF's. No more "SIP" nor "PSTN" in this WG. First, DMTFs aren't just about SIP - it's used by other protocols as well. But yes obviously it's about enabling WebRTC browsers to communicate with n= on-WebRTC peers, including those in SIP, such as IVRs and voicemail servers= and so on - not just in "Telco's" but also in Enterprises. Some people in this WG don't want to worry about that, which is fine - don'= t worry about it. If you don't want to use RFC4733, your Javascript/Server= code doesn't have to worry about it. But some people in this WG *do* want= to support interworking with other deployed devices/domains. So long as t= he mechanisms needed to do so don't hurt WebRTC or force a specific archite= ctural model, why do you care? -hadriel From ibc@aliax.net Sun Nov 13 04:28:41 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC0221F8B50 for ; Sun, 13 Nov 2011 04:28:41 -0800 (PST) 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.039, 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 VvITJE9-Wvv0 for ; Sun, 13 Nov 2011 04:28:41 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD9F221F8B44 for ; Sun, 13 Nov 2011 04:28:40 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so5219616vcb.31 for ; Sun, 13 Nov 2011 04:28:40 -0800 (PST) Received: by 10.220.150.204 with SMTP id z12mr2054194vcv.43.1321187320078; Sun, 13 Nov 2011 04:28:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Sun, 13 Nov 2011 04:28:20 -0800 (PST) In-Reply-To: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 13 Nov 2011 13:28:20 +0100 Message-ID: To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Sun, 13 Nov 2011 12:28:41 -0000 2011/11/13 Hadriel Kaplan : > So long as the mechanisms needed to do so don't hurt WebRTC or force a sp= ecific architectural model, why do you care? Some telcos in this WG (and I could find exact mails) would accept even if WebRTC uses a pure SIP stack. Some others propose G729 inclusion in WebRTC (wow!), and all of them ask for non mandatory SRTP. Soon, they will also ask non mandatory ICE (they will argue "ICE mandatory to implement in WebRTC client, but not mandatory to use"). DTMF's via RTP is just the less important subject. What I care is all the rest, and the fact that 75% of mails in this WG are about PSTN legacy interoperability. Regards. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Sun Nov 13 05:59:04 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A4921F8B61 for ; Sun, 13 Nov 2011 05:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=-0.015, 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 8eYvV28ybGBO for ; Sun, 13 Nov 2011 05:59:04 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id E565421F8B40 for ; Sun, 13 Nov 2011 05:59:03 -0800 (PST) Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pADDxdd8001712; Sun, 13 Nov 2011 08:59:39 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Nov 2011 08:59:01 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Nov 2011 19:29:13 +0530 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.0339.001; Sun, 13 Nov 2011 19:29:12 +0530 From: "Ravindran, Parthasarathi" To: Cullen Jennings Thread-Topic: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of WebRTC) Thread-Index: AQHMnoiMLXoobGtfx0Kkx8oSZTnrRJWj1oYwgABiqoCAAVQz4IAA1mMAgAScmgA= Date: Sun, 13 Nov 2011 13:59:12 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01CE76D3@inba-mail01.sonusnet.com> References: <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <4EB7E6A5.70209@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349D81@inba-mail01.sonusnet.com> <4EB9ACF5.80805@alvestrand.no> <387F9047F55E8C42850AD6B3A7A03C6C01349F60@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FE6@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A6B5@inba-mail01.sonusnet.com> <4368BF50-2B50-4C9A-9CF4-E7D87705E4BF@cisco.com> In-Reply-To: <4368BF50-2B50-4C9A-9CF4-E7D87705E4BF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.53.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Nov 2011 13:59:13.0651 (UTC) FILETIME=[6CDB2430:01CCA20C] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP requirement - wiretapping (Re: Let's define the purpose of 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: Sun, 13 Nov 2011 13:59:04 -0000 >-----Original Message----- >From: Cullen Jennings [mailto:fluffy@cisco.com] > >On Nov 10, 2011, at 13:19 , Ravindran, Parthasarathi wrote: > >> AFAIK in case of telepresence or equivalent endpoint, it requires the >special hardware to encrypt/decrypt the whole bunch of media from it. > >Really? For a fairly high end 3 screenTP systems, it's like a 6 mbps >stream. AFAIK, ~15Mbps is very much possible for 3 screen TP and one of=20 the related link is http://www.nojitter.com/blog/225400682. I come to know about these numbers during SBC development to interop with=20 telepresence. May be multiple variant of TP exists I seem to recall a Linksys router with VPN could do crypto at >that rate. Been awhile since I looked at the numbers so perhaps I have >this all wrong. In fact, I started thinking in this line based on your=20 point on SIPREC requirement not to mandate separate SRTP keys for=20 telepresence recording & communication session and it was accepted in SIPREC. From HKaplan@acmepacket.com Sun Nov 13 06:01:17 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1751F21F8BA4 for ; Sun, 13 Nov 2011 06:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM1AGxX7CiB8 for ; Sun, 13 Nov 2011 06:01:16 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6E85A21F8B9E for ; Sun, 13 Nov 2011 06:01:16 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 13 Nov 2011 09:01:15 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sun, 13 Nov 2011 09:01:15 -0500 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of WebRTC) Thread-Index: AQHMogy0oPY+iIKWa0aledDcjGopdA== Date: Sun, 13 Nov 2011 14:01:14 +0000 Message-ID: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> 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="iso-8859-1" Content-ID: <3318F9BD11713249BBDB4ABAE97DBA10@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Sun, 13 Nov 2011 14:01:17 -0000 On Nov 13, 2011, at 7:28 AM, I=F1aki Baz Castillo wrote: > 2011/11/13 Hadriel Kaplan : >> So long as the mechanisms needed to do so don't hurt WebRTC or force a s= pecific architectural model, why do you care? >=20 > Some telcos in this WG (and I could find exact mails) would accept > even if WebRTC uses a pure SIP stack. I'm not sure we have the same understanding of the word "telco". A "telco"= for me is a telephone-company/telecommunications provider/communications s= ervice provider (wireless, landline, cable MSOs, etc.). As far as I can te= ll, of the 482 members of this mailing list, there are about 32 with email = addresses that imply they work for "telcos", and none of them have advocate= d embedding a SIP stack in the browser. Lots of people on this mailing lis= t work for companies that sell products to "telco's", but most of them do n= ot advocate putting a SIP stack in the browser either.[1] Also I really think you're being unfair to people who work for telco's. I = have personally spoken off-line with several of the "telco's" that monitor = this mailing list, and all of them believed that whatever's needed to inter= work to non-WebRTC must not hurt/degrade WebRTC. For example most of them = actually *want* SRTP to be used, and even think ICE is needed. Of course t= hey would also prefer to be able to interface to WebRTC with as least cost/= complexity as possible, but they know it's not all going to be possible. > and all of them ask for non mandatory > SRTP. I don't think that's a fair assessment. I don't recall a single one of the= people who work for telco's ask for non-mandatory SRTP, and even if one di= d he/she does not represent "all of them". > Soon, they will also ask non mandatory ICE (they will argue "ICE > mandatory to implement in WebRTC client, but not mandatory to use"). > DTMF's via RTP is just the less important subject. What I care is all > the rest, But DTMF was the topic of the email. > and the fact that 75% of mails in this WG are about PSTN > legacy interoperability. No, they're not. 75% might be about SIP-related interoperability, but SIP = is not just the PSTN. The SRTP/RTP debate, for example, is not about the P= STN. The forking debate is not about the PSTN. The ICE and media consent = debates were about both PSTN and Enterprise SIP. The ROAP vs. real API deb= ate was not about the PSTN nor even SIP. The congestion control threads we= re not either. The TURN URI scheme thread is not about it. The data chann= el thread is not about it. ... -hadriel From juberti@google.com Sun Nov 13 06:24:40 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2673E21F8B67 for ; Sun, 13 Nov 2011 06:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.751 X-Spam-Level: X-Spam-Status: No, score=-102.751 tagged_above=-999 required=5 tests=[AWL=0.225, 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 93tRRMm74j8n for ; Sun, 13 Nov 2011 06:24:39 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2AF21F8B66 for ; Sun, 13 Nov 2011 06:24:39 -0800 (PST) Received: by iaeo4 with SMTP id o4so8014893iae.31 for ; Sun, 13 Nov 2011 06:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=C1CSZPTG6T6iAJiN0tkScE17eA4+AMve70nWB+6/4J4=; b=KQyfMkw4TXhIz/TiIiKb06nrwXbhRubFd7Et7FlhnWHuie1IxtpT04lBbVGaRbuG7C KJbEB40I2xegPrBEcfDA== Received: by 10.50.170.105 with SMTP id al9mr20285797igc.28.1321194280252; Sun, 13 Nov 2011 06:24:40 -0800 (PST) Received: by 10.50.170.105 with SMTP id al9mr20285788igc.28.1321194280124; Sun, 13 Nov 2011 06:24:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.34.4 with HTTP; Sun, 13 Nov 2011 06:24:18 -0800 (PST) In-Reply-To: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> From: Justin Uberti Date: Sun, 13 Nov 2011 09:24:18 -0500 Message-ID: To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=e89a8f3ba1fdbeff9e04b19e8304 X-System-Of-Record: true Cc: "" Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Sun, 13 Nov 2011 14:24:40 -0000 --e89a8f3ba1fdbeff9e04b19e8304 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Nov 13, 2011 at 7:02 AM, Hadriel Kaplan wro= te: > > On Nov 13, 2011, at 6:38 AM, I=C3=B1aki Baz Castillo wrote: > > > No, please, forget DTMF's. No more "SIP" nor "PSTN" in this WG. > > First, DMTFs aren't just about SIP - it's used by other protocols as well= . > But yes obviously it's about enabling WebRTC browsers to communicate with > non-WebRTC peers, including those in SIP, such as IVRs and voicemail > servers and so on - not just in "Telco's" but also in Enterprises. > > Some people in this WG don't want to worry about that, which is fine - > don't worry about it. If you don't want to use RFC4733, your > Javascript/Server code doesn't have to worry about it. But some people i= n > this WG *do* want to support interworking with other deployed > devices/domains. So long as the mechanisms needed to do so don't hurt > WebRTC or force a specific architectural model, why do you care? > As a non-"telco" participant in this WG, I strongly agree with this. DTMF has a clear upside (support for PSTN) and no downside other than the need for a new API method. --e89a8f3ba1fdbeff9e04b19e8304 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun, Nov 13, 2011 at 7:02 AM, Hadriel= Kaplan <HKa= plan@acmepacket.com> wrote:

On Nov 13, 2011, at 6:38 AM, I=C3=B1aki Baz Castillo wrote:

> No, please, forget DTMF's. No more "SIP" nor "PSTN&= quot; in this WG.

First, DMTFs aren't just about SIP - it's used by other proto= cols as well.
But yes obviously it's about enabling WebRTC browsers to communicate wi= th non-WebRTC peers, including those in SIP, such as IVRs and voicemail ser= vers and so on - not just in "Telco's" but also in Enterprise= s.

Some people in this WG don't want to worry about that, which is fine - = don't worry about it. =C2=A0If you don't want to use RFC4733, your = Javascript/Server code doesn't have to worry about it. =C2=A0But some p= eople in this WG *do* want to support interworking with other deployed devi= ces/domains. =C2=A0So long as the mechanisms needed to do so don't hurt= WebRTC or force a specific architectural model, why do you care?

As a non-"telco" participant in = this WG, I strongly agree with this. DTMF has a clear upside (support for P= STN) and no downside other than the need for a new API method.
--e89a8f3ba1fdbeff9e04b19e8304-- From csp@csperkins.org Sun Nov 13 08:04:56 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD3921F8B0D; Sun, 13 Nov 2011 08:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pl5pyTqUfgCE; Sun, 13 Nov 2011 08:04:55 -0800 (PST) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1C77A21F8B08; Sun, 13 Nov 2011 08:04:55 -0800 (PST) Received: from dhcp-4355.meeting.ietf.org ([130.129.67.85]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1RPcYB-0005yP-jH; Sun, 13 Nov 2011 16:04:55 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Colin Perkins In-Reply-To: <0B68D2E0-3480-47FB-8427-4032FD7B18F6@vidyo.com> Date: Mon, 14 Nov 2011 00:04:48 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111024232740.11885.97235.idtracker@ietfa.amsl.com> <462F77C3-8CAD-4699-9238-71B5C9EF7F9B@csperkins.org> <0B68D2E0-3480-47FB-8427-4032FD7B18F6@vidyo.com> To: Jonathan Lennox X-Mailer: Apple Mail (2.1251.1) Cc: "rtcweb@ietf.org" , IETF AVTCore WG Subject: Re: [rtcweb] I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 16:04:56 -0000 Jonathan, A more compelling argument for reporting from all SSRCs may be that = various AVPF and RTCP XR packets make no sense unless sent from the SSRC = corresponding to the correct media type. Sending just those, but not = regular RTCP reports, will cause havoc to the RTCP participant timeout = rules, and SSRC collision detection, unless you signal and heavily = special-case the code. This doesn't seem worth it, for tiny bandwidth = savings. Reporting on yourself is harder to defend, I agree, but the potential to = confuse monitoring equipment (and given the activity in XRBLOCK, someone = must care about that=85), and the additional signalling needed, again = seem to outweigh the bandwidth cost. Colin On 27 Oct 2011, at 23:57, Jonathan Lennox wrote: > Hi, Colin -- >=20 > Thanks for taking a look my draft! >=20 > I saw this recommendation in the multiplex-architecture draft, after I = finished my own (I didn't get a chance to read any other -00 drafts = before finishing my own before the deadline). >=20 > I think this is an AVTCore issue, so I'm following up there...further = discussion should probably just be on AVTCore, unless there are = WebRTC-specific issues. >=20 >=20 > The multiplexing-architecture draft in general is a very good draft -- = it's extremely thorough and useful -- but I admit to not being very = convinced by that section of it. >=20 > At small numbers of sources, self-reporting and cross-reporting does = indeed use a fairly small amount of bandwidth, but the problem is that = their bandwidth usage is quadratic in the number of sources, since every = source must report on every other. So as the number of sources grows, = they begin to consume all RTCP bandwidth sending redundant or trivial = information. >=20 > And this for the sake of third-party monitors, which (personally) I've = never seen deployed outside a research environment, and seem = architecturally dubious to me, at least for offer-answer negotiated = streams. (IPTV and other declarative-SDP architectures are probably = different.) >=20 > On Oct 27, 2011, at 11:12 AM, Colin Perkins wrote: >=20 >> Jonathan, >>=20 >> Thanks for submitting. This is a good draft. >>=20 >> One comment: Section 3.1 suggests that a source generating multiple = RTP streams, with multiple SSRCs, should not send RTCP reports for its = own media, and should pick a single SSRC to use when sending reports on = other media. I agree that this would save a small amount of bandwidth, = but I think the savings are negligible, it complicates the monitoring = model, and so is a mistake. We talk about this in = draft-westerlund-avtcore-multiplex-architecture-00 (Section 9, in = particular). >>=20 >> Cheers, >> Colin >=20 > -- > Jonathan Lennox > jonathan@vidyo.com >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From tim@phonefromhere.com Sun Nov 13 08:21:17 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8166821F8AF7 for ; Sun, 13 Nov 2011 08:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 xgdLnsWUvC3A for ; Sun, 13 Nov 2011 08:21:17 -0800 (PST) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 0036B21F8AF0 for ; Sun, 13 Nov 2011 08:21:16 -0800 (PST) Received: from [192.168.157.49] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id EC16937A902 for ; Sun, 13 Nov 2011 16:34:00 +0000 (GMT) From: Tim Panton Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Nov 2011 16:21:12 +0000 Message-Id: <1E272E30-843F-48E0-9FF4-C3C74A51635C@phonefromhere.com> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [rtcweb] Why this effort matters. X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Nov 2011 16:21:17 -0000 For any folks who doubt the importance of getting this right as a framework for innovation - I encourage you to watch this: = http://om.wordpress.com/2011/11/13/how-to-prepare-for-the-future-of-the-in= ternet-video/?utm_source=3Ddlvr.it&utm_medium=3Dtwitter Tim.= From miguelecasassanchez@gmail.com Sun Nov 13 10:46:58 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F86621F8477 for ; Sun, 13 Nov 2011 10:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.989 X-Spam-Level: X-Spam-Status: No, score=-2.989 tagged_above=-999 required=5 tests=[AWL=0.609, 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 DAh02-Fk+kDi for ; Sun, 13 Nov 2011 10:46:57 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 008A421F8481 for ; Sun, 13 Nov 2011 10:46:56 -0800 (PST) Received: by wyf28 with SMTP id 28so3859692wyf.31 for ; Sun, 13 Nov 2011 10:46:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x/WAM4/VThLxhJhWtugz1FvcdlsMtEdpQu3QLwEbkt4=; b=EL47N9QYg5jNpJtV4T4NmA1aXFiLtSuJCva3YKNKyJ66wqauHttynm3vT7rzUOXuyh IwPyKXToXA8fEAAHs9sabzZp2l8bqSW5er1M8xg6QqRkQ2dnS3b0saCkKApWW+HPRfJE ausTAkurnoBR5oyyk1gIqyUbfxEtG4LFz4EUI= MIME-Version: 1.0 Received: by 10.216.134.93 with SMTP id r71mr3491750wei.59.1321210017676; Sun, 13 Nov 2011 10:46:57 -0800 (PST) Received: by 10.216.89.142 with HTTP; Sun, 13 Nov 2011 10:46:57 -0800 (PST) Received: by 10.216.89.142 with HTTP; Sun, 13 Nov 2011 10:46:57 -0800 (PST) In-Reply-To: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> Date: Sun, 13 Nov 2011 19:46:57 +0100 Message-ID: From: Miguel Casas-Sanchez To: Justin Uberti Content-Type: multipart/alternative; boundary=00504502c85ec6fe5d04b1a22dc5 Cc: "<,rtcweb@ietf.org>," Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Sun, 13 Nov 2011 18:46:58 -0000 --00504502c85ec6fe5d04b1a22dc5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =C4=B0t is indeed very interesting to have interoperability with loads of systems, but that should (personal opinion) be left to the applications, and not be suggested in a standard that everyone will need to parse. So: keep standard lean would be my vote (=3Dleave dtmf out) try and focus on mandatory and really nice-to-have features. Miguel On Nov 13, 2011 3:24 p.m., "Justin Uberti" wrote: > > > On Sun, Nov 13, 2011 at 7:02 AM, Hadriel Kaplan w= rote: > >> >> On Nov 13, 2011, at 6:38 AM, I=C3=B1aki Baz Castillo wrote: >> >> > No, please, forget DTMF's. No more "SIP" nor "PSTN" in this WG. >> >> First, DMTFs aren't just about SIP - it's used by other protocols as wel= l. >> But yes obviously it's about enabling WebRTC browsers to communicate wit= h >> non-WebRTC peers, including those in SIP, such as IVRs and voicemail >> servers and so on - not just in "Telco's" but also in Enterprises. >> >> Some people in this WG don't want to worry about that, which is fine - >> don't worry about it. If you don't want to use RFC4733, your >> Javascript/Server code doesn't have to worry about it. But some people = in >> this WG *do* want to support interworking with other deployed >> devices/domains. So long as the mechanisms needed to do so don't hurt >> WebRTC or force a specific architectural model, why do you care? >> > > As a non-"telco" participant in this WG, I strongly agree with this. DTMF > has a clear upside (support for PSTN) and no downside other than the need > for a new API method. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --00504502c85ec6fe5d04b1a22dc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=C4=B0t is indeed very interesting to have interoperability with loads o= f systems, but that should (personal opinion) be left to the applications, = and not be suggested in a standard that everyone will need to parse. So: ke= ep standard lean would be my vote (=3Dleave dtmf out) try and focus on mand= atory and really nice-to-have features.
Miguel

On Nov 13, 2011 3:24 p.m., "Justin Uberti&q= uot; <juberti@google.com> w= rote:


On Sun, Nov 13, 2011 at 7:02 AM, Hadriel= Kaplan <HKaplan@acmepacket.com> wrote:

On Nov 13, 2011, at 6:38 AM, I=C3=B1aki Baz Castillo wrote:

> No, please, forget DTMF's. No more "SIP" nor "PSTN&= quot; in this WG.

First, DMTFs aren't just about SIP - it's used by other proto= cols as well.
But yes obviously it's about enabling WebRTC browsers to communicate wi= th non-WebRTC peers, including those in SIP, such as IVRs and voicemail ser= vers and so on - not just in "Telco's" but also in Enterprise= s.

Some people in this WG don't want to worry about that, which is fine - = don't worry about it. =C2=A0If you don't want to use RFC4733, your = Javascript/Server code doesn't have to worry about it. =C2=A0But some p= eople in this WG *do* want to support interworking with other deployed devi= ces/domains. =C2=A0So long as the mechanisms needed to do so don't hurt= WebRTC or force a specific architectural model, why do you care?

As a non-"telco" participant in = this WG, I strongly agree with this. DTMF has a clear upside (support for P= STN) and no downside other than the need for a new API method.

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

--00504502c85ec6fe5d04b1a22dc5-- From jonathan@vidyo.com Sun Nov 13 13:17:22 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A5021F86AA; Sun, 13 Nov 2011 13:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 ngfromaUYmvO; Sun, 13 Nov 2011 13:17:21 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 738A321F86A6; Sun, 13 Nov 2011 13:17:21 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C09E27A2D0A; Sun, 13 Nov 2011 16:17:16 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 49E4E7A2D34; Sun, 13 Nov 2011 16:17:16 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Sun, 13 Nov 2011 16:17:15 -0500 From: Jonathan Lennox To: Colin Perkins Date: Sun, 13 Nov 2011 16:17:13 -0500 Thread-Topic: [rtcweb] I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt Thread-Index: AcyiHfyR6IKAmjCsQHKJtY3bzl7hTQAKqtYg Message-ID: References: <20111024232740.11885.97235.idtracker@ietfa.amsl.com> <462F77C3-8CAD-4699-9238-71B5C9EF7F9B@csperkins.org> <0B68D2E0-3480-47FB-8427-4032FD7B18F6@vidyo.com> 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: "rtcweb@ietf.org" , IETF AVTCore WG Subject: Re: [rtcweb] I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 21:17:22 -0000 Colin, I believe this would work under the logic I describe in media-type-mux: you= still send RR or SR packets for every source, you just treat your sources = other than the reporting source as though they're "disconnected" receivers,= i.e. don't include redundant reports in their SRs/RRs. The number of SR/RR packets is linear in the number of sources in a session= -- it's the number of reports that's quadratic, and thus problematic. If there's a need for some XR reports to choose a reporting source that has= the same media type as the source being reported on, that should be fine. -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org]=20 Sent: Monday, November 14, 2011 12:05 AM To: Jonathan Lennox Cc: rtcweb@ietf.org; IETF AVTCore WG Subject: Re: [rtcweb] I-D Action: draft-lennox-rtcweb-rtp-media-type-mux-00= .txt Jonathan, A more compelling argument for reporting from all SSRCs may be that various= AVPF and RTCP XR packets make no sense unless sent from the SSRC correspon= ding to the correct media type. Sending just those, but not regular RTCP re= ports, will cause havoc to the RTCP participant timeout rules, and SSRC col= lision detection, unless you signal and heavily special-case the code. This= doesn't seem worth it, for tiny bandwidth savings. Reporting on yourself is harder to defend, I agree, but the potential to co= nfuse monitoring equipment (and given the activity in XRBLOCK, someone must= care about that...), and the additional signalling needed, again seem to o= utweigh the bandwidth cost. Colin On 27 Oct 2011, at 23:57, Jonathan Lennox wrote: > Hi, Colin -- >=20 > Thanks for taking a look my draft! >=20 > I saw this recommendation in the multiplex-architecture draft, after I fi= nished my own (I didn't get a chance to read any other -00 drafts before fi= nishing my own before the deadline). >=20 > I think this is an AVTCore issue, so I'm following up there...further dis= cussion should probably just be on AVTCore, unless there are WebRTC-specifi= c issues. >=20 >=20 > The multiplexing-architecture draft in general is a very good draft -- it= 's extremely thorough and useful -- but I admit to not being very convinced= by that section of it. >=20 > At small numbers of sources, self-reporting and cross-reporting does inde= ed use a fairly small amount of bandwidth, but the problem is that their ba= ndwidth usage is quadratic in the number of sources, since every source mus= t report on every other. So as the number of sources grows, they begin to c= onsume all RTCP bandwidth sending redundant or trivial information. >=20 > And this for the sake of third-party monitors, which (personally) I've ne= ver seen deployed outside a research environment, and seem architecturally = dubious to me, at least for offer-answer negotiated streams. (IPTV and othe= r declarative-SDP architectures are probably different.) >=20 > On Oct 27, 2011, at 11:12 AM, Colin Perkins wrote: >=20 >> Jonathan, >>=20 >> Thanks for submitting. This is a good draft. >>=20 >> One comment: Section 3.1 suggests that a source generating multiple RTP = streams, with multiple SSRCs, should not send RTCP reports for its own medi= a, and should pick a single SSRC to use when sending reports on other media= . I agree that this would save a small amount of bandwidth, but I think the= savings are negligible, it complicates the monitoring model, and so is a m= istake. We talk about this in draft-westerlund-avtcore-multiplex-architectu= re-00 (Section 9, in particular). >>=20 >> Cheers, >> Colin >=20 > -- > Jonathan Lennox > jonathan@vidyo.com >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From petithug@acm.org Sun Nov 13 14:50:08 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9097921F8B04 for ; Sun, 13 Nov 2011 14:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.625 X-Spam-Level: X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, NO_RELAYS=-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 mysb0D7mrL0E for ; Sun, 13 Nov 2011 14:50:07 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 93EFD21F8B01 for ; Sun, 13 Nov 2011 14:50:07 -0800 (PST) Received: from [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6] (unknown [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id BAEEF20138; Sun, 13 Nov 2011 22:40:30 +0000 (UTC) Message-ID: <4EC04998.9070300@acm.org> Date: Sun, 13 Nov 2011 17:50:00 -0500 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15 MIME-Version: 1.0 To: Miguel Casas-Sanchez References: <4EBC3475.90706@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "<,rtcweb@ietf.org>," Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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: Sun, 13 Nov 2011 22:50:08 -0000 On 11/13/2011 01:46 PM, Miguel Casas-Sanchez wrote: > İt is indeed very interesting to have interoperability with loads of systems, > but that should (personal opinion) be left to the applications, and not be > suggested in a standard that everyone will need to parse. So: keep standard lean > would be my vote (=leave dtmf out) try and focus on mandatory and really > nice-to-have features. > Miguel I do not know why you and others are singling out DTMF. I am no fan of building stuff around carriers needs myself, but DTMF is a codec, no more, no less. Even the fast codec switching mechanism is not special - comfort noise use it too, and a system that would recognize music and dynamically switch between audio and MIDI would probably be considered innovative. > > On Nov 13, 2011 3:24 p.m., "Justin Uberti" > wrote: > > > > On Sun, Nov 13, 2011 at 7:02 AM, Hadriel Kaplan > wrote: > > > On Nov 13, 2011, at 6:38 AM, Iñaki Baz Castillo wrote: > > > No, please, forget DTMF's. No more "SIP" nor "PSTN" in this WG. > > First, DMTFs aren't just about SIP - it's used by other protocols as well. > But yes obviously it's about enabling WebRTC browsers to communicate > with non-WebRTC peers, including those in SIP, such as IVRs and > voicemail servers and so on - not just in "Telco's" but also in Enterprises. > > Some people in this WG don't want to worry about that, which is fine - > don't worry about it. If you don't want to use RFC4733, your > Javascript/Server code doesn't have to worry about it. But some people > in this WG *do* want to support interworking with other deployed > devices/domains. So long as the mechanisms needed to do so don't hurt > WebRTC or force a specific architectural model, why do you care? > > > As a non-"telco" participant in this WG, I strongly agree with this. DTMF > has a clear upside (support for PSTN) and no downside other than the need > for a new API method. > > _______________________________________________ > 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 -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From mary.ietf.barnes@gmail.com Sun Nov 13 23:39:19 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F027D11E8190; Sun, 13 Nov 2011 23:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.174 X-Spam-Level: X-Spam-Status: No, score=-103.174 tagged_above=-999 required=5 tests=[AWL=0.425, 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 zMli7c0VtLm1; Sun, 13 Nov 2011 23:39:17 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F03411E8165; Sun, 13 Nov 2011 23:39:12 -0800 (PST) Received: by vcbfk1 with SMTP id fk1so5676223vcb.31 for ; Sun, 13 Nov 2011 23:39:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=aRlTjEvx7WhMRN7pRziCIYTrcKIsMe2bWz9UgZLV/CE=; b=OgP2JjM8dK0D0nCLN6cVo9KZEzJlubK8pOz4PGgU12WgO9KUkMJv2EnoorxEEVnqQN DVhrfZQoFVul3FZ+7Jv/IR3BSsmmhu7wyD8EJGEiyds5Wqch5DDtx06xtuTI+i4kGNVX eVwbTmdg2yG9dJGLdldO1m+Lf9caXKXaIAEI0= MIME-Version: 1.0 Received: by 10.52.65.176 with SMTP id y16mr33614532vds.53.1321256349525; Sun, 13 Nov 2011 23:39:09 -0800 (PST) Received: by 10.52.175.131 with HTTP; Sun, 13 Nov 2011 23:39:09 -0800 (PST) Date: Mon, 14 Nov 2011 01:39:09 -0600 Message-ID: From: Mary Barnes To: CLUE , rtcweb@ietf.org, avtcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] CLUE/RTCWEB adhoc - RTP requirements/usages for multi-stream X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Nov 2011 07:39:19 -0000 Hello CLUE, RTCWEB and AVTCORE WG members, Per the discussion in the CLUE WG session this morning, an adhoc is planned on Thursday, 11:40-12:50 (room TBA) to discuss requirements and usages of RTP for multi-stream for CLUE and RTCWEB. Note, this also relates to the discussion today in AVTCORE around multiplexing. A proposed agenda has been appended to the CLUE WG agenda for IETF-82: http://www.ietf.org/proceedings/82/agenda/clue.html Note since the meeting is during lunch, the secretariat is arranging for us to have one of the rooms that allows food, although please consider the note about outside food: http://www.ietf.org/meeting/82/things-to-note.html I will post a note with the room to the mailing list (and update the agenda) as soon as I have the information. Regards, Mary and Ted (as chairs for the adhoc) From tim@phonefromhere.com Mon Nov 14 00:30:53 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A3121F8D71 for ; Mon, 14 Nov 2011 00:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlZaKDKPXMyo for ; Mon, 14 Nov 2011 00:30:52 -0800 (PST) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1FD21F8D70 for ; Mon, 14 Nov 2011 00:30:51 -0800 (PST) Received: from [10.161.77.185] (unknown [212.183.132.77]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 44BD037A902; Mon, 14 Nov 2011 08:43:29 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Tim Panton In-Reply-To: <4EC04998.9070300@acm.org> Date: Mon, 14 Nov 2011 08:30:40 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <47BA59C6-6827-4E03-AF79-251403925334@phonefromhere.com> References: <4EBC3475.90706@alvestrand.no> <4EC04998.9070300@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.1251.1) Cc: Miguel Casas-Sanchez , "<, rtcweb@ietf.org>, " Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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, 14 Nov 2011 08:30:53 -0000 On 13 Nov 2011, at 22:50, Marc Petit-Huguenin wrote: > On 11/13/2011 01:46 PM, Miguel Casas-Sanchez wrote: >> =C4=B0t is indeed very interesting to have interoperability with = loads of systems, >> but that should (personal opinion) be left to the applications, and = not be >> suggested in a standard that everyone will need to parse. So: keep = standard lean >> would be my vote (=3Dleave dtmf out) try and focus on mandatory and = really >> nice-to-have features. >> Miguel >=20 > I do not know why you and others are singling out DTMF. I am no fan = of building > stuff around carriers needs myself, but DTMF is a codec, no more, no = less. Even > the fast codec switching mechanism is not special - comfort noise use = it too, > and a system that would recognize music and dynamically switch between = audio and > MIDI would probably be considered innovative. Which gives further weight to my argument that we should be exposing the = codec as a javascript object , the we could have a generic 'notification from = this codec instance' callback, instead of doing all these legacy hacks as one-off special = cases. Tim.= From oscar.ohlsson@ericsson.com Mon Nov 14 00:36:18 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CDE21F8DB7 for ; Mon, 14 Nov 2011 00:36:18 -0800 (PST) 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 4UFFhNuYTYjZ for ; Mon, 14 Nov 2011 00:36:17 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 28ADD21F8DB6 for ; Mon, 14 Nov 2011 00:36:16 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-a5-4ec0d2ff0ba8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EE.2E.13753.FF2D0CE4; Mon, 14 Nov 2011 09:36:15 +0100 (CET) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.198]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 14 Nov 2011 09:36:15 +0100 From: Oscar Ohlsson To: Eric Rescorla Date: Mon, 14 Nov 2011 09:36:13 +0100 Thread-Topic: Regarding the assertion mechanism in the new security draft Thread-Index: AcygkUmAUf6KuCOmRvqUz79XUI8r/ACFxEQw Message-ID: References: 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== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding the assertion mechanism in the new security 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, 14 Nov 2011 08:36:18 -0000 I had a slightly different scenario in mind when I was posing the question.= Say that I have several client certificates (issued by some CA) installed = in my browser and I want to use one of them to authenticate myself in WebRT= C. Would I then also need to sign the ROAP session ID using this certificat= e? If not, what is the difference between a CA issued certifcate and self-s= igned certificate whose fingerprint is asserted through BrowserID? Regards, Oscar Ohlsson=20 > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com]=20 > Sent: den 11 november 2011 17:45 > To: Oscar Ohlsson > Cc: rtcweb@ietf.org > Subject: Re: Regarding the assertion mechanism in the new=20 > security draft >=20 > On Fri, Nov 11, 2011 at 7:42 AM, Oscar Ohlsson=20 > wrote: > > Eric, > > > > I read through your latest security draft and I found the=20 > the assertion mechanism described in the Appendix very=20 > interesting. One thing I didn't quite understand though is=20 > why the ROAP session ID needs to be included in the=20 > assertion. As far as I can tell you only need to assert the=20 > fingerprint. I would appreciate if you could explain your=20 > reasoning here. >=20 > Thanks! >=20 > I should probably admit at this point that I haven't done a=20 > complete security analysis of the assertion-based system, so=20 > exactly what fields need to be signed is, I think a bit of an=20 > open question. I tried to make the level of maturity clear in=20 > my draft, but I'm not certain I did. >=20 > With that said, my theory there was that it would be a good=20 > idea to cryptographically bind the assertion to this specific=20 > session rather than just to the identity in general. > This prevents replay style attacks. However, as you suggest,=20 > it's not entirely clear how one would go about mounting such=20 > an attack without simultaneously controlling enough keying=20 > material so you could do anything. Do you see a downside to=20 > signing this data? >=20 > Best, > -Ekr > = From harald@alvestrand.no Mon Nov 14 00:38:32 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8803C21F8DF8 for ; Mon, 14 Nov 2011 00:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.199 X-Spam-Level: X-Spam-Status: No, score=-110.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 SFfMWQHvRrBg for ; Mon, 14 Nov 2011 00:38:31 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1330F21F8DF6 for ; Mon, 14 Nov 2011 00:38:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2E7BF39E0CD for ; Mon, 14 Nov 2011 09:38:24 +0100 (CET) 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 siVcT5o5gRLo for ; Mon, 14 Nov 2011 09:38:23 +0100 (CET) Received: from [192.168.147.22] (unknown [72.14.229.194]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 2458E39E074 for ; Mon, 14 Nov 2011 09:38:22 +0100 (CET) Message-ID: <4EC0D37B.9020207@alvestrand.no> Date: Mon, 14 Nov 2011 16:38:19 +0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4EBC3475.90706@alvestrand.no> <4EC04998.9070300@acm.org> <47BA59C6-6827-4E03-AF79-251403925334@phonefromhere.com> In-Reply-To: <47BA59C6-6827-4E03-AF79-251403925334@phonefromhere.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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, 14 Nov 2011 08:38:32 -0000 On 11/14/2011 04:30 PM, Tim Panton wrote: > On 13 Nov 2011, at 22:50, Marc Petit-Huguenin wrote: > >> On 11/13/2011 01:46 PM, Miguel Casas-Sanchez wrote: >>> İt is indeed very interesting to have interoperability with loads of systems, >>> but that should (personal opinion) be left to the applications, and not be >>> suggested in a standard that everyone will need to parse. So: keep standard lean >>> would be my vote (=leave dtmf out) try and focus on mandatory and really >>> nice-to-have features. >>> Miguel >> I do not know why you and others are singling out DTMF. I am no fan of building >> stuff around carriers needs myself, but DTMF is a codec, no more, no less. Even >> the fast codec switching mechanism is not special - comfort noise use it too, >> and a system that would recognize music and dynamically switch between audio and >> MIDI would probably be considered innovative. > Which gives further weight to my argument that we should be exposing the codec > as a javascript object , the we could have a generic 'notification from this codec instance' > callback, instead of doing all these legacy hacks as one-off special cases. what would the codec object represent? The currently proposed API presents a MediaStreamTrack object. How would a codec object relate to the MediaStreamTrack object? (this is an api discussion, so probably belongs on the W3C list) Harald From neils@vipadia.com Mon Nov 14 00:39:05 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D5E21F8E03 for ; Mon, 14 Nov 2011 00:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[AWL=0.064, 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 qHiHPYIxfUs4 for ; Mon, 14 Nov 2011 00:39:04 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8511E21F8E01 for ; Mon, 14 Nov 2011 00:39:04 -0800 (PST) Received: by iaeo4 with SMTP id o4so9023049iae.31 for ; Mon, 14 Nov 2011 00:39:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.20.201 with SMTP id g9mr4960759ibb.57.1321259943710; Mon, 14 Nov 2011 00:39:03 -0800 (PST) Sender: neils@vipadia.com Received: by 10.231.207.10 with HTTP; Mon, 14 Nov 2011 00:39:03 -0800 (PST) In-Reply-To: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> Date: Mon, 14 Nov 2011 08:39:03 +0000 X-Google-Sender-Auth: cPrLZ8l6XLjR3G5-qQKX3ir5hWM Message-ID: From: Neil Stratford To: Justin Uberti Content-Type: multipart/alternative; boundary=0015175ce0d899d01e04b1adcdb8 Cc: "" Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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, 14 Nov 2011 08:39:05 -0000 --0015175ce0d899d01e04b1adcdb8 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Nov 13, 2011 at 2:24 PM, Justin Uberti wrote: > > As a non-"telco" participant in this WG, I strongly agree with this. DTMF > has a clear upside (support for PSTN) and no downside other than the need > for a new API method. > This is my concern, that we are proposing a codec specific API method when we have ruled out exposing APIs for other codecs. If two peers have negotiated a data channel between them it doesn't make a lot of sense to send DTMF over RTP, it should be carried over the reliable data channel. So if we do expose an API for sending tones, can it be done in such a way that it can be carried using whatever the most appropriate transport is? (obviously without requiring any javascript changes - because we can't expect javascript developers to upgrade) Neil --0015175ce0d899d01e04b1adcdb8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Nov 13, 2011 at 2:24 PM, Justin Uberti <= span dir=3D"ltr"><juberti@google.c= om> wrote:

As a= non-"telco" participant in this WG, I strongly agree with this. = DTMF has a clear upside (support for PSTN) and no downside other than the n= eed for a new API method.

This is my concern, that we are proposing a cod= ec specific API method when we have ruled out exposing APIs for other codec= s.

If two peers have negotiated a data channel bet= ween them it doesn't make a lot of sense to send DTMF over RTP, it shou= ld be carried over the reliable data channel. So if we do expose an API for= sending tones, can it be done in such a way that it can be carried using w= hatever the most appropriate transport is? (obviously without requiring any= javascript changes - because we can't expect javascript developers to = upgrade)

Neil
--0015175ce0d899d01e04b1adcdb8-- From ekr@rtfm.com Mon Nov 14 00:42:09 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDD321F8E38 for ; Mon, 14 Nov 2011 00:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.937 X-Spam-Level: X-Spam-Status: No, score=-102.937 tagged_above=-999 required=5 tests=[AWL=0.040, 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 2p4K0tp6Ps6z for ; Mon, 14 Nov 2011 00:42:08 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B42A21F8E32 for ; Mon, 14 Nov 2011 00:42:08 -0800 (PST) Received: by ggnr5 with SMTP id r5so695089ggn.31 for ; Mon, 14 Nov 2011 00:42:08 -0800 (PST) Received: by 10.146.72.7 with SMTP id u7mr2513670yaa.9.1321260128071; Mon, 14 Nov 2011 00:42:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.146.88.36 with HTTP; Mon, 14 Nov 2011 00:41:26 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Mon, 14 Nov 2011 00:41:26 -0800 Message-ID: To: Oscar Ohlsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Regarding the assertion mechanism in the new security 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, 14 Nov 2011 08:42:09 -0000 On Mon, Nov 14, 2011 at 12:36 AM, Oscar Ohlsson wrote: > I had a slightly different scenario in mind when I was posing the questio= n. Say that I have several client certificates (issued by some CA) installe= d in my browser and I want to use one of them to authenticate myself in Web= RTC. Would I then also need to sign the ROAP session ID using this certific= ate? If not, what is the difference between a CA issued certifcate and self= -signed certificate whose fingerprint is asserted through BrowserID? I would assume that whatever mechanism you had for generating assertions would have them cover the same data values. I.e., I'm not yet ready to commit on whether we need the session ID, but presumably it should always be covered or not. -Ekr From juberti@google.com Mon Nov 14 01:17:35 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BB021F84D8 for ; Mon, 14 Nov 2011 01:17:28 -0800 (PST) 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 3C4UpoPTMgod for ; Mon, 14 Nov 2011 01:17:24 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CD91C21F8E91 for ; Mon, 14 Nov 2011 01:15:26 -0800 (PST) Received: by iaeo4 with SMTP id o4so9061690iae.31 for ; Mon, 14 Nov 2011 01:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=TIVfEVavQvMmo4Ha6roramLxLBgWTbu3QYCPSGgyV3s=; b=gt1Ydr6o1YqtdAo5z4fS5l2xKX6rADnub7DgHrzivwogvEGdIbxk75/WFPsGrTVcSK cF9jwewFGSozKRAcrAcg== Received: by 10.231.69.146 with SMTP id z18mr5089757ibi.79.1321262055274; Mon, 14 Nov 2011 01:14:15 -0800 (PST) Received: by 10.231.69.146 with SMTP id z18mr5089750ibi.79.1321262055122; Mon, 14 Nov 2011 01:14:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.194.134 with HTTP; Mon, 14 Nov 2011 01:13:54 -0800 (PST) In-Reply-To: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> From: Justin Uberti Date: Mon, 14 Nov 2011 04:13:54 -0500 Message-ID: To: Neil Stratford Content-Type: multipart/alternative; boundary=0015176f10da73666f04b1ae4bb7 X-System-Of-Record: true Cc: "" Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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, 14 Nov 2011 09:17:35 -0000 --0015176f10da73666f04b1ae4bb7 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 14, 2011 at 3:39 AM, Neil Stratford wrote: > On Sun, Nov 13, 2011 at 2:24 PM, Justin Uberti wrote: > >> >> As a non-"telco" participant in this WG, I strongly agree with this. DTMF >> has a clear upside (support for PSTN) and no downside other than the need >> for a new API method. >> > > This is my concern, that we are proposing a codec specific API method when > we have ruled out exposing APIs for other codecs. > > If two peers have negotiated a data channel between them it doesn't make a > lot of sense to send DTMF over RTP, it should be carried over the reliable > data channel. So if we do expose an API for sending tones, can it be done > in such a way that it can be carried using whatever the most appropriate > transport is? (obviously without requiring any javascript changes - because > we can't expect javascript developers to upgrade) > > If two peers have negotiated a data channel, it doesn't make sense to use DTMF at all. I can see the converse argument to make the DataStream API use DTMF if it is the only thing available, in order to avoid adding a DTMF-specific API, but I think the semantics are different enough that the DTMF API is a better approach. Regarding whether this API should be extended to be a generic codec API, I think it should be obvious that the ability to send one of 12 well-defined signals in a standardized manner is orders of magnitude simpler than the configuration options available for modern video codecs. --0015176f10da73666f04b1ae4bb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Nov 14, 2011 at 3:39 AM, Neil St= ratford <neils@belltower.co.uk> wrote:
On Sun, Nov 13, 2011 at 2:24 PM, Justin Ube= rti <juberti@google.com> wrote:

As a non-"te= lco" participant in this WG, I strongly agree with this. DTMF has a cl= ear upside (support for PSTN) and no downside other than the need for a new= API method.

This is my concern, that we are proposing= a codec specific API method when we have ruled out exposing APIs for other= codecs.

If two peers have negotiated a data chann= el between them it doesn't make a lot of sense to send DTMF over RTP, i= t should be carried over the reliable data channel. So if we do expose an A= PI for sending tones, can it be done in such a way that it can be carried u= sing whatever the most appropriate transport is? (obviously without requiri= ng any javascript changes - because we can't expect javascript develope= rs to upgrade)


If two peers = have negotiated a data channel, it doesn't make sense to use DTMF at al= l. I can see the converse argument to make the DataStream API use DTMF if i= t is the only thing available, in order to avoid adding a DTMF-specific API= , but I think the semantics are different enough that the DTMF API is a bet= ter approach.

Regarding whether this API should be extended to be a g= eneric codec API, I think it should be obvious that the ability to send one= of 12 well-defined signals in a standardized manner is orders of magnitude= simpler than the configuration options available for modern video codecs.<= /div>

--0015176f10da73666f04b1ae4bb7-- From wolfgang.beck01@googlemail.com Mon Nov 14 01:35:17 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD85E21F8F0C for ; Mon, 14 Nov 2011 01:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 uKkfFS5dHeIz for ; Mon, 14 Nov 2011 01:35:13 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEAF21F8F10 for ; Mon, 14 Nov 2011 01:35:11 -0800 (PST) Received: by ggnr5 with SMTP id r5so742755ggn.31 for ; Mon, 14 Nov 2011 01:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iTu5Y+WeeRmLTYbxV/uhINl8mE/WIeTaqFP2ASrVUrQ=; b=d92nUc5RG+QY1B3fiN5ZQAtEaToZ5SlrwK7DTV1jdKdq9eDOSXKiBx80u9X0TNbGPW W2MO5CP+NH9rLmNbV7TIF4hrAQ0njRBYE9kwicwHleDYvIno2nG9UInVLgTwM+LS3E8W xZY7o+zGBPTQaxifX+LougjWQg/fO0qtbMOco= MIME-Version: 1.0 Received: by 10.68.38.169 with SMTP id h9mr48431617pbk.113.1321263310651; Mon, 14 Nov 2011 01:35:10 -0800 (PST) Received: by 10.68.64.66 with HTTP; Mon, 14 Nov 2011 01:35:10 -0800 (PST) In-Reply-To: <4EAF64FF.8020101@jesup.org> References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> Date: Mon, 14 Nov 2011 17:35:10 +0800 Message-ID: From: Wolfgang Beck To: Randell Jesup Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 09:35:19 -0000 Is rtcweb-data protocol only usable if both browsers use the same JS client? If not, how is the content of the data stream -- the 'codec' -- negotiated between the different JS clients? ROAP will not work as it is the JS clients which writes to the data stream. The ROAP component of the browser doesn't know what's in there. rtcweb-data will only work across different servers if you have standardized the datastream's content. However, if we dropped the server-to-server interworking requirement, rtcweb-data would be a good base for exciting applications. Wolfgang Beck From ibc@aliax.net Mon Nov 14 01:59:14 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB6D21F8B18 for ; Mon, 14 Nov 2011 01:59:09 -0800 (PST) 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.039, 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 AskP6+XzT7rr for ; Mon, 14 Nov 2011 01:59:08 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C36BE21F8B1F for ; Mon, 14 Nov 2011 01:55:34 -0800 (PST) Received: by vws5 with SMTP id 5so5870102vws.31 for ; Mon, 14 Nov 2011 01:53:38 -0800 (PST) Received: by 10.52.65.36 with SMTP id u4mr33605844vds.58.1321264418151; Mon, 14 Nov 2011 01:53:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Mon, 14 Nov 2011 01:53:17 -0800 (PST) In-Reply-To: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 14 Nov 2011 10:53:17 +0100 Message-ID: To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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, 14 Nov 2011 09:59:18 -0000 2011/11/13 Hadriel Kaplan : >> 2011/11/13 Hadriel Kaplan : >>> So long as the mechanisms needed to do so don't hurt WebRTC or force a = specific architectural model, why do you care? >> >> Some telcos in this WG (and I could find exact mails) would accept >> even if WebRTC uses a pure SIP stack. > > I'm not sure we have the same understanding of the word "telco". =C2=A0A = "telco" for me is a telephone-company/telecommunications provider/communica= tions service provider (wireless, landline, cable MSOs, etc.). =C2=A0As far= as I can tell, of the 482 members of this mailing list, there are about 32= with email addresses that imply they work for "telcos", and none of them h= ave advocated embedding a SIP stack in the browser. =C2=A0Lots of people on= this mailing list work for companies that sell products to "telco's", but = most of them do not advocate putting a SIP stack in the browser either.[1] Ok, let me say that with the world "telco" I include telephony/telecommunications companies, telephony vendors (phones, PBXs, SBCs, gateways, softswitches...) and anyone with real interest in interoperability with existing SIP and/or PSTN networks. > Also I really think you're being unfair to people who work for telco's. = =C2=A0I have personally spoken off-line with several of the "telco's" that = monitor this mailing list, and all of them believed that whatever's needed = to interwork to non-WebRTC must not hurt/degrade WebRTC. =C2=A0For example = most of them actually *want* SRTP to be used, and even think ICE is needed.= =C2=A0Of course they would also prefer to be able to interface to WebRTC w= ith as least cost/complexity as possible, but they know it's not all going = to be possible. My concern is that 75% of the traffic in this maillist is about making WebRTC capable to accomplish with SIP/PSTN requirements. And that is not so bad, but what is really bad is that there is no more. Nobody is proposing things that are currently unfeasible with SIP, so we are limiting the posibilities of WebRTC to those provided by SIP protocol. The vision/scope of WebRTC is currently limited to what SIP provides. I would like to hear proposals that are out of the scope of the pure telephony, but those proposals won't came from telcos (see the "definition" above) since telcos have never succeeded in the Web. >> Soon, they will also ask non mandatory ICE (they will argue "ICE >> mandatory to implement in WebRTC client, but not mandatory to use"). >> DTMF's via RTP is just the less important subject. What I care is all >> the rest, > > But DTMF was the topic of the email. RTP/SRTP is unreliable so sending like-reliable information (DTMF's) over an unreliable stream is, for sure, not the best design. In WebRTC such reliable info could be sent over signaling or over the data-channel (both of them reliable). Why to choose the worst option? reply: to interoperate with existing VoIP protocols. >> and the fact that 75% of mails in this WG are about PSTN >> legacy interoperability. > > No, they're not. =C2=A075% might be about SIP-related interoperability, b= ut SIP is not just the PSTN. =C2=A0The SRTP/RTP debate, for example, is not= about the PSTN. The SRTP/RTP debate is about interoperability with PSTN or SIP networks, isn't it? The best argument I've read is "upgrading telco's devices is too expensive so plain RTP is desired". SRTP is cheap and easy to implement in a fresh deployment. Mandating SRTP has not the same inplications as mandating HTTPS (server certificates and so) so those arguments about "HTTPS is not mandatory so neither SRTP" are just a good excuse IMHO. >The forking debate is not about the PSTN. =C2=A0The ICE and media consent = debates were about both PSTN and Enterprise SIP. =C2=A0The ROAP vs. real AP= I debate was not about the PSTN nor even SIP. =C2=A0The congestion control = threads were not either. =C2=A0The TURN URI scheme thread is not about it. = =C2=A0The data channel thread is not about it. =C2=A0... Well, let's see what happens. I still think that we need some crazy pure Web folks in this WG (not too much or we'll have proposals about using port TCP 80 for sending RTP). ;) Regards. --=20 I=C3=B1aki Baz Castillo From neils@vipadia.com Mon Nov 14 02:16:35 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438E721F8CCB for ; Mon, 14 Nov 2011 02:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=0.060, 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 ssTg3e7H9y42 for ; Mon, 14 Nov 2011 02:16:34 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62A9B21F84F5 for ; Mon, 14 Nov 2011 02:16:34 -0800 (PST) Received: by iaeo4 with SMTP id o4so9130754iae.31 for ; Mon, 14 Nov 2011 02:16:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.20.201 with SMTP id g9mr5034857ibb.57.1321265793804; Mon, 14 Nov 2011 02:16:33 -0800 (PST) Sender: neils@vipadia.com Received: by 10.231.207.10 with HTTP; Mon, 14 Nov 2011 02:16:33 -0800 (PST) In-Reply-To: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> Date: Mon, 14 Nov 2011 10:16:33 +0000 X-Google-Sender-Auth: VzylS_-EJCkPa1bgruDmF_eJVIk Message-ID: From: Neil Stratford To: Justin Uberti Content-Type: multipart/alternative; boundary=0015175ce0d84b2b5c04b1af2a00 Cc: "" Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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, 14 Nov 2011 10:16:35 -0000 --0015175ce0d84b2b5c04b1af2a00 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 14, 2011 at 9:13 AM, Justin Uberti wrote: > > On Mon, Nov 14, 2011 at 3:39 AM, Neil Stratford wrote: > >> On Sun, Nov 13, 2011 at 2:24 PM, Justin Uberti wrote: >> >>> >>> As a non-"telco" participant in this WG, I strongly agree with this. >>> DTMF has a clear upside (support for PSTN) and no downside other than the >>> need for a new API method. >>> >> >> This is my concern, that we are proposing a codec specific API method >> when we have ruled out exposing APIs for other codecs. >> >> If two peers have negotiated a data channel between them it doesn't make >> a lot of sense to send DTMF over RTP, it should be carried over the >> reliable data channel. So if we do expose an API for sending tones, can it >> be done in such a way that it can be carried using whatever the most >> appropriate transport is? (obviously without requiring any javascript >> changes - because we can't expect javascript developers to upgrade) >> >> > If two peers have negotiated a data channel, it doesn't make sense to use > DTMF at all. > If a WebRTC capable media server is relaying media to the PSTN you may still want to signal some kind of DTMF between the client and the media server for onward relay. If the data channel is available, why not use it for DTMF? Should the DTMF API only be for RFC4733 and not any other transport? > Regarding whether this API should be extended to be a generic codec API, I > think it should be obvious that the ability to send one of 12 well-defined > signals in a standardized manner is orders of magnitude simpler than the > configuration options available for modern video codecs. > I still see a benefit in exposing codec parameters, and in providing codecs with the ability to generate events. Imagine I was building an n-way video conference solution based on a scalable video codec, with a central point transrating each stream based on the active speaker. Receiving codec events in the javascript would enable me to detect rate changes and re-render the display appropriately without requiring a full renegotiation each time. Neil --0015175ce0d84b2b5c04b1af2a00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Nov 14, 2011 at 9:13 AM, Justin = Uberti <juberti@= google.com> wrote:
On Mon, Nov 14= , 2011 at 3:39 AM, Neil Stratford <neils@belltower.co.uk> wrote:
On Sun, Nov 13, 2011 at 2:24 PM, Justin Ube= rti <juberti@google.com> wrote:

As a non-"te= lco" participant in this WG, I strongly agree with this. DTMF has a cl= ear upside (support for PSTN) and no downside other than the need for a new= API method.

This is my concern, that we are proposing= a codec specific API method when we have ruled out exposing APIs for other= codecs.

If two peers have negotiated a data chann= el between them it doesn't make a lot of sense to send DTMF over RTP, i= t should be carried over the reliable data channel. So if we do expose an A= PI for sending tones, can it be done in such a way that it can be carried u= sing whatever the most appropriate transport is? (obviously without requiri= ng any javascript changes - because we can't expect javascript develope= rs to upgrade)


I= f two peers have negotiated a data channel, it doesn't make sense to us= e DTMF at all.
=A0
If a WebRTC capa= ble media server is relaying media to the PSTN you may still want to signal= some kind of DTMF between the client and the media server for onward relay= . If the data channel is available, why not use it for DTMF?=A0Should the D= TMF API only be for RFC4733 and not any other transport?
=A0
Regarding whether this API should be extended to be a generic= codec API, I think it should be obvious that the ability to send one of 12= well-defined signals in a standardized manner is orders of magnitude simpl= er than the configuration options available for modern video codecs.

I still see a benefit in exposing co= dec parameters, and in providing codecs with the ability to generate events= . Imagine I was building an n-way video conference solution based on a scal= able video codec, with a central point transrating each stream based on the= active speaker. Receiving codec events in the javascript would enable me t= o detect rate changes and re-render the display appropriately without requi= ring a full renegotiation each time.

Neil
--0015175ce0d84b2b5c04b1af2a00-- From harald@alvestrand.no Mon Nov 14 02:23:10 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F252E21F8AFF for ; Mon, 14 Nov 2011 02:23:09 -0800 (PST) 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=[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 UGfYWn3iU5h2 for ; Mon, 14 Nov 2011 02:23:09 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8235221F8446 for ; Mon, 14 Nov 2011 02:23:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C2E4B39E0CD; Mon, 14 Nov 2011 11:23:07 +0100 (CET) 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 Z+PMQZvdPgWc; Mon, 14 Nov 2011 11:23:07 +0100 (CET) Received: from [130.129.22.244] (dhcp-16f4.meeting.ietf.org [130.129.22.244]) by eikenes.alvestrand.no (Postfix) with ESMTPS id DFBD539E074; Mon, 14 Nov 2011 11:23:05 +0100 (CET) Message-ID: <4EC0EC06.7020701@alvestrand.no> Date: Mon, 14 Nov 2011 18:23:02 +0800 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4EBC3475.90706@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: [rtcweb] Traffic on the list (Re: Traffic should be encrypted. (Re: Let's define the purpose of 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, 14 Nov 2011 10:23:10 -0000 On 11/14/2011 05:53 PM, Iñaki Baz Castillo wrote: > > My concern is that 75% of the traffic in this maillist is about making > WebRTC capable to accomplish with SIP/PSTN requirements. And that is > not so bad, but what is really bad is that there is no more. Inaki, out of the last 903 messages on the list, 151 of them (approximately 1 of 6) were written by you. Many, many of your messages are about SIP. Perhaps if you did not talk so much about SIP, there would be more room for the "other stuff" that you miss so much? Harald From wolfgang.beck01@googlemail.com Mon Nov 14 02:37:18 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1270B21F8D3A for ; Mon, 14 Nov 2011 02:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.936 X-Spam-Level: X-Spam-Status: No, score=-2.936 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 pA7uN+2AnMjk for ; Mon, 14 Nov 2011 02:37:17 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 622A421F8CE0 for ; Mon, 14 Nov 2011 02:37:17 -0800 (PST) Received: by ggnr5 with SMTP id r5so802448ggn.31 for ; Mon, 14 Nov 2011 02:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jqsxFu99Kh6fL/ZVP+zis1HB5nCUg/ve1BWCPa8CnaY=; b=v7N5hgtbryfNG4Vq9W1mnePWm9lX89vn0QgBsi/NbFCu32XCz6tT4M6Oao1VMFwgNn cPoqGfsY2TaxEXPPFwHUNBJef1gHiE1maufNUhdfnSL764FJMkZO+2nfJDyfdrAlVxuz qbNxHs74vNlw75l5tgpLIVHEEln9x/FHH9kzw= MIME-Version: 1.0 Received: by 10.68.120.230 with SMTP id lf6mr12119252pbb.96.1321267036596; Mon, 14 Nov 2011 02:37:16 -0800 (PST) Received: by 10.68.64.66 with HTTP; Mon, 14 Nov 2011 02:37:16 -0800 (PST) In-Reply-To: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> Date: Mon, 14 Nov 2011 18:37:16 +0800 Message-ID: From: Wolfgang Beck To: "" Content-Type: text/plain; charset=ISO-8859-1 Subject: [rtcweb] Fwd: Traffic should be encrypted. (Re: Let's define the purpose of 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, 14 Nov 2011 10:37:18 -0000 If I recall this correctly, the DTMF payload type was made for a specific scenario: 1. an analogue phone is connected to a (SIP) device 2. the user presses a key on her phone during a call. 3. The device detects the tone generated by the phone. Relaying it out of band with some SIP message can lead to undesired effects: a bit of the DTMF might have escaped the SIP device, was sent as G.711, and was detected by the remote PSTN party. Now if the SIP message (eg INFO) arrives and gets translated by a SIP-PSTN gateway into a DTMF tone, the remote party will see two DTMF events instead of one. The DTMF payload solves this. As long as we don't want to attach POTS phones to the browser, outband signalling of events should be sufficient. If we do connect POTS lines to the browser, we have to talk about fax as well. Thankfully, modem ports have disappeared from today's laptops and PCs. Wolfgang Beck From juberti@google.com Mon Nov 14 02:40:19 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A3611E8140 for ; Mon, 14 Nov 2011 02:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.864 X-Spam-Level: X-Spam-Status: No, score=-102.864 tagged_above=-999 required=5 tests=[AWL=0.113, 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 HYj3AMUaDhe6 for ; Mon, 14 Nov 2011 02:40:19 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC5A411E812C for ; Mon, 14 Nov 2011 02:40:18 -0800 (PST) Received: by iaeo4 with SMTP id o4so9157262iae.31 for ; Mon, 14 Nov 2011 02:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=VO2uhuGOQ+f5+2wCf9ngLhU/85zSXJBX43McI30aYm4=; b=s65a1VB0tSeJDUt2FBBr1L0xAgOKyKd4lPd56ioJ8jPoJ4evA8yy5Bi6ZOYKJrev9U YNhPbMunhFMuRNxjPFCw== Received: by 10.231.9.10 with SMTP id j10mr5092355ibj.53.1321267218354; Mon, 14 Nov 2011 02:40:18 -0800 (PST) Received: by 10.231.9.10 with SMTP id j10mr5092347ibj.53.1321267218189; Mon, 14 Nov 2011 02:40:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.194.134 with HTTP; Mon, 14 Nov 2011 02:39:57 -0800 (PST) In-Reply-To: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> From: Justin Uberti Date: Mon, 14 Nov 2011 05:39:57 -0500 Message-ID: To: Neil Stratford Content-Type: multipart/alternative; boundary=00151773e7e2318e9904b1af7f7e X-System-Of-Record: true Cc: "" Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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, 14 Nov 2011 10:40:20 -0000 --00151773e7e2318e9904b1af7f7e Content-Type: text/plain; charset=UTF-8 On Mon, Nov 14, 2011 at 5:16 AM, Neil Stratford wrote: > > > On Mon, Nov 14, 2011 at 9:13 AM, Justin Uberti wrote: >> >> On Mon, Nov 14, 2011 at 3:39 AM, Neil Stratford wrote: >> >>> On Sun, Nov 13, 2011 at 2:24 PM, Justin Uberti wrote: >>> >>>> >>>> As a non-"telco" participant in this WG, I strongly agree with this. >>>> DTMF has a clear upside (support for PSTN) and no downside other than the >>>> need for a new API method. >>>> >>> >>> This is my concern, that we are proposing a codec specific API method >>> when we have ruled out exposing APIs for other codecs. >>> >>> If two peers have negotiated a data channel between them it doesn't make >>> a lot of sense to send DTMF over RTP, it should be carried over the >>> reliable data channel. So if we do expose an API for sending tones, can it >>> be done in such a way that it can be carried using whatever the most >>> appropriate transport is? (obviously without requiring any javascript >>> changes - because we can't expect javascript developers to upgrade) >>> >>> >> If two peers have negotiated a data channel, it doesn't make sense to use >> DTMF at all. >> > > If a WebRTC capable media server is relaying media to the PSTN you may > still want to signal some kind of DTMF between the client and the media > server for onward relay. If the data channel is available, why not use it > for DTMF? > Why represent the DTMF in an alternate format, when the only thing that cares about it wants it in RFC 4733? > Should the DTMF API only be for RFC4733 and not any other transport? > That's my thinking. > > >> Regarding whether this API should be extended to be a generic codec API, >> I think it should be obvious that the ability to send one of 12 >> well-defined signals in a standardized manner is orders of magnitude >> simpler than the configuration options available for modern video codecs. >> > > I still see a benefit in exposing codec parameters, and in providing > codecs with the ability to generate events. Imagine I was building an n-way > video conference solution based on a scalable video codec, with a central > point transrating each stream based on the active speaker. Receiving codec > events in the javascript would enable me to detect rate changes and > re-render the display appropriately without requiring a full renegotiation > each time. > It's not hard for me to imagine that scenario, but I don't understand how a codec API is needed to allow UI relayout on stream resolution change. > > Neil > --00151773e7e2318e9904b1af7f7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Nov 14, 2011 at 5:16 AM, Neil St= ratford <neil= s@belltower.co.uk> wrote:


On Mon, Nov 14, 2011 a= t 9:13 AM, Justin Uberti <juberti@google.com> wrote:
On Mon, Nov 14, 2011 at 3:3= 9 AM, Neil Stratford <neils@belltower.co.uk> wrote:
On Sun, Nov 13, 2011 at 2:24 PM, Justin Ube= rti <juberti@google.com> wrote:

As a non-"te= lco" participant in this WG, I strongly agree with this. DTMF has a cl= ear upside (support for PSTN) and no downside other than the need for a new= API method.

This is my concern, that we are proposing= a codec specific API method when we have ruled out exposing APIs for other= codecs.

If two peers have negotiated a data chann= el between them it doesn't make a lot of sense to send DTMF over RTP, i= t should be carried over the reliable data channel. So if we do expose an A= PI for sending tones, can it be done in such a way that it can be carried u= sing whatever the most appropriate transport is? (obviously without requiri= ng any javascript changes - because we can't expect javascript develope= rs to upgrade)


I= f two peers have negotiated a data channel, it doesn't make sense to us= e DTMF at all.
=C2=A0
If a We= bRTC capable media server is relaying media to the PSTN you may still want = to signal some kind of DTMF between the client and the media server for onw= ard relay. If the data channel is available, why not use it for DTMF?

Why represent the DTMF in an alterna= te format, when the only thing that cares about it wants it in RFC 4733?
=C2=A0
=C2=A0Should the DTMF API only be for RFC47= 33 and not any other transport?

That's my thinking.=C2=A0
=C2=A0
=
Regarding whether this API should be extended to be a gener= ic codec API, I think it should be obvious that the ability to send one of = 12 well-defined signals in a standardized manner is orders of magnitude sim= pler than the configuration options available for modern video codecs.

I still see a benefit in expos= ing codec parameters, and in providing codecs with the ability to generate = events. Imagine I was building an n-way video conference solution based on = a scalable video codec, with a central point transrating each stream based = on the active speaker. Receiving codec events in the javascript would enabl= e me to detect rate changes and re-render the display appropriately without= requiring a full renegotiation each time.

It's not hard for me to imagine = that scenario, but I don't understand how a codec API is needed to allo= w UI relayout on stream resolution change.=C2=A0

Neil

--00151773e7e2318e9904b1af7f7e-- From juberti@google.com Mon Nov 14 02:42:58 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835FD11E8184 for ; Mon, 14 Nov 2011 02:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.886 X-Spam-Level: X-Spam-Status: No, score=-102.886 tagged_above=-999 required=5 tests=[AWL=0.090, 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 9r3Nfyj2lcFH for ; Mon, 14 Nov 2011 02:42:58 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D27D311E8182 for ; Mon, 14 Nov 2011 02:42:57 -0800 (PST) Received: by iaeo4 with SMTP id o4so9160295iae.31 for ; Mon, 14 Nov 2011 02:42:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Mp/HFQjS4V4RI6bwCBeNg0f5HW8g0vxZ+/ka9h14DJc=; b=t2CFzorO+1k0lO7B7zU9tGovWyPWOO/bKe4CoThr6nnUURJMEo1A7WzLZXY13tY4Jy x0Gj9sUST88qF+ihpOhQ== Received: by 10.50.100.194 with SMTP id fa2mr18229544igb.49.1321267377519; Mon, 14 Nov 2011 02:42:57 -0800 (PST) Received: by 10.50.100.194 with SMTP id fa2mr18229520igb.49.1321267377141; Mon, 14 Nov 2011 02:42:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.194.134 with HTTP; Mon, 14 Nov 2011 02:42:36 -0800 (PST) In-Reply-To: References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> From: Justin Uberti Date: Mon, 14 Nov 2011 05:42:36 -0500 Message-ID: To: Wolfgang Beck Content-Type: multipart/alternative; boundary=e89a8f3ba4d5aaf77a04b1af88c6 X-System-Of-Record: true Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] New Version Notification for draft-jesup-rtcweb-data-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 10:42:58 -0000 --e89a8f3ba4d5aaf77a04b1af88c6 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 14, 2011 at 4:35 AM, Wolfgang Beck < wolfgang.beck01@googlemail.com> wrote: > Is rtcweb-data protocol only usable if both browsers use the same JS > client? No. > If not, how is the content of the data stream -- the 'codec' > -- negotiated between the different JS clients? ROAP will not work as > it is the JS clients which writes to the data stream. The ROAP > component of the browser doesn't know what's in there. > The format of the data stream will be standardized. > > rtcweb-data will only work across different servers if you have > standardized the datastream's content. > Agree. > > However, if we dropped the server-to-server interworking requirement, > rtcweb-data would be a good base for exciting applications. > I agree the data channel will result in exciting applications, regardless of s2s interworking. > > > Wolfgang Beck > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --e89a8f3ba4d5aaf77a04b1af88c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Nov 14, 2011 at 4:35 AM, Wolfgan= g Beck <wolfgang.beck01@googlemail.com> wrote:
Is rtcweb-data protocol only usable if both browsers use the same JS
client?

No.=C2=A0
=C2=A0
If not, how is the content of the data stream= -- the 'codec'
-- negotiated between the different JS clients? ROAP will not work as
it is the JS clients which writes to the data stream. The ROAP
component of the browser doesn't know what's in there.

The format of the data stream will be standardized.= =C2=A0

rtcweb-data will only work across different servers if you have
standardized the datastream's content.

<= div>Agree.=C2=A0

However, if we dropped the server-to-server interworking requirement,
rtcweb-data would be a good base for exciting applications.

I agree the data channel will result in exciting appli= cations, regardless of s2s interworking.


Wolfgang Beck
_____________________= __________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--e89a8f3ba4d5aaf77a04b1af88c6-- From neils@vipadia.com Mon Nov 14 02:50:59 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBCD1F0C43 for ; Mon, 14 Nov 2011 02:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.056, 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 2XSopevMfWpm for ; Mon, 14 Nov 2011 02:50:58 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4461F0C34 for ; Mon, 14 Nov 2011 02:50:58 -0800 (PST) Received: by iaeo4 with SMTP id o4so9169100iae.31 for ; Mon, 14 Nov 2011 02:50:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.160.161 with SMTP id xl1mr22935546igb.5.1321267857714; Mon, 14 Nov 2011 02:50:57 -0800 (PST) Sender: neils@vipadia.com Received: by 10.231.207.10 with HTTP; Mon, 14 Nov 2011 02:50:57 -0800 (PST) In-Reply-To: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> Date: Mon, 14 Nov 2011 10:50:57 +0000 X-Google-Sender-Auth: E7xaysrJxmpB5NgI8od_I44veTI Message-ID: From: Neil Stratford To: Justin Uberti Content-Type: multipart/alternative; boundary=14dae93409554fef9b04b1afa5b9 Cc: "" Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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, 14 Nov 2011 10:50:59 -0000 --14dae93409554fef9b04b1afa5b9 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 14, 2011 at 10:39 AM, Justin Uberti wrote: > On Mon, Nov 14, 2011 at 5:16 AM, Neil Stratford wrote: > >> On Mon, Nov 14, 2011 at 9:13 AM, Justin Uberti wrote: >>> >>> On Mon, Nov 14, 2011 at 3:39 AM, Neil Stratford wrote: >>> >>>> On Sun, Nov 13, 2011 at 2:24 PM, Justin Uberti wrote: >>>> >>>>> >>>>> As a non-"telco" participant in this WG, I strongly agree with this. >>>>> DTMF has a clear upside (support for PSTN) and no downside other than the >>>>> need for a new API method. >>>>> >>>> >>>> This is my concern, that we are proposing a codec specific API method >>>> when we have ruled out exposing APIs for other codecs. >>>> >>>> If two peers have negotiated a data channel between them it doesn't >>>> make a lot of sense to send DTMF over RTP, it should be carried over the >>>> reliable data channel. So if we do expose an API for sending tones, can it >>>> be done in such a way that it can be carried using whatever the most >>>> appropriate transport is? (obviously without requiring any javascript >>>> changes - because we can't expect javascript developers to upgrade) >>>> >>>> >>> If two peers have negotiated a data channel, it doesn't make sense to >>> use DTMF at all. >>> >> >> If a WebRTC capable media server is relaying media to the PSTN you may >> still want to signal some kind of DTMF between the client and the media >> server for onward relay. If the data channel is available, why not use it >> for DTMF? >> > > Why represent the DTMF in an alternate format, when the only thing that > cares about it wants it in RFC 4733? > Only a SIP destination endpoint would want it in RFC 4733, a PSTN endpoint is going to want it in-band in the media stream, which the relaying media server from WebRTC to PSTN would likely do. (No SIP here.) > Should the DTMF API only be for RFC4733 and not any other transport? >> > > That's my thinking. > >> >> >>> Regarding whether this API should be extended to be a generic codec API, >>> I think it should be obvious that the ability to send one of 12 >>> well-defined signals in a standardized manner is orders of magnitude >>> simpler than the configuration options available for modern video codecs. >>> >> >> I still see a benefit in exposing codec parameters, and in providing >> codecs with the ability to generate events. Imagine I was building an n-way >> video conference solution based on a scalable video codec, with a central >> point transrating each stream based on the active speaker. Receiving codec >> events in the javascript would enable me to detect rate changes and >> re-render the display appropriately without requiring a full renegotiation >> each time. >> > > It's not hard for me to imagine that scenario, but I don't understand how > a codec API is needed to allow UI relayout on stream resolution change. > How today am I notified of a quality or resolution change in the decoded incoming video stream? What I want to avoid is the use of an external signalling mechanism to tell me this, so I can avoid the glitchy resize-before-ready - I want to do it when the data really is at the new resolution. > > Neil --14dae93409554fef9b04b1afa5b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Nov 14, 2011 at 10:39 AM, Justin Uberti <juberti@google.com> wrote:
On Mon, Nov 14, 2011 at 5:16 A= M, Neil Stratford <neils@belltower.co.uk> wrote:
On Mon, Nov 14, 2011 at 9:13 AM, Justin Ube= rti <juberti@google.com> wrote:
On Mon, Nov 14, 2011 at 3:3= 9 AM, Neil Stratford <neils@belltower.co.uk> wrote:
On Sun, Nov 13, 2011 at 2:24 PM, Justin Ube= rti <juberti@google.com> wrote:

As a non-"te= lco" participant in this WG, I strongly agree with this. DTMF has a cl= ear upside (support for PSTN) and no downside other than the need for a new= API method.

This is my concern, that we are proposing= a codec specific API method when we have ruled out exposing APIs for other= codecs.

If two peers have negotiated a data chann= el between them it doesn't make a lot of sense to send DTMF over RTP, i= t should be carried over the reliable data channel. So if we do expose an A= PI for sending tones, can it be done in such a way that it can be carried u= sing whatever the most appropriate transport is? (obviously without requiri= ng any javascript changes - because we can't expect javascript develope= rs to upgrade)


I= f two peers have negotiated a data channel, it doesn't make sense to us= e DTMF at all.
=A0
If a WebRT= C capable media server is relaying media to the PSTN you may still want to = signal some kind of DTMF between the client and the media server for onward= relay. If the data channel is available, why not use it for DTMF?

Why represent the DTMF in an a= lternate format, when the only thing that cares about it wants it in RFC 47= 33?

Only a SIP destination endp= oint would want it in RFC 4733, a PSTN endpoint is going to want it in-band= in the media stream, which the relaying media server from WebRTC to PSTN w= ould likely do. (No SIP here.)
=A0
=A0Should the DTMF API only be for RFC4733 = and not any other transport?

<= div>That's my thinking.=A0
=A0
Regarding whether this API should be extended to be a generic = codec API, I think it should be obvious that the ability to send one of 12 = well-defined signals in a standardized manner is orders of magnitude simple= r than the configuration options available for modern video codecs.

I still see a benefit in expos= ing codec parameters, and in providing codecs with the ability to generate = events. Imagine I was building an n-way video conference solution based on = a scalable video codec, with a central point transrating each stream based = on the active speaker. Receiving codec events in the javascript would enabl= e me to detect rate changes and re-render the display appropriately without= requiring a full renegotiation each time.

It's not hard for me to im= agine that scenario, but I don't understand how a codec API is needed t= o allow UI relayout on stream resolution change.=A0

How today am I notified of a quality or resolution chan= ge in the decoded incoming video stream? What I want to avoid is the use of= an external signalling mechanism to tell me this, so I can avoid the glitc= hy resize-before-ready - I want to do it when the data really is at the new= resolution.
=A0
Neil --14dae93409554fef9b04b1afa5b9-- From juberti@google.com Mon Nov 14 03:07:43 2011 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD1611E81E0 for ; Mon, 14 Nov 2011 03:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=0.075, 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 xNnFDHaZb8Df for ; Mon, 14 Nov 2011 03:07:42 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0036411E811C for ; Mon, 14 Nov 2011 03:07:40 -0800 (PST) Received: by iaeo4 with SMTP id o4so9186889iae.31 for ; Mon, 14 Nov 2011 03:07:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=WPVicENPi0w/bWADBa+EN7+mu9SUtZNpEGBmgnVSLoI=; b=adpOXhi5bI0pcD6SFg8ggQ+Ey/znOhZfZg8MqK6KTaKDFnjgtiTMgPSqg9vP1RYpML BJ8ZhnfIleCw1Z3oitjA== Received: by 10.42.72.135 with SMTP id o7mr22410570icj.45.1321268860647; Mon, 14 Nov 2011 03:07:40 -0800 (PST) Received: by 10.42.72.135 with SMTP id o7mr22410561icj.45.1321268860497; Mon, 14 Nov 2011 03:07:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.194.134 with HTTP; Mon, 14 Nov 2011 03:07:19 -0800 (PST) In-Reply-To: References: <5454E693-5C34-4C77-BA07-2A9EE9EE4AFD@cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01349FFE@inba-mail01.sonusnet.com> <1D062974A4845E4D8A343C653804920206D3B7FD@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C0134A105@inba-mail01.sonusnet.com> <1F2A2C70609D9E41844A2126145FC09804691DA2@HKGMBOXPRD22.polycom.com> <1D062974A4845E4D8A343C653804920206D3BA57@XMB-BGL-414.cisco.com> <4EBC3475.90706@alvestrand.no> From: Justin Uberti Date: Mon, 14 Nov 2011 06:07:19 -0500 Message-ID: To: Neil Stratford Content-Type: multipart/alternative; boundary=90e6ba6e87d0152f0904b1afe196 X-System-Of-Record: true Cc: "" Subject: Re: [rtcweb] Traffic should be encrypted. (Re: Let's define the purpose of 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, 14 Nov 2011 11:07:43 -0000 --90e6ba6e87d0152f0904b1afe196 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 14, 2011 at 5:50 AM, Neil Stratford wrote: > On Mon, Nov 14, 2011 at 10:39 AM, Justin Uberti wrote: > >> On Mon, Nov 14, 2011 at 5:16 AM, Neil Stratford wrote: >> >>> On Mon, Nov 14, 2011 at 9:13 AM, Justin Uberti wrote: >>>> >>>> On Mon, Nov 14, 2011 at 3:39 AM, Neil Stratford wrote: >>>> >>>>> On Sun, Nov 13, 2011 at 2:24 PM, Justin Uberti wrote: >>>>> >>>>>> >>>>>> As a non-"telco" participant in this WG, I strongly agree with this. >>>>>> DTMF has a clear upside (support for PSTN) and no downside other than the >>>>>> need for a new API method. >>>>>> >>>>> >>>>> This is my concern, that we are proposing a codec specific API method >>>>> when we have ruled out exposing APIs for other codecs. >>>>> >>>>> If two peers have negotiated a data channel between them it doesn't >>>>> make a lot of sense to send DTMF over RTP, it should be carried over the >>>>> reliable data channel. So if we do expose an API for sending tones, can it >>>>> be done in such a way that it can be carried using whatever the most >>>>> appropriate transport is? (obviously without requiring any javascript >>>>> changes - because we can't expect javascript developers to upgrade) >>>>> >>>>> >>>> If two peers have negotiated a data channel, it doesn't make sense to >>>> use DTMF at all. >>>> >>> >>> If a WebRTC capable media server is relaying media to the PSTN you may >>> still want to signal some kind of DTMF between the client and the media >>> server for onward relay. If the data channel is available, why not use it >>> for DTMF? >>> >> >> Why represent the DTMF in an alternate format, when the only thing that >> cares about it wants it in RFC 4733? >> > > Only a SIP destination endpoint would want it in RFC 4733, a PSTN endpoint > is going to want it in-band in the media stream, which the relaying media > server from WebRTC to PSTN would likely do. (No SIP here.) > This is a RTP thing, not a SIP thing. The PSTN gateway will take RTP as input, including RFC 4733 telephone-event. > >> Should the DTMF API only be for RFC4733 and not any other transport? >>> >> >> That's my thinking. >> >>> >>> >>>> Regarding whether this API should be extended to be a generic codec >>>> API, I think it should be obvious that the ability to send one of 12 >>>> well-defined signals in a standardized manner is orders of magnitude >>>> simpler than the configuration options available for modern video codecs. >>>> >>> >>> I still see a benefit in exposing codec parameters, and in providing >>> codecs with the ability to generate events. Imagine I was building an n-way >>> video conference solution based on a scalable video codec, with a central >>> point transrating each stream based on the active speaker. Receiving codec >>> events in the javascript would enable me to detect rate changes and >>> re-render the display appropriately without requiring a full renegotiation >>> each time. >>> >> >> It's not hard for me to imagine that scenario, but I don't understand how >> a codec API is needed to allow UI relayout on stream resolution change. >> > > How today am I notified of a quality or resolution change in the decoded > incoming video stream? What I want to avoid is the use of an external > signalling mechanism to tell me this, so I can avoid the glitchy > resize-before-ready - I want to do it when the data really is at the new > resolution. > Agreed. The