From internet-drafts@ietf.org Thu Sep 1 04:19: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 74A1721F8BB3; Thu, 1 Sep 2011 04:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.353 X-Spam-Level: X-Spam-Status: No, score=-102.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 pelIMXWEJoXf; Thu, 1 Sep 2011 04:19:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A6721F8B8D; Thu, 1 Sep 2011 04:19:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110901111933.7153.76292.idtracker@ietfa.amsl.com> Date: Thu, 01 Sep 2011 04:19:33 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 11:19:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : Web Real-Time Communication Use-cases and Requirements Author(s) : Christer Holmberg Stefan Hakansson Goran AP Eriksson Filename : draft-ietf-rtcweb-use-cases-and-requirements-04.txt Pages : 19 Date : 2011-09-01 This document describes web based real-time communication use-cases. Based on the use-cases, the document also derives requirements related to the browser, and the API used by web applications to request and control media stream services provided by the browser. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-require= ments-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-requirem= ents-04.txt From christer.holmberg@ericsson.com Thu Sep 1 04:21: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 2B4B521F85F2 for ; Thu, 1 Sep 2011 04:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scPE01yShkLA for ; Thu, 1 Sep 2011 04:21:39 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0431021F85F1 for ; Thu, 1 Sep 2011 04:21:38 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-12-4e5f6b1d8fbe Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AE.48.02839.D1B6F5E4; Thu, 1 Sep 2011 13:23:09 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 1 Sep 2011 13:23:08 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Date: Thu, 1 Sep 2011 13:23:06 +0200 Thread-Topic: Symmetric RTP and uni-directional media streams Thread-Index: AcxomYV8muHlGwn7Tpe2Zvqda7t9+A== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233DD0AC8@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852233DD0AC8ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Symmetric RTP and uni-directional media streams X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Sep 2011 11:21:40 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852233DD0AC8ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There has been much talk about the usage of symmetric RTP. Also, draft-perk= ins-rtcweb-rtp-usage suggests that symmetric RTP is required. However, the PeerConnection API currently only supports the establishment o= f uni-directional streams, so for a single two way communication one needs = to create two separate uni-directional streams. So, I assume that one requirement from RTCWEB to W3C will be to add support= of the establishment of bi-directional streams to the PeerConnection API. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05852233DD0AC8ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
There has been much t= alk about the usage of symmetric RTP. Also, draft-perkins-rtcweb-rtp-usage = suggests that symmetric RTP is required.
 
However, the PeerConn= ection API currently only supports the establishment of uni-directional str= eams, so for a single two way communication one needs to create two separat= e uni-directional streams.
 
So, I assume that one= requirement from RTCWEB to W3C will be to add support of the establishment= of bi-directional streams to the PeerConnection API.
 
Regards,
 
Christer
 
 
 --_000_7F2072F1E0DE894DA4B517B93C6A05852233DD0AC8ESESSCMS0356e_-- From stefan.lk.hakansson@ericsson.com Thu Sep 1 04:21: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 4AAFB21F8B13 for ; Thu, 1 Sep 2011 04:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.317 X-Spam-Level: X-Spam-Status: No, score=-6.317 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 rWxvbkOlq+9s for ; Thu, 1 Sep 2011 04:21: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 7D61F21F85F1 for ; Thu, 1 Sep 2011 04:21:51 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-59-4e5f6b2b807a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F9.58.02839.B2B6F5E4; Thu, 1 Sep 2011 13:23:23 +0200 (CEST) Received: from [150.132.141.36] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Thu, 1 Sep 2011 13:23:23 +0200 Message-ID: <4E5F6B2A.9010002@ericsson.com> Date: Thu, 1 Sep 2011 13:23:22 +0200 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <20110901111933.7153.36351.idtracker@ietfa.amsl.com> In-Reply-To: <20110901111933.7153.36351.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110901111933.7153.36351.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb-use-cases-and-requirements-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 11:21:52 -0000 FYI. From the change log: Changes from draft-ietf-rtcweb-use-cases-and-requirements-03 o Editorials o Changed when the self-view is displayed in 4.2.1.1, and added words about allowing users to remove and re-insert it. o Clarified 4.2.6.1 o Removed the "mono" stuff from 4.2.7.1 o Added that communication should not be possible to eavesdrop to most use cases - and req. F17 o Re-phrased 4.3.3.1 to not describe the technical solution so much, and removed "stereo" stuff. Solution possibilities are now in a note. o Re-inserted API requirements after discussion in the W3C webrtc WG. (Re-phrased A15 and added A18 compared to version -02). Stefan -------- Original Message -------- Subject: New Version Notification for draft-ietf-rtcweb-use-cases-and-requirements-04.txt Date: Thu, 1 Sep 2011 13:19:33 +0200 From: internet-drafts@ietf.org To: Stefan Håkansson LK CC: Stefan Håkansson LK , Göran Eriksson AP , Christer Holmberg A new version of I-D, draft-ietf-rtcweb-use-cases-and-requirements-04.txt has been successfully submitted by Stefan Hakansson and posted to the IETF repository. Filename: draft-ietf-rtcweb-use-cases-and-requirements Revision: 04 Title: Web Real-Time Communication Use-cases and Requirements Creation date: 2011-09-01 WG ID: rtcweb Number of pages: 19 Abstract: This document describes web based real-time communication use-cases. Based on the use-cases, the document also derives requirements related to the browser, and the API used by web applications to request and control media stream services provided by the browser. The IETF Secretariat From harald@alvestrand.no Thu Sep 1 04:29: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 3419621F8A51 for ; Thu, 1 Sep 2011 04:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.898 X-Spam-Level: X-Spam-Status: No, score=-106.898 tagged_above=-999 required=5 tests=[AWL=3.700, 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 Lu2psQB+pW-H for ; Thu, 1 Sep 2011 04:29:26 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 466FF21F85F6 for ; Thu, 1 Sep 2011 04:29:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CE06739E173; Thu, 1 Sep 2011 13:29:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aT6P0EBRjjPX; Thu, 1 Sep 2011 13:29:41 +0200 (CEST) Received: from [172.16.41.131] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 9E51C39E08B; Thu, 1 Sep 2011 13:29:40 +0200 (CEST) Message-ID: <4E5F6CEF.6020203@alvestrand.no> Date: Thu, 01 Sep 2011 13:30:55 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852233DD0AC8@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233DD0AC8@ESESSCMS0356.eemea.ericsson.se> Content-Type: multipart/alternative; boundary="------------000306030108030702070403" Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Symmetric RTP and uni-directional media streams X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Sep 2011 11:29:27 -0000 This is a multi-part message in MIME format. --------------000306030108030702070403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/01/11 13:23, Christer Holmberg wrote: > Hi, > There has been much talk about the usage of symmetric RTP. Also, > draft-perkins-rtcweb-rtp-usage suggests that symmetric RTP is required. > However, the PeerConnection API currently only supports the > establishment of uni-directional streams, so for a single two way > communication one needs to create two separate uni-directional streams. > So, I assume that one requirement from RTCWEB to W3C will be to add > support of the establishment of bi-directional streams to the > PeerConnection API. To be precise: I think (and we're implementing) that between two PeerConnections, there will be a small number of *RTP sessions* (ideally one). These will be bidirectional. These will be used for transporting any number of *MediaStreams* (a WEBRTC API concept), each of which corresponds to a CNAME (RTP protocol concept). These are unidirectional. So the right answer is "yes" and "no", as far as I can see. > Regards, > Christer > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------000306030108030702070403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09/01/11 13:23, Christer Holmberg wrote:
 
Hi,
 
There has been much talk about the usage of symmetric RTP. Also, draft-perkins-rtcweb-rtp-usage suggests that symmetric RTP is required.
 
However, the PeerConnection API currently only supports the establishment of uni-directional streams, so for a single two way communication one needs to create two separate uni-directional streams.
 
So, I assume that one requirement from RTCWEB to W3C will be to add support of the establishment of bi-directional streams to the PeerConnection API.
To be precise:

I think (and we're implementing) that between two PeerConnections, there will be a small number of *RTP sessions*  (ideally one). These will be bidirectional.

These will be used for transporting any number of *MediaStreams* (a WEBRTC API concept), each of which corresponds to a CNAME (RTP protocol concept). These are unidirectional.

So the right answer is "yes" and "no", as far as I can see.
 
Regards,
 
Christer
 
 
 

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

--------------000306030108030702070403-- From harald@alvestrand.no Thu Sep 1 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 991D821F8713 for ; Thu, 1 Sep 2011 04:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.207 X-Spam-Level: X-Spam-Status: No, score=-107.207 tagged_above=-999 required=5 tests=[AWL=3.392, 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 RxDQo57H69J1 for ; Thu, 1 Sep 2011 04:56:28 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C1A7A21F86EA for ; Thu, 1 Sep 2011 04:56:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ACACB39E175 for ; Thu, 1 Sep 2011 13:56:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82rTmgBkYV4Z for ; Thu, 1 Sep 2011 13:56:42 +0200 (CEST) Received: from [172.16.41.131] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 1CEF939E173 for ; Thu, 1 Sep 2011 13:56:42 +0200 (CEST) Message-ID: <4E5F7344.4060803@alvestrand.no> Date: Thu, 01 Sep 2011 13:57:56 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] New topic: Model for multi-unicast support X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Sep 2011 11:56:28 -0000 In the thread about draft-perkins-rtcweb-usage, the following exchange took place: >> > Speaking for some implementors of the WEBRTC API, it's also clear that there's a significant cost to implementing the multiway RTP session concept - both in code complexity and API complexity. I think this warrants more discussion, where all 3 outcomes should be on the table: >> > >> > - We recommend doing multi-unicast with a shared RTP session only >> > - We recommend supporting both shared and split RTP sessions for multi-unicast >> > - We recommend doing multi-unicast with split RTP sessions only >> > >> > We should probably do this in a new thread. > Indeed; I'd be interested to know what complexity you're seeing. I would have expected the shared RTP session model to decrease complexity, since the RTP layer can be oblivious to the detail of the underlying transport connections, and wouldn't have to worry about tracking SSRC and payload type mapping separately for each session. I think this is a topic that deserves its own thread. The context is use case 4.2.7, "Multiparty video communication", the one without a central server; each party sends its video and audio streams to all participants in the meeting directly. One can imagine supporting this with a single RTP session, where all video streams are equal and sent with the same SSRC to all participants, all participants send receiver reports (RRs) about all the SSRCs they see to all other participants, and all senders send their SR reports to all participants. Now, this has implications for both API design, service design and protocol operation. API: The model presented is no longer "this object is your connection to A; that object is your connection to B". There has to be a representation of your "cloud" as a multidestination object, with procedures for adding to and subtracting from the list of participants. Error reporting must include which participant the error relates to. Service: The requirement for perfect equality means that you cannot allow any party to adapt its presence to what it can receive; for instance, as I understand it, nobody can drop the video and only be an audio participant, because that would break the model of equality, rendering sender reports meaningless to some participants. Protocol: The requirement for a single agreed RTCP bandwidth means that this bandwidth has to be computed for the session as a whole - with the simplistic answer being 5% of the lowest common denominator. In contrast, if one chooses the multiple-RTP-session approach: - the API retains its "one object, one destination" orientation. - the degree to which service is equal to all parties is a matter for the application, not the protocol - rate adaption, choice of RTP bandwidht and so on can be negotiated on each link individually I think this forum needs to pick one of the options in my initial note, and design its protocols and APIs accordingly. Thoughts? Harald From bernard_aboba@hotmail.com Thu Sep 1 07:34: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 635D021F9B9F for ; Thu, 1 Sep 2011 07:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=0.241, 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 mmTtQpBDx3lG for ; Thu, 1 Sep 2011 07:34:01 -0700 (PDT) Received: from blu0-omc1-s4.blu0.hotmail.com (blu0-omc1-s4.blu0.hotmail.com [65.55.116.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9368D21F9B7E for ; Thu, 1 Sep 2011 07:34:01 -0700 (PDT) Received: from BLU152-W48 ([65.55.116.8]) by blu0-omc1-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Sep 2011 07:35:30 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_54cfd690-8d79-460a-8acd-d5cf65abd6f2_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: , Date: Thu, 1 Sep 2011 07:35:30 -0700 Importance: Normal In-Reply-To: <4E5F6CEF.6020203@alvestrand.no> References: <7F2072F1E0DE894DA4B517B93C6A05852233DD0AC8@ESESSCMS0356.eemea.ericsson.se>, <4E5F6CEF.6020203@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 01 Sep 2011 14:35:30.0905 (UTC) FILETIME=[6671FC90:01CC68B4] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Symmetric RTP and uni-directional media streams X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Sep 2011 14:34:02 -0000 --_54cfd690-8d79-460a-8acd-d5cf65abd6f2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think Christer's question related to the following text from the W3C WEBR= TC editor's draft (http://dev.w3.org/2011/webrtc/editor/webrtc.html) Sectio= n 4: All streams represented by MediaStream objects must be marked as "sendonly" by the peer that initially adds the stream to the session. The PeerConnection API does not support bidirectional ("sendrecv") audio or video media streams. [SDPOFFERANSWER] =20 Date: Thu=2C 1 Sep 2011 13:30:55 +0200 From: harald@alvestrand.no To: christer.holmberg@ericsson.com CC: rtcweb@ietf.org Subject: Re: [rtcweb] Symmetric RTP and uni-directional media streams =20 =20 =20 =20 On 09/01/11 13:23=2C Christer Holmberg wrote: =20 =20 =20 =20 =20 =20 =20 Hi=2C =20 There has been much talk about the usage of symmetric RTP. Also=2C draft-perkins-rtcweb-rtp-usage suggests that symmetric RTP is required. =20 However=2C the PeerConnection API currently only supports the establishment of uni-directional streams=2C so for a single two way communication one needs to create two separate uni-directional streams. =20 So=2C I assume that one requirement from RTCWEB to W3C will be to add support of the establishment of bi-directional streams to the PeerConnection API. =20 To be precise: =20 I think (and we're implementing) that between two PeerConnections=2C there will be a small number of *RTP sessions* (ideally one). These will be bidirectional. =20 These will be used for transporting any number of *MediaStreams* (a WEBRTC API concept)=2C each of which corresponds to a CNAME (RTP protocol concept). These are unidirectional. =20 So the right answer is "yes" and "no"=2C as far as I can see. =20 =20 Regards=2C =20 Christer =20 =20 =20 =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 =20 =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb = --_54cfd690-8d79-460a-8acd-d5cf65abd6f2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I think Christer's question related to the following text from the W3C WEBR= TC editor's draft (http://dev.w3.org/2011/webrtc/editor/webrtc.html) Sectio= n 4:

All streams represented by MediaStream objects m= ust be marked as "sendonly" by the peer that initially adds the stream to the session. The PeerConnection API does not support bidirectional ("sendrecv") audio or video media streams. [SDPOFFERAN= SWER]

Date: Thu=2C 1 Sep 2011 13:30:55 +0200From: harald@alvestrand.no
To: christer.holmberg@ericsson.com
CC: r= tcweb@ietf.org
Subject: Re: [rtcweb] Symmetric RTP and uni-directional m= edia streams

=20 =20 =20 =20 On 09/01/11 13:23=2C Christer Holmberg wrote:
=20 =20 =20
 =3B
Hi=2C
 =3B
There has b= een much talk about the usage of symmetric RTP. Also=2C draft-perkins-rtcweb-rtp-usage suggests that symmetric RTP is required.
 =3B
However=2C = the PeerConnection API currently only supports the establishment of uni-directional streams=2C so for a single two way communication one needs to create two separate uni-directional streams.
 =3B
So=2C I ass= ume that one requirement from RTCWEB to W3C will be to add support of the establishment of bi-directional streams to the PeerConnection API.
To be precise:

I think (and we're implementing) that between two PeerConnections=2C there will be a small number of *RTP sessions* =3B (ideally one). T= hese will be bidirectional.

These will be used for transporting any number of *MediaStreams* (a WEBRTC API concept)=2C each of which corresponds to a CNAME (RTP protocol concept). These are unidirectional.

So the right answer is "yes" and "no"=2C as far as I can see.
 =3B
Regards=2C<= /font>
 =3B
Christer
 =3B
 =3B
 

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

=20
_______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
= --_54cfd690-8d79-460a-8acd-d5cf65abd6f2_-- From harald@alvestrand.no Thu Sep 1 08:50: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 CBCBF21F9905 for ; Thu, 1 Sep 2011 08:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.468 X-Spam-Level: X-Spam-Status: No, score=-107.468 tagged_above=-999 required=5 tests=[AWL=3.130, 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 EEaACB6wcRVp for ; Thu, 1 Sep 2011 08:50:00 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEBA21F98FE for ; Thu, 1 Sep 2011 08:50:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B5A3B39E175; Thu, 1 Sep 2011 17:50:16 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+5mjdMbCUeB; Thu, 1 Sep 2011 17:50:16 +0200 (CEST) Received: from [172.16.41.131] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id A4B0E39E173; Thu, 1 Sep 2011 17:50:15 +0200 (CEST) Message-ID: <4E5FAA03.60007@alvestrand.no> Date: Thu, 01 Sep 2011 17:51:31 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12 MIME-Version: 1.0 To: Bernard Aboba References: <7F2072F1E0DE894DA4B517B93C6A05852233DD0AC8@ESESSCMS0356.eemea.ericsson.se>, <4E5F6CEF.6020203@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030904080105090201030208" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Symmetric RTP and uni-directional media streams X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Sep 2011 15:50:01 -0000 This is a multi-part message in MIME format. --------------030904080105090201030208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/01/11 16:35, Bernard Aboba wrote: > I think Christer's question related to the following text from the W3C > WEBRTC editor's draft > (http://dev.w3.org/2011/webrtc/editor/webrtc.html) Section 4: > > All streams represented by |MediaStream > | > objects must be marked as "sendonly" by the peer that initially adds > the stream to the session. The |PeerConnection > | API > does not support bidirectional ("sendrecv") audio or video media > streams. [SDPOFFERANSWER] > Yes, as Christer knows, I think that's a broken design, have argued against it, and we're not implementing to it. It's a bit strange of me of all people to flash the interoperability card, but this is not interoperable with other RTP usages either. --------------030904080105090201030208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09/01/11 16:35, Bernard Aboba wrote:
I think Christer's question related to the following text from the W3C WEBRTC editor's draft (http://dev.w3.org/2011/webrtc/editor/webrtc.html) Section 4:

All streams represented by MediaStream objects must be marked as "sendonly" by the peer that initially adds the stream to the session. The PeerConnection API does not support bidirectional ("sendrecv") audio or video media streams. [SDPOFFERANSWER]
Yes, as Christer knows, I think that's a broken design, have argued against it, and we're not implementing to it.
It's a bit strange of me of all people to flash the interoperability card, but this is not interoperable with other RTP usages either.


--------------030904080105090201030208-- From christer.holmberg@ericsson.com Thu Sep 1 09:10: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 A20CB21F991E for ; Thu, 1 Sep 2011 09:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uf+F83bVEWeu for ; Thu, 1 Sep 2011 09:10:44 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2C47321F9929 for ; Thu, 1 Sep 2011 09:10:44 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-1a-4e5faed3699d Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 22.AF.02839.3DEAF5E4; Thu, 1 Sep 2011 18:12:03 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 1 Sep 2011 18:12:03 +0200 From: Christer Holmberg To: Harald Alvestrand , Bernard Aboba Date: Thu, 1 Sep 2011 18:12:02 +0200 Thread-Topic: [rtcweb] Symmetric RTP and uni-directional media streams Thread-Index: AcxovwdyT7yxl7y7SMaozlfEEPCrcAAArJ1g Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233DD0CBF@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852233DD0AC8@ESESSCMS0356.eemea.ericsson.se>, <4E5F6CEF.6020203@alvestrand.no> <4E5FAA03.60007@alvestrand.no> In-Reply-To: <4E5FAA03.60007@alvestrand.no> 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_7F2072F1E0DE894DA4B517B93C6A05852233DD0CBFESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Symmetric RTP and uni-directional media streams X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 01 Sep 2011 16:10:45 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852233DD0CBFESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I can't of course speak on behalf of others, but at least in IETF I assume = one reason why people haven't said anything is simply because they haven't = read the API :) Regards, Christer ________________________________ From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: 1. syyskuuta 2011 18:52 To: Bernard Aboba Cc: Christer Holmberg; rtcweb@ietf.org Subject: Re: [rtcweb] Symmetric RTP and uni-directional media streams On 09/01/11 16:35, Bernard Aboba wrote: I think Christer's question related to the following text from the W3C WEBR= TC editor's draft (http://dev.w3.org/2011/webrtc/editor/webrtc.html) Sectio= n 4: All streams represented by MediaStream objects must be marked as "sendonly" by the peer = that initially adds the stream to the session. The PeerConnection API does not suppor= t bidirectional ("sendrecv") audio or video media streams. [SDPOFFERANSWER]= Yes, as Christer knows, I think that's a broken design, have argued against= it, and we're not implementing to it. It's a bit strange of me of all people to flash the interoperability card, = but this is not interoperable with other RTP usages either. --_000_7F2072F1E0DE894DA4B517B93C6A05852233DD0CBFESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I can't of course speak on behalf of others, but a= t least=20 in IETF I assume one reason why people haven't said anything is simply beca= use=20 they haven't read the API :)
 
Regards,
 
Christer

From: Harald Alvestrand=20 [mailto:harald@alvestrand.no]
Sent: 1. syyskuuta 2011=20 18:52
To: Bernard Aboba
Cc: Christer Holmberg;=20 rtcweb@ietf.org
Subject: Re: [rtcweb] Symmetric RTP and=20 uni-directional media streams

On 09/01/11 16:35, Bernard Aboba wrote:=20
I think Christer's question related to the following tex= t from=20 the W3C WEBRTC editor's draft (http://dev.w3= .org/2011/webrtc/editor/webrtc.html)=20 Section 4:

All streams represented by MediaStream objects must be marked = as=20 "sendonly" by the peer that initially adds the stream to the session. T= he=20 PeerConnection API does not support= =20 bidirectional ("sendrecv") audio or video media streams. [SDPOFFERANSWER]
Yes= , as=20 Christer knows, I think that's a broken design, have argued against it, a= nd=20 we're not implementing to it.
It's a bit strange of me of all people t= o=20 flash the interoperability card, but this is not interoperable with other= RTP=20 usages either.


--_000_7F2072F1E0DE894DA4B517B93C6A05852233DD0CBFESESSCMS0356e_-- From yang.yanzi@zte.com.cn Fri Sep 2 02:06: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 08CF321F8D6C for ; Fri, 2 Sep 2011 02:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.331 X-Spam-Level: X-Spam-Status: No, score=-99.331 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GE2yvH1YtxGG for ; Fri, 2 Sep 2011 02:06:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 78F7621F8D65 for ; Fri, 2 Sep 2011 02:06:20 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 13132977368623; Fri, 2 Sep 2011 16:52:54 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 74991.3036320248; Fri, 2 Sep 2011 17:03:49 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p8293h9E041957; Fri, 2 Sep 2011 17:03:43 +0800 (GMT-8) (envelope-from yang.yanzi@zte.com.cn) To: rtcweb@ietf.org, magnus.westerlund@ericsson.com MIME-Version: 1.0 X-KeepSent: 268DFB86:1810E2CF-482578FF:0030883E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: yang.yanzi@zte.com.cn Date: Fri, 2 Sep 2011 17:03:42 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-09-02 17:03:45, Serialize complete at 2011-09-02 17:03:45 Content-Type: multipart/alternative; boundary="=_alternative 0031C656482578FF_=" X-MAIL: mse01.zte.com.cn p8293h9E041957 Subject: [rtcweb] selecting codec for RTCweb? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 09:06:22 -0000 This is a multipart message in MIME format. --=_alternative 0031C656482578FF_= Content-Type: text/plain; charset="US-ASCII" Dear Magnus and All RTCweb experts, Was the A/V codec selecting discussed in RTCweb WG? Do you think we should specify codec selecting for RTCweb in this Wroking Group? It's greatly appreciated if you response even though it has been discussed before. Thanks alot. Best Regards, YANG Yanzi --=_alternative 0031C656482578FF_= Content-Type: text/html; charset="US-ASCII"
Dear Magnus and All RTCweb experts,

Was the A/V codec selecting discussed in RTCweb WG? Do you think we should specify codec selecting for RTCweb in this Wroking Group?
It's greatly appreciated if you response even though it has been discussed before.
Thanks alot.


Best Regards,
YANG Yanzi
 --=_alternative 0031C656482578FF_=-- From randell-ietf@jesup.org Fri Sep 2 15:14: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 8D3D221F8D07 for ; Fri, 2 Sep 2011 15:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 7vtaxRvDtk1s for ; Fri, 2 Sep 2011 15:14:31 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C208F21F8D05 for ; Fri, 2 Sep 2011 15:14:31 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Qzc1v-0006zI-LJ; Fri, 02 Sep 2011 17:16:07 -0500 Message-ID: <4E615505.70508@jesup.org> Date: Fri, 02 Sep 2011 18:13:25 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: public-webrtc@w3.org References: <4E610B78.7000103@skype.net> In-Reply-To: <4E610B78.7000103@skype.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] PeerConnection Data Channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2011 22:14:32 -0000 CC-ing IETF rtcweb to cover the encryption/SDP/negotiation aspects of this proposal. On 9/2/2011 12:59 PM, Matthew Kaufman wrote: > On 9/2/11 5:52 PM, Justin Uberti wrote: >> Section 5 in the WEBRTC spec >> (http://dev.w3.org/2011/webrtc/editor/webrtc.html) discusses at >> length a mechanism for transmitting and securing datagrams over the >> PeerConnection transport. At both an API and a wire level, this >> mechanism is quite different from the existing mechanisms that are >> used for transmission of audio and video data: >> - The availability of the data stream is not easily known, whereas >> audio/video can be negotiated and stream existence learned from the >> *Stream methods/callbacks. > > Agree. True >> - It defines its own encryption mechanism, whereas audio/video will >> use SDES-SRTP, or DTLS-SRTP > > Agree. True, kinda, but that's not a value judgement, just an observation. > >> - Only one data stream exists, whereas audio/video can have many streams > > Agree. True > >> >> I would like to propose an approach where we remove the send() >> method, and add a createDataStream() method to PeerConnection. This >> method creates a DataStream object, a descendant of MediaStream. This >> object can then be added/removed from PeerConnection via the existing >> add/removeStream APIs, and it will show up in >> localStreams/remoteStreams like any other MediaStream. It will also >> fire events indicating the stream status. > > Great idea. I agree ways to create and add datastreams are important, as is the ability to have multiple ones. Otherwise people will just roll-their-own multistream muxes. If there can be only one stream, it would almost have to be an unreliable-datagram service, so you could build more complex stuff on top of it. > >> >> Some specifics: >> - This stream will show up in SDP > > I don't like SDP, but if we do SDP, that's where it'd need to be. > >> , and it can be its own RTP session, > > Disagree. RTP semantics are inappropriate for sending data. The data > should be sent using one of the two methods for muxing data that were > proposed (one by me, one by cbran). > > There should be a way to demux multiple streams of data using an > additional sub-header. Agreed. RTP for non media-stream data is not a good choice. >> or muxed with other RTP sessions, just like any other audio/video >> stream. If the remote side doesn't support/want the data stream, it >> can signal this via its answer SDP. > > Agree. Agree > >> - For encryption, it simply uses the underlying encryption of the >> session, i.e. none, SDES-SRTP, or DTLS-SRTP, as appropriate. > > Absolutely correct. Possibly needs masking for the "none" case > however... need to discuss. Hmmm.... This (blah-SRTP for encrypting the data streams means full un-encrypted RTP headers at a minimum, plus a bunch of those "RTP semantics" you disagreed with above. Unless I mis-understand how this would work. This (RTP encapsulation of the data) is my biggest heartburn with this proposal. I thought that idea had died at the mic, but apparently not. The strongest arguments in favor of RTP are: simplify code (everything ends up RTP), and RTP provides implicit information about loss and timing information that can be of use to congestion-control algorithms. For example, if both audio and video are currently inactive/muted, you still want the congestion control/bandwidth estimation code to continue to work for data channels. That in fact might be the strongest argument in favor, though there are other ways to provide that information. So we should detail out the ramifications of this (and think carefully about any security implications to SRTP use here, though it's probably ok from a security standpoint). > >> - Multiple DataStreams can be created, just like MediaStreams. This >> may be of value to certain applications, who want to have multiple >> flows, perhaps with their own QoS. > > Agree. Prioritization makes sense here, especially if/when we get > congestion control. Agree. I'll use the ancient example of netrek - it wanted and needed both a reliable and unreliable channel. The QOS characteristics of the two would have been different as well (if they'd been settable). Prioritization should not just be within data streams, but also it should prioritize individual data streams versus media streams. >> - We can (perhaps later) add different kinds of DataStreams, i.e. >> datagram and reliable. When creating a DataStream, you can specify >> what kind of stream you want. > > Also a good idea. Agreed. -- Randell Jesup randell-ietf@jesup.org From bernard_aboba@hotmail.com Fri Sep 2 17:11: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 E88FC21F856B for ; Fri, 2 Sep 2011 17:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.196 X-Spam-Level: X-Spam-Status: No, score=-102.196 tagged_above=-999 required=5 tests=[AWL=0.402, 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 Y7NUUNZE9L4V for ; Fri, 2 Sep 2011 17:11:32 -0700 (PDT) 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 21B5921F8561 for ; Fri, 2 Sep 2011 17:11:32 -0700 (PDT) Received: from BLU152-W19 ([65.55.111.136]) by blu0-omc4-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Sep 2011 17:13:08 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_ef49723c-b4ff-4505-bf57-a9907e014c0d_" X-Originating-IP: [64.134.138.94] From: Bernard Aboba To: , Date: Fri, 2 Sep 2011 17:13:08 -0700 Importance: Normal In-Reply-To: <4E615505.70508@jesup.org> References: , <4E610B78.7000103@skype.net>, <4E615505.70508@jesup.org> MIME-Version: 1.0 X-OriginalArrivalTime: 03 Sep 2011 00:13:08.0913 (UTC) FILETIME=[42A41210:01CC69CE] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] PeerConnection Data Channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 00:11:33 -0000 --_ef49723c-b4ff-4505-bf57-a9907e014c0d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > >> Section 5 in the WEBRTC spec=20 > >> (http://dev.w3.org/2011/webrtc/editor/webrtc.html) discusses at=20 > >> length a mechanism for transmitting and securing datagrams over the=20 > >> PeerConnection transport.=20 [BA] The objective here appears to be "masking" (e.g. to prevent sending of= arbitrary datagrams) rather than providing a full set of security services= .=20 > > > At both an API and a wire level=2C this=20 > >> mechanism is quite different from the existing mechanisms that are=20 > >> used for transmission of audio and video data:> >> - The availability = of the data stream is not easily known=2C whereas=20 > >> audio/video can be negotiated and stream existence learned from the=20 > >> *Stream methods/callbacks. [BA] It looked to me that the data channel was negotiated in SDP=2C no? > >> - It defines its own encryption mechanism=2C whereas audio/video will= =20 > >> use SDES-SRTP=2C or DTLS-SRTP [BA] I don't believe that the objective here is to duplicate the security s= ervices in SRTP=2C DTLS=2C TLS=2C IPsec or any other comprehensive security= framework. It's closer to the "masking" supported by WebSockets. =20 > >> - This stream will show up in SDP [BA] I believe that's what the current spec already says.=20 > > Disagree. RTP semantics are inappropriate for sending data. The data=20 > > should be sent using one of the two methods for muxing data that were=20 > > proposed (one by me=2C one by cbran). [BA] Agree that RTP semantics aren't necessarily appropriate for non media-= stream data.=20 > >> - For encryption=2C it simply uses the underlying encryption of the=20 > >> session=2C i.e. none=2C SDES-SRTP=2C or DTLS-SRTP=2C as appropriate. [BA] If the underlying semantics of RTP aren't a good fit=2C why would that= make sense? > > Absolutely correct. Possibly needs masking for the "none" case=20 > > however... need to discuss. [BA] Right. That's why it's there=2C not to provide a generic security fra= mework.=20 >=20 > Hmmm.... This (blah-SRTP for encrypting the data streams means full=20 > un-encrypted RTP headers at a minimum=2C plus a bunch of those "RTP=20 > semantics" you disagreed with above. Unless I mis-understand how this=20 > would work. [BA] Right. That's what trying to force RTP security on non-media data isn= 't appropriate.=20 = --_ef49723c-b4ff-4505-bf57-a9907e014c0d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B >=3B>=3B Section 5 in the WEBRTC spec
>=3B >=3B>= =3B (http://dev.w3.org/2011/webrtc/editor/webrtc.html) discusses at
>= =3B >=3B>=3B length a mechanism for transmitting and securing datagrams= over the
>=3B >=3B>=3B PeerConnection transport. =3B

[BA] The objective here appears to be "masking" (e.g. to = prevent sending of arbitrary datagrams) rather than providing a full set of= security services. =3B

>=3B >=3B >=3B A= t both an API and a wire level=2C this
>=3B >=3B>=3B mechanism is= quite different from the existing mechanisms that are
>=3B >=3B>= =3B used for transmission of audio and video data:
>=3B >=3B&= gt=3B - The availability of the data stream is not easily known=2C whereas =
>=3B >=3B>=3B audio/video can be negotiated and stream existence = learned from the
>=3B >=3B>=3B *Stream methods/callbacks.

[BA] It looked to me that the data channel was negotiated= in SDP=2C no?

>=3B >=3B>=3B - It defines its own encry= ption mechanism=2C whereas audio/video will
>=3B >=3B>=3B use SDE= S-SRTP=2C or DTLS-SRTP

[BA] I don't believe that the obje= ctive here is to duplicate the security services in SRTP=2C DTLS=2C TLS=2C = IPsec or any other comprehensive security framework. =3B
It's= closer to the "masking" supported by WebSockets.  =3B


>=3B >=3B>=3B - This stream will show up in S= DP

[BA] I believe that's what the current spec already sa= ys. =3B

>=3B >=3B Disagree. RTP semantics = are inappropriate for sending data. The data
>=3B >=3B should be se= nt using one of the two methods for muxing data that were
>=3B >=3B= proposed (one by me=2C one by cbran).

[BA] Agree that RT= P semantics aren't necessarily appropriate for non media-stream data. = =3B

>=3B >=3B>=3B - For encryption=2C it sim= ply uses the underlying encryption of the
>=3B >=3B>=3B session= =2C i.e. none=2C SDES-SRTP=2C or DTLS-SRTP=2C as appropriate.

=
[BA] If the underlying semantics of RTP aren't a good fit=2C why would= that make sense?

>=3B >=3B Absolutely correct= . Possibly needs masking for the "none" case
>=3B >=3B however... n= eed to discuss.

[BA] Right.  =3BThat's why it's there= =2C not to provide a generic security framework. =3B

>=3B
>=3B Hmmm.... This (blah-SRTP for encrypting the data = streams means full
>=3B un-encrypted RTP headers at a minimum=2C plus= a bunch of those "RTP
>=3B semantics" you disagreed with above. Unl= ess I mis-understand how this
>=3B would work.

[BA] Right.  =3BThat's what trying to force RTP security on non-medi= a data isn't appropriate. =3B


=
= --_ef49723c-b4ff-4505-bf57-a9907e014c0d_-- From cbran@cisco.com Fri Sep 2 17:12: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 18AFA21F8A64 for ; Fri, 2 Sep 2011 17:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, 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 aAfk6l2ItYRQ for ; Fri, 2 Sep 2011 17:12:12 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 220F721F856B for ; Fri, 2 Sep 2011 17:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cbran@cisco.com; l=837; q=dns/txt; s=iport; t=1315008829; x=1316218429; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=DUElrPmSp9g1u+/d6+bCfLsKQn56nEs7X+5AAt8IaX0=; b=WpFhHUkXkOJNHc68uR5rusWpxc6gHVEl/m9eSz5GavmMe7zPmXLLoRL4 2MWalJYKz+DmUblh2LUNTY5xR+EGqY/UeY+LUaXUvL42H43bjwuqqyhqZ Uqd8GQ2H15R+vBD+5+ryFrDWdds+rIDLz9D4R2ymRTUKFJB701nqwuas+ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAItwYU6rRDoG/2dsb2JhbABCqGl4gUYBAQEBAgEBAQEPAScCAS4DHQEICWQwAQEEARIih1AEmGABnx6GZQSHaYRQhnOFGIwV X-IronPort-AV: E=Sophos;i="4.68,321,1312156800"; d="scan'208";a="19024156" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-5.cisco.com with ESMTP; 03 Sep 2011 00:13:49 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p830DmBQ021072; Sat, 3 Sep 2011 00:13:48 GMT Received: from xmb-sjc-228.amer.cisco.com ([128.107.191.125]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Sep 2011 17:13:48 -0700 Received: from 10.20.222.55 ([10.20.222.55]) by xmb-sjc-228.amer.cisco.com ([128.107.191.125]) with Microsoft Exchange Server HTTP-DAV ; Sat, 3 Sep 2011 00:13:48 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Fri, 02 Sep 2011 17:13:47 -0700 From: cbran To: , , Message-ID: Thread-Topic: [rtcweb] selecting codec for RTCweb? Thread-Index: AcxpzllXIZP7w5kZgU6FOrWl5Zku5A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Sep 2011 00:13:48.0369 (UTC) FILETIME=[5A289410:01CC69CE] Subject: Re: [rtcweb] selecting codec for RTCweb? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 00:12:13 -0000 Hi YANG, On 9/2/11 2:03 AM, "yang.yanzi@zte.com.cn" wrote: > > Dear Magnus and All RTCweb experts, > > Was the A/V codec selecting discussed in RTCweb WG? Do you think we should > specify codec selecting for RTCweb in this Wroking Group? > Cullen and I submitted this draft proposal regarding rtc-web and the A/V codec support. http://tools.ietf.org/html/draft-cbran-rtcweb-codec-00 I presented this at IETF 81 and will be sending out an update with feedback I have received. > > > > It's greatly appreciated if you response even though it has been discussed > before. > Thanks alot. > > > Best Regards, > YANG Yanzi > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From juberti@google.com Fri Sep 2 20:45: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 3874821F8BD5 for ; Fri, 2 Sep 2011 20:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.612 X-Spam-Level: X-Spam-Status: No, score=-105.612 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkKdv3bd63Of for ; Fri, 2 Sep 2011 20:45:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2363921F8C30 for ; Fri, 2 Sep 2011 20:45:26 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p833l1nl024032 for ; Fri, 2 Sep 2011 20:47:02 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315021622; bh=5/QQMjmicBQS2Z64dhJVwAjstQE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=qm0RFUZeCr6RfrCl6G54p5Oiv+cDz2RWMoGqt47xWgVA7fT99GPmkNgLBPlTLsilb 0m6+9WXs6d9FqCh7IaE7w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=YJ/9gmvAt0Ppivw1CkYjU44CVbrSLt19HY+mKL6iuHyO70rjNlzlGCY/XqMTNlNkg kqPKeWptB6+ilFYygw1nw== Received: from iadk27 (iadk27.prod.google.com [10.12.137.27]) by wpaz5.hot.corp.google.com with ESMTP id p833l0Wv009576 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 2 Sep 2011 20:47:00 -0700 Received: by iadk27 with SMTP id k27so4849828iad.29 for ; Fri, 02 Sep 2011 20:47:00 -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; bh=YsYYoOhzbXkBALsaHBE5EMr8YMvZEYMxanXBUkg/hDw=; b=pgxzt9Rgy+g+cdyci+9E3he1iwUHyOLWcBww7gEJulglREpihqIrfQXF52fzmh7HMU 6jZ68SmqM0AoRiKB/JEA== Received: by 10.42.245.5 with SMTP id ls5mr1596049icb.149.1315021620300; Fri, 02 Sep 2011 20:47:00 -0700 (PDT) Received: by 10.42.245.5 with SMTP id ls5mr1596040icb.149.1315021620115; Fri, 02 Sep 2011 20:47:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.36.10 with HTTP; Fri, 2 Sep 2011 20:46:40 -0700 (PDT) In-Reply-To: References: <4E610B78.7000103@skype.net> <4E615505.70508@jesup.org> From: Justin Uberti Date: Fri, 2 Sep 2011 23:46:40 -0400 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=90e6ba5bc13789fac404ac01541d X-System-Of-Record: true Cc: rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] PeerConnection Data Channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 03:45:28 -0000 --90e6ba5bc13789fac404ac01541d Content-Type: text/plain; charset=UTF-8 On Fri, Sep 2, 2011 at 8:13 PM, Bernard Aboba wrote: > > >> Section 5 in the WEBRTC spec > > >> (http://dev.w3.org/2011/webrtc/editor/webrtc.html) discusses at > > >> length a mechanism for transmitting and securing datagrams over the > > >> PeerConnection transport. > > [BA] The objective here appears to be "masking" (e.g. to prevent sending of > arbitrary datagrams) rather than providing a full set of security services. > The current spec provides an encryption and authentication mechanism, in addition to the masking. From the spec: "The data is made to appear pseudo-random, so that it cannot be used in a cross-protocol attack, even if somehow the stream were to be directed at an unsuspecting remote host. The data is hashed in such a way that it cannot be modified in transit. That data is encrypted so that it cannot be read in transit." > > > > > At both an API and a wire level, this > > >> mechanism is quite different from the existing mechanisms that are > > >> used for transmission of audio and video data: > > >> - The availability of the data stream is not easily known, whereas > > >> audio/video can be negotiated and stream existence learned from the > > >> *Stream methods/callbacks. > > [BA] It looked to me that the data channel was negotiated in SDP, no? > Yes. But the API doesn't expose whether the data channel was successfully negotiated. > > > >> - It defines its own encryption mechanism, whereas audio/video will > > >> use SDES-SRTP, or DTLS-SRTP > > [BA] I don't believe that the objective here is to duplicate the security > services in SRTP, DTLS, TLS, IPsec or any other comprehensive security > framework. > It's closer to the "masking" supported by WebSockets. > That's not my understanding of the spec, as evidenced above. > > > > >> - This stream will show up in SDP > > [BA] I believe that's what the current spec already says. > > > > Disagree. RTP semantics are inappropriate for sending data. The data > > > should be sent using one of the two methods for muxing data that were > > > proposed (one by me, one by cbran). > > [BA] Agree that RTP semantics aren't necessarily appropriate for non > media-stream data. > Yeah, I admit my original opinion on this was that RTP was crazy. But looking at it more, we're going to end up duplicating much of what RTP provides - Matthew's proposal adds a 4 byte header to distinguish it from STUN, and we probably also need a stream id and a sequence number (for TFRC). At that point we're only a timestamp away from a full RTP header. I think this is an interesting discussion, so I'll send a new email to the list to discuss the wire format of this protocol, which I think can be considered separately from the DataStream proposal I'm putting forth here. > > > >> - For encryption, it simply uses the underlying encryption of the > > >> session, i.e. none, SDES-SRTP, or DTLS-SRTP, as appropriate. > > [BA] If the underlying semantics of RTP aren't a good fit, why would that > make sense? > True. However, if we use DTLS, we can apply DTLS without the need for RTP semantics. Or as Matthew says, we could also make SRTP-style encryption work with whatever datagram protocol we come up with. > > > > Absolutely correct. Possibly needs masking for the "none" case > > > however... need to discuss. > > [BA] Right. That's why it's there, not to provide a generic security > framework. > See above. > > > > > Hmmm.... This (blah-SRTP for encrypting the data streams means full > > un-encrypted RTP headers at a minimum, plus a bunch of those "RTP > > semantics" you disagreed with above. Unless I mis-understand how this > > would work. > > [BA] Right. That's what trying to force RTP security on non-media data > isn't appropriate. > See above. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --90e6ba5bc13789fac404ac01541d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 2, 2011 at 8:13 PM, Bernard = Aboba <be= rnard_aboba@hotmail.com> wrote:
> >> Section 5 in the WEBRTC spec
> >> (htt= p://dev.w3.org/2011/webrtc/editor/webrtc.html) discusses at
> &g= t;> length a mechanism for transmitting and securing datagrams over the =
> >> PeerConnection transport.=C2=A0

[BA] The objective here appears to be "masking" (e.g. to preven= t sending of arbitrary datagrams) rather than providing a full set of secur= ity services.=C2=A0

The current spec provides an e= ncryption and authentication mechanism, in addition to the masking. From th= e spec: "The data is made to appear pseudo-random, so that it cannot b= e used in a cross-protocol attack, even if somehow the stream were to be di= rected at an unsuspecting remote host. The data is hashed in such a way tha= t it cannot be modified in transit. That data is encrypted so that it canno= t be read in transit."

> > > At both an API and a wire level, this
&= gt; >> mechanism is quite different from the existing mechanisms that= are
> >> used for transmission of audio and video data:
>= >> - The availability of the data stream is not easily known, wherea= s
> >> audio/video can be negotiated and stream existence lear= ned from the
> >> *Stream methods/callbacks.

[BA= ] It looked to me that the data channel was negotiated in SDP, no?

Yes. But the API doesn't expo= se whether the data channel was successfully negotiated.=C2=A0

> >> - It defines its own encryption mechanism, whereas audi= o/video will
> >> use SDES-SRTP, or DTLS-SRTP

[BA] I do= n't believe that the objective here is to duplicate the security servic= es in SRTP, DTLS, TLS, IPsec or any other comprehensive security framework.= =C2=A0
It's closer to the "masking" supported by WebSockets. = =C2=A0

That's not my = understanding of the spec, as evidenced above.
=C2=A0


= > >> - This stream will show up in SDP

[BA= ] I believe that's what the current spec already says.=C2=A0

> > Disagree. RTP semantics are inappropriate for= sending data. The data
> > should be sent using one of the two m= ethods for muxing data that were
> > proposed (one by me, one by = cbran).

[BA] Agree that RTP semantics aren't necessarily a= ppropriate for non media-stream data.=C2=A0
<= div>
Yeah, I admit my original opinion on this was that RTP w= as crazy. But looking at it more, we're going to end up duplicating muc= h of what RTP provides - Matthew's proposal adds a 4 byte header to dis= tinguish it from STUN, and we probably also need a stream id and a sequence= number (for TFRC). At that point we're only a timestamp away from a fu= ll RTP header.

I think this is an interesting discussion, so I'll = send a new email to the list to discuss the wire format of this protocol, w= hich I think can be considered separately from the DataStream proposal I= 9;m putting forth here.

> >> - For encryption, it simply uses the underly= ing encryption of the
> >> session, i.e. none, SDES-SRTP, or DTLS-SRTP, as appropriate.<= br>
[BA] If the underlying semantics of RTP aren't = a good fit, why would that make sense?

True. However, if we use DTLS, we can apply DTLS without the= need for RTP semantics. Or as Matthew says, we could also make SRTP-style = encryption work with whatever datagram protocol we come up with.

> > Absol= utely correct. Possibly needs masking for the "none" case
>= ; > however... need to discuss.

[BA] Right. =C2= =A0That's why it's there, not to provide a generic security framewo= rk.=C2=A0

See above.=C2=A0

>
> Hmmm.... This (blah-SRTP for encrypting the data streams mea= ns full
> un-encrypted RTP headers at a minimum, plus a bunch of tho= se "RTP
> semantics" you disagreed with above. Unless I m= is-understand how this
> would work.

[BA] Right. =C2=A0That'= s what trying to force RTP security on non-media data isn't appropriate= .=C2=A0

See above.
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;">



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


--90e6ba5bc13789fac404ac01541d-- From juberti@google.com Fri Sep 2 20:49: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 2376D21F8C30 for ; Fri, 2 Sep 2011 20:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.699 X-Spam-Level: X-Spam-Status: No, score=-104.699 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2vrk4BJpUae for ; Fri, 2 Sep 2011 20:49:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id C0CAC21F8C11 for ; Fri, 2 Sep 2011 20:49:37 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p833pDBH004480 for ; Fri, 2 Sep 2011 20:51:14 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315021874; bh=dh4vEdnbCx5g133otnYsJdY9epc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=aEg4sriORrc1IvWqlxrVb9LW6iHDENa8ltUGqVCzWAriF72KZoFtViu1DMbcaPHFp eZi7zLid7SBVGgGVV/t1Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=G+BdWzbCBuKiLnXqB0eIJ1ssxV9tEN1dk0uZZnSN/ncbrFWfnQoj5M0AYzk8oVGjm DeELcZcQDWC3h3u7m3FZA== Received: from iage36 (iage36.prod.google.com [10.12.207.36]) by wpaz9.hot.corp.google.com with ESMTP id p833ohlF009691 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 2 Sep 2011 20:51:12 -0700 Received: by iage36 with SMTP id e36so5332865iag.23 for ; Fri, 02 Sep 2011 20:51:12 -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; bh=Tk6hupDiGKC2K5FRs9EOtveFD9kiAKK7naBnvXABXOY=; b=CnUGi3REcm3jn2SWFXu/CxXYnRxgUer0HZ0xJQI5LVWsyRqNkXct3o9L5vSHNj5Lgw 5LFxot/8uYkt5wRLyA1Q== Received: by 10.231.41.69 with SMTP id n5mr3194253ibe.92.1315021871336; Fri, 02 Sep 2011 20:51:11 -0700 (PDT) Received: by 10.231.41.69 with SMTP id n5mr3194226ibe.92.1315021870148; Fri, 02 Sep 2011 20:51:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.36.10 with HTTP; Fri, 2 Sep 2011 20:50:49 -0700 (PDT) In-Reply-To: <4E615505.70508@jesup.org> References: <4E610B78.7000103@skype.net> <4E615505.70508@jesup.org> From: Justin Uberti Date: Fri, 2 Sep 2011 23:50:49 -0400 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=0015177407d4712b1504ac01635b X-System-Of-Record: true Cc: "rtcweb@ietf.org" , public-webrtc@w3.org Subject: Re: [rtcweb] PeerConnection Data Channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 03:49:39 -0000 --0015177407d4712b1504ac01635b Content-Type: text/plain; charset=UTF-8 On Fri, Sep 2, 2011 at 6:13 PM, Randell Jesup wrote: > CC-ing IETF rtcweb to cover the encryption/SDP/negotiation aspects of this > proposal. > > > On 9/2/2011 12:59 PM, Matthew Kaufman wrote: > >> On 9/2/11 5:52 PM, Justin Uberti wrote: >> >>> Section 5 in the WEBRTC spec (http://dev.w3.org/2011/** >>> webrtc/editor/webrtc.html) >>> discusses at length a mechanism for transmitting and securing datagrams over >>> the PeerConnection transport. At both an API and a wire level, this >>> mechanism is quite different from the existing mechanisms that are used for >>> transmission of audio and video data: >>> - The availability of the data stream is not easily known, whereas >>> audio/video can be negotiated and stream existence learned from the *Stream >>> methods/callbacks. >>> >> >> Agree. >> > > True > > > - It defines its own encryption mechanism, whereas audio/video will use >>> SDES-SRTP, or DTLS-SRTP >>> >> >> Agree. >> > > True, kinda, but that's not a value judgement, just an observation. > > > >> - Only one data stream exists, whereas audio/video can have many streams >>> >> >> Agree. >> > > True > > > >> >>> I would like to propose an approach where we remove the send() method, >>> and add a createDataStream() method to PeerConnection. This method creates a >>> DataStream object, a descendant of MediaStream. This object can then be >>> added/removed from PeerConnection via the existing add/removeStream APIs, >>> and it will show up in localStreams/remoteStreams like any other >>> MediaStream. It will also fire events indicating the stream status. >>> >> >> Great idea. >> > > I agree ways to create and add datastreams are important, as is the ability > to have multiple ones. Otherwise people will just roll-their-own > multistream muxes. If there can be only one stream, it would almost have to > be an unreliable-datagram service, so you could build more complex stuff on > top of it. > > > >> >>> Some specifics: >>> - This stream will show up in SDP >>> >> >> I don't like SDP, but if we do SDP, that's where it'd need to be. >> >> , and it can be its own RTP session, >>> >> >> Disagree. RTP semantics are inappropriate for sending data. The data >> should be sent using one of the two methods for muxing data that were >> proposed (one by me, one by cbran). >> >> There should be a way to demux multiple streams of data using an >> additional sub-header. >> > > Agreed. RTP for non media-stream data is not a good choice. > > > or muxed with other RTP sessions, just like any other audio/video stream. >>> If the remote side doesn't support/want the data stream, it can signal this >>> via its answer SDP. >>> >> >> Agree. >> > > Agree > > >> - For encryption, it simply uses the underlying encryption of the >>> session, i.e. none, SDES-SRTP, or DTLS-SRTP, as appropriate. >>> >> >> Absolutely correct. Possibly needs masking for the "none" case however... >> need to discuss. >> > > Hmmm.... This (blah-SRTP for encrypting the data streams means full > un-encrypted RTP headers at a minimum, plus a bunch of those "RTP semantics" > you disagreed with above. Unless I mis-understand how this would work. > > This (RTP encapsulation of the data) is my biggest heartburn with this > proposal. I thought that idea had died at the mic, but apparently not. > > The strongest arguments in favor of RTP are: simplify code (everything ends > up RTP), and RTP provides implicit information about loss and timing > information that can be of use to congestion-control algorithms. For > example, if both audio and video are currently inactive/muted, you still > want the congestion control/bandwidth estimation code to continue to work > for data channels. That in fact might be the strongest argument in favor, > though there are other ways to provide that information. > > So we should detail out the ramifications of this (and think carefully > about any security implications to SRTP use here, though it's probably ok > from a security standpoint). I do think we want common congestion control for audio/video/data. I don't think this necessarily implies RTP, although it does imply something RTP-like, so it may just be simplest to go with RTP. As mentioned in my reply to Bernard, I think this topic merits its own thread. > > > >> - Multiple DataStreams can be created, just like MediaStreams. This may >>> be of value to certain applications, who want to have multiple flows, >>> perhaps with their own QoS. >>> >> >> Agree. Prioritization makes sense here, especially if/when we get >> congestion control. >> > > Agree. I'll use the ancient example of netrek - it wanted and needed both > a reliable and unreliable channel. The QOS characteristics of the two would > have been different as well (if they'd been settable). Prioritization > should not just be within data streams, but also it should prioritize > individual data streams versus media streams. > > > - We can (perhaps later) add different kinds of DataStreams, i.e. datagram >>> and reliable. When creating a DataStream, you can specify what kind of >>> stream you want. >>> >> >> Also a good idea. >> > > Agreed. > > -- > Randell Jesup > randell-ietf@jesup.org > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --0015177407d4712b1504ac01635b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 2, 2011 at 6:13 PM, Randell = Jesup <rande= ll-ietf@jesup.org> wrote:
CC-ing IETF rtcweb to cover the encryption/SDP/negotiation aspects of this = proposal.


On 9/2/2011 12:59 PM, Matthew Kaufman wrote:
On 9/2/11 5:52 PM, Justin Uberti wrote:
Section 5 in the WEBRTC spec (http://dev.w3.org/2011/webrtc/edit= or/webrtc.html) discusses at length a mechanism for transmitting and se= curing datagrams over the PeerConnection transport. At both an API and a wi= re level, this mechanism is quite different from the existing mechanisms th= at are used for transmission of audio and video data:
- The availability of the data stream is not easily known, whereas audio/vi= deo can be negotiated and stream existence learned from the *Stream methods= /callbacks.

Agree.

True


- It defines its own encryption mechanism, whereas audio/video will use SDE= S-SRTP, or DTLS-SRTP

Agree.

True, kinda, but that's not a value judgement, just an observation.


- Only one data stream exists, whereas audio/video can have many streams

Agree.

True




I would like to propose an approach where we remove the send() method, and = add a createDataStream() method to PeerConnection. This method creates a Da= taStream object, a descendant of MediaStream. This object can then be added= /removed from PeerConnection via the existing add/removeStream APIs, and it= will show up in localStreams/remoteStreams like any other MediaStream. It = will also fire events indicating the stream status.

Great idea.

I agree ways to create and add datastreams are important, as is the ability= to have multiple ones. =C2=A0Otherwise people will just roll-their-own mul= tistream muxes. =C2=A0If there can be only one stream, it would almost have= to be an unreliable-datagram service, so you could build more complex stuf= f on top of it.




Some specifics:
- This stream will show up in SDP

I don't like SDP, but if we do SDP, that's where it'd need to b= e.

, and it can be its own RTP session,

Disagree. RTP semantics are inappropriate for sending data. The data should= be sent using one of the two methods for muxing data that were proposed (o= ne by me, one by cbran).

There should be a way to demux multiple streams of data using an additional= sub-header.

Agreed. =C2=A0RTP for non media-stream data is not a good choice.


or muxed with other RTP sessions, just like any other audio/video stream. I= f the remote side doesn't support/want the data stream, it can signal t= his via its answer SDP.

Agree.

Agree


- For encryption, it simply uses the underlying encryption of the session, = i.e. none, SDES-SRTP, or DTLS-SRTP, as appropriate.

Absolutely correct. Possibly needs masking for the "none" case ho= wever... need to discuss.

Hmmm.... =C2=A0This (blah-SRTP for encrypting the data streams means full u= n-encrypted RTP headers at a minimum, plus a bunch of those "RTP seman= tics" you disagreed with above. =C2=A0Unless I mis-understand how this= would work.

This (RTP encapsulation of the data) is my biggest heartburn with this prop= osal. =C2=A0I thought that idea had died at the mic, but apparently not.
The strongest arguments in favor of RTP are: simplify code (everything ends= up RTP), and RTP provides implicit information about loss and timing infor= mation that can be of use to congestion-control algorithms. =C2=A0For examp= le, if both audio and video are currently inactive/muted, you still want th= e congestion control/bandwidth estimation code to continue to work for data= channels. =C2=A0That in fact might be the strongest argument in favor, tho= ugh there are other ways to provide that information.

So we should detail out the ramifications of this (and think carefully abou= t any security implications to SRTP use here, though it's probably ok f= rom a security standpoint).

I do think we w= ant common congestion control for audio/video/data. I don't think this = necessarily implies RTP, although it does imply something RTP-like, so it m= ay just be simplest to go with RTP. As mentioned in my reply to Bernard, I = think this topic merits its own thread.



- Multiple DataStreams can be created, just like MediaStreams. This may be = of value to certain applications, who want to have multiple flows, perhaps = with their own QoS.

Agree. Prioritization makes sense here, especially if/when we get congestio= n control.

Agree. =C2=A0I'll use the ancient example of netrek - it wanted and nee= ded both a reliable and unreliable channel. =C2=A0The QOS characteristics o= f the two would have been different as well (if they'd been settable). = =C2=A0Prioritization should not just be within data streams, but also it sh= ould prioritize individual data streams versus media streams.


- We can (perhaps later) add different kinds of DataStreams, i.e. datagram = and reliable. When creating a DataStream, you can specify what kind of stre= am you want.

Also a good idea.

Agreed.

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

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

--0015177407d4712b1504ac01635b-- From stefan.lk.hakansson@ericsson.com Fri Sep 2 22:30: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 EE60821F8C33 for ; Fri, 2 Sep 2011 22:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.317 X-Spam-Level: X-Spam-Status: No, score=-6.317 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 r3LxS0kkgauy for ; Fri, 2 Sep 2011 22:30:04 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id E509621F8C30 for ; Fri, 2 Sep 2011 22:30:02 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-e3-4e61bbb90ffc Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 64.C7.02839.9BBB16E4; Sat, 3 Sep 2011 07:31:38 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.112]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sat, 3 Sep 2011 07:31:37 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Harald Alvestrand , "rtcweb@ietf.org" Date: Sat, 3 Sep 2011 07:31:36 +0200 Thread-Topic: [rtcweb] New topic: Model for multi-unicast support Thread-Index: Acxonmi2aGEHqqgXTPKiB1xc8U+hMQBWhz9c Message-ID: References: <4E5F7344.4060803@alvestrand.no> In-Reply-To: <4E5F7344.4060803@alvestrand.no> 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] New topic: Model for multi-unicast support X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 03 Sep 2011 05:30:05 -0000 Harald wrote: >In the thread about draft-perkins-rtcweb-usage, the following exchange >took place: >>> > Speaking for some implementors of the WEBRTC API, it's also clear th= at there's a significant cost to implementing the multiway RTP session conc= ept - both in code >complexity and API complexity. I think this warrants mo= re discussion, where all 3 outcomes should be on the table: >>> > >>> > - We recommend doing multi-unicast with a shared RTP session only >>> > - We recommend supporting both shared and split RTP sessions for mul= ti-unicast >>> > - We recommend doing multi-unicast with split RTP sessions only >>> > >>> > We should probably do this in a new thread. >> Indeed; I'd be interested to know what complexity you're seeing. I would= have expected the shared RTP session model to decrease complexity, since t= he RTP layer can be >>oblivious to the detail of the underlying transport c= onnections, and wouldn't have to worry about tracking SSRC and payload type= mapping separately for each session. >I think this is a topic that deserves its own thread. > >The context is use case 4.2.7, "Multiparty video communication", the one >without a central server; each party sends its video and audio streams >to all participants in the meeting directly. > >One can imagine supporting this with a single RTP session, where all >video streams are equal and sent with the same SSRC to all participants, >all participants send receiver reports (RRs) about all the SSRCs they >see to all other participants, and all senders send their SR reports to >all participants. To me an RTP session was connected to a port/IP address, so I don't underst= and how this could be one session (the destination port/IP would be differe= nt for each stream). (I expect to be corrected!) Is multicast assumed? > >Now, this has implications for both API design, service design and >protocol operation. > >API: The model presented is no longer "this object is your connection to >A; that object is your connection to B". There has to be a >representation of your "cloud" as a multidestination object, with >procedures for adding to and subtracting from the list of participants. >Error reporting must include which participant the error relates to. > >Service: The requirement for perfect equality means that you cannot >allow any party to adapt its presence to what it can receive; for >instance, as I understand it, nobody can drop the video and only be an >audio participant, because that would break the model of equality, >rendering sender reports meaningless to some participants. > >Protocol: The requirement for a single agreed RTCP bandwidth means that >this bandwidth has to be computed for the session as a whole - with the >simplistic answer being 5% of the lowest common denominator. > >In contrast, if one chooses the multiple-RTP-session approach: > >- the API retains its "one object, one destination" orientation. > >- the degree to which service is equal to all parties is a matter for >the application, not the protocol > >- rate adaption, choice of RTP bandwidht and so on can be negotiated on >each link individually > >I think this forum needs to pick one of the options in my initial note, >and design its protocols and APIs accordingly. >Thoughts? This was to some extent discussed on the webrtc list earlier. My view is th= e same as then: we should go for the '"one object, one destination" and mul= tiple RTP-session' approach.=20 Stefan Harald _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb= From ekr@rtfm.com Sat Sep 3 08:12: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 946AA21F8B36 for ; Sat, 3 Sep 2011 08:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.972 X-Spam-Level: X-Spam-Status: No, score=-102.972 tagged_above=-999 required=5 tests=[AWL=0.005, 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 uB58Vj97vuOC for ; Sat, 3 Sep 2011 08:12:55 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF93921F8AFA for ; Sat, 3 Sep 2011 08:12:54 -0700 (PDT) Received: by wyg8 with SMTP id 8so3323925wyg.31 for ; Sat, 03 Sep 2011 08:14:33 -0700 (PDT) Received: by 10.227.165.202 with SMTP id j10mr2219249wby.18.1315062873130; Sat, 03 Sep 2011 08:14:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.3.5 with HTTP; Sat, 3 Sep 2011 08:14:13 -0700 (PDT) In-Reply-To: References: <4E610B78.7000103@skype.net> <4E615505.70508@jesup.org> From: Eric Rescorla Date: Sat, 3 Sep 2011 08:14:13 -0700 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] PeerConnection Data Channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2011 15:12:55 -0000 On Fri, Sep 2, 2011 at 8:46 PM, Justin Uberti wrote: > > > On Fri, Sep 2, 2011 at 8:13 PM, Bernard Aboba > wrote: >> >> > >> Section 5 in the WEBRTC spec >> > >> (http://dev.w3.org/2011/webrtc/editor/webrtc.html) discusses at >> > >> length a mechanism for transmitting and securing datagrams over the >> > >> PeerConnection transport. >> [BA] The objective here appears to be "masking" (e.g. to prevent sending >> of arbitrary datagrams) rather than providing a full set of security >> services. > > The current spec provides an encryption and authentication mechanism, in > addition to the masking. From the spec: "The data is made to appear > pseudo-random, so that it cannot be used in a cross-protocol attack, even if > somehow the stream were to be directed at an unsuspecting remote host. The > data is hashed in such a way that it cannot be modified in transit. That > data is encrypted so that it cannot be read in transit." I believe Justin is correct here: the protocol appears to be designed to provide rather more than masking. With that said, in my opinion it is likely not necessary to mask UDP data. Masking is designed to prevent cross-protocol attacks on intermediaries, which are not really a common feature of UDP data transmission (as opposed to HTTP intercepting proxies, which are quite common and for which masking was originally designed. -Ekr From matthew.kaufman@skype.net Sun Sep 4 20:11: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 411C821F851A for ; Sun, 4 Sep 2011 20:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNpYqRPpbWvi for ; Sun, 4 Sep 2011 20:11:58 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id DC22521F8538 for ; Sun, 4 Sep 2011 20:11:56 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id E60F47FE; Mon, 5 Sep 2011 05:13:38 +0200 (CEST) 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; s=mx; bh=Wy6pdfKSecc9cJtVYI1mRk3/Aa4=; b=HL6szVzJV Ifb8FkdKNSUccLwl/MLRT67bA3knBUcQ/Ug7+5rq8yUQ2lpDTnYrsHbWV++ohXdq lJSlFxj7UHuqgQrme26jtLNT7xDPnas0mG3CrOmak3w5SYTnopJnBVeeSwS9czIh UjKZMSH5cp3t7wLDQiNJvAgfUJyWjRw1js= 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; q=dns; s=mx; b=R7eZjRPdW6VRLe5qaINq5/AF4Gy+Nud0jeYdGCGSPaNdaQB1 fohdQni5CxPdDk9Mhx2AjSvq7pClBx9AONaquYIjsFuO8USNlLIeqz36Om0lTP6y nAJ3ucs9ATxtKiAs2A8yPnNYUYWp6GpT6zWDNfRDOU/Cf+FdonF0q6q7AIs= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id D81A77FC; Mon, 5 Sep 2011 05:13:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id B14D63506FEB; Mon, 5 Sep 2011 05:13:38 +0200 (CEST) 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 ojfYWyhdSC7z; Mon, 5 Sep 2011 05:13:37 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 726F83506FE3; Mon, 5 Sep 2011 05:13:37 +0200 (CEST) Message-ID: <4E643E39.8020205@skype.net> Date: Sun, 04 Sep 2011 20:12:57 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Harald Alvestrand References: <4E259484.20509@ericsson.com>, <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com>, <4E26B742.6050606@jitsi.org>, <62C71813-83B4-44D3-8E54-28262311CDB3@cisco.com> <4E27BE02.7090606@ericsson.com> <9F9278CB1892FB48BF35CB5CC3992478A5395C720E@HKGMBOXPRD01.polycom.com> <4E2EB82C.30709@alvestrand.no> In-Reply-To: <4E2EB82C.30709@alvestrand.no> Content-Type: multipart/alternative; boundary="------------010202020906010705090501" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Support for websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Sep 2011 03:11:59 -0000 This is a multi-part message in MIME format. --------------010202020906010705090501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/26/2011 5:50 AM, Harald Alvestrand wrote: > On 07/26/11 01:28, Avasarala, Ranjit wrote: >> Hi all >> >> By when can we expect WebRTC code (Google code) to support Websockets? > ... > In this forum, it may be appropriate to describe exactly how you see > Websockets fitting in with the RTCWEB specification suite; so far, > it's seemed to be not very closely related. I think there's a legitimate question as to how transmission of media over TCP should work. I believe that the existing code bases all assume that if you get IP addresses, you use them; if you get IP addresses for TURN servers you talk to them over UDP and use TURN for relaying; and if you get IP addresses for TURNS servers you talk to them over TLS/TCP and use them for relaying. Therefore the only TCP transport is TURN-over-TLS-over-TCP. Is that sufficient and reasonable, or should media-over-websockets (or something else) be how TCP transmission of media works? Matthew Kaufman --------------010202020906010705090501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/26/2011 5:50 AM, Harald Alvestrand wrote:
On 07/26/11 01:28, Avasarala, Ranjit wrote: 
Hi all

By when can we expect WebRTC code (Google code) to support Websockets?
...
In this forum, it may be appropriate to describe exactly how you see Websockets fitting in with the RTCWEB specification suite; so far, it's seemed to be not very closely related.

I think there's a legitimate question as to how transmission of media over TCP should work. I believe that the existing code bases all assume that if you get IP addresses, you use them; if you get IP addresses for TURN servers you talk to them over UDP and use TURN for relaying; and if you get IP addresses for TURNS servers you talk to them over TLS/TCP and use them for relaying. Therefore the only TCP transport is TURN-over-TLS-over-TCP.

Is that sufficient and reasonable, or should media-over-websockets (or something else) be how TCP transmission of media works?

Matthew Kaufman
--------------010202020906010705090501-- From harald@alvestrand.no Mon Sep 5 03:07: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 4400421F8715 for ; Mon, 5 Sep 2011 03:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.029 X-Spam-Level: X-Spam-Status: No, score=-107.029 tagged_above=-999 required=5 tests=[AWL=3.569, 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 ancKz8bwUnjg for ; Mon, 5 Sep 2011 03:07:23 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2541A21F84D8 for ; Mon, 5 Sep 2011 03:07:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6BE6539E0FE for ; Mon, 5 Sep 2011 12:07:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjakXC4-gYkG for ; Mon, 5 Sep 2011 12:07:44 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id AB8F839E084 for ; Mon, 5 Sep 2011 12:07:44 +0200 (CEST) Message-ID: <4E649FBD.1090001@alvestrand.no> Date: Mon, 05 Sep 2011 12:09:01 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="------------000001080001060005040600" Subject: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 10:07:24 -0000 This is a multi-part message in MIME format. --------------000001080001060005040600 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit There is a congestion control algorithm inside the Google WebRTC codebase that hasn't been documented publicly before, and might be interesting as input when we get around to discussing what congestion control should be mandatory-to-implement in this group. It's not forwarded as a candidate for what the result should be; I think there can be better solutions (see the "further work" section in this draft). The code is available through www.webrtc.org, and the IPR statements covering the code are found here: https://sites.google.com/site/webrtc/license-rights Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt Date: Mon, 05 Sep 2011 03:03:38 -0700 From: internet-drafts@ietf.org To: harald@alvestrand.no CC: harald@alvestrand.no, holmer@google.com A new version of I-D, draft-alvestrand-rtcweb-congestion-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-rtcweb-congestion Revision: 00 Title: A Google Congestion Control for Real-Time Communication on the World Wide Web Creation date: 2011-09-05 WG ID: Individual Submission Number of pages: 14 Abstract: This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one sender- based and one receiver-based. It is published to aid the discussion on mandatory-to-implement flow control for RTCWEB applications; initial discussion is expected in the RTCWEB WG's mailing list. The IETF Secretariat --------------000001080001060005040600 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit There is a congestion control algorithm inside the Google WebRTC codebase that hasn't been documented publicly before, and might be interesting as input when we get around to discussing what congestion control should be mandatory-to-implement in this group.

It's not forwarded as a candidate for what the result should be; I think there can be better solutions (see the "further work" section in this draft).

The code is available through www.webrtc.org,  and the IPR statements covering the code are found here: https://sites.google.com/site/webrtc/license-rights

                    Harald

-------- Original Message --------
Subject: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt
Date: Mon, 05 Sep 2011 03:03:38 -0700
From: internet-drafts@ietf.org
To: harald@alvestrand.no
CC: harald@alvestrand.no, holmer@google.com 


A new version of I-D, draft-alvestrand-rtcweb-congestion-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.

Filename:	 draft-alvestrand-rtcweb-congestion
Revision:	 00
Title:		 A Google Congestion Control for Real-Time Communication on the World Wide Web
Creation date:	 2011-09-05
WG ID:		 Individual Submission
Number of pages: 14

Abstract:
   This document describes two methods of congestion control when using
   real-time communications on the World Wide Web (RTCWEB); one sender-
   based and one receiver-based.

   It is published to aid the discussion on mandatory-to-implement flow
   control for RTCWEB applications; initial discussion is expected in
   the RTCWEB WG&#39;s mailing list.


                                                                                  


The IETF Secretariat
--------------000001080001060005040600-- From magnus.westerlund@ericsson.com Mon Sep 5 05:02: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 ECD4021F8B24 for ; Mon, 5 Sep 2011 05:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.504 X-Spam-Level: X-Spam-Status: No, score=-106.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 8N7iihMe7ED9 for ; Mon, 5 Sep 2011 05:02:10 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id CDD3721F8B21 for ; Mon, 5 Sep 2011 05:02:09 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-4a-4e64baa83e02 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 96.7B.02839.8AAB46E4; Mon, 5 Sep 2011 14:03:52 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Mon, 5 Sep 2011 14:03:51 +0200 Message-ID: <4E64BAA6.4010200@ericsson.com> Date: Mon, 5 Sep 2011 14:03:50 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Harald Alvestrand References: <4E5F7344.4060803@alvestrand.no> In-Reply-To: <4E5F7344.4060803@alvestrand.no> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New topic: Model for multi-unicast support X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Sep 2011 12:02:11 -0000 On 2011-09-01 13:57, Harald Alvestrand wrote: > In the thread about draft-perkins-rtcweb-usage, the following exchange > took place: >>>> Speaking for some implementors of the WEBRTC API, it's also clear that there's a significant cost to implementing the multiway RTP session concept - both in code complexity and API complexity. I think this warrants more discussion, where all 3 outcomes should be on the table: >>>> >>>> - We recommend doing multi-unicast with a shared RTP session only >>>> - We recommend supporting both shared and split RTP sessions for multi-unicast >>>> - We recommend doing multi-unicast with split RTP sessions only >>>> >>>> We should probably do this in a new thread. >> Indeed; I'd be interested to know what complexity you're seeing. I would have expected the shared RTP session model to decrease complexity, since the RTP layer can be oblivious to the detail of the underlying transport connections, and wouldn't have to worry about tracking SSRC and payload type mapping separately for each session. > I think this is a topic that deserves its own thread. > > The context is use case 4.2.7, "Multiparty video communication", the one > without a central server; each party sends its video and audio streams > to all participants in the meeting directly. > > One can imagine supporting this with a single RTP session, where all > video streams are equal and sent with the same SSRC to all participants, > all participants send receiver reports (RRs) about all the SSRCs they > see to all other participants, and all senders send their SR reports to > all participants. > > Now, this has implications for both API design, service design and > protocol operation. > > API: The model presented is no longer "this object is your connection to > A; that object is your connection to B". There has to be a > representation of your "cloud" as a multidestination object, with > procedures for adding to and subtracting from the list of participants. > Error reporting must include which participant the error relates to. > > Service: The requirement for perfect equality means that you cannot > allow any party to adapt its presence to what it can receive; for > instance, as I understand it, nobody can drop the video and only be an > audio participant, because that would break the model of equality, > rendering sender reports meaningless to some participants. > > Protocol: The requirement for a single agreed RTCP bandwidth means that > this bandwidth has to be computed for the session as a whole - with the > simplistic answer being 5% of the lowest common denominator. I agree with the issues of having it being represented like this. And so far I don't think I have identified a use case that requires a joint RTP session for the multi-unicast case. The centralized mixer use case has certain benefits for a joint RTP session, but there you can apply a RTP mixer to enable difference in service on what being delivered and in what quality to each participant. > > In contrast, if one chooses the multiple-RTP-session approach: > > - the API retains its "one object, one destination" orientation. I mostly agree, there are a few thinks I think it is important to discuss here. And I will have slides on this relation ship for Thursday. > > - the degree to which service is equal to all parties is a matter for > the application, not the protocol Yes, it is not dictated by the protocol, but I don't think the application will be in full control either. It can indicate what is desired, but local and network resources needs to be included in the consideration. > > - rate adaption, choice of RTP bandwidht and so on can be negotiated on > each link individually Yes, but there is clearly a need to take the combinations into account. An issue is clearly that one need to divide the available uplink bit-rate between the streams one needs to send. Another issue is that if one has three peers, and each request a different resolution one may not have the computing resources to encode three versions, and may have to limit it too two resolutions, where one is delivered to two peers. Also the need for joint identifiers between peers for streams that are the same source but may vary in representation likely needs to be kept between the different legs. Otherwise the application logic is > > I think this forum needs to pick one of the options in my initial note, > and design its protocols and APIs accordingly. Sorry, I don't know which initial note you are referencing. But I do think we need to agree on how we handle RTP sessions in relation to the relevant API constructs and what binding between API resources that are needed to allow the lower layer to correctly keep semantics. We will have some opportunity to discuss this on Thursday in the Interim meeting. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Sep 5 05:05: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 4375821F8B3A for ; Mon, 5 Sep 2011 05:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.505 X-Spam-Level: X-Spam-Status: No, score=-106.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 S1qvcuhYrshY for ; Mon, 5 Sep 2011 05:05:57 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 751B421F8B2C for ; Mon, 5 Sep 2011 05:05:57 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-f0-4e64bb8c4d37 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9D.1C.02839.C8BB46E4; Mon, 5 Sep 2011 14:07:41 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Mon, 5 Sep 2011 14:07:40 +0200 Message-ID: <4E64BB8B.2000307@ericsson.com> Date: Mon, 5 Sep 2011 14:07:39 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E5F7344.4060803@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] New topic: Model for multi-unicast support X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Sep 2011 12:05:58 -0000 On 2011-09-03 07:31, Stefan Hkansson LK wrote: > Harald wrote: >> In the thread about draft-perkins-rtcweb-usage, the following >> exchange took place: >>>>> Speaking for some implementors of the WEBRTC API, it's also >>>>> clear that there's a significant cost to implementing the >>>>> multiway RTP session concept - both in code >complexity and >>>>> API complexity. I think this warrants more discussion, where >>>>> all 3 outcomes should be on the table: >>>>> >>>>> - We recommend doing multi-unicast with a shared RTP session >>>>> only - We recommend supporting both shared and split RTP >>>>> sessions for multi-unicast - We recommend doing multi-unicast >>>>> with split RTP sessions only >>>>> >>>>> We should probably do this in a new thread. >>> Indeed; I'd be interested to know what complexity you're seeing. >>> I would have expected the shared RTP session model to decrease >>> complexity, since the RTP layer can be >>oblivious to the detail >>> of the underlying transport connections, and wouldn't have to >>> worry about tracking SSRC and payload type mapping separately for >>> each session. >> I think this is a topic that deserves its own thread. >> >> The context is use case 4.2.7, "Multiparty video communication", >> the one without a central server; each party sends its video and >> audio streams to all participants in the meeting directly. >> >> One can imagine supporting this with a single RTP session, where >> all video streams are equal and sent with the same SSRC to all >> participants, all participants send receiver reports (RRs) about >> all the SSRCs they see to all other participants, and all senders >> send their SR reports to all participants. > > To me an RTP session was connected to a port/IP address, so I don't > understand how this could be one session (the destination port/IP > would be different for each stream). (I expect to be corrected!) Is > multicast assumed? > No, no multicast assumed. This uses the fundamental definition of an RTP session as a joint SSRC space as the basis. What Harald talks about here is what I call multi-unicast, where one basically configure a replication module under the regular RTP/RTCP stack processing to send out each RTP and RTCP packet to multiple destinations using unicast. All incomming traffic would preferably be received on a single port (pair) from the other peers. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From harald@alvestrand.no Mon Sep 5 06:45: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 8EF9421F8B4C for ; Mon, 5 Sep 2011 06:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.132 X-Spam-Level: X-Spam-Status: No, score=-107.132 tagged_above=-999 required=5 tests=[AWL=3.467, 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 S-kT3SLTJJDJ for ; Mon, 5 Sep 2011 06:45:04 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F3EEE21F8B36 for ; Mon, 5 Sep 2011 06:45:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3A9C939E0FE; Mon, 5 Sep 2011 15:45:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTz5-oAsjbHY; Mon, 5 Sep 2011 15:45:29 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id AC81D39E084; Mon, 5 Sep 2011 15:45:29 +0200 (CEST) Message-ID: <4E64D2C6.2020304@alvestrand.no> Date: Mon, 05 Sep 2011 15:46:46 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Magnus Westerlund References: <4E5F7344.4060803@alvestrand.no> <4E64BAA6.4010200@ericsson.com> In-Reply-To: <4E64BAA6.4010200@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New topic: Model for multi-unicast support X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Sep 2011 13:45:04 -0000 On 09/05/11 14:03, Magnus Westerlund wrote: >> > >> > I think this forum needs to pick one of the options in my initial note, >> > and design its protocols and APIs accordingly. > Sorry, I don't know which initial note you are referencing. > From the quoted section in the note that started this thread: > - We recommend doing multi-unicast with a shared RTP session only > - We recommend supporting both shared and split RTP sessions for multi-unicast > - We recommend doing multi-unicast with split RTP sessions only From harald@alvestrand.no Mon Sep 5 08:13: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 31D8E21F8B9D for ; Mon, 5 Sep 2011 08:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.228 X-Spam-Level: X-Spam-Status: No, score=-107.228 tagged_above=-999 required=5 tests=[AWL=3.371, 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 mgrUO23bKyDT for ; Mon, 5 Sep 2011 08:13:10 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 224EE21F8B58 for ; Mon, 5 Sep 2011 08:13:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C026239E048; Mon, 5 Sep 2011 17:14:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL1TDIkc-CLK; Mon, 5 Sep 2011 17:14:52 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 0E6DB39E040; Mon, 5 Sep 2011 17:14:52 +0200 (CEST) Message-ID: <4E64E76B.9090306@alvestrand.no> Date: Mon, 05 Sep 2011 17:14:51 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Magnus Westerlund References: <4E5F7344.4060803@alvestrand.no> <4E64BAA6.4010200@ericsson.com> In-Reply-To: <4E64BAA6.4010200@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New topic: Model for multi-unicast support X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Sep 2011 15:13:11 -0000 On 09/05/11 14:03, Magnus Westerlund wrote: > On 2011-09-01 13:57, Harald Alvestrand wrote: >> In the thread about draft-perkins-rtcweb-usage, the following exchange >> took place: >>>>> Speaking for some implementors of the WEBRTC API, it's also clear that there's a significant cost to implementing the multiway RTP session concept - both in code complexity and API complexity. I think this warrants more discussion, where all 3 outcomes should be on the table: >>>>> >>>>> - We recommend doing multi-unicast with a shared RTP session only >>>>> - We recommend supporting both shared and split RTP sessions for multi-unicast >>>>> - We recommend doing multi-unicast with split RTP sessions only >>>>> >>>>> We should probably do this in a new thread. >>> Indeed; I'd be interested to know what complexity you're seeing. I would have expected the shared RTP session model to decrease complexity, since the RTP layer can be oblivious to the detail of the underlying transport connections, and wouldn't have to worry about tracking SSRC and payload type mapping separately for each session. >> I think this is a topic that deserves its own thread. >> >> The context is use case 4.2.7, "Multiparty video communication", the one >> without a central server; each party sends its video and audio streams >> to all participants in the meeting directly. >> >> One can imagine supporting this with a single RTP session, where all >> video streams are equal and sent with the same SSRC to all participants, >> all participants send receiver reports (RRs) about all the SSRCs they >> see to all other participants, and all senders send their SR reports to >> all participants. >> >> Now, this has implications for both API design, service design and >> protocol operation. >> >> API: The model presented is no longer "this object is your connection to >> A; that object is your connection to B". There has to be a >> representation of your "cloud" as a multidestination object, with >> procedures for adding to and subtracting from the list of participants. >> Error reporting must include which participant the error relates to. >> >> Service: The requirement for perfect equality means that you cannot >> allow any party to adapt its presence to what it can receive; for >> instance, as I understand it, nobody can drop the video and only be an >> audio participant, because that would break the model of equality, >> rendering sender reports meaningless to some participants. >> >> Protocol: The requirement for a single agreed RTCP bandwidth means that >> this bandwidth has to be computed for the session as a whole - with the >> simplistic answer being 5% of the lowest common denominator. > I agree with the issues of having it being represented like this. And so > far I don't think I have identified a use case that requires a joint RTP > session for the multi-unicast case. > > The centralized mixer use case has certain benefits for a joint RTP > session, but there you can apply a RTP mixer to enable difference in > service on what being delivered and in what quality to each participant. > >> In contrast, if one chooses the multiple-RTP-session approach: >> >> - the API retains its "one object, one destination" orientation. > I mostly agree, there are a few thinks I think it is important to > discuss here. And I will have slides on this relation ship for Thursday. Looking forward to it. >> - the degree to which service is equal to all parties is a matter for >> the application, not the protocol > Yes, it is not dictated by the protocol, but I don't think the > application will be in full control either. It can indicate what is > desired, but local and network resources needs to be included in the > consideration. Yes, the application needs to adapt. That's an area where I expect applications to differ, and the successful ones will be the ones that adapt better. >> - rate adaption, choice of RTP bandwidht and so on can be negotiated on >> each link individually > Yes, but there is clearly a need to take the combinations into account. > An issue is clearly that one need to divide the available uplink > bit-rate between the streams one needs to send. Another issue is that if > one has three peers, and each request a different resolution one may not > have the computing resources to encode three versions, and may have to > limit it too two resolutions, where one is delivered to two peers. Yes, the application needs to consider all the factors when negotiating. The typical challenging scenario I see is a 4-way call with 3 participants on the same high speed network and 1 participant calling in from a 3G phone. If the meeting is not called primarily for the guy on the phone, the 3 other participants might want to see each other in full HD and listen to each other using wideband codecs; the 4th one has to make a reasonable apportioning of his bandwidth. > Also the need for joint identifiers between peers for streams that are > the same source but may vary in representation likely needs to be kept > between the different legs. Otherwise the application logic is > >> I think this forum needs to pick one of the options in my initial note, >> and design its protocols and APIs accordingly. > Sorry, I don't know which initial note you are referencing. > > But I do think we need to agree on how we handle RTP sessions in > relation to the relevant API constructs and what binding between API > resources that are needed to allow the lower layer to correctly keep > semantics. > > We will have some opportunity to discuss this on Thursday in the Interim > meeting. From stewe@stewe.org Mon Sep 5 10:07: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 8693821F8B86 for ; Mon, 5 Sep 2011 10:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kV3VvgSv0dK3 for ; Mon, 5 Sep 2011 10:07:55 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id AC7D721F8B85 for ; Mon, 5 Sep 2011 10:07:53 -0700 (PDT) Received: from [192.168.1.62] (unverified [71.202.147.60]) by stewe.org (SurgeMail 3.9e) with ESMTP id 33439-1743317 for multiple; Mon, 05 Sep 2011 19:09:34 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Mon, 05 Sep 2011 10:09:23 -0700 From: Stephan Wenger To: cbran , , , Message-ID: Thread-Topic: [rtcweb] selecting codec for RTCweb? 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] selecting codec for RTCweb? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 17:07:56 -0000 In this context, Alex and myself drafted and presented in Quebec http://www.ietf.org/internet-drafts/draft-wenger-rtcweb-layered-codec-00.tx t, which argues against mandation of codec technologies not supporting scalability. I have not seen any significant discussion in Quebec or on this mailing list about codec selection, though there was some initial noise on this topic during the BOFs. Regards, Stephan On 9.2.2011 17:13 , "cbran" wrote: >Hi YANG, > >On 9/2/11 2:03 AM, "yang.yanzi@zte.com.cn" wrote: > >> >> Dear Magnus and All RTCweb experts, >> >> Was the A/V codec selecting discussed in RTCweb WG? Do you think we >>should >> specify codec selecting for RTCweb in this Wroking Group? >> >Cullen and I submitted this draft proposal regarding rtc-web and the A/V >codec support. > >http://tools.ietf.org/html/draft-cbran-rtcweb-codec-00 > >I presented this at IETF 81 and will be sending out an update with >feedback >I have received. > > >> >> >> >> It's greatly appreciated if you response even though it has been >>discussed >> before. >> Thanks alot. >> >> >> Best Regards, >> YANG Yanzi >> >> >> _______________________________________________ >> 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 pravindran@sonusnet.com Mon Sep 5 12:14: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 81B4B21F8BA6 for ; Mon, 5 Sep 2011 12:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120, 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 oicGBV0mCk3T for ; Mon, 5 Sep 2011 12:14:29 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 45CB821F8B80 for ; Mon, 5 Sep 2011 12:14:29 -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 p85JGeJm019674; Mon, 5 Sep 2011 15:16:41 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Sep 2011 15:16:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6C00.43F4AACE" Date: Tue, 6 Sep 2011 00:46:08 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver Thread-Index: Acxjrn+fkEqucGj3QAyVQKFs0Fq8LwITx5QQ References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: "Bernard Aboba" , , X-OriginalArrivalTime: 05 Sep 2011 19:16:11.0435 (UTC) FILETIME=[45D5EFB0:01CC6C00] Subject: Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 05 Sep 2011 19:14:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6C00.43F4AACE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard, =20 Sorry for the delay reply. =20 There is a huge difference between tunneling the protocol and converting the protocol from one format to another. The tunneling works well only in case the destination support the tunneled data without negotiation. It will be bad assumption in case the standard does not defined so. For example,=20 =20 1) Browser A supports Jingle (XMPP for real-time data) and encapsulates the data in HTTP and send it to webserver1 2) RTCwebserver1 tunnel jingle data in SIP and sends it to RTCwebserver2 3) RTCwebserver2 does not support Jingle towards browser but it support some other variant of HTTP based metadata to the browser.=20 My question is how webserver2 do perform the interop correctly in case Jingle is not mandated as metadata standard mechanism. Please let me know your opinion here. =20 My understanding was that RTCwebserver1 may use some proprietary mechanism (may be jingle) to communicate between browser and webserver which will be converted into RFC 3261 SIP at webserver1 and forwarded to RTCwebserver2. RTCWebserver2 converts back SIP to its own proprietary metadata to communicate with browser. This mechanism works well but still better mechanism exists. =20 Thanks Partha =20 =20 =20 =20 From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Friday, August 26, 2011 12:35 AM To: Ravindran Parthasarathi; hoang.su.tk@gmail.com; rtcweb@ietf.org Subject: RE: [rtcweb] Some misunderstandings about =20 > The issue in case webserver acts as new RTCWEB & SIP GW for VoIP > communication, there is a need of protocol mapping between the protocol > used between browser & RTCWebserver (say RTCweb protocol) to SIP.=20 =20 [BA] Not necessarily. For example, in the case of XMPP, BOSH can be used to encapsulate XMPP over HTTP. The BOSH Connection Manager/Web server does not do "mapping", it just encapsulates/decapsulates XMPP stanzas,=20 enabling communication between XMPP clients supporting BOSH and=20 XMPP servers. This be handled entirely in Javascript with no native support for XMPP.=20 =20 For detailed examples of how this works (with sample code), please see: http://professionalxmpp.com/ ------_=_NextPart_001_01CC6C00.43F4AACE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bernard,

 

Sorry for the delay reply.

 

There is a huge difference between tunneling the protocol = and converting the protocol from one format to another. The tunneling works = well only in case the destination support the tunneled data without = negotiation. It will be bad assumption in case the standard does not defined so. =  For example,

 

1)      Browser A supports Jingle (XMPP for real-time data) and encapsulates the data in HTTP and send it to = webserver1

2)      RTCwebserver1 tunnel jingle data in SIP and sends it to = RTCwebserver2

3)      RTCwebserver2 does not support Jingle towards browser but = it support some other variant of HTTP based metadata to the browser. =

My question is how webserver2 do perform the interop = correctly in case Jingle is not mandated as metadata standard mechanism. Please = let me know your opinion here.

 

My understanding was that RTCwebserver1 may use some = proprietary mechanism (may be jingle) to communicate between browser and webserver = which will be converted into RFC 3261 SIP at webserver1 and forwarded to = RTCwebserver2. RTCWebserver2 converts back SIP to its own proprietary metadata to = communicate with browser. This mechanism works well but still better mechanism = exists.

 

Thanks

Partha

 

 

 

 

From:= Bernard = Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Friday, August 26, 2011 12:35 AM
To: Ravindran Parthasarathi; hoang.su.tk@gmail.com; = rtcweb@ietf.org
Subject: RE: [rtcweb] Some misunderstandings about <Usecase = & architecture: Browser application with separate webserver & = voipserver>

 

> The issue in case webserver acts as new RTCWEB & SIP GW for VoIP
> communication, there is a need of protocol mapping between the = protocol
> used between browser & RTCWebserver (say RTCweb protocol) to = SIP.
 
[BA] Not necessarily.  For example, in the case of XMPP, BOSH can = be used
to encapsulate XMPP over HTTP.  The BOSH Connection Manager/Web = server
does not do "mapping", it just encapsulates/decapsulates = XMPP stanzas,
enabling communication between XMPP clients supporting BOSH and =
XMPP servers.   This be handled entirely in Javascript with no = native
support for XMPP.
 
For detailed examples of how this works (with sample code), please = see:
http://professionalxmpp.com/

------_=_NextPart_001_01CC6C00.43F4AACE-- From harald@alvestrand.no Mon Sep 5 13:10: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 AC49C21F8A55 for ; Mon, 5 Sep 2011 13:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.39 X-Spam-Level: X-Spam-Status: No, score=-106.39 tagged_above=-999 required=5 tests=[AWL=4.209, 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 4ybhIdsHn0ZH for ; Mon, 5 Sep 2011 13:10:54 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 09BAE21F8A1A for ; Mon, 5 Sep 2011 13:10:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4104139E050 for ; Mon, 5 Sep 2011 22:12:29 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xasZX+EgnMug for ; Mon, 5 Sep 2011 22:12:28 +0200 (CEST) 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 94D3239E040 for ; Mon, 5 Sep 2011 22:12:28 +0200 (CEST) Message-ID: <4E652D2C.8080408@alvestrand.no> Date: Mon, 05 Sep 2011 22:12:28 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] selecting codec for RTCweb? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 20:10:54 -0000 On 09/05/2011 07:09 PM, Stephan Wenger wrote: > In this context, Alex and myself drafted and presented in Quebec > http://www.ietf.org/internet-drafts/draft-wenger-rtcweb-layered-codec-00.tx > t, which argues against mandation of codec technologies not supporting > scalability. I have not seen any significant discussion in Quebec or on > this mailing list about codec selection, though there was some initial > noise on this topic during the BOFs. The other consideration that has been raised is, of course, the issue of license-insisted-on versus practiced-without-a-license codecs (I won't call them "license required" or "license free"; that would be presumptuous.) I believe we need a baseline codec that is "good enough", but I have neither a clear picture on how to quantify "good enough", nor a conviction that the scalability advantages raised in draft-wenger are important enough to tilt the balance. Harald From stewe@stewe.org Mon Sep 5 16:46:02 2011 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 78A551B60AD3 for ; Mon, 5 Sep 2011 16:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDearAJ8bveQ for ; Mon, 5 Sep 2011 16:46:01 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfc.amsl.com (Postfix) with ESMTP id 6D7381B60ACA for ; Mon, 5 Sep 2011 16:45:57 -0700 (PDT) Received: from [192.168.1.62] (unverified [71.202.147.60]) by stewe.org (SurgeMail 3.9e) with ESMTP id 33551-1743317 for multiple; Tue, 06 Sep 2011 00:27:55 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Mon, 05 Sep 2011 15:27:42 -0700 From: Stephan Wenger To: Harald Alvestrand , Message-ID: Thread-Topic: [rtcweb] selecting codec for RTCweb? In-Reply-To: <4E652D2C.8080408@alvestrand.no> 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] selecting codec for RTCweb? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 23:46:02 -0000 On 9.5.2011 13:12 , "Harald Alvestrand" wrote: >On 09/05/2011 07:09 PM, Stephan Wenger wrote: >> In this context, Alex and myself drafted and presented in Quebec >> >>http://www.ietf.org/internet-drafts/draft-wenger-rtcweb-layered-codec-00. >>tx >> t, which argues against mandation of codec technologies not supporting >> scalability. I have not seen any significant discussion in Quebec or on >> this mailing list about codec selection, though there was some initial >> noise on this topic during the BOFs. >The other consideration that has been raised is, of course, the issue of >license-insisted-on versus practiced-without-a-license codecs (I won't >call them "license required" or "license free"; that would be >presumptuous.) > >I believe we need a baseline codec that is "good enough", but I have >neither a clear picture on how to quantify "good enough", nor a >conviction that the scalability advantages raised in draft-wenger are >important enough to tilt the balance. Hi Harald, What you write above is IMO a reasonable position only if you are convinced that "practiced-without-a-license" has a sustainable mid-to long-term perspective. With respect to VP8, I'm not convinced, for a number of reasons, some of which I could talk publicly about when asked (though I prefer not to load up this list with my arguments, and, therefore, don't volunteer them now). Based on my current knowledge, I could accept H.261 and H.263 as being "practiced-witout-a-license", but those two are probably not considered "good enough" anymore by many here. Btw., I like your "practiced-without-a-license" formulation, but note that H.264 and its profiles (including commercially highly relevant profiles such as High Profile) is occasionally also practiced without a license, as a few open source projects in this field indicate. Whether this is a particularly good business choice depends on the business model of the person making or using H.264 based systems. Similarly, there are (and have been for a while) indications that VP8 could soon fall in the "license-insisted-on" category, in which case the prudence of practicing VP8 without entering in license(s) also depends on the business model... Stephan > > Harald > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From matthew.kaufman@skype.net Mon Sep 5 20:36: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 04E8C21F841A for ; Mon, 5 Sep 2011 20:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.723 X-Spam-Level: X-Spam-Status: No, score=-4.723 tagged_above=-999 required=5 tests=[AWL=1.875, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-zy4nBpsjBl for ; Mon, 5 Sep 2011 20:36:30 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9D59321F8443 for ; Mon, 5 Sep 2011 20:36:26 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id B16177FC; Tue, 6 Sep 2011 05:38:08 +0200 (CEST) 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; s=mx; bh=Zltpt0Yu3SRtnS5eLCtu0KG1vHo=; b=hCu4H0EJH wWpQxnOhrxPW3zO//D63GRZRBdmgOlqRVPziwGKnsIkTHmfUQFu/YNkcmqJwl1uE FQUGzT0c0w3XOGO3vz3roXTnLqrH0zG+IFxfkgj0JSSk1sgdMl+xPf9POzNmUs1Z hnpe0Xv8ZY+BzEx9TQdzlwpDA8rKAtcGsc= 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; q=dns; s=mx; b=EVOPKqneiPmbLvawFS63ukbm+dUU/hdpRR+uUYa+puMR61BX NhzKq0Bnub978j/jZ9XoZCVld6ZWOiUZwBlE+HABDoYIw5QeCpyyR4nKh4zOIZmm Fp2RN32osfFSY/XxnQk0BVHNvDusBq6j8oECOCBb35Zo5yyLdXD76aNmX9A= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id AF61C7F6; Tue, 6 Sep 2011 05:38:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 888C93507345; Tue, 6 Sep 2011 05:38:08 +0200 (CEST) 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 gZ2LRSgNnohT; Tue, 6 Sep 2011 05:38:07 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 7A0183507061; Tue, 6 Sep 2011 05:38:06 +0200 (CEST) Message-ID: <4E659576.1000301@skype.net> Date: Mon, 05 Sep 2011 20:37:26 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Ravindran Parthasarathi References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> Content-Type: multipart/alternative; boundary="------------040105050203060104060003" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 03:36:41 -0000 This is a multi-part message in MIME format. --------------040105050203060104060003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/5/2011 12:16 PM, Ravindran Parthasarathi wrote: > > Bernard, > > Sorry for the delay reply. > > There is a huge difference between tunneling the protocol and > converting the protocol from one format to another. The tunneling > works well only in case the destination support the tunneled data > without negotiation. It will be bad assumption in case the standard > does not defined so. For example, > > 1)Browser A supports Jingle (XMPP for real-time data) and encapsulates > the data in HTTP and send it to webserver1 > That isn't how it works. Browser A supports WebRTC. Do you mean browser A is running Javascript that implements Jingle or something similar for its signaling (over HTTP and/or Websockets) to its associated web server? > 2)RTCwebserver1 tunnel jingle data in SIP and sends it to RTCwebserver2 > Federation between webserver1 and webserver2 is up to the operators of those sites. Presumably SIP is a good (but not only) choice for federation. Many sites won't have a desire or need to federate. > 3)RTCwebserver2 does not support Jingle towards browser but it support > some other variant of HTTP based metadata to the browser. > Do you mean that webserver2 and its clients are running compatible code that exchanges signaling via a mechanism other than Jingle? That's fine, and up to the operator of that site. > My question is how webserver2 do perform the interop correctly in case > Jingle is not mandated as metadata standard mechanism. Please let me > know your opinion here. > Every site that wishes to federate with others will need to choose a signaling protocol that is agreed between them. > My understanding was that RTCwebserver1 may use some proprietary > mechanism (may be jingle) to communicate between browser and webserver > which will be converted into RFC 3261 SIP at webserver1 and forwarded > to RTCwebserver2. RTCWebserver2 converts back SIP to its own > proprietary metadata to communicate with browser. This mechanism works > well but still better mechanism exists. > That understanding appears to be correct. This is exactly the same as "Hotmail talks some proprietary protocol over HTTP between its HTML/Javascript client and its servers which is then converted to SMTP for sending to Gmail, where Gmail talks a different proprietary protocol over HTTP between its HTML/Javascript client and its servers." It appears to have resulted in some significant innovations in the email service space, while still allowing federation between domains using a standard protocol. If you think this is a bad idea, provide an alternative we might discuss. Matthew Kaufman --------------040105050203060104060003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/5/2011 12:16 PM, Ravindran Parthasarathi wrote:

Bernard,

 

Sorry for the delay reply.

 

There is a huge difference between tunneling the protocol and converting the protocol from one format to another. The tunneling works well only in case the destination support the tunneled data without negotiation. It will be bad assumption in case the standard does not defined so.  For example,

 

1)      Browser A supports Jingle (XMPP for real-time data) and encapsulates the data in HTTP and send it to webserver1


That isn't how it works. Browser A supports WebRTC. Do you mean browser A is running Javascript that implements Jingle or something similar for its signaling (over HTTP and/or Websockets) to its associated web server?

2)      RTCwebserver1 tunnel jingle data in SIP and sends it to RTCwebserver2


Federation between webserver1 and webserver2 is up to the operators of those sites. Presumably SIP is a good (but not only) choice for federation. Many sites won't have a desire or need to federate.

3)      RTCwebserver2 does not support Jingle towards browser but it support some other variant of HTTP based metadata to the browser.


Do you mean that webserver2 and its clients are running compatible code that exchanges signaling via a mechanism other than Jingle? That's fine, and up to the operator of that site.

My question is how webserver2 do perform the interop correctly in case Jingle is not mandated as metadata standard mechanism. Please let me know your opinion here.


Every site that wishes to federate with others will need to choose a signaling protocol that is agreed between them.

 

My understanding was that RTCwebserver1 may use some proprietary mechanism (may be jingle) to communicate between browser and webserver which will be converted into RFC 3261 SIP at webserver1 and forwarded to RTCwebserver2. RTCWebserver2 converts back SIP to its own proprietary metadata to communicate with browser. This mechanism works well but still better mechanism exists.


That understanding appears to be correct. This is exactly the same as "Hotmail talks some proprietary protocol over HTTP between its HTML/Javascript client and its servers which is then converted to SMTP for sending to Gmail, where Gmail talks a different proprietary protocol over HTTP between its HTML/Javascript client and its servers." It appears to have resulted in some significant innovations in the email service space, while still allowing federation between domains using a standard protocol.

If you think this is a bad idea, provide an alternative we might discuss.

Matthew Kaufman

--------------040105050203060104060003-- From matthew.kaufman@skype.net Mon Sep 5 20:38: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 0C22E21F841A for ; Mon, 5 Sep 2011 20:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.834 X-Spam-Level: X-Spam-Status: No, score=-4.834 tagged_above=-999 required=5 tests=[AWL=1.764, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgiKX1yVkyff for ; Mon, 5 Sep 2011 20:38:17 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id E1C2521F8419 for ; Mon, 5 Sep 2011 20:38:16 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id DECA97FC; Tue, 6 Sep 2011 05:40:01 +0200 (CEST) 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; s=mx; bh=NeoZm4bMSwUuSkvgYXYOOrHaPRo=; b=cHVfKAw8+ JKShJNlEjFX4+PBPSSLdxbFxsib1E5mEKLLI8i/VpWj3k3E42ySz5tajW1pxn52m eoairctCcM21UL3rB5oNl++WpzjJb4N6Y5cIKokfpW9iQCwx8dAb0P5EM1aYIbnd lawuxizJr2MGhY20JV6R/Cdxs7YgEfH1IY= 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; q=dns; s=mx; b=MUFkKPgemMZ3avnNQClH0rSBPlJkhI2sCLpM6yMnKdL4j/RO g1hMb24nDisxXyQPi1kqEp4DTaFmHEBHkEwBLixUJEHHvFXQjdysPKRkXZJw+HkL FbdE3xpQtE82Q7Gz0QbzkKvcbNgV9/qCnwvVpF1jLfpEVJAMKaxHuLemUaM= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id DD3CB7F6; Tue, 6 Sep 2011 05:40:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id A10C63507386; Tue, 6 Sep 2011 05:40:01 +0200 (CEST) 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 VPHJxmyoqD15; Tue, 6 Sep 2011 05:40:00 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 365B83507061; Tue, 6 Sep 2011 05:39:59 +0200 (CEST) Message-ID: <4E6595E7.7060503@skype.net> Date: Mon, 05 Sep 2011 20:39:19 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> Content-Type: multipart/alternative; boundary="------------040906050803010102040805" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 03:38:18 -0000 This is a multi-part message in MIME format. --------------040906050803010102040805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/23/2011 5:57 PM, Ravindran Parthasarathi wrote: > > I'm interested in hearing the reasons for why SIP MUST NOT be used in > browser. > The primary reason for avoiding a protocol like SIP between the web browser and its associated server(s) is that adding *any* functionality requires a round of standardization effort, whereas following the web model (HTML and Javascript in the clients, arbitrary signaling over HTTP) allows for immediate and frequent innovation on that channel. Matthew Kaufman --------------040906050803010102040805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 8/23/2011 5:57 PM, Ravindran Parthasarathi wrote:

 

I’m interested in hearing the reasons for why SIP MUST NOT be used in browser.

 


The primary reason for avoiding a protocol like SIP between the web browser and its associated server(s) is that adding *any* functionality requires a round of standardization effort, whereas following the web model (HTML and Javascript in the clients, arbitrary signaling over HTTP) allows for immediate and frequent innovation on that channel.

Matthew Kaufman

--------------040906050803010102040805-- From matthew.kaufman@skype.net Mon Sep 5 20:41: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 6DCAC21F844C for ; Mon, 5 Sep 2011 20:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.932 X-Spam-Level: X-Spam-Status: No, score=-4.932 tagged_above=-999 required=5 tests=[AWL=1.667, 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 NfYOYqYMwCLt for ; Mon, 5 Sep 2011 20:41:33 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id BE94F21F844D for ; Mon, 5 Sep 2011 20:41:33 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id BF5347FC; Tue, 6 Sep 2011 05:43:18 +0200 (CEST) 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=idH2T2r3qlmXgN 18/xAkc0vdiYs=; b=rMVznjEWXCzPypk4nRzbbg55IPslv3BBmjE+EQpoiaPVZ+ Sd9okOZ6W0moCfGPkhgfG/T1EiHpICl49qBj3x43jjAYkVhAn0g31+vXcjN6/a6/ cFciHNlE4I7BS/Qbiy+uhoILYbjDbcINGSKHqZVkJSwzOhe2Atf57HqjOt7Xs= 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=ZF+pKXtIN8tD91XQx+54+j SINBdds/5x62Py5lzLaGG6aKORL46MormTZetADFkTZxgptJhKIOSIXgc7Ts3X+2 NlVOcpvJDn2zW4IOo6rY37GQhR2gW1cdJuSm1jsWu+UWO31XPk0GNtlKOz/jOud0 LMSGHnVnQ7+vhG5c2tnYc= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id BDA6E7F6; Tue, 6 Sep 2011 05:43:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id A39383506FC6; Tue, 6 Sep 2011 05:43:18 +0200 (CEST) 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 xahevFneRmc6; Tue, 6 Sep 2011 05:43:18 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 46A143506E2E; Tue, 6 Sep 2011 05:43:17 +0200 (CEST) Message-ID: <4E6596AD.6010307@skype.net> Date: Mon, 05 Sep 2011 20:42:37 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Justin Uberti References: <4E4FE6D3.3000409@alvestrand.no> <4E50F3B7.9020902@alvestrand.no> <2014B96E-BD04-4EA4-8EC2-C42C428E90E5@cisco.com> <4E54ADB7.8000800@alvestrand.no> <4E54C5FE.7030504@ericsson.com> <4E54C72F.7030004@alvestrand.no> <4E550112.4070601@alvestrand.no> <4E555B63.2080505@jesup.org> <4E565EB8.6080603@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" , public-webrtc@w3.org Subject: Re: [rtcweb] Mapping of media streams to RTP (Re: Query: What does "context" mean in the context (sic) of requirement A15? [ACTION-6]) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 03:41:34 -0000 On 8/25/2011 4:15 PM, Justin Uberti wrote: > SSRCs are the easiest thing to demux on, and everything will be much > simpler if we exchange the SSRCs in signaling. Agree. We have a signaling mechanism already for every end of every connection, should be trivial to specify the SSRC that should be used for each media stream. Especially if we stop with the SDP nonsense. Matthew Kaufman From csp@csperkins.org Tue Sep 6 03:39: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 DDFA221F85A1 for ; Tue, 6 Sep 2011 03:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.491 X-Spam-Level: X-Spam-Status: No, score=-103.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkqHSBay-bQP for ; Tue, 6 Sep 2011 03:39:26 -0700 (PDT) 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 AE55F21F8586 for ; Tue, 6 Sep 2011 03:39:25 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R0t5a-0005MU-mK; Tue, 06 Sep 2011 10:41:11 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-117--156462467 From: Colin Perkins In-Reply-To: Date: Tue, 6 Sep 2011 11:41:10 +0100 Message-Id: References: <4E610B78.7000103@skype.net> <4E615505.70508@jesup.org> To: Justin Uberti X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] PeerConnection Data Channel X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 10:39:27 -0000 --Apple-Mail-117--156462467 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 3 Sep 2011, at 04:46, Justin Uberti wrote: > On Fri, Sep 2, 2011 at 8:13 PM, Bernard Aboba = wrote: > > >> Section 5 in the WEBRTC spec=20 > > >> (http://dev.w3.org/2011/webrtc/editor/webrtc.html) discusses at=20= > > >> length a mechanism for transmitting and securing datagrams over = the=20 > > >> PeerConnection transport.=20 >=20 > [BA] The objective here appears to be "masking" (e.g. to prevent = sending of arbitrary datagrams) rather than providing a full set of = security services.=20 >=20 > The current spec provides an encryption and authentication mechanism, = in addition to the masking. =46rom the spec: "The data is made to appear = pseudo-random, so that it cannot be used in a cross-protocol attack, = even if somehow the stream were to be directed at an unsuspecting remote = host. The data is hashed in such a way that it cannot be modified in = transit. That data is encrypted so that it cannot be read in transit." >=20 > > > > At both an API and a wire level, this=20 > > >> mechanism is quite different from the existing mechanisms that = are=20 > > >> used for transmission of audio and video data: > > >> - The availability of the data stream is not easily known, = whereas=20 > > >> audio/video can be negotiated and stream existence learned from = the=20 > > >> *Stream methods/callbacks. >=20 > [BA] It looked to me that the data channel was negotiated in SDP, no? >=20 > Yes. But the API doesn't expose whether the data channel was = successfully negotiated.=20 >=20 > > >> - It defines its own encryption mechanism, whereas audio/video = will=20 > > >> use SDES-SRTP, or DTLS-SRTP >=20 > [BA] I don't believe that the objective here is to duplicate the = security services in SRTP, DTLS, TLS, IPsec or any other comprehensive = security framework.=20 > It's closer to the "masking" supported by WebSockets. =20 >=20 > That's not my understanding of the spec, as evidenced above. > =20 >=20 >=20 > > >> - This stream will show up in SDP >=20 > [BA] I believe that's what the current spec already says.=20 >=20 > > > Disagree. RTP semantics are inappropriate for sending data. The = data=20 > > > should be sent using one of the two methods for muxing data that = were=20 > > > proposed (one by me, one by cbran). >=20 > [BA] Agree that RTP semantics aren't necessarily appropriate for non = media-stream data.=20 >=20 > Yeah, I admit my original opinion on this was that RTP was crazy. But = looking at it more, we're going to end up duplicating much of what RTP = provides - Matthew's proposal adds a 4 byte header to distinguish it = from STUN, and we probably also need a stream id and a sequence number = (for TFRC). At that point we're only a timestamp away from a full RTP = header. ...and a payload type, contributing source list, header extensions, a = bunch of semantics relating to timing and media playout, and the whole = of RTCP. RTP is not just a data header format. --=20 Colin Perkins http://csperkins.org/ --Apple-Mail-117--156462467 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Fri, = Sep 2, 2011 at 8:13 PM, Bernard Aboba <bernard_aboba@hotmail.com>= ; wrote:
> >> Section 5 in the WEBRTC spec
> >> (http://dev.w3.org/2011/webrtc/editor/webrtc.html) = discusses at
> >> length a mechanism for transmitting and = securing datagrams over the
> >> PeerConnection = transport. 

[BA] The objective here = appears to be "masking" (e.g. to prevent sending of arbitrary datagrams) = rather than providing a full set of security services. 

The current spec provides = an encryption and authentication mechanism, in addition to the masking. = =46rom the spec: "The data is made to appear pseudo-random, so that it = cannot be used in a cross-protocol attack, even if somehow the stream = were to be directed at an unsuspecting remote host. The data is hashed = in such a way that it cannot be modified in transit. That data is = encrypted so that it cannot be read in transit."

> > > At both = an API and a wire level, this
> >> mechanism is quite = different from the existing mechanisms that are
> >> used for transmission of audio and video = data:
> >> - The availability of the data stream is = not easily known, whereas
> >> audio/video can be = negotiated and stream existence learned from the
> >> *Stream = methods/callbacks.

[BA] It looked to me = that the data channel was negotiated in SDP, = no?

Yes. But the API = doesn't expose whether the data channel was successfully = negotiated. 

> >> - It defines its = own encryption mechanism, whereas audio/video will
> >> use SDES-SRTP, or DTLS-SRTP

[BA] I = don't believe that the objective here is to duplicate the security = services in SRTP, DTLS, TLS, IPsec or any other comprehensive security = framework. 
It's closer to the "masking" supported by WebSockets. =  

That's not my = understanding of the spec, as evidenced = above.
 


> >> - This = stream will show up in SDP

[BA] I believe that's = what the current spec already says. 

> > Disagree. RTP semantics are inappropriate = for sending data. The data
> > should be sent using one of the = two methods for muxing data that were
> > proposed (one by me, = one by cbran).

[BA] Agree that RTP semantics aren't necessarily = appropriate for non media-stream = data. 

Yeah, I = admit my original opinion on this was that RTP was crazy. But looking at = it more, we're going to end up duplicating much of what RTP provides - = Matthew's proposal adds a 4 byte header to distinguish it from STUN, and = we probably also need a stream id and a sequence number (for TFRC). At = that point we're only a timestamp away from a full RTP = header.

...and a payload = type, contributing source list, header extensions, a bunch of semantics = relating to timing and media playout, and the whole of RTCP. RTP is not = just a data header format.

http://csperkins.org/



= --Apple-Mail-117--156462467-- From csp@csperkins.org Tue Sep 6 04:11: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 B164821F8640 for ; Tue, 6 Sep 2011 04:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.501 X-Spam-Level: X-Spam-Status: No, score=-103.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 d16MquIYgsmp for ; Tue, 6 Sep 2011 04:11:17 -0700 (PDT) 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 8D56921F855F for ; Tue, 6 Sep 2011 04:11:17 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R0taR-0001zr-ka; Tue, 06 Sep 2011 11:13:03 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4E5F7344.4060803@alvestrand.no> Date: Tue, 6 Sep 2011 12:13:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0D9019B2-B788-422E-82AC-03FB3585A743@csperkins.org> References: <4E5F7344.4060803@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] New topic: Model for multi-unicast support X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 11:11:19 -0000 On 1 Sep 2011, at 12:57, Harald Alvestrand wrote: > In the thread about draft-perkins-rtcweb-usage, the following exchange = took place: >>> > Speaking for some implementors of the WEBRTC API, it's also clear = that there's a significant cost to implementing the multiway RTP session = concept - both in code complexity and API complexity. I think this = warrants more discussion, where all 3 outcomes should be on the table: >>> > > - We recommend doing multi-unicast with a shared RTP session = only >>> > - We recommend supporting both shared and split RTP sessions for = multi-unicast >>> > - We recommend doing multi-unicast with split RTP sessions only >>> > > We should probably do this in a new thread. >> Indeed; I'd be interested to know what complexity you're seeing. I = would have expected the shared RTP session model to decrease complexity, = since the RTP layer can be oblivious to the detail of the underlying = transport connections, and wouldn't have to worry about tracking SSRC = and payload type mapping separately for each session. > I think this is a topic that deserves its own thread. >=20 > The context is use case 4.2.7, "Multiparty video communication", the = one without a central server; each party sends its video and audio = streams to all participants in the meeting directly. >=20 > One can imagine supporting this with a single RTP session, where all = video streams are equal and sent with the same SSRC to all participants, = all participants send receiver reports (RRs) about all the SSRCs they = see to all other participants, and all senders send their SR reports to = all participants. >=20 > Now, this has implications for both API design, service design and = protocol operation. >=20 > API: The model presented is no longer "this object is your connection = to A; that object is your connection to B". There has to be a = representation of your "cloud" as a multidestination object, with = procedures for adding to and subtracting from the list of participants. = Error reporting must include which participant the error relates to. Agree. This is the model RTP suggests for a session: a = group-communication cloud, with the details of whether that's = implemented as a single point-to-point flow, a centralised mixer, = multi-unicast, or a multicast group being hidden below the RTP layer.=20 You can model transport layer flow as its own RTP session, but then you = get into coordination issues between the RTP sessions. Also, it doesn't = solve the issue that "your connection to B" is not necessarily = meaningful, it B is a reflector that expands to multiple participants. > Service: The requirement for perfect equality means that you cannot = allow any party to adapt its presence to what it can receive; for = instance, as I understand it, nobody can drop the video and only be an = audio participant, because that would break the model of equality, = rendering sender reports meaningless to some participants. This is why audio and video are usually sent in separate RTP sessions.=20= > Protocol: The requirement for a single agreed RTCP bandwidth means = that this bandwidth has to be computed for the session as a whole - with = the simplistic answer being 5% of the lowest common denominator. This is a problem if you have flows with significantly different rates = in the same RTP session, yes. > In contrast, if one chooses the multiple-RTP-session approach: >=20 > - the API retains its "one object, one destination" orientation. >=20 > - the degree to which service is equal to all parties is a matter for = the application, not the protocol >=20 > - rate adaption, choice of RTP bandwidht and so on can be negotiated = on each link individually >=20 > I think this forum needs to pick one of the options in my initial = note, and design its protocols and APIs accordingly. > Thoughts? I'm not sure it's a simple as picking one model or the other. There are = some scenarios where the model of a single RTP session across multiple = transport-layer flows makes a lot of sense (e.g., centralised = conferences using a mixer, for the reasons described in RFC 5117), but = in other cases there are stronger arguments for treating each transport = layer flow separately (e.g., multi-unicast, if you're multiplexing audio = and video in a single session, and sending only a subset of media flows = to some of the participants). A better model might be to provide an = appropriate RTP session API, plus a higher layer API that manages the = grouping of RTP sessions into a single multimedia conference.=20 This would also make legacy interoperability easier, since there are = legacy systems that use both the single RTP session and multiple RTP = sessions models. Colin --=20 Colin Perkins http://csperkins.org/ From igor.faynberg@alcatel-lucent.com Tue Sep 6 06:11: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 B96DA21F86A0 for ; Tue, 6 Sep 2011 06:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.605 X-Spam-Level: X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytKIO3kYBlFM for ; Tue, 6 Sep 2011 06:11:57 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id C8C6E21F86DD for ; Tue, 6 Sep 2011 06:11:57 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p86DDfvG024575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2011 08:13:41 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p86DDePS021761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Sep 2011 08:13:41 -0500 Received: from [135.244.40.187] (faynberg.lra.lucent.com [135.244.40.187]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p86DDd3n003565; Tue, 6 Sep 2011 08:13:40 -0500 (CDT) Message-ID: <4E661C83.5000103@alcatel-lucent.com> Date: Tue, 06 Sep 2011 09:13:39 -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: Matthew Kaufman References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> In-Reply-To: <4E6595E7.7060503@skype.net> Content-Type: multipart/alternative; boundary="------------060602050607000503040302" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] 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, 06 Sep 2011 13:11:58 -0000 This is a multi-part message in MIME format. --------------060602050607000503040302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I find this reasoning hard to understand. First, the SIP standard has been around for a decade. What new standardization is needed? Igor On 9/5/2011 11:39 PM, Matthew Kaufman wrote: > On 8/23/2011 5:57 PM, Ravindran Parthasarathi wrote: >> >> I'm interested in hearing the reasons for why SIP MUST NOT be used in >> browser. >> > > The primary reason for avoiding a protocol like SIP between the web > browser and its associated server(s) is that adding *any* > functionality requires a round of standardization effort, whereas > following the web model (HTML and Javascript in the clients, arbitrary > signaling over HTTP) allows for immediate and frequent innovation on > that channel. > > Matthew Kaufman > --------------060602050607000503040302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I find this reasoning hard to understand.  First, the SIP standard has been around for a decade. What new standardization is needed?

Igor

On 9/5/2011 11:39 PM, Matthew Kaufman wrote:
On 8/23/2011 5:57 PM, Ravindran Parthasarathi wrote:

 

I’m interested in hearing the reasons for why SIP MUST NOT be used in browser.

 


The primary reason for avoiding a protocol like SIP between the web browser and its associated server(s) is that adding *any* functionality requires a round of standardization effort, whereas following the web model (HTML and Javascript in the clients, arbitrary signaling over HTTP) allows for immediate and frequent innovation on that channel.

Matthew Kaufman

--------------060602050607000503040302-- From fluffy@cisco.com Tue Sep 6 07:44: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 74E7F21F8ADC for ; Tue, 6 Sep 2011 07:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.311 X-Spam-Level: X-Spam-Status: No, score=-103.311 tagged_above=-999 required=5 tests=[AWL=-0.712, 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 hdShcv6vyooB for ; Tue, 6 Sep 2011 07:44:36 -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 E404521F8AD3 for ; Tue, 6 Sep 2011 07:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3382; q=dns/txt; s=iport; t=1315320383; x=1316529983; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=bKa7VmQv7caUCxKRzKQaFZWW5xzUTIlpP9Y7bmltpwY=; b=cT8hzHUHfOHAmY06kAyU9E6vLKy8uDdJNV8hijg9+SCH/xDoyDiAmR4z vnLinjTiNC9u2BXdF11aE6+zf6cBhh/50rAqgo2X3cS+tXv2zoPvO12PH pyUflENV8581YUhzuty5TZMVJjrlGYfmS3Sk85Dt3aENaNIlac2v/a15L A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAGExZk6rRDoI/2dsb2JhbABCqAF4gV8BJ4IyoQiBIwGfFoYKYASHa4tDhQ+MHQ X-IronPort-AV: E=Sophos;i="4.68,338,1312156800"; d="scan'208";a="433087" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 06 Sep 2011 14:46:21 +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 p86Ejed1004800 for ; Tue, 6 Sep 2011 14:46:21 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Sep 2011 08:46:21 -0600 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 14:44:37 -0000 In my roll as an individual contributor, I want to propose some text = that I think we can get rough consensus on around that helps specify = which parts of the signaling issues we agree on and which we don't.=20 At the last meeting, my read of the the room was there was a fair amount = of agreement in the room that offer / answer semantics with SDP are = what we want to use. I don't think there was was broad agreement on if = one should use SIP or not, or for that matter jingle. If we can nail = down this decisions as the direction the WG is going, it will really = help make progress. What I would like to do is propose some following = principles in the text below. If we have agreement on these, then they = would go into the overview document and help guide the design of other = documents. I want to highlight that none of the principles below imply = that we would need to use SIP in the browsers - the principals would all = work fine if we there was signaling gateway in the web server that = converged SIP to whatever proprietary HTML / JS / HTTP that the = applications wanted to use between the browser and the web server.=20 1) The media negotiations will be done using the same SDP offer/answer = semantics that are used in SIP.=20 2) It will be possible to gateway between legacy SIP devices that = support ICE and appropriate RTP / SDP mechanisms and codecs without = using a media gateway. A signaling gateway to convert between the = signaling on the web side to the SIP signaling may be needed.=20 3) When a new codec is specified, and the SPD for the new codec is = specified in the MMUSIC WG, no other standardization would should be = required for it to be possible to use that in the web browsers. Adding a = new codecs which might have new SDP parameters should not change the = APIs between the browser and javascript application. As soon as the = browsers support the new codec, old applications written before the = codecs was specified should automatically be able to use the new codec = where appropriate with no changes to the JS applications.=20 People has looked at alternatives to all these in a fair amount of = detail. For example, we have considered alternatives to the SDP offer / = answer such as the advertisement proposal draft = (draft-peterson-sipcore-advprop-01) and discussed that several times in = the WG. The primary issues identified with this was concerns over = mapping this to legacy SDP. Similarly people have considered a = replacement for SDP in the SDPng work which was eventually abandoned due = to the difficulty of having a incentive for implementations to migrate = from SDP to SDPng.=20 We have also considered just sending audio and video directly over = something like DTLS and not suing RTP. The WG has clearly rejected this = due to a variety of reasons - the desire not to to have the operating = expense of media gateway and reduction in quality of experience is = obviously a high priority goal for the designs of the RTP multiplexing = draft.=20 The JS API is being developed by W3C but when proposing APIs that should = violate the third principal, such as the the API in section 4 of = draft-jennings-rtcweb-api-00, it is clear that many people that are more = from the browser and web application world do not want such an API.=20 From csp@csperkins.org Tue Sep 6 08: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 1DF6121F8B7C for ; Tue, 6 Sep 2011 08:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.516 X-Spam-Level: X-Spam-Status: No, score=-103.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 5zCtb0iFC6EU for ; Tue, 6 Sep 2011 08:10:46 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id 6F80D21F8B45 for ; Tue, 6 Sep 2011 08:10:45 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R0xKB-0000H2-at; Tue, 06 Sep 2011 15:12:31 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Tue, 6 Sep 2011 16:12:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 15:10:48 -0000 Cullen, One minor point inline. On 6 Sep 2011, at 15:46, Cullen Jennings wrote: > In my roll as an individual contributor, I want to propose some text = that I think we can get rough consensus on around that helps specify = which parts of the signaling issues we agree on and which we don't.=20 >=20 > At the last meeting, my read of the the room was there was a fair = amount of agreement in the room that offer / answer semantics with SDP = are what we want to use. I don't think there was was broad agreement on = if one should use SIP or not, or for that matter jingle. If we can nail = down this decisions as the direction the WG is going, it will really = help make progress. What I would like to do is propose some following = principles in the text below. If we have agreement on these, then they = would go into the overview document and help guide the design of other = documents. I want to highlight that none of the principles below imply = that we would need to use SIP in the browsers - the principals would all = work fine if we there was signaling gateway in the web server that = converged SIP to whatever proprietary HTML / JS / HTTP that the = applications wanted to use between the browser and the web server.=20 >=20 >=20 >=20 > 1) The media negotiations will be done using the same SDP offer/answer = semantics that are used in SIP.=20 >=20 > 2) It will be possible to gateway between legacy SIP devices that = support ICE and appropriate RTP / SDP mechanisms and codecs without = using a media gateway. A signaling gateway to convert between the = signaling on the web side to the SIP signaling may be needed.=20 >=20 > 3) When a new codec is specified, and the SPD for the new codec is = specified in the MMUSIC WG, no other standardization would should be = required for it to be possible to use that in the web browsers. Adding a = new codecs which might have new SDP parameters should not change the = APIs between the browser and javascript application. As soon as the = browsers support the new codec, old applications written before the = codecs was specified should automatically be able to use the new codec = where appropriate with no changes to the JS applications.=20 To be clear on this last point: when RTP payload formats are defined for = new codecs, they define a MIME media type and its parameters, and then a = mapping of those onto SDP syntax in a standard way. If it was desirable, = we could define a mapping from MIME media type names and parameters onto = some non-SDP syntax without losing the investment in RTP payload formats = and parameters for signalling.=20 And, given that other parts of the browser rely on media types, we = should be clear that codec names/parameters are drawn from the same = namespace. Colin =20 > People has looked at alternatives to all these in a fair amount of = detail. For example, we have considered alternatives to the SDP offer / = answer such as the advertisement proposal draft = (draft-peterson-sipcore-advprop-01) and discussed that several times in = the WG. The primary issues identified with this was concerns over = mapping this to legacy SDP. Similarly people have considered a = replacement for SDP in the SDPng work which was eventually abandoned due = to the difficulty of having a incentive for implementations to migrate = from SDP to SDPng.=20 >=20 > We have also considered just sending audio and video directly over = something like DTLS and not suing RTP. The WG has clearly rejected this = due to a variety of reasons - the desire not to to have the operating = expense of media gateway and reduction in quality of experience is = obviously a high priority goal for the designs of the RTP multiplexing = draft.=20 >=20 > The JS API is being developed by W3C but when proposing APIs that = should violate the third principal, such as the the API in section 4 of = draft-jennings-rtcweb-api-00, it is clear that many people that are more = from the browser and web application world do not want such an API.=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ From matthew.kaufman@skype.net Tue Sep 6 08: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 5F66D21F8BB5 for ; Tue, 6 Sep 2011 08:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.02 X-Spam-Level: X-Spam-Status: No, score=-5.02 tagged_above=-999 required=5 tests=[AWL=1.579, 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 nvKAP73Tu9Fn for ; Tue, 6 Sep 2011 08:19:20 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 37DFD21F8B4D for ; Tue, 6 Sep 2011 08:19:20 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id C2F7716F5; Tue, 6 Sep 2011 17:21:05 +0200 (CEST) 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=Srpg9etEG+F5lh HQcGnrPonjWtU=; b=S1lcBCVO4q4WIgIzSX8N9QnWw6rjqKIlw0W6jaVtLz9B3r wDKDJfIo9k3XjLxvkNsKsyWenpEAkDGmu6R+pvbU2Ve60NUCBbidjKvd6SSdIi18 J4IgnpLoQB0pqjmrnbcaz5sxrp1rSsadZqGSENg336HX6iiHlfej5z4jNnBnA= 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=cgxnIAQiL2gWNVMQrEqhOF hZHRMcv6V83g3EdC15F1yO7/Xc050kfabi9KWScYsSQkyL4CS1iQQ1Wtr8a/qxI+ ZERp7lMTQDH2flFH/6XzfF9WAhKsMOcZLNM2Gy41IXWVEKW5H99luKaJVDkAbWRH oXzT9HADvOcM4mt435zAw= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id C0BE27F6; Tue, 6 Sep 2011 17:21:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 9E6C53507021; Tue, 6 Sep 2011 17:21:05 +0200 (CEST) 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 kqruZJH91YpK; Tue, 6 Sep 2011 17:21:04 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 4E5233507E86; Tue, 6 Sep 2011 17:21:02 +0200 (CEST) Message-ID: <4E663A35.7000507@skype.net> Date: Tue, 06 Sep 2011 08:20:21 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 15:19:21 -0000 On 9/6/2011 7:46 AM, Cullen Jennings wrote: > In my roll as an individual contributor, I want to propose some text th= at I think we can get rough consensus on around that helps specify which = parts of the signaling issues we agree on and which we don't. > > At the last meeting, my read of the the room was there was a fair amoun= t of agreement in the room that offer / answer semantics with SDP are wh= at we want to use. I don't think there was was broad agreement on if one = should use SIP or not, or for that matter jingle. If we can nail down thi= s decisions as the direction the WG is going, it will really help make pr= ogress. What I would like to do is propose some following principles in t= he text below. If we have agreement on these, then they would go into the= overview document and help guide the design of other documents. I want t= o highlight that none of the principles below imply that we would need to= use SIP in the browsers - the principals would all work fine if we there= was signaling gateway in the web server that converged SIP to whatever p= roprietary HTML / JS / HTTP that the applications wanted to use between = the browser and the web server. > > > > 1) The media negotiations will be done using the same SDP offer/answer = semantics that are used in SIP. I think this would be unfortunate. We have an opportunity here to not=20 repeat this mistake. And *if* we go down this road, we need additional language around things = like exposing the capabilities via an API that doesn't start the=20 offer/answer process itself. (Use case: determine if a browser has an=20 appropriate camera and encoder before suggesting that they call the=20 customer service rep for a live chat.) > > 2) It will be possible to gateway between legacy SIP devices that suppo= rt ICE and appropriate RTP / SDP mechanisms and codecs without using a me= dia gateway. A signaling gateway to convert between the signaling on the = web side to the SIP signaling may be needed. Agree. > > 3) When a new codec is specified, and the SPD for the new codec is spec= ified in the MMUSIC WG, no other standardization would should be required= for it to be possible to use that in the web browsers. I would be ok with reusing the SDP parameter string as specified as a=20 parameter to the API, but I don't think it should be a blob of SDP that=20 combines both the codec parameters *and* the connection/ICE parameters,=20 *and* I think that offer/answer is the wrong model. However, see below... > Adding a new codecs which might have new SDP parameters should not ch= ange the APIs between the browser and javascript application. As soon as = the browsers support the new codec, old applications written before the c= odecs was specified should automatically be able to use the new codec whe= re appropriate with no changes to the JS applications. This is a good idea. But then where do all the parameters that *weren't* = specified in the MMUSIC WG go? (Like "force Opus codec to music mode",=20 or "change your motion estimation algorithm") > > > People has looked at alternatives to all these in a fair amount of det= ail. For example, we have considered alternatives to the SDP offer / answ= er such as the advertisement proposal draft (draft-peterson-sipcore-advpr= op-01) and discussed that several times in the WG. This is mixing up the API and the wire protocol. If people want to use=20 SDP offer/answer between the browser and the web server, that's fine,=20 but that doesn't mean we need to bake SDP offer/answer into the=20 Javascript API. (And it certainly doesn't mean we need to mix up the=20 layers, with connection properties in the SDP *and* encoder properties=20 in the same SDP... done properly, these would go to/from different=20 Javascript objects anyway.) Likewise, advprop should be able to be supported as well... with a=20 different set of Javascript talking to the same APIs. > The primary issues identified with this was concerns over mapping thi= s to legacy SDP. This makes the assumption that the primary use case will have things=20 that speak only SDP offer/answer on the far side. I think that's a very=20 IETF + SIP + legacy point of view, which is an unfortunate way to=20 approach the future of communications as enabled by web applications. I think that as long as the browser *or* the server *can* map it to SDP=20 offer/answer when needed, that is sufficient. > Similarly people have considered a replacement for SDP in the SDPng wor= k which was eventually abandoned due to the difficulty of having a incent= ive for implementations to migrate from SDP to SDPng. Obviously can't use something that was abandoned. > > We have also considered just sending audio and video directly over some= thing like DTLS and not suing RTP. That would break point 2 above. > The WG has clearly rejected this due to a variety of reasons - the de= sire not to to have the operating expense of media gateway and reduction = in quality of experience is obviously a high priority goal for the design= s of the RTP multiplexing draft. Agree. > > The JS API is being developed by W3C but when proposing APIs that shoul= d violate the third principal, such as the the API in section 4 of draft-= jennings-rtcweb-api-00, it is clear that many people that are more from t= he browser and web application world do not want such an API. Too many negatives for me to parse. Matthew Kaufman From emil@sip-communicator.org Tue Sep 6 08:47: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 884E421F8BBA for ; Tue, 6 Sep 2011 08:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5NIp22NWQTJ for ; Tue, 6 Sep 2011 08:47:37 -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 220DC21F8BB3 for ; Tue, 6 Sep 2011 08:47:36 -0700 (PDT) Received: by fxe6 with SMTP id 6so4940780fxe.31 for ; Tue, 06 Sep 2011 08:49:21 -0700 (PDT) Received: by 10.223.55.219 with SMTP id v27mr3341240fag.2.1315324160900; Tue, 06 Sep 2011 08:49:20 -0700 (PDT) Received: from camionet.local ([78.90.181.123]) by mx.google.com with ESMTPS id o18sm130501fal.20.2011.09.06.08.49.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Sep 2011 08:49:19 -0700 (PDT) Message-ID: <4E6640FC.8080108@jitsi.org> Date: Tue, 06 Sep 2011 18:49:16 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; bg; rv:1.9.2.21) Gecko/20110830 Thunderbird/3.1.13 MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 15:47:38 -0000 Hey Cullen, =D0=9D=D0=B0 06.09.11 17:46, Cullen Jennings =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: >=20 > In my roll as an individual contributor, I want to propose some text > that I think we can get rough consensus on around that helps specify > which parts of the signaling issues we agree on and which we don't. >=20 > At the last meeting, my read of the the room was there was a fair > amount of agreement in the room that offer / answer semantics with > SDP are what we want to use. I don't think there was was broad > agreement on if one should use SIP or not, or for that matter jingle. > If we can nail down this decisions as the direction the WG is going, > it will really help make progress. What I would like to do is propose > some following principles in the text below. If we have agreement on > these, then they would go into the overview document and help guide > the design of other documents. I want to highlight that none of the > principles below imply that we would need to use SIP in the browsers > - the principals would all work fine if we there was signaling > gateway in the web server that converged SIP to whatever proprietary > HTML / JS / HTTP that the applications wanted to use between the > browser and the web server. >=20 >=20 >=20 > 1) The media negotiations will be done using the same SDP > offer/answer semantics that are used in SIP. Does this cover media format negotiation only or does it also cover transport negotiation? I believe you once mentioned you were a fan of "sending ICE candidates as they become available" and for that to happen we'd probably need something more XMPP-like than SIP/SDP-like. > 2) It will be possible to gateway between legacy SIP devices that > support ICE and appropriate RTP / SDP mechanisms and codecs without > using a media gateway. A signaling gateway to convert between the > signaling on the web side to the SIP signaling may be needed. +1 > 3) When a new codec is specified, and the SPD for the new codec is > specified in the MMUSIC WG, no other standardization would should be > required for it to be possible to use that in the web browsers. I was about to suggest we should also mention the result from the PAYLOAD WG here (rather than MMUSIC only) but I believe that's actually what Colin meant. Cheers, Emil > Adding a new codecs which might have new SDP parameters should not > change the APIs between the browser and javascript application. As > soon as the browsers support the new codec, old applications written > before the codecs was specified should automatically be able to use > the new codec where appropriate with no changes to the JS > applications. >=20 >=20 > People has looked at alternatives to all these in a fair amount of > detail. For example, we have considered alternatives to the SDP offer > / answer such as the advertisement proposal draft > (draft-peterson-sipcore-advprop-01) and discussed that several times > in the WG. The primary issues identified with this was concerns over > mapping this to legacy SDP. Similarly people have considered a > replacement for SDP in the SDPng work which was eventually abandoned > due to the difficulty of having a incentive for implementations to > migrate from SDP to SDPng. >=20 > We have also considered just sending audio and video directly over > something like DTLS and not suing RTP. The WG has clearly rejected > this due to a variety of reasons - the desire not to to have the > operating expense of media gateway and reduction in quality of > experience is obviously a high priority goal for the designs of the > RTP multiplexing draft. >=20 > The JS API is being developed by W3C but when proposing APIs that > should violate the third principal, such as the the API in section 4 > of draft-jennings-rtcweb-api-00, it is clear that many people that > are more from the browser and web application world do not want such > an API. >=20 > _______________________________________________ rtcweb mailing list=20 > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb >=20 --=20 http://jitsi.org From emil@sip-communicator.org Tue Sep 6 08:50: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 C795B21F8BB1 for ; Tue, 6 Sep 2011 08:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxiANomDhkNU for ; Tue, 6 Sep 2011 08:50:28 -0700 (PDT) Received: from mail-ey0-f174.google.com (mail-ey0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9180321F8C4B for ; Tue, 6 Sep 2011 08:50:27 -0700 (PDT) Received: by eyx24 with SMTP id 24so4240256eyx.19 for ; Tue, 06 Sep 2011 08:52:08 -0700 (PDT) Received: by 10.204.157.144 with SMTP id b16mr674259bkx.396.1315324328228; Tue, 06 Sep 2011 08:52:08 -0700 (PDT) Received: from camionet.local ([78.90.181.123]) by mx.google.com with ESMTPS id p9sm103277fah.1.2011.09.06.08.52.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Sep 2011 08:52:07 -0700 (PDT) Message-ID: <4E6641A6.10103@jitsi.org> Date: Tue, 06 Sep 2011 18:52:06 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; bg; rv:1.9.2.21) Gecko/20110830 Thunderbird/3.1.13 MIME-Version: 1.0 To: Matthew Kaufman References: <4E663A35.7000507@skype.net> In-Reply-To: <4E663A35.7000507@skype.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 15:50:28 -0000 Hey Matthew, =D0=9D=D0=B0 06.09.11 18:20, Matthew Kaufman =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > On 9/6/2011 7:46 AM, Cullen Jennings wrote: >> In my roll as an individual contributor, I want to propose some >> text that I think we can get rough consensus on around that helps >> specify which parts of the signaling issues we agree on and which >> we don't. >>=20 >> At the last meeting, my read of the the room was there was a fair >> amount of agreement in the room that offer / answer semantics with >> SDP are what we want to use. I don't think there was was broad >> agreement on if one should use SIP or not, or for that matter >> jingle. If we can nail down this decisions as the direction the WG >> is going, it will really help make progress. What I would like to >> do is propose some following principles in the text below. If we >> have agreement on these, then they would go into the overview >> document and help guide the design of other documents. I want to >> highlight that none of the principles below imply that we would >> need to use SIP in the browsers - the principals would all work >> fine if we there was signaling gateway in the web server that >> converged SIP to whatever proprietary HTML / JS / HTTP that the >> applications wanted to use between the browser and the web server. >>=20 >>=20 >>=20 >> 1) The media negotiations will be done using the same SDP >> offer/answer semantics that are used in SIP. >=20 > I think this would be unfortunate. We have an opportunity here to not > repeat this mistake. I'd be interested in hearing what mistakes you have in mind. > And *if* we go down this road, we need additional language around > things like exposing the capabilities via an API that doesn't start > the offer/answer process itself. (Use case: determine if a browser > has an appropriate camera and encoder before suggesting that they > call the customer service rep for a live chat.) +1 Personally I'd vote for mimicing XMPP's service discovery here. (see XEP-0030 and XEP-0115 on http://xmpp.org/extensions ) I definitely think discovery of capabilities should not be part of the offer/answer negotiation. Emil --=20 http://jitsi.org From csp@csperkins.org Tue Sep 6 09:06: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 911D421F8BB7 for ; Tue, 6 Sep 2011 09:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.522 X-Spam-Level: X-Spam-Status: No, score=-103.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 h+5eWR9D9Tbs for ; Tue, 6 Sep 2011 09:06:42 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by ietfa.amsl.com (Postfix) with ESMTP id E2AB421F8BB2 for ; Tue, 6 Sep 2011 09:06:41 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R0yCJ-0001VZ-Xy; Tue, 06 Sep 2011 16:08:27 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4E6640FC.8080108@jitsi.org> Date: Tue, 6 Sep 2011 17:08:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E6640FC.8080108@jitsi.org> To: Emil Ivov X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 16:06:42 -0000 On 6 Sep 2011, at 16:49, Emil Ivov wrote: ... >> 3) When a new codec is specified, and the SPD for the new codec is >> specified in the MMUSIC WG, no other standardization would should be >> required for it to be possible to use that in the web browsers. >=20 > I was about to suggest we should also mention the result from the > PAYLOAD WG here (rather than MMUSIC only) but I believe that's = actually > what Colin meant. The standards are done in PAYLOAD (was AVT before the split), not = MMUSIC, true. My main point though was that the codec names and = parameters aren't defined in terms of SDP, but rather using MIME media = type names and parameters, which happen to currently get mapped to SDP.=20= --=20 Colin Perkins http://csperkins.org/ From blizzard@mozilla.com Tue Sep 6 10:15: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 D09B521F8B59 for ; Tue, 6 Sep 2011 10:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 kJs+-u2cLJv6 for ; Tue, 6 Sep 2011 10:15:09 -0700 (PDT) Received: from mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3402121F8B50 for ; Tue, 6 Sep 2011 10:15:09 -0700 (PDT) Received: from [10.250.4.144] (corp-240.mv.mozilla.com [63.245.220.240]) by mail.mozilla.com (Postfix) with ESMTPSA id 179BCAE64681; Tue, 6 Sep 2011 10:16:56 -0700 (PDT) Message-ID: <4E665588.5000700@mozilla.com> Date: Tue, 06 Sep 2011 10:16:56 -0700 From: Christopher Blizzard User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Matthew Kaufman References: <4E259484.20509@ericsson.com>, <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com>, <4E26B742.6050606@jitsi.org>, <62C71813-83B4-44D3-8E54-28262311CDB3@cisco.com> <4E27BE02.7090606@ericsson.com> <9F9278CB1892FB48BF35CB5CC3992478A5395C720E@HKGMBOXPRD01.polycom.com> <4E2EB82C.30709@alvestrand.no> <4E643E39.8020205@skype.net> In-Reply-To: <4E643E39.8020205@skype.net> Content-Type: multipart/alternative; boundary="------------040405080303010308060806" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Support for websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 17:15:10 -0000 This is a multi-part message in MIME format. --------------040405080303010308060806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/4/2011 8:12 PM, Matthew Kaufman wrote: > > I think there's a legitimate question as to how transmission of media > over TCP should work. I believe that the existing code bases all > assume that if you get IP addresses, you use them; if you get IP > addresses for TURN servers you talk to them over UDP and use TURN for > relaying; and if you get IP addresses for TURNS servers you talk to > them over TLS/TCP and use them for relaying. Therefore the only TCP > transport is TURN-over-TLS-over-TCP. > > Is that sufficient and reasonable, or should media-over-websockets (or > something else) be how TCP transmission of media works? It's important to note that WebSockets aren't raw sockets in the classic TCP or POSIX sense. So a conversation about transmission of media over TCP doesn't really apply to WebSockets, exactly. It's true that since WS is over TCP that it's reliable and ordered. What would be interesting would be a discussion of how to take media data coming in over a WebSocket and feed it to a consumer that could display that media, as well as the reverse. But an API discussion feels like something that's more that's something that belongs at the W3C. If we wanted a standardized representation in WS that might happen here, but it's not something that's strictly required. Well-built APIs to encoders and decoders could mean that it's up to page implementers to figure out how to package the data, manipulated by JS. --Chris --------------040405080303010308060806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/4/2011 8:12 PM, Matthew Kaufman wrote:

I think there's a legitimate question as to how transmission of media over TCP should work. I believe that the existing code bases all assume that if you get IP addresses, you use them; if you get IP addresses for TURN servers you talk to them over UDP and use TURN for relaying; and if you get IP addresses for TURNS servers you talk to them over TLS/TCP and use them for relaying. Therefore the only TCP transport is TURN-over-TLS-over-TCP.

Is that sufficient and reasonable, or should media-over-websockets (or something else) be how TCP transmission of media works?

It's important to note that WebSockets aren't raw sockets in the classic TCP or POSIX sense.  So a conversation about transmission of media over TCP doesn't really apply to WebSockets, exactly.  It's true that since WS is over TCP that it's reliable and ordered.  What would be interesting would be a discussion of how to take media data coming in over a WebSocket and feed it to a consumer that could display that media, as well as the reverse.  But an API discussion feels like something that's more that's something that belongs at the W3C.

If we wanted a standardized representation in WS that might happen here, but it's not something that's strictly required.  Well-built APIs to encoders and decoders could mean that it's up to page implementers to figure out how to package the data, manipulated by JS.

--Chris
--------------040405080303010308060806-- From pravindran@sonusnet.com Tue Sep 6 11:05: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 30CCF21F8B5E for ; Tue, 6 Sep 2011 11:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.109, 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 InV1BsuCUsvb for ; Tue, 6 Sep 2011 11:04:59 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id BF65621F8B28 for ; Tue, 6 Sep 2011 11:04:58 -0700 (PDT) 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 p86I7Brq003928; Tue, 6 Sep 2011 14:07:11 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Sep 2011 14:06:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6CBF.B93E88BC" Date: Tue, 6 Sep 2011 23:36:35 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> In-Reply-To: <4E659576.1000301@skype.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver Thread-Index: AcxsRmig665lmf8XSfGdZFBIXE6VJAAdCW6Q References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> From: "Ravindran Parthasarathi" To: "Matthew Kaufman" X-OriginalArrivalTime: 06 Sep 2011 18:06:41.0720 (UTC) FILETIME=[BAE7AB80:01CC6CBF] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 18:05:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6CBF.B93E88BC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Matthew, =20 Please read inline. =20 Thanks Partha =20 From: Matthew Kaufman [mailto:matthew.kaufman@skype.net]=20 Sent: Tuesday, September 06, 2011 9:07 AM To: Ravindran Parthasarathi Cc: Bernard Aboba; hoang.su.tk@gmail.com; rtcweb@ietf.org Subject: Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver =20 On 9/5/2011 12:16 PM, Ravindran Parthasarathi wrote:=20 Bernard, =20 Sorry for the delay reply. =20 There is a huge difference between tunneling the protocol and converting the protocol from one format to another. The tunneling works well only in case the destination support the tunneled data without negotiation. It will be bad assumption in case the standard does not defined so. For example,=20 =20 Browser A supports Jingle (XMPP for real-time data) and encapsulates the data in HTTP and send it to webserver1 That isn't how it works. Browser A supports WebRTC. Do you mean browser A is running Javascript that implements Jingle or something similar for its signaling (over HTTP and/or Websockets) to its associated web server? [Partha]Browser A supports WebRTC Javascript API which is mapped to Jingle. Browser A is not required to have native support of Jingle. I guess that we mean the same thing. RTCwebserver1 tunnel jingle data in SIP and sends it to RTCwebserver2 Federation between webserver1 and webserver2 is up to the operators of those sites. Presumably SIP is a good (but not only) choice for federation. Many sites won't have a desire or need to federate. [Partha] Here is the problem, it is expected that webserver1 has to converts its proprietary stuff into SIP or other equivalent. So, RTCweb to SIP gateway is mandated in your proposed architecture for the basic dialog between two users in two webservers. It will be tough for each webserver developer to create the proprietary protocol and mapping. Instead, the basic SIP functionality provided in browser will make sure the basic call works between any users across webserver without limiting the innovative application build by individual webservers. RTCwebserver2 does not support Jingle towards browser but it support some other variant of HTTP based metadata to the browser.=20 Do you mean that webserver2 and its clients are running compatible code that exchanges signaling via a mechanism other than Jingle? That's fine, and up to the operator of that site. My question is how webserver2 do perform the interop correctly in case Jingle is not mandated as metadata standard mechanism. Please let me know your opinion here. Every site that wishes to federate with others will need to choose a signaling protocol that is agreed between them. [Partha] it is bad network design because SIP is well accepted in real-time applications (telecom or unified communication) and also there is no need of contract with each site (company) and implement their protocol to interop with them. =20 My understanding was that RTCwebserver1 may use some proprietary mechanism (may be jingle) to communicate between browser and webserver which will be converted into RFC 3261 SIP at webserver1 and forwarded to RTCwebserver2. RTCWebserver2 converts back SIP to its own proprietary metadata to communicate with browser. This mechanism works well but still better mechanism exists. That understanding appears to be correct. This is exactly the same as "Hotmail talks some proprietary protocol over HTTP between its HTML/Javascript client and its servers which is then converted to SMTP for sending to Gmail, where Gmail talks a different proprietary protocol over HTTP between its HTML/Javascript client and its servers." It appears to have resulted in some significant innovations in the email service space, while still allowing federation between domains using a standard protocol. [Partha] This paradigm will not exactly fit for real-time communication because there is a need of communication between browser to browser apart from webserver to webserver communication. Still I could not under the reason why SIP will stop the innovation whereas HTTP will allow. If you think this is a bad idea, provide an alternative we might discuss. [Partha] I'm thinking of the solution which is in line of draft-cbran-rtcweb-protocols-00. Browser is intelligent entity which makes real-time communication with other browser using SIP. The configuration data required for browser SIP client is received through Javascript and/or received metadata from webserver using HTTP connection. Making SIP as a protocol for real-time communication will make sure that browser not only communicates with another browser but also ensure that it works with existing SIP implementation. It was my original usecase wherein browser directly communicates with VoIP-server. VoIP server may communicates with browser which does not matter for the originating browser. Matthew Kaufman ------_=_NextPart_001_01CC6CBF.B93E88BC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Matthew,

 

Please read inline.

 

Thanks

Partha

 

From: Matthew Kaufman [mailto:matthew.kaufman@skype.net]
Sent: Tuesday, September 06, 2011 9:07 AM
To: Ravindran Parthasarathi
Cc: Bernard Aboba; hoang.su.tk@gmail.com; rtcweb@ietf.org
Subject: Re: [rtcweb] Usecase & architecture: Browser = application with separate webserver & voipserver

 

On 9/5/2011 12:16 PM, Ravindran Parthasarathi = wrote:

Bernard,

 

Sorry for the delay reply.

 

There is a huge difference between tunneling the protocol = and converting the protocol from one format to another. The tunneling works = well only in case the destination support the tunneled data without = negotiation. It will be bad assumption in case the standard does not defined so. =  For example,

 

Browser A supports Jingle = (XMPP for real-time data) and encapsulates the data in HTTP and send it to = webserver1


That isn't how it works. Browser A supports WebRTC. Do you mean browser = A is running Javascript that implements Jingle or something similar for its signaling (over HTTP and/or Websockets) to its associated web = server?

[Partha]Browser = A supports WebRTC Javascript API which is mapped to Jingle. Browser A is = not required to have native support of Jingle. I guess that we mean the same = thing.



RTCwebserver1 tunnel jingle = data in SIP and sends it to RTCwebserver2


Federation between webserver1 and webserver2 is up to the operators of = those sites. Presumably SIP is a good (but not only) choice for federation. = Many sites won't have a desire or need to federate.

[Partha] Here is the problem, it is expected that = webserver1 has to converts its proprietary stuff into SIP or other equivalent. So, = RTCweb to SIP gateway is mandated in your proposed architecture for the basic = dialog between two users in two webservers. It will be tough for each webserver developer to create the proprietary protocol and mapping. Instead, the = basic SIP functionality provided in browser will make sure the basic call = works between any users across webserver without limiting the innovative = application build by individual webservers.




RTCwebserver2 does not = support Jingle towards browser but it support some other variant of HTTP based = metadata to the browser.


Do you mean that webserver2 and its clients are running compatible code = that exchanges signaling via a mechanism other than Jingle? That's fine, and = up to the operator of that site.


My question is how webserver2 do perform the interop = correctly in case Jingle is not mandated as metadata standard mechanism. Please = let me know your opinion here.


Every site that wishes to federate with others will need to choose a = signaling protocol that is agreed between them.

[Partha] it is bad network design because SIP is well = accepted in real-time applications (telecom or unified communication) and also = there is no need of contract with each site (company) and implement their = protocol to interop with them.




 

My understanding was that RTCwebserver1 may use some proprietary mechanism = (may be jingle) to communicate between browser and webserver which will be = converted into RFC 3261 SIP at webserver1 and forwarded to RTCwebserver2. = RTCWebserver2 converts back SIP to its own proprietary metadata to communicate with = browser. This mechanism works well but still better mechanism = exists.


That understanding appears to be correct. This is exactly the same as "Hotmail talks some proprietary protocol over HTTP between its HTML/Javascript client and its servers which is then converted to SMTP = for sending to Gmail, where Gmail talks a different proprietary protocol = over HTTP between its HTML/Javascript client and its servers." It appears to = have resulted in some significant innovations in the email service space, = while still allowing federation between domains using a standard = protocol.

[Partha] This = paradigm will not exactly fit for real-time communication because there is a need = of communication between browser to browser apart from webserver to = webserver communication. Still I could not under the reason why SIP will stop the innovation = whereas HTTP will allow.

If you think this is a bad idea, provide an alternative we might = discuss.

[Partha] = I’m thinking of the solution which is in line of draft-cbran-rtcweb-protocols-00. = Browser is intelligent entity which makes real-time communication with other = browser using SIP. The configuration data required for browser SIP client is received = through Javascript and/or received metadata from webserver using HTTP = connection. Making SIP as a protocol for real-time communication will make sure that browser not only communicates with another browser but also ensure that = it works with existing SIP implementation. It was my original usecase = wherein browser directly communicates with VoIP-server. VoIP server may = communicates with browser which does not matter for the originating = browser.



Matthew Kaufman

------_=_NextPart_001_01CC6CBF.B93E88BC-- From matthew.kaufman@skype.net Tue Sep 6 11:32: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 F03B121F8CB1 for ; Tue, 6 Sep 2011 11:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.585 X-Spam-Level: X-Spam-Status: No, score=-4.585 tagged_above=-999 required=5 tests=[AWL=2.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ifc2AweXrELf for ; Tue, 6 Sep 2011 11:32:03 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4F57F21F8CA6 for ; Tue, 6 Sep 2011 11:32:03 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id CFBC416F5; Tue, 6 Sep 2011 20:33:49 +0200 (CEST) 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; s=mx; bh=WpG4EDC6u67pTABVzuKLMOH8BZk=; b=VJnwoQ9jf Iq0SbWMjSP5YP8UefwaE9L8LzJGxIWqEhfCC827dc+kPh44ezXnLf61LQ6spVKkq iMIJclNEIV+ryZ5X17m3uxY1tqTXt0zZm8XDLRie3CWmm60BKbIddB6u4vJDmww3 Ja+6Zc9n9pDK0DFRZGS/KhzHWO23mTQWXw= 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; q=dns; s=mx; b=ORe8O6C9Z6eWzxiyrt8v8lnMcQ22fKKZGd2x3tF1wR5tZKd0 2e1ATnL2Z8GWNvRVItWSAumtV1t4irNac9BPUNQ5cX4Eyh4SlmaAK9AQqAcF6API AQHU/zojh3xMmSvTRrskEiUjeBU2FFOgIAq17jJHksbtJZ/sYZkK9lvCABQ= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id CDA377F6; Tue, 6 Sep 2011 20:33:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 99FAB35073C4; Tue, 6 Sep 2011 20:33:49 +0200 (CEST) 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 eQh+ZzCVmJEy; Tue, 6 Sep 2011 20:33:45 +0200 (CEST) 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 840063506EB9; Tue, 6 Sep 2011 20:33:43 +0200 (CEST) Message-ID: <4E666785.7040409@skype.net> Date: Tue, 06 Sep 2011 11:33:41 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Ravindran Parthasarathi References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> Content-Type: multipart/alternative; boundary="------------090408000308000509050404" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 18:32:08 -0000 This is a multi-part message in MIME format. --------------090408000308000509050404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/6/11 11:06 AM, Ravindran Parthasarathi wrote: > > Matthew, > > Please read inline. > > Thanks > > Partha > > *From:*Matthew Kaufman [mailto:matthew.kaufman@skype.net] > *Sent:* Tuesday, September 06, 2011 9:07 AM > *To:* Ravindran Parthasarathi > *Cc:* Bernard Aboba; hoang.su.tk@gmail.com; rtcweb@ietf.org > *Subject:* Re: [rtcweb] Usecase & architecture: Browser application > with separate webserver & voipserver > > On 9/5/2011 12:16 PM, Ravindran Parthasarathi wrote: > > Bernard, > > Sorry for the delay reply. > > There is a huge difference between tunneling the protocol and > converting the protocol from one format to another. The tunneling > works well only in case the destination support the tunneled data > without negotiation. It will be bad assumption in case the standard > does not defined so. For example, > > Browser A supports Jingle (XMPP for real-time data) and encapsulates > the data in HTTP and send it to webserver1 > > > That isn't how it works. Browser A supports WebRTC. Do you mean > browser A is running Javascript that implements Jingle or something > similar for its signaling (over HTTP and/or Websockets) to its > associated web server? > > */[Partha]Browser A supports WebRTC Javascript API which is mapped to > Jingle. Browser A is not required to have native support of Jingle. I > guess that we mean the same thing./* > > Sounds like we mean the same thing. > > RTCwebserver1 tunnel jingle data in SIP and sends it to RTCwebserver2 > > > Federation between webserver1 and webserver2 is up to the operators of > those sites. Presumably SIP is a good (but not only) choice for > federation. Many sites won't have a desire or need to federate. > > */[Partha] Here is the problem, it is expected that webserver1 has to > converts its proprietary stuff into SIP or other equivalent. So, > RTCweb to SIP gateway is mandated in your proposed architecture for > the basic dialog between two users in two webservers. It will be tough > for each webserver developer to create the proprietary protocol and > mapping. Instead, the basic SIP functionality provided in browser will > make sure the basic call works between any users across webserver > without limiting the innovative application build by individual > webservers./* > > Disagree. It is expected that webserver1 usually *doesn't* convert its proprietary stuff into SIP. That only happens when you want to federate with another service that uses SIP. If it is "tough" to create a mapping between your proprietary stuff and SIP then perhaps you didn't design your proprietary stuff properly... that isn't my problem however. Basic SIP functionality provided in the browser would likely limit the API in ways that block innovation. > > > RTCwebserver2 does not support Jingle towards browser but it support > some other variant of HTTP based metadata to the browser. > > > Do you mean that webserver2 and its clients are running compatible > code that exchanges signaling via a mechanism other than Jingle? > That's fine, and up to the operator of that site. > > > My question is how webserver2 do perform the interop correctly in case > Jingle is not mandated as metadata standard mechanism. Please let me > know your opinion here. > > > Every site that wishes to federate with others will need to choose a > signaling protocol that is agreed between them. > > */[Partha] it is bad network design because SIP is well accepted in > real-time applications (telecom or unified communication) and also > there is no need of contract with each site (company) and implement > their protocol to interop with them./* > > SIP is well accepted in *some* real-time applications. I would note that the most popular real-time applications don't actually use SIP. And yet there is SIP, for when you wish to interop without lengthy contract or discussion. The best of both worlds. > > > My understanding was that RTCwebserver1 may use some proprietary > mechanism (may be jingle) to communicate between browser and webserver > which will be converted into RFC 3261 SIP at webserver1 and forwarded > to RTCwebserver2. RTCWebserver2 converts back SIP to its own > proprietary metadata to communicate with browser. This mechanism works > well but still better mechanism exists. > > > That understanding appears to be correct. This is exactly the same as > "Hotmail talks some proprietary protocol over HTTP between its > HTML/Javascript client and its servers which is then converted to SMTP > for sending to Gmail, where Gmail talks a different proprietary > protocol over HTTP between its HTML/Javascript client and its > servers." It appears to have resulted in some significant innovations > in the email service space, while still allowing federation between > domains using a standard protocol. > > */[Partha] This paradigm will not exactly fit for real-time > communication because there is a need of communication between browser > to browser apart from webserver to webserver communication. Still I > could not under the reason why SIP will stop the innovation whereas > HTTP will allow./* > Because SIP requires standards activities before adding any useful functionality. I'll point to one of my favorites here: bridged line appearances. Despite lots of effort to fix this, there still isn't a way to do this reliably. And yet, if I created a web application using HTTP signaling and Javascript APIs on a web browser that provides a *platform* and not just a "phone", I could create a system in which bridged line appearances work well if I so desired with just a little bit of programming. > If you think this is a bad idea, provide an alternative we might discuss. > > */[Partha] I'm thinking of the solution which is in line of > draft-cbran-rtcweb-protocols-00. Browser is intelligent entity which > makes real-time communication with other browser using SIP. The > configuration data required for browser SIP client is received through > Javascript and/or received metadata from webserver using HTTP > connection. Making SIP as a protocol for real-time communication will > make sure that browser not only communicates with another browser but > also ensure that it works with existing SIP implementation. It was my > original usecase wherein browser directly communicates with > VoIP-server. VoIP server may communicates with browser which does not > matter for the originating browser./* > > So you want the browser to be a phone, and not a platform for innovation in the area of real-time applications. It is already a platform for innovation in many other areas, why limit it here? Matthew Kaufman --------------090408000308000509050404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/6/11 11:06 AM, Ravindran Parthasarathi wrote:

Matthew,

 

Please read inline.

 

Thanks

Partha

 

From: Matthew Kaufman [mailto:matthew.kaufman@skype.net]
Sent: Tuesday, September 06, 2011 9:07 AM
To: Ravindran Parthasarathi
Cc: Bernard Aboba; hoang.su.tk@gmail.com; rtcweb@ietf.org
Subject: Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver

 

On 9/5/2011 12:16 PM, Ravindran Parthasarathi wrote:

Bernard,

 

Sorry for the delay reply.

 

There is a huge difference between tunneling the protocol and converting the protocol from one format to another. The tunneling works well only in case the destination support the tunneled data without negotiation. It will be bad assumption in case the standard does not defined so.  For example,

 

Browser A supports Jingle (XMPP for real-time data) and encapsulates the data in HTTP and send it to webserver1


That isn't how it works. Browser A supports WebRTC. Do you mean browser A is running Javascript that implements Jingle or something similar for its signaling (over HTTP and/or Websockets) to its associated web server?

[Partha]Browser A supports WebRTC Javascript API which is mapped to Jingle. Browser A is not required to have native support of Jingle. I guess that we mean the same thing.



Sounds like we mean the same thing.


RTCwebserver1 tunnel jingle data in SIP and sends it to RTCwebserver2


Federation between webserver1 and webserver2 is up to the operators of those sites. Presumably SIP is a good (but not only) choice for federation. Many sites won't have a desire or need to federate.

[Partha] Here is the problem, it is expected that webserver1 has to converts its proprietary stuff into SIP or other equivalent. So, RTCweb to SIP gateway is mandated in your proposed architecture for the basic dialog between two users in two webservers. It will be tough for each webserver developer to create the proprietary protocol and mapping. Instead, the basic SIP functionality provided in browser will make sure the basic call works between any users across webserver without limiting the innovative application build by individual webservers.



Disagree. It is expected that webserver1 usually *doesn't* convert its proprietary stuff into SIP. That only happens when you want to federate with another service that uses SIP.

If it is "tough" to create a mapping between your proprietary stuff and SIP then perhaps you didn't design your proprietary stuff properly... that isn't my problem however.

Basic SIP functionality provided in the browser would likely limit the API in ways that block innovation.



RTCwebserver2 does not support Jingle towards browser but it support some other variant of HTTP based metadata to the browser.


Do you mean that webserver2 and its clients are running compatible code that exchanges signaling via a mechanism other than Jingle? That's fine, and up to the operator of that site.


My question is how webserver2 do perform the interop correctly in case Jingle is not mandated as metadata standard mechanism. Please let me know your opinion here.


Every site that wishes to federate with others will need to choose a signaling protocol that is agreed between them.

[Partha] it is bad network design because SIP is well accepted in real-time applications (telecom or unified communication) and also there is no need of contract with each site (company) and implement their protocol to interop with them.



SIP is well accepted in *some* real-time applications. I would note that the most popular real-time applications don't actually use SIP.

And yet there is SIP, for when you wish to interop without lengthy contract or discussion. The best of both worlds.



 

My understanding was that RTCwebserver1 may use some proprietary mechanism (may be jingle) to communicate between browser and webserver which will be converted into RFC 3261 SIP at webserver1 and forwarded to RTCwebserver2. RTCWebserver2 converts back SIP to its own proprietary metadata to communicate with browser. This mechanism works well but still better mechanism exists.


That understanding appears to be correct. This is exactly the same as "Hotmail talks some proprietary protocol over HTTP between its HTML/Javascript client and its servers which is then converted to SMTP for sending to Gmail, where Gmail talks a different proprietary protocol over HTTP between its HTML/Javascript client and its servers." It appears to have resulted in some significant innovations in the email service space, while still allowing federation between domains using a standard protocol.

[Partha] This paradigm will not exactly fit for real-time communication because there is a need of communication between browser to browser apart from webserver to webserver communication. Still I could not under the reason why SIP will stop the innovation whereas HTTP will allow.


Because SIP requires standards activities before adding any useful functionality. I'll point to one of my favorites here: bridged line appearances. Despite lots of effort to fix this, there still isn't a way to do this reliably. And yet, if I created a web application using HTTP signaling and Javascript APIs on a web browser that provides a *platform* and not just a "phone", I could create a system in which bridged line appearances work well if I so desired with just a little bit of programming.

If you think this is a bad idea, provide an alternative we might discuss.

[Partha] I’m thinking of the solution which is in line of draft-cbran-rtcweb-protocols-00. Browser is intelligent entity which makes real-time communication with other browser using SIP. The configuration data required for browser SIP client is received through Javascript and/or received metadata from webserver using HTTP connection. Making SIP as a protocol for real-time communication will make sure that browser not only communicates with another browser but also ensure that it works with existing SIP implementation. It was my original usecase wherein browser directly communicates with VoIP-server. VoIP server may communicates with browser which does not matter for the originating browser.



So you want the browser to be a phone, and not a platform for innovation in the area of real-time applications. It is already a platform for innovation in many other areas, why limit it here?

Matthew Kaufman

--------------090408000308000509050404-- From pravindran@sonusnet.com Tue Sep 6 11:34: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 4E1A821F8D2B for ; Tue, 6 Sep 2011 11:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.116, 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 oWmwVxO51GqO for ; Tue, 6 Sep 2011 11:34:46 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id AC79D21F8D2A for ; Tue, 6 Sep 2011 11:34:45 -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 p86Ib0nX023562; Tue, 6 Sep 2011 14:37:00 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Sep 2011 14:36:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6CC3.E3A2F5B2" Date: Wed, 7 Sep 2011 00:06:23 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> In-Reply-To: <4E661C83.5000103@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] Thread-Index: AcxsltI1OnFhNZrWTKywTMB8sCGk/QAK9kAw References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> From: "Ravindran Parthasarathi" To: , "Matthew Kaufman" X-OriginalArrivalTime: 06 Sep 2011 18:36:30.0882 (UTC) FILETIME=[E5542020:01CC6CC3] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 18:34:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6CC3.E3A2F5B2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Matthew, =20 Even in case of SIP, there is no need of standardization in case it is within single webserver(skype). SIP supports x-header or proprietary header to extend the way you want it for providing innovative functionality. There is no extension barrier from SIP perspective but it ensure that basic call works across web servers. For example, skype browser user will able to talk to gmail real-time user even though all skype functionality are not supported. =20 In case you have the points why HTTP allows innovation but SIP will not, let us discuss in detail. =20 Thanks Partha =20 From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com]=20 Sent: Tuesday, September 06, 2011 6:44 PM To: Matthew Kaufman Cc: Ravindran Parthasarathi; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] =20 I find this reasoning hard to understand. First, the SIP standard has been around for a decade. What new standardization is needed? Igor On 9/5/2011 11:39 PM, Matthew Kaufman wrote:=20 On 8/23/2011 5:57 PM, Ravindran Parthasarathi wrote:=20 =20 I'm interested in hearing the reasons for why SIP MUST NOT be used in browser. =20 The primary reason for avoiding a protocol like SIP between the web browser and its associated server(s) is that adding *any* functionality requires a round of standardization effort, whereas following the web model (HTML and Javascript in the clients, arbitrary signaling over HTTP) allows for immediate and frequent innovation on that channel. Matthew Kaufman ------_=_NextPart_001_01CC6CC3.E3A2F5B2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Matthew,

 

Even in case of SIP, there is no need of standardization = in case it is within single webserver(skype). SIP supports x-header or = proprietary header to extend the way you want it for providing innovative = functionality. There is no extension barrier from SIP perspective but it ensure that = basic call works across web servers. For example, skype browser user will able = to talk to gmail real-time user even though all skype functionality are not supported.

 

 In case you have the points why HTTP allows = innovation but SIP will not, let us discuss in detail.

 

Thanks

Partha

 

From: Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com]
Sent: Tuesday, September 06, 2011 6:44 PM
To: Matthew Kaufman
Cc: Ravindran Parthasarathi; rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remote recording - RTC-Web client acting as SIPREC session recording = client]

 

I find this reasoning hard to understand.  = First, the SIP standard has been around for a decade. What new standardization is = needed?

Igor

On 9/5/2011 11:39 PM, Matthew Kaufman wrote:

On 8/23/2011 5:57 PM, Ravindran Parthasarathi = wrote:

 

I’m interested in hearing the reasons for why SIP = MUST NOT be used in browser.

 


The primary reason for avoiding a protocol like SIP between the web = browser and its associated server(s) is that adding *any* functionality requires a = round of standardization effort, whereas following the web model (HTML and = Javascript in the clients, arbitrary signaling over HTTP) allows for immediate and = frequent innovation on that channel.

Matthew Kaufman

------_=_NextPart_001_01CC6CC3.E3A2F5B2-- From matthew.kaufman@skype.net Tue Sep 6 11:38: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 01F0A21F8CF9 for ; Tue, 6 Sep 2011 11:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.752 X-Spam-Level: X-Spam-Status: No, score=-4.752 tagged_above=-999 required=5 tests=[AWL=1.846, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6dsTyNznRYg for ; Tue, 6 Sep 2011 11:38:55 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id EFBD321F8CF6 for ; Tue, 6 Sep 2011 11:38:54 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id AF1CD16F5; Tue, 6 Sep 2011 20:40:41 +0200 (CEST) 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; s=mx; bh=q13oV5EOGC3TRZXkxSo5e9TiHUI=; b=FWle0YFTY 1Wuxaw2Qor+bOfDMaOgbV43BA5nkImF5BUvj0jBkEamw5lh/xeHZPiHsM/98+95i vBajSOIZIDHoAPOL9mNxjtDCcp105EL+MukpUTOWD4CG+yGrdzw+AQhY2gi0sDiu 4jb4qbpIrUmxkTKDfDYIS4ZjtrQbvnPuF8= 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; q=dns; s=mx; b=bGxAUR4h7vIxDiBzZCV4wecwWBoP5vv0Q7G/VHrxUI/evFrm a0oE3K4qxebVdCoodY6MO/Ec3yKgWFf/JCLZuTKgd81qAJoG6/51D3laVD5yXGMh sr4QqoS+ky+Ib+PtITKGgiSN0s+MPtKu8VmuIsRzvancCL9MwM4sdqPjUvA= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id ADAC07F6; Tue, 6 Sep 2011 20:40:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 8FB2F3507E34; Tue, 6 Sep 2011 20:40:41 +0200 (CEST) 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 VaQIVxSGqRnZ; Tue, 6 Sep 2011 20:40:40 +0200 (CEST) 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 91FA23507345; Tue, 6 Sep 2011 20:40:39 +0200 (CEST) Message-ID: <4E666926.8050705@skype.net> Date: Tue, 06 Sep 2011 11:40:38 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> Content-Type: multipart/alternative; boundary="------------070506040508090700030908" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 18:38:56 -0000 This is a multi-part message in MIME format. --------------070506040508090700030908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/6/11 11:36 AM, Ravindran Parthasarathi wrote: > > Matthew, > > Even in case of SIP, there is no need of standardization in case it is > within single webserver(skype). SIP supports x-header or proprietary > header to extend the way you want it for providing innovative > functionality. > Not if SIP is baked in to the browser it doesn't. If the browser implements a SIP phone in native code, I have no way of adding "x-header" or anything else. I live with the functionality provided by the browser. If on the other hand, you want SIP implemented in Javascript then sure, if a developer wants to use it, great. If they want to extend it, that's fine too. And if they'd rather use another model, they are free to do that. Just as you would expect from a *platform*. > There is no extension barrier from SIP perspective but it ensure that > basic call works across web servers. For example, skype browser user > will able to talk to gmail real-time user even though all skype > functionality are not supported. > See above. > > In case you have the points why HTTP allows innovation but SIP will > not, let us discuss in detail. > See above. I want you to be free to use SIP, but not *required* to use SIP. And there's some security reasons that I'd rather you tunnel it over HTTP rather than opening up your ability to send UDP packets to port 5060. Matthew Kaufman --------------070506040508090700030908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/6/11 11:36 AM, Ravindran Parthasarathi wrote:

Matthew,

 

Even in case of SIP, there is no need of standardization in case it is within single webserver(skype). SIP supports x-header or proprietary header to extend the way you want it for providing innovative functionality.


Not if SIP is baked in to the browser it doesn't. If the browser implements a SIP phone in native code, I have no way of adding "x-header" or anything else. I live with the functionality provided by the browser.

If on the other hand, you want SIP implemented in Javascript then sure, if a developer wants to use it, great. If they want to extend it, that's fine too. And if they'd rather use another model, they are free to do that. Just as you would expect from a *platform*.

There is no extension barrier from SIP perspective but it ensure that basic call works across web servers. For example, skype browser user will able to talk to gmail real-time user even though all skype functionality are not supported.

See above.

 

 In case you have the points why HTTP allows innovation but SIP will not, let us discuss in detail.


See above. I want you to be free to use SIP, but not *required* to use SIP.

And there's some security reasons that I'd rather you tunnel it over HTTP rather than opening up your ability to send UDP packets to port 5060.

Matthew Kaufman

--------------070506040508090700030908-- From oej@edvina.net Tue Sep 6 11:45: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 3A54A21F8D48 for ; Tue, 6 Sep 2011 11:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 9uTmZi5f7L-g for ; Tue, 6 Sep 2011 11:45:26 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id A507021F8D47 for ; Tue, 6 Sep 2011 11:45:26 -0700 (PDT) Received: from [192.168.40.76] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 60D5C754BCE4; Tue, 6 Sep 2011 18:47:10 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <4E666926.8050705@skype.net> Date: Tue, 6 Sep 2011 20:47:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> To: Matthew Kaufman X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 18:45:27 -0000 6 sep 2011 kl. 20:40 skrev Matthew Kaufman: > On 9/6/11 11:36 AM, Ravindran Parthasarathi wrote: >> Matthew, >> =20 >> Even in case of SIP, there is no need of standardization in case it = is within single webserver(skype). SIP supports x-header or proprietary = header to extend the way you want it for providing innovative = functionality. >=20 > Not if SIP is baked in to the browser it doesn't. If the browser = implements a SIP phone in native code, I have no way of adding = "x-header" or anything else. I live with the functionality provided by = the browser. That's an implementation detail. One can easily add an API call to add = headers on the outbound INVITE. >=20 > If on the other hand, you want SIP implemented in Javascript then = sure, if a developer wants to use it, great. If they want to extend it, = that's fine too. And if they'd rather use another model, they are free = to do that. Just as you would expect from a *platform*. >=20 >> There is no extension barrier from SIP perspective but it ensure that = basic call works across web servers. For example, skype browser user = will able to talk to gmail real-time user even though all skype = functionality are not supported. > See above. >> =20 >> In case you have the points why HTTP allows innovation but SIP will = not, let us discuss in detail. >=20 > See above. I want you to be free to use SIP, but not *required* to use = SIP. >=20 > And there's some security reasons that I'd rather you tunnel it over = HTTP rather than opening up your ability to send UDP packets to port = 5060. SIP runs on TCP and TLS ports too. I am not arguing for either side, just correcting some details... /O From pravindran@sonusnet.com Tue Sep 6 12:00: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 22EA121F8D13 for ; Tue, 6 Sep 2011 12:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 D5gdrNiTOv2E for ; Tue, 6 Sep 2011 12:00:53 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFD621F8D89 for ; Tue, 6 Sep 2011 12:00:46 -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 p86J2wQR007816; Tue, 6 Sep 2011 15:02:58 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Sep 2011 15:02:28 -0400 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, 7 Sep 2011 00:32:24 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F086C@sonusinmail02.sonusnet.com> In-Reply-To: <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] Thread-Index: AcxsxWWfyNnA2J9pQ+iNipdIXlgKZwAAIJVg References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> From: "Ravindran Parthasarathi" To: "Olle E. Johansson" , "Matthew Kaufman" X-OriginalArrivalTime: 06 Sep 2011 19:02:28.0315 (UTC) FILETIME=[85A18AB0:01CC6CC7] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 19:00:56 -0000 Matthew, >> And there's some security reasons that I'd rather you tunnel it over >HTTP rather than opening up your ability to send UDP packets to port >5060. >SIP runs on TCP and TLS ports too. In case one port opening (80) will not create security issue but how opening two ports (80 & 5060) will cause security issue? Could you please explain the security reason between port 80 for HTTP and 5060 for SIP Please read inline for further comments. Thanks Partha >-----Original Message----- >From: Olle E. Johansson [mailto:oej@edvina.net] >Sent: Wednesday, September 07, 2011 12:17 AM >To: Matthew Kaufman >Cc: Ravindran Parthasarathi; rtcweb@ietf.org >Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote >recording - RTC-Web client acting as SIPREC session recording client] > > >6 sep 2011 kl. 20:40 skrev Matthew Kaufman: > >> On 9/6/11 11:36 AM, Ravindran Parthasarathi wrote: >>> Matthew, >>> >>> Even in case of SIP, there is no need of standardization in case it >is within single webserver(skype). SIP supports x-header or proprietary >header to extend the way you want it for providing innovative >functionality. >> >> Not if SIP is baked in to the browser it doesn't. If the browser >implements a SIP phone in native code, I have no way of adding "x- >header" or anything else. I live with the functionality provided by the >browser. >That's an implementation detail. One can easily add an API call to add >headers on the outbound INVITE. [Partha] My understanding is same as olle. Javascript API MUST provide the mechanism to add proprietary SIP headers or else I agree with you that solution is useless. > >> >> If on the other hand, you want SIP implemented in Javascript then >sure, if a developer wants to use it, great. If they want to extend it, >that's fine too. And if they'd rather use another model, they are free >to do that. Just as you would expect from a *platform*. >> >>> There is no extension barrier from SIP perspective but it ensure that >basic call works across web servers. For example, skype browser user >will able to talk to gmail real-time user even though all skype >functionality are not supported. >> See above. >>> >>> In case you have the points why HTTP allows innovation but SIP will >not, let us discuss in detail. >> >> See above. I want you to be free to use SIP, but not *required* to use >SIP. [Partha] In case Javascript API supports for adding new headers, there is no difference right? >> >> And there's some security reasons that I'd rather you tunnel it over >HTTP rather than opening up your ability to send UDP packets to port >5060. >SIP runs on TCP and TLS ports too. [Partha]=20 > >I am not arguing for either side, just correcting some details... > >/O From pravindran@sonusnet.com Tue Sep 6 12:20: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 C26D921F8DDD for ; Tue, 6 Sep 2011 12:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.107, 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 ujO-nhc25Ejb for ; Tue, 6 Sep 2011 12:20:17 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id D63DF21F8D57 for ; Tue, 6 Sep 2011 12:20:16 -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 p86JMVgJ020833; Tue, 6 Sep 2011 15:22:31 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Sep 2011 15:22:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6CCA.3F4A5792" Date: Wed, 7 Sep 2011 00:51:56 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F086D@sonusinmail02.sonusnet.com> In-Reply-To: <4E666785.7040409@skype.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver Thread-Index: Acxsw4j0QEQjeP+zQauUz1nAwB/5WgABA50w References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> <4E666785.7040409@skype.net> From: "Ravindran Parthasarathi" To: "Matthew Kaufman" X-OriginalArrivalTime: 06 Sep 2011 19:22:01.0503 (UTC) FILETIME=[40E7D2F0:01CC6CCA] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 19:20:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6CCA.3F4A5792 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Matthew, =20 Please read inline. =20 Thanks Partha =20 From: Matthew Kaufman [mailto:matthew.kaufman@skype.net]=20 Sent: Wednesday, September 07, 2011 12:04 AM To: Ravindran Parthasarathi Cc: Bernard Aboba; hoang.su.tk@gmail.com; rtcweb@ietf.org Subject: Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver =20 On 9/6/11 11:06 AM, Ravindran Parthasarathi wrote:=20 Matthew, =20 Please read inline. =20 Thanks Partha =20 From: Matthew Kaufman [mailto:matthew.kaufman@skype.net]=20 Sent: Tuesday, September 06, 2011 9:07 AM To: Ravindran Parthasarathi Cc: Bernard Aboba; hoang.su.tk@gmail.com; rtcweb@ietf.org Subject: Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver =20 On 9/5/2011 12:16 PM, Ravindran Parthasarathi wrote:=20 Bernard, =20 Sorry for the delay reply. =20 There is a huge difference between tunneling the protocol and converting the protocol from one format to another. The tunneling works well only in case the destination support the tunneled data without negotiation. It will be bad assumption in case the standard does not defined so. For example,=20 =20 Browser A supports Jingle (XMPP for real-time data) and encapsulates the data in HTTP and send it to webserver1 That isn't how it works. Browser A supports WebRTC. Do you mean browser A is running Javascript that implements Jingle or something similar for its signaling (over HTTP and/or Websockets) to its associated web server? [Partha]Browser A supports WebRTC Javascript API which is mapped to Jingle. Browser A is not required to have native support of Jingle. I guess that we mean the same thing. =20 Sounds like we mean the same thing. RTCwebserver1 tunnel jingle data in SIP and sends it to RTCwebserver2 Federation between webserver1 and webserver2 is up to the operators of those sites. Presumably SIP is a good (but not only) choice for federation. Many sites won't have a desire or need to federate. [Partha] Here is the problem, it is expected that webserver1 has to converts its proprietary stuff into SIP or other equivalent. So, RTCweb to SIP gateway is mandated in your proposed architecture for the basic dialog between two users in two webservers. It will be tough for each webserver developer to create the proprietary protocol and mapping. Instead, the basic SIP functionality provided in browser will make sure the basic call works between any users across webserver without limiting the innovative application build by individual webservers. =20 Disagree. It is expected that webserver1 usually *doesn't* convert its proprietary stuff into SIP. That only happens when you want to federate with another service that uses SIP. If it is "tough" to create a mapping between your proprietary stuff and SIP then perhaps you didn't design your proprietary stuff properly... that isn't my problem however. Basic SIP functionality provided in the browser would likely limit the API in ways that block innovation. [Partha] we discussed in another mail thread for providing Javascript API which helps to add SIP proprietary headers. =20 RTCwebserver2 does not support Jingle towards browser but it support some other variant of HTTP based metadata to the browser.=20 Do you mean that webserver2 and its clients are running compatible code that exchanges signaling via a mechanism other than Jingle? That's fine, and up to the operator of that site. My question is how webserver2 do perform the interop correctly in case Jingle is not mandated as metadata standard mechanism. Please let me know your opinion here. Every site that wishes to federate with others will need to choose a signaling protocol that is agreed between them. [Partha] it is bad network design because SIP is well accepted in real-time applications (telecom or unified communication) and also there is no need of contract with each site (company) and implement their protocol to interop with them. =20 SIP is well accepted in *some* real-time applications. I would note that the most popular real-time applications don't actually use SIP. [Partha] Those mentioned popular real-time applications will never interop with any other popular real-time application and also IETF or other standard is not required for those real-time applications. And yet there is SIP, for when you wish to interop without lengthy contract or discussion. The best of both worlds. =20 My understanding was that RTCwebserver1 may use some proprietary mechanism (may be jingle) to communicate between browser and webserver which will be converted into RFC 3261 SIP at webserver1 and forwarded to RTCwebserver2. RTCWebserver2 converts back SIP to its own proprietary metadata to communicate with browser. This mechanism works well but still better mechanism exists. That understanding appears to be correct. This is exactly the same as "Hotmail talks some proprietary protocol over HTTP between its HTML/Javascript client and its servers which is then converted to SMTP for sending to Gmail, where Gmail talks a different proprietary protocol over HTTP between its HTML/Javascript client and its servers." It appears to have resulted in some significant innovations in the email service space, while still allowing federation between domains using a standard protocol. [Partha] This paradigm will not exactly fit for real-time communication because there is a need of communication between browser to browser apart from webserver to webserver communication. Still I could not under the reason why SIP will stop the innovation whereas HTTP will allow. Because SIP requires standards activities before adding any useful functionality. I'll point to one of my favorites here: bridged line appearances. Despite lots of effort to fix this, there still isn't a way to do this reliably. And yet, if I created a web application using HTTP signaling and Javascript APIs on a web browser that provides a *platform* and not just a "phone", I could create a system in which bridged line appearances work well if I so desired with just a little bit of programming. [Partha] In case you write some bridged line appearance which will not work my implementation of bridged line appearance. Hope you agree here. My point is that atleast basic scenario is taken as part of IETF bliss WG. Even I have mentioned earlier for the basic call in SIP because I know that supplementary services are not going to work easily. But most of the user uses basic call. If you think this is a bad idea, provide an alternative we might discuss. [Partha] I'm thinking of the solution which is in line of draft-cbran-rtcweb-protocols-00. Browser is intelligent entity which makes real-time communication with other browser using SIP. The configuration data required for browser SIP client is received through Javascript and/or received metadata from webserver using HTTP connection. Making SIP as a protocol for real-time communication will make sure that browser not only communicates with another browser but also ensure that it works with existing SIP implementation. It was my original usecase wherein browser directly communicates with VoIP-server. VoIP server may communicates with browser which does not matter for the originating browser. =20 So you want the browser to be a phone, and not a platform for innovation in the area of real-time applications. It is already a platform for innovation in many other areas, why limit it here? [Partha] My intention is not to make browser as SIP phone. SIP is a real-time communication protocol which helps to innovate application which obsoletes legacy phones using browser. I'm asking why not take advantage of SIP in the browser. Matthew Kaufman ------_=_NextPart_001_01CC6CCA.3F4A5792 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Matthew,

 

Please read inline.

 

Thanks

Partha

 

From: Matthew Kaufman [mailto:matthew.kaufman@skype.net]
Sent: Wednesday, September 07, 2011 12:04 AM
To: Ravindran Parthasarathi
Cc: Bernard Aboba; hoang.su.tk@gmail.com; rtcweb@ietf.org
Subject: Re: [rtcweb] Usecase & architecture: Browser = application with separate webserver & voipserver

 

On 9/6/11 11:06 AM, Ravindran Parthasarathi wrote: =

Matthew,

 

Please read inline.

 

Thanks

Partha

 

From: Matthew Kaufman [mailto:matthew.kaufman@skype.ne= t]
Sent: Tuesday, September 06, 2011 9:07 AM
To: Ravindran Parthasarathi
Cc: Bernard Aboba; hoang.su.tk@gmail.com; rtcweb@ietf.org
Subject: Re: [rtcweb] Usecase & architecture: Browser = application with separate webserver & voipserver

 

On 9/5/2011 12:16 PM, Ravindran Parthasarathi = wrote:

Bernard,

 

Sorry for the delay reply.

 

There is a huge difference between tunneling the protocol = and converting the protocol from one format to another. The tunneling works well only = in case the destination support the tunneled data without negotiation. It will = be bad assumption in case the standard does not defined so.  For example, =

 

Browser A supports Jingle = (XMPP for real-time data) and encapsulates the data in HTTP and send it to = webserver1


That isn't how it works. Browser A supports WebRTC. Do you mean browser = A is running Javascript that implements Jingle or something similar for its signaling (over HTTP and/or Websockets) to its associated web = server?

[Partha]Browser = A supports WebRTC Javascript API which is mapped to Jingle. Browser A is = not required to have native support of Jingle. I guess that we mean the same = thing.

 


Sounds like we mean the same thing.




RTCwebserver1 tunnel jingle = data in SIP and sends it to RTCwebserver2


Federation between webserver1 and webserver2 is up to the operators of = those sites. Presumably SIP is a good (but not only) choice for federation. = Many sites won't have a desire or need to federate.

[Partha] Here is the problem, it is expected that = webserver1 has to converts its proprietary stuff into SIP or other equivalent. So, = RTCweb to SIP gateway is mandated in your proposed architecture for the basic = dialog between two users in two webservers. It will be tough for each webserver developer to create the proprietary protocol and mapping. Instead, the = basic SIP functionality provided in browser will make sure the basic call = works between any users across webserver without limiting the innovative = application build by individual webservers.

 


Disagree. It is expected that webserver1 usually *doesn't* convert its proprietary stuff into SIP. That only happens when you want to federate = with another service that uses SIP.

If it is "tough" to create a mapping between your proprietary = stuff and SIP then perhaps you didn't design your proprietary stuff = properly... that isn't my problem however.

Basic SIP functionality provided in the browser would likely limit the = API in ways that block innovation.
[Partha] we discussed in another = mail thread for providing Javascript API which helps to add SIP proprietary = headers.
 




RTCwebserver2 does not = support Jingle towards browser but it support some other variant of HTTP based = metadata to the browser.


Do you mean that webserver2 and its clients are running compatible code = that exchanges signaling via a mechanism other than Jingle? That's fine, and = up to the operator of that site.



My question is how webserver2 do perform the interop = correctly in case Jingle is not mandated as metadata standard mechanism. Please = let me know your opinion here.


Every site that wishes to federate with others will need to choose a = signaling protocol that is agreed between them.

[Partha] it is bad network design because SIP is well = accepted in real-time applications (telecom or unified communication) and also = there is no need of contract with each site (company) and implement their = protocol to interop with them.

 


SIP is well accepted in *some* real-time applications. I would note that = the most popular real-time applications don't actually use SIP.

[Partha] Those mentioned popular real-time applications = will never interop with any other popular real-time application and also IETF = or other standard is not required for those real-time = applications.



And yet there is SIP, for when you wish to interop without lengthy = contract or discussion. The best of both worlds.





 

My understanding was that RTCwebserver1 may use some proprietary mechanism = (may be jingle) to communicate between browser and webserver which will be = converted into RFC 3261 SIP at webserver1 and forwarded to RTCwebserver2. = RTCWebserver2 converts back SIP to its own proprietary metadata to communicate with = browser. This mechanism works well but still better mechanism = exists.


That understanding appears to be correct. This is exactly the same as "Hotmail talks some proprietary protocol over HTTP between its HTML/Javascript client and its servers which is then converted to SMTP = for sending to Gmail, where Gmail talks a different proprietary protocol = over HTTP between its HTML/Javascript client and its servers." It appears to have = resulted in some significant innovations in the email service space, while still allowing federation between domains using a standard = protocol.

[Partha] This = paradigm will not exactly fit for real-time communication because there is a need = of communication between browser to browser apart from webserver to = webserver communication. Still I could not under the reason why SIP will stop the innovation whereas HTTP will allow.


Because SIP requires standards activities before adding any useful functionality. I'll point to one of my favorites here: bridged line appearances. Despite lots of effort to fix this, there still isn't a way = to do this reliably. And yet, if I created a web application using HTTP = signaling and Javascript APIs on a web browser that provides a *platform* and not just = a "phone", I could create a system in which bridged line = appearances work well if I so desired with just a little bit of programming.

[Partha] In case you write some bridged line appearance = which will not work my implementation of bridged line appearance. Hope you = agree here. My point is that atleast basic scenario is taken as part of IETF = bliss WG. Even I have mentioned earlier for the basic call in SIP because I = know that supplementary services are not going to work easily. But most of the = user uses basic call.




If you think this is = a bad idea, provide an alternative we might discuss.

[Partha] = I’m thinking of the solution which is in line of = draft-cbran-rtcweb-protocols-00. Browser is intelligent entity which makes real-time communication with = other browser using SIP. The configuration data required for browser SIP = client is received through Javascript and/or received metadata from webserver = using HTTP connection. Making SIP as a protocol for real-time communication will = make sure that browser not only communicates with another browser but also ensure = that it works with existing SIP implementation. It was my original usecase = wherein browser directly communicates with VoIP-server. VoIP server may = communicates with browser which does not matter for the originating = browser.

 


So you want the browser to be a phone, and not a platform for innovation = in the area of real-time applications. It is already a platform for innovation = in many other areas, why limit it here?

[Partha] My = intention is not to make browser as SIP phone. SIP is a real-time communication = protocol which helps to innovate application which obsoletes legacy phones using browser. I’m asking why not take advantage of SIP in the = browser.



Matthew Kaufman

------_=_NextPart_001_01CC6CCA.3F4A5792-- From tasveren@sonusnet.com Tue Sep 6 12:23: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 9344E21F8DF3 for ; Tue, 6 Sep 2011 12:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnL1uSIs8elj for ; Tue, 6 Sep 2011 12:23:00 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id DF53921F8DE3 for ; Tue, 6 Sep 2011 12:22:59 -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 p86JPEoL022616; Tue, 6 Sep 2011 15:25:14 -0400 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: Tue, 6 Sep 2011 15:24:43 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] Thread-Index: AcxsxWa6uLMlQZgpSKmObyh7+21UnwABHRzA References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> From: "Asveren, Tolga" To: "Olle E. Johansson" , "Matthew Kaufman" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 19:23:00 -0000 What about semantics (adding just a X-header won't help there) or how = much SIP would be left anyhow if all semantical control is exposed = through the API? I think bridged line appearance is a good test to run against different = models. Thanks, Tolga -----Original Message----- From: rtcweb-bounces@ietf.org on behalf of Olle E. Johansson Sent: Tue 9/6/2011 2:47 PM To: Matthew Kaufman Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remoterecording - RTC-Web client acting as SIPREC session = recordingclient] =20 6 sep 2011 kl. 20:40 skrev Matthew Kaufman: > On 9/6/11 11:36 AM, Ravindran Parthasarathi wrote: >> Matthew, >> =20 >> Even in case of SIP, there is no need of standardization in case it = is within single webserver(skype). SIP supports x-header or proprietary = header to extend the way you want it for providing innovative = functionality. >=20 > Not if SIP is baked in to the browser it doesn't. If the browser = implements a SIP phone in native code, I have no way of adding = "x-header" or anything else. I live with the functionality provided by = the browser. That's an implementation detail. One can easily add an API call to add = headers on the outbound INVITE. >=20 > If on the other hand, you want SIP implemented in Javascript then = sure, if a developer wants to use it, great. If they want to extend it, = that's fine too. And if they'd rather use another model, they are free = to do that. Just as you would expect from a *platform*. >=20 >> There is no extension barrier from SIP perspective but it ensure that = basic call works across web servers. For example, skype browser user = will able to talk to gmail real-time user even though all skype = functionality are not supported. > See above. >> =20 >> In case you have the points why HTTP allows innovation but SIP will = not, let us discuss in detail. >=20 > See above. I want you to be free to use SIP, but not *required* to use = SIP. >=20 > And there's some security reasons that I'd rather you tunnel it over = HTTP rather than opening up your ability to send UDP packets to port = 5060. SIP runs on TCP and TLS ports too. I am not arguing for either side, just correcting some details... /O _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From igor.faynberg@alcatel-lucent.com Tue Sep 6 12:44: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 63D0621F8E22 for ; Tue, 6 Sep 2011 12:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.605 X-Spam-Level: X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 SCLcBJOKsGuf for ; Tue, 6 Sep 2011 12:44:51 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB3C21F8E3D for ; Tue, 6 Sep 2011 12:44:51 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p86Jkb4b005199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Sep 2011 14:46:37 -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 p86JkaXE001890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 6 Sep 2011 14:46:37 -0500 Received: from [135.244.40.187] (faynberg.lra.lucent.com [135.244.40.187]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p86JkaBb009217; Tue, 6 Sep 2011 14:46:36 -0500 (CDT) Message-ID: <4E66789C.4020307@alcatel-lucent.com> Date: Tue, 06 Sep 2011 15:46:36 -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: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> In-Reply-To: <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] 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, 06 Sep 2011 19:44:52 -0000 The key question is: What MUST the browser provide to support a SIP implementation in an application? (I asked this question a few thousand messages back, but the thread was inconclusive.) HTTP alone cannot do the job. How will the user agent receive notifications, for example? Igor On 9/6/2011 2:47 PM, Olle E. Johansson wrote: > 6 sep 2011 kl. 20:40 skrev Matthew Kaufman: > >> On 9/6/11 11:36 AM, Ravindran Parthasarathi wrote: >>> Matthew, >>> >>> Even in case of SIP, there is no need of standardization in case it is within single webserver(skype). SIP supports x-header or proprietary header to extend the way you want it for providing innovative functionality. >> Not if SIP is baked in to the browser it doesn't. If the browser implements a SIP phone in native code, I have no way of adding "x-header" or anything else. I live with the functionality provided by the browser. > That's an implementation detail. One can easily add an API call to add headers on the outbound INVITE. > >> If on the other hand, you want SIP implemented in Javascript then sure, if a developer wants to use it, great. If they want to extend it, that's fine too. And if they'd rather use another model, they are free to do that. Just as you would expect from a *platform*. >> >>> There is no extension barrier from SIP perspective but it ensure that basic call works across web servers. For example, skype browser user will able to talk to gmail real-time user even though all skype functionality are not supported. >> See above. >>> >>> In case you have the points why HTTP allows innovation but SIP will not, let us discuss in detail. >> See above. I want you to be free to use SIP, but not *required* to use SIP. >> >> And there's some security reasons that I'd rather you tunnel it over HTTP rather than opening up your ability to send UDP packets to port 5060. > SIP runs on TCP and TLS ports too. > > I am not arguing for either side, just correcting some details... > > /O > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From juberti@google.com Tue Sep 6 13:21: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 7858B21F8DFD for ; Tue, 6 Sep 2011 13:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.669 X-Spam-Level: X-Spam-Status: No, score=-104.669 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1ILGFnYWKTI for ; Tue, 6 Sep 2011 13:21:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 21D6821F8E0F for ; Tue, 6 Sep 2011 13:21:35 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p86KNCZd020324 for ; Tue, 6 Sep 2011 13:23:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315340593; bh=dBT6KUEk50c7cxTByU866k/aIzo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=VkTsdg7nwTCWYTgKFmQhAFETd3F8mvqarq3KSxgJtf4nUaG19QhjSt7tL7acY4cFf BSBR1lGhhJBGtxKHQ98Mg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=RHyOb+BdAq4HUibAfg0myJlHqe5wAxe34TOpm7f1n6IeszJd+Hi6IkGmzXZPl+IrQ rR+/2u1C9wU9wHWvPCJNA== Received: from yib12 (yib12.prod.google.com [10.243.65.76]) by hpaq5.eem.corp.google.com with ESMTP id p86KMYl3016683 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 6 Sep 2011 13:23:11 -0700 Received: by yib12 with SMTP id 12so3838146yib.10 for ; Tue, 06 Sep 2011 13:23:11 -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; bh=0tQyaPKLcFVJXkz5BQezhZ6jEXcCmzG99NYUNWRt25U=; b=WHHG0+8xXx1O2Gp61gKCcecvu/KWiz8KA8Te+5fPJDIUVZ/Y9YRBMWnZIKR8J33H0i PytqT4qpoKNG7zcg+Ezw== Received: by 10.231.66.85 with SMTP id m21mr10411859ibi.53.1315340591499; Tue, 06 Sep 2011 13:23:11 -0700 (PDT) Received: by 10.231.66.85 with SMTP id m21mr10411852ibi.53.1315340591272; Tue, 06 Sep 2011 13:23:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.36.10 with HTTP; Tue, 6 Sep 2011 13:22:50 -0700 (PDT) In-Reply-To: <4E66789C.4020307@alcatel-lucent.com> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <4E66789C.4020307@alcatel-lucent.com> From: Justin Uberti Date: Tue, 6 Sep 2011 16:22:50 -0400 Message-ID: To: igor.faynberg@alcatel-lucent.com Content-Type: multipart/alternative; boundary=0015176f09d8b392d004ac4b9864 X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 20:21:37 -0000 --0015176f09d8b392d004ac4b9864 Content-Type: text/plain; charset=UTF-8 Notifications can be received over WebSockets, or any of the existing mechanisms web applications use for server->client notifications. On Tue, Sep 6, 2011 at 3:46 PM, Igor Faynberg < igor.faynberg@alcatel-lucent.com> wrote: > The key question is: What MUST the browser provide to support a SIP > implementation in an application? (I asked this question a few thousand > messages back, but the thread was inconclusive.) > > HTTP alone cannot do the job. How will the user agent receive > notifications, for example? > > Igor > > > On 9/6/2011 2:47 PM, Olle E. Johansson wrote: > >> 6 sep 2011 kl. 20:40 skrev Matthew Kaufman: >> >> On 9/6/11 11:36 AM, Ravindran Parthasarathi wrote: >>> >>>> Matthew, >>>> >>>> Even in case of SIP, there is no need of standardization in case it is >>>> within single webserver(skype). SIP supports x-header or proprietary header >>>> to extend the way you want it for providing innovative functionality. >>>> >>> Not if SIP is baked in to the browser it doesn't. If the browser >>> implements a SIP phone in native code, I have no way of adding "x-header" or >>> anything else. I live with the functionality provided by the browser. >>> >> That's an implementation detail. One can easily add an API call to add >> headers on the outbound INVITE. >> >> If on the other hand, you want SIP implemented in Javascript then sure, >>> if a developer wants to use it, great. If they want to extend it, that's >>> fine too. And if they'd rather use another model, they are free to do that. >>> Just as you would expect from a *platform*. >>> >>> There is no extension barrier from SIP perspective but it ensure that >>>> basic call works across web servers. For example, skype browser user will >>>> able to talk to gmail real-time user even though all skype functionality are >>>> not supported. >>>> >>> See above. >>> >>>> >>>> In case you have the points why HTTP allows innovation but SIP will >>>> not, let us discuss in detail. >>>> >>> See above. I want you to be free to use SIP, but not *required* to use >>> SIP. >>> >>> And there's some security reasons that I'd rather you tunnel it over HTTP >>> rather than opening up your ability to send UDP packets to port 5060. >>> >> SIP runs on TCP and TLS ports too. >> >> I am not arguing for either side, just correcting some details... >> >> /O >> >> ______________________________**_________________ >> 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 > --0015176f09d8b392d004ac4b9864 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Notifications can be received over WebSockets, or any of the existing mecha= nisms web applications use for server->client notifications.

On Tue, Sep 6, 2011 at 3:46 PM, Igor Faynberg <igor.fa= ynberg@alcatel-lucent.com> wrote:
The key question is: =C2=A0What MUST the br= owser provide to support a SIP implementation in an application? (I asked t= his question a few thousand messages back, but the thread was inconclusive.= )

HTTP alone cannot do the job. How will the user agent receive notifications= , for example?

Igor


On 9/6/2011 2:47 PM, Olle E. Johansson wrote:
6 sep 2011 kl. 20:40 skrev Matthew Kaufman:

On 9/6/11 11:36 AM, Ravindran Parthasarathi wrote:
Matthew,

Even in case of SIP, there is no need of standardization in case it is with= in single webserver(skype). SIP supports x-header or proprietary header to = extend the way you want it for providing innovative functionality.
Not if SIP is baked in to the browser it doesn't. If the browser implem= ents a SIP phone in native code, I have no way of adding "x-header&quo= t; or anything else. I live with the functionality provided by the browser.=
That's an implementation detail. One can easily add an API call to add = headers on the outbound INVITE.

If on the other hand, you want SIP implemented in Javascript then sure, if = a developer wants to use it, great. If they want to extend it, that's f= ine too. And if they'd rather use another model, they are free to do th= at. Just as you would expect from a *platform*.

There is no extension barrier from SIP perspective but it ensure that basic= call works across web servers. For example, skype browser user will able t= o talk to gmail real-time user even though all skype functionality are not = supported.
See above.

=C2=A0In case you have the points why HTTP allows innovation but SIP will = not, let us discuss in detail.
See above. I want you to be free to use SIP, but not *required* to use SIP.=

And there's some security reasons that I'd rather you tunnel it ove= r HTTP rather than opening up your ability to send UDP packets to port 5060= .
SIP runs on TCP and TLS ports too.

I am not arguing for either side, just correcting some details...

/O

_______________________________________________
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

--0015176f09d8b392d004ac4b9864-- From matthew.kaufman@skype.net Tue Sep 6 14:10: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 69A3C21F8E5C for ; Tue, 6 Sep 2011 14:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[AWL=1.704, 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 MRUEOWSG+Biu for ; Tue, 6 Sep 2011 14:10:00 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 97D3021F8E13 for ; Tue, 6 Sep 2011 14:09:29 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 33A0416F6; Tue, 6 Sep 2011 23:11:13 +0200 (CEST) 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=Eii7uKeu6U8cMW jVjIpOyy5m2Pk=; b=B1fpjgSeIVCzZvNkZad1xxX05rVRYSunVO7zXg1Nb+J9xg yj6eqZ9PZKXnW3Gdj1E8Fx2q4/KqGMy6jDgWDCqqOwRsfZnRnnfrl8qxO6QWE6wO puHSBg2qMdy0KyOrqSDzHnX5t1quM/RjYyYIfnzTOOQLLaArX+teaeQWZi754= 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=o1J+VA/vEUJTYCQYNdEEVz q+hLd/5HWS1s9MpqDvTJUsHPi8C6i3EnF2KVULmp4M/cy2A9/CuzBTwRSH2CyD1T sESxNKeX8CUBq2jMp71H8Cvml//+HFW/EGlo+Edt2a6Lf0PV2bqLEae/wetOnv7X zZIbDK7wy3Hy9Hans5cK4= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 322767F6; Tue, 6 Sep 2011 23:11:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 19E6E3507F15; Tue, 6 Sep 2011 23:11:13 +0200 (CEST) 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 kRYhOQiGvMdY; Tue, 6 Sep 2011 23:11:12 +0200 (CEST) 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 BDB8B3507FF7; Tue, 6 Sep 2011 23:11:11 +0200 (CEST) Message-ID: <4E668C6E.9000407@skype.net> Date: Tue, 06 Sep 2011 14:11:10 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: "Asveren, Tolga" References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 21:10:01 -0000 On 9/6/11 12:24 PM, Asveren, Tolga wrote: > What about semantics (adding just a X-header won't help there) or how much SIP would be left anyhow if all semantical control is exposed through the API? Exactly what I was going to say. Simply adding headers is not sufficient, unless you can also tell the far end to ignore the existing headers and control the functionality directly... in which case we're just using SIP as a transport. > > I think bridged line appearance is a good test to run against different models. Actually nearly any of the 100s of specialized existing SIP specifications is a good test, but the best ones are indeed the ones that *still* aren't final specifications. Matthew Kaufman From matthew.kaufman@skype.net Tue Sep 6 14:14: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 7CE2D21F8E2A for ; Tue, 6 Sep 2011 14:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.017 X-Spam-Level: X-Spam-Status: No, score=-5.017 tagged_above=-999 required=5 tests=[AWL=1.582, 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 AqxBs0pPewd5 for ; Tue, 6 Sep 2011 14:14:43 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2A921F8E22 for ; Tue, 6 Sep 2011 14:14:43 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 4B6FF16F5; Tue, 6 Sep 2011 23:16:28 +0200 (CEST) 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=lZt7Q7cIBhaOU/ PlC5MbiBlBgFk=; b=YMga/+QbsQdIvAWWSc4bu4wbYp8glyixFXHooD5fXkQftp t/Ox+i5p4PwxkkVIRoehaVvaPGwpEJVO2IeGjiubhPgdDpseM3/Iu9M/dIXyIbt/ ZaNzMZtLZAkciQbqgpbQzSMG0kzRz4cTW+t1s1e/MNzbYJKxpa8/M9xnGJArA= 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=l+hSBDpPvqrNCkQdWD34hV 4pdL2PMw5rPXLtzA/mwdEl/BUDExcGQNCwtR1T0Vil4Jn1d0kTFgz++rOtSLafY3 7lkMkyHNsQWVuX+onwtVy6yD3o43DzXnrQU6q93nRhuHAZr3NDd+BvTVtUZZZgeX nwxidawGLo2790Sr7DWF0= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 40A5B7F6; Tue, 6 Sep 2011 23:16:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 096ED350800F; Tue, 6 Sep 2011 23:16:28 +0200 (CEST) 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 c3jXIG2fHiXj; Tue, 6 Sep 2011 23:16:27 +0200 (CEST) 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 112DE3508008; Tue, 6 Sep 2011 23:16:25 +0200 (CEST) Message-ID: <4E668DA8.8050104@skype.net> Date: Tue, 06 Sep 2011 14:16:24 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <2E239D6FCD033C4BAF15F386A979BF510F086C@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F086C@sonusinmail02.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 21:14:44 -0000 On 9/6/11 12:02 PM, Ravindran Parthasarathi wrote: > Matthew, > > >> And there's some security reasons that I'd rather you tunnel it > over >> HTTP rather than opening up your ability to send UDP packets to port >> 5060. >> SIP runs on TCP and TLS ports too. > In case one port opening (80) will not create security issue but how > opening two ports (80& 5060) will cause security issue? Could you > please explain the security reason between port 80 for HTTP and 5060 for > SIP There has been a whole lot of work regarding what browsers do and don't do over HTTP. (Think: cross site access, what headers can be controlled from script, etc.) We would be forced to reinvent all of this for a reduced-functionality SIP in order to get the same protections. (Should a browser that runs Javascript loaded from www.evil.com be able to send SIP INVITE to addresses inside your firewall?) And there is a whole lot of infrastructure that allows organizations to safely allow HTTP to pass in and out of their infrastructure. > > Please read inline for further comments. > > Thanks > Partha > >> -----Original Message----- >> From: Olle E. Johansson [mailto:oej@edvina.net] >> Sent: Wednesday, September 07, 2011 12:17 AM >> To: Matthew Kaufman >> Cc: Ravindran Parthasarathi; rtcweb@ietf.org >> Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote >> recording - RTC-Web client acting as SIPREC session recording client] >> >> >> 6 sep 2011 kl. 20:40 skrev Matthew Kaufman: >> >>> On 9/6/11 11:36 AM, Ravindran Parthasarathi wrote: >>>> Matthew, >>>> >>>> Even in case of SIP, there is no need of standardization in case it >> is within single webserver(skype). SIP supports x-header or proprietary >> header to extend the way you want it for providing innovative >> functionality. >>> Not if SIP is baked in to the browser it doesn't. If the browser >> implements a SIP phone in native code, I have no way of adding "x- >> header" or anything else. I live with the functionality provided by the >> browser. >> That's an implementation detail. One can easily add an API call to add >> headers on the outbound INVITE. > [Partha] My understanding is same as olle. Javascript API MUST provide > the mechanism to add proprietary SIP headers or else I agree with you > that solution is useless. Not nearly sufficient as I stated before. The problem is the semantics of all the existing SIP messages and headers, not whether or not you can add more. Matthew Kaufman From matthew.kaufman@skype.net Tue Sep 6 14:23: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 5A07921F8EAA for ; Tue, 6 Sep 2011 14:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.122 X-Spam-Level: X-Spam-Status: No, score=-5.122 tagged_above=-999 required=5 tests=[AWL=1.476, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bIMpULIOgQF for ; Tue, 6 Sep 2011 14:23:24 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 621ED21F8E91 for ; Tue, 6 Sep 2011 14:23:24 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 248D016F5; Tue, 6 Sep 2011 23:25:11 +0200 (CEST) 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; s=mx; bh=d3G8guX/ykkIufxMwNhugg93GaA=; b=pSiVq9Iqi RWG9opSoLthr7NsvLbOzAI1rJ1SCpsetxwXzQ7ozooxQRoVoMwRSjuNvgSmYOKee BZ/Pk60ncRQhYARnF6VcqHTxUKnvB0Fh315dq89RQtzqo9qAQc7Pnx1/Z5mIp2mY h3M++3Qj1yCkdTr9/F2Xe4oa7Xv4MOwwiY= 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; q=dns; s=mx; b=ZO+x2VqSXbyKv6x/u7UfGgkrwBPWCJUahi3K2Q12Zgu1o/7r bkaOAw4ZJSvjwk0apUckljRLryrr9YjXLSu2HNxkaZ93aw6dbJ1iO24LMnwho8dC zlW3bNnb9oNS7Oppip2ihCnBQY3GEjKhAVrSssdok752mOYR5knfdm4ejhk= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 1A1807F6; Tue, 6 Sep 2011 23:25:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id DF9F43507FF7; Tue, 6 Sep 2011 23:25:10 +0200 (CEST) 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 w5yU-lPuC4lr; Tue, 6 Sep 2011 23:25:10 +0200 (CEST) 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 421313508008; Tue, 6 Sep 2011 23:25:09 +0200 (CEST) Message-ID: <4E668FB3.9020601@skype.net> Date: Tue, 06 Sep 2011 14:25:07 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> In-Reply-To: <4E661C83.5000103@alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------020804020709030806050204" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 21:23:25 -0000 This is a multi-part message in MIME format. --------------020804020709030806050204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/6/11 6:13 AM, Igor Faynberg wrote: > I find this reasoning hard to understand. First, the SIP standard has > been around for a decade. What new standardization is needed? The issue is whenever you wish to innovate and add functionality. See the long, long list of RFCs that extend SIP. For some examples: RFC3515 - Refer method RFC3842 - Message waiting RFC3891 - Replaces header RFC3911 - Join header RFC3960 - Early media RFC4411 - Reason header for preemption Never mind all the things that aren't even finished... draft-ietf-bliss-shared-appearances draft-ietf-bliss-call-park-extension true bridged line appearances etc etc If all you want is a basic point-to-point phone, there's a short list of RFCs you implement and you're done. But that isn't a platform for innovation... it is just a phone. Matthew Kaufman --------------020804020709030806050204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/6/11 6:13 AM, Igor Faynberg wrote:
I find this reasoning hard to understand.  First, the SIP standard has been around for a decade. What new standardization is needed?

The issue is whenever you wish to innovate and add functionality.

See the long, long list of RFCs that extend SIP. For some examples:
RFC3515 - Refer method
RFC3842 - Message waiting
RFC3891 - Replaces header
RFC3911 - Join header
RFC3960 - Early media
RFC4411 - Reason header for preemption

Never mind all the things that aren't even finished...

draft-ietf-bliss-shared-appearances
draft-ietf-bliss-call-park-extension

true bridged line appearances

etc

etc

If all you want is a basic point-to-point phone, there's a short list of RFCs you implement and you're done. But that isn't a platform for innovation... it is just a phone.

Matthew Kaufman

--------------020804020709030806050204-- From matthew.kaufman@skype.net Tue Sep 6 14: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 D82B121F8B85 for ; Tue, 6 Sep 2011 14:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.214 X-Spam-Level: X-Spam-Status: No, score=-5.214 tagged_above=-999 required=5 tests=[AWL=1.384, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHJEGEpF7udk for ; Tue, 6 Sep 2011 14:26:19 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 35BC121F8EAD for ; Tue, 6 Sep 2011 14:26:18 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 4FCDF16FF; Tue, 6 Sep 2011 23:28:05 +0200 (CEST) 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; s=mx; bh=t4hK7cW7Fa9fg9+x4iztNHSBeig=; b=GvSWFCCLf Ml/AZuyGvn8BfZHe7lALm8Yqm3hO2vpol2gyZeP7pHf5RyBHRTK6ytR09KaR/ltp U6ZB44TBTdhLZha7ClISALp0gyjSL5SBLnUU473bG7i8wk1nhWGkIZ8q0I+1bU5k 3cE+9l/unSNs7dGUqKl5AnEND/0bZVw5f0= 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; q=dns; s=mx; b=JlLSCTltOPzy8xqiO53ZiIzsPSbCN+555hSlraK0mwtChNBl yfFW/CjTZ/cQIN7S11NrtseduIi9K0yy5jZNjgZi5FArTJgzaIN6ZNEaySf3O7gi Jg7eeo7jTg3RqEOyx9FEZ4Z/JMRmPA7QcdzbvVQ7NgeYLHkHOHvP8LT4U/0= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 4E3A57F6; Tue, 6 Sep 2011 23:28:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 30A04350800F; Tue, 6 Sep 2011 23:28:05 +0200 (CEST) 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 HM7LPkaTrtbj; Tue, 6 Sep 2011 23:28:04 +0200 (CEST) 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 E0A27350800D; Tue, 6 Sep 2011 23:28:03 +0200 (CEST) Message-ID: <4E669062.3060707@skype.net> Date: Tue, 06 Sep 2011 14:28:02 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> In-Reply-To: <4E668FB3.9020601@skype.net> Content-Type: multipart/alternative; boundary="------------090605060609020600060103" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 21:26:20 -0000 This is a multi-part message in MIME format. --------------090605060609020600060103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/6/11 2:25 PM, Matthew Kaufman wrote: > On 9/6/11 6:13 AM, Igor Faynberg wrote: >> I find this reasoning hard to understand. First, the SIP standard >> has been around for a decade. What new standardization is needed? > > The issue is whenever you wish to innovate and add functionality. To make this really simple, an analogy: What would Gmail be like if every web browser had a built-in IMAP client (== "a complete SIP implementation") *and* that was the only way you could display tables of email subject lines in the browser window (== "the only way to use the codec and RTP transport")? Matthew Kaufman --------------090605060609020600060103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/6/11 2:25 PM, Matthew Kaufman wrote:
On 9/6/11 6:13 AM, Igor Faynberg wrote:
I find this reasoning hard to understand.  First, the SIP standard has been around for a decade. What new standardization is needed?

The issue is whenever you wish to innovate and add functionality.

To make this really simple, an analogy:

What would Gmail be like if every web browser had a built-in IMAP client (== "a complete SIP implementation") *and* that was the only way you could display tables of email subject lines in the browser window (== "the only way to use the codec and RTP transport")?

Matthew Kaufman
--------------090605060609020600060103-- From randell-ietf@jesup.org Tue Sep 6 15:22: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 A1BD421F8EE1 for ; Tue, 6 Sep 2011 15:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdwRpKVb4ZZp for ; Tue, 6 Sep 2011 15:22: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 AB47E21F8EDF for ; Tue, 6 Sep 2011 15:22:46 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R144H-0000U6-Kt for rtcweb@ietf.org; Tue, 06 Sep 2011 17:24:33 -0500 Message-ID: <4E669CF6.3030708@jesup.org> Date: Tue, 06 Sep 2011 18:21:42 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E649FBD.1090001@alvestrand.no> In-Reply-To: <4E649FBD.1090001@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] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 22:22:47 -0000 On 9/5/2011 6:09 AM, Harald Alvestrand wrote: > There is a congestion control algorithm inside the Google WebRTC > codebase that hasn't been documented publicly before, and might be > interesting as input when we get around to discussing what congestion > control should be mandatory-to-implement in this group. Where is this in the webrtc drop? I looked but didn't see anything hooked up to RTPReceiverVideo::EstimateBandwidth(). There's something in this genre for iSAC, though I didn't have time to look closely but it appears to be somewhat specialized for iSAC. > > It's not forwarded as a candidate for what the result should be; I > think there can be better solutions (see the "further work" section in > this draft). Harald et al: this definitely answers my suggestion/request that we make congestion control mandatory, and that we target something similar to Radvision's NetSense, which this appears to have similar characteristics to. A few comments: In 3. (Receiver-side): When an over-use is detected the system transitions to the decrease state, where the available bandwidth estimate is decreased to a factor times the currently incoming bit rate. A_hat(i) = alpha*R_hat(i) alpha is typically chosen to be in the interval [0.8, 0.95]. May I suggest that there's more information available here than a single bit of "over-bandwidth". We have an estimate here how *much* we're over-bandwidth, though cross-traffic and other fixed streams (audio) are part of that too, so it needs to be used with a grain of salt - but that slope is useful information. In either case we want to measure the highest incoming rate during the under-use interval: R_max = max{R_hat(i)} for i in 1..K where K is the number of frames of under-use before returning to the normal state. R_max is a measure of the actual bandwidth available and is a good guess of what bit rate we should be able to transmit at. Therefore the available bandwidth will be set to Rmax when we transition from the hold state to the increase state. This is good, but it might make sense to explain why this is the case (as the draft does for other parts); I assume the argument is that if the delay is reducing after a bottleneck, then from the router that was buffering to us (usually just on the far end of the bottleneck) packets are flowing through from there as fast as they can. In fact, the rate they're getting through *while* you're over-bandwidth is actually the best estimate of total bandwidth you're likely to get. So in fact you can estimate it well in all cases except when you're in "increase" mode (buffers drained and stable), pretty much. I would also suggest that the rate to use is R_max * gamma (where gamma < 1.0) BTW, the description of directions here is confusing; the receiver is determining the apparent bandwidth the sender should be using; "we should be able to transmit at" is both wrong and confusing (probably should be "the sender should be able to transmit at"). Sender-side control: 10% seems rather high. My experience was more aggressive in the face of loss, both in the limit at which it reacts and the amount it reduces - over maybe 5% loss I would cut sender bandwidth by 10 or 15% on top of whatever the slope told me to do. Interop - the receiver could incorporate packet loss into the estimate used for TMMBR, which might improve talking to senders who don't follow this algorithm. We should consider how to handle cases that involve interop and if and how to detect them; the algorithm may want to be different for those cases. Future: We very much want to merge all the info we can from all the streams, so we can control where the bandwidth restrictions are applied instead of running it on N streams independently. (For example, if we're sending two video streams we may want to apportion the bandwidth according to their size/framerate instead of equally, and we'll very much want to consider for data channels (and perhaps media) a 'priority' factor ala RTFMP.) I'll have more comments, but I need to turn into a pumpkin now and wanted to get what I have on the wire. I haven't spent a lot of time fleshing them out or editing, so take them as a starting point for discussion. > > The code is available through www.webrtc.org, and the IPR statements > covering the code are found here: > https://sites.google.com/site/webrtc/license-rights > > Harald > > -------- Original Message -------- > Subject: New Version Notification for > draft-alvestrand-rtcweb-congestion-00.txt > Date: Mon, 05 Sep 2011 03:03:38 -0700 > From: internet-drafts@ietf.org > To: harald@alvestrand.no > CC: harald@alvestrand.no, holmer@google.com > > > > A new version of I-D, draft-alvestrand-rtcweb-congestion-00.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. > > Filename: draft-alvestrand-rtcweb-congestion > Revision: 00 > Title: A Google Congestion Control for Real-Time Communication on the World Wide Web > Creation date: 2011-09-05 > WG ID: Individual Submission > Number of pages: 14 > > Abstract: > This document describes two methods of congestion control when using > real-time communications on the World Wide Web (RTCWEB); one sender- > based and one receiver-based. > > It is published to aid the discussion on mandatory-to-implement flow > control for RTCWEB applications; initial discussion is expected in > the RTCWEB WG's mailing list. > > > -- Randell Jesup randell-ietf@jesup.org From pkyzivat@alum.mit.edu Tue Sep 6 16:14: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 312BB21F8E22 for ; Tue, 6 Sep 2011 16:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 j5TmiWDIy3+Q for ; Tue, 6 Sep 2011 16:14:24 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8AD21F8E1C for ; Tue, 6 Sep 2011 16:14:24 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta10.westchester.pa.mail.comcast.net with comcast id VbE01h0031swQuc5AbGCsc; Tue, 06 Sep 2011 23:16:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta15.westchester.pa.mail.comcast.net with comcast id VbGB1h01C0tdiYw3bbGB0Q; Tue, 06 Sep 2011 23:16:12 +0000 Message-ID: <4E66A9D9.30107@alum.mit.edu> Date: Tue, 06 Sep 2011 19:16:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 06 Sep 2011 23:14:25 -0000 The bridged line appearance case is an interesting one. It is definitely a feature that sip has trouble with. There are proprietary solutions for shared line appearance that use sip for call set up, along with other protocols. (Or at least *can* use sip, even if they usually use something else proprietary.) But they are proprietary, so that you have to buy the whole solution from one vendor, generally including all the phones. IIUC, with RTCWEB as Matthew is proposing it, you would be able to use anybody's phone that had a browser and supported RTCWEB. The limitation is that then all of the phones that want to be part of the shared line appearance group will need to share a server. IOW, you will need an RTCWEB capable web server representing the AOR. That could be a big hurdle for retrofitting existing sip-based phone systems, though perhaps an attractive approach for up and coming competitors to those existing systems. Thanks, Paul On 9/6/11 3:24 PM, Asveren, Tolga wrote: > What about semantics (adding just a X-header won't help there) or how much SIP would be left anyhow if all semantical control is exposed through the API? > > I think bridged line appearance is a good test to run against different models. > > Thanks, > Tolga > > > -----Original Message----- > From: rtcweb-bounces@ietf.org on behalf of Olle E. Johansson > Sent: Tue 9/6/2011 2:47 PM > To: Matthew Kaufman > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] > > > 6 sep 2011 kl. 20:40 skrev Matthew Kaufman: > >> On 9/6/11 11:36 AM, Ravindran Parthasarathi wrote: >>> Matthew, >>> >>> Even in case of SIP, there is no need of standardization in case it is within single webserver(skype). SIP supports x-header or proprietary header to extend the way you want it for providing innovative functionality. >> >> Not if SIP is baked in to the browser it doesn't. If the browser implements a SIP phone in native code, I have no way of adding "x-header" or anything else. I live with the functionality provided by the browser. > That's an implementation detail. One can easily add an API call to add headers on the outbound INVITE. > >> >> If on the other hand, you want SIP implemented in Javascript then sure, if a developer wants to use it, great. If they want to extend it, that's fine too. And if they'd rather use another model, they are free to do that. Just as you would expect from a *platform*. >> >>> There is no extension barrier from SIP perspective but it ensure that basic call works across web servers. For example, skype browser user will able to talk to gmail real-time user even though all skype functionality are not supported. >> See above. >>> >>> In case you have the points why HTTP allows innovation but SIP will not, let us discuss in detail. >> >> See above. I want you to be free to use SIP, but not *required* to use SIP. >> >> And there's some security reasons that I'd rather you tunnel it over HTTP rather than opening up your ability to send UDP packets to port 5060. > SIP runs on TCP and TLS ports too. > > I am not arguing for either side, just correcting some details... > > /O > > _______________________________________________ > 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 Sep 6 17:49: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 8E6C621F8D6F for ; Tue, 6 Sep 2011 17:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.288 X-Spam-Level: X-Spam-Status: No, score=-103.288 tagged_above=-999 required=5 tests=[AWL=-0.689, 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 j1GyiVYxHwmb for ; Tue, 6 Sep 2011 17:48:56 -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 5D8BA21F8D66 for ; Tue, 6 Sep 2011 17:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1433; q=dns/txt; s=iport; t=1315356644; x=1316566244; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=nPReBDpFHe1kzxa34tUPLJjkxQwO62jrKSb84K202PI=; b=MGzkQjoox5vLc97kZU0QaI5wmVUan9YwXCR9NqjeIGLKayz+mUzolblh pnsKUGPYqBQgXbIhcjyk8/CQIVKSihQedx8nZ7vrhL/I7GKXmghU2I2sa wQwQq0e+apeuUD/CGWdr62KG+j7LO04MMO+T9LJW/rrtBjw59lp/K7yfP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACC/Zk6rRDoI/2dsb2JhbABDqAp4gUYBAQEBAgESASc/EAsOOFcGNYdRmSYBn1WGCmAEh2uLQ4UPjB0 X-IronPort-AV: E=Sophos;i="4.68,342,1312156800"; d="scan'208";a="554375" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 07 Sep 2011 00:50:44 +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 p870ogH9020716; Wed, 7 Sep 2011 00:50:43 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Tue, 6 Sep 2011 18:50:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Colin Perkins X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 00:49:00 -0000 On Sep 6, 2011, at 9:12 AM, Colin Perkins wrote: >> 3) When a new codec is specified, and the SPD for the new codec is = specified in the MMUSIC WG, no other standardization would should be = required for it to be possible to use that in the web browsers. Adding a = new codecs which might have new SDP parameters should not change the = APIs between the browser and javascript application. As soon as the = browsers support the new codec, old applications written before the = codecs was specified should automatically be able to use the new codec = where appropriate with no changes to the JS applications.=20 >=20 > To be clear on this last point: when RTP payload formats are defined = for new codecs, they define a MIME media type and its parameters, and = then a mapping of those onto SDP syntax in a standard way. If it was = desirable, we could define a mapping from MIME media type names and = parameters onto some non-SDP syntax without losing the investment in RTP = payload formats and parameters for signalling.=20 >=20 > And, given that other parts of the browser rely on media types, we = should be clear that codec names/parameters are drawn from the same = namespace. >=20 > Colin Just sloppy on my part - what I was trying to get at was that whatever = happens, it is basically algorithmic to map it into the API specs we and = we don't have to write any new specs for the JS API.=20 From fluffy@cisco.com Tue Sep 6 17:58: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 2E0FE21F8DAF for ; Tue, 6 Sep 2011 17:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.281 X-Spam-Level: X-Spam-Status: No, score=-103.281 tagged_above=-999 required=5 tests=[AWL=-0.682, 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 b1o4IgdsGtTq for ; Tue, 6 Sep 2011 17:58:00 -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 45CC021F8DA8 for ; Tue, 6 Sep 2011 17:57:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1383; q=dns/txt; s=iport; t=1315357187; x=1316566787; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=VaxMqGRr4kO44aJ7vQq7S9ggfPoAf4OtZ2JZz+qNFfY=; b=OEQC43574qsJKvpxKA298OhfDkm8gF47aul2+MXLep6kkAQvT0tX+vuP xUBnJUJaKfiWZbCUaIPVgzvGrvmEk/v5apt9WvW3FX9rtzkMrJHamSvpG oDCcGyXlb7NvW1Zzgd2skwKDJJFHMV8so0VSWlsYeFoEM2y4P1WDpRh9k A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHjBZk6rRDoI/2dsb2JhbABDqAp4gUYBAQEBAxIBJz8QCw44VwY1oG4Bn1SGCmAEh2uLQ4UPjB0 X-IronPort-AV: E=Sophos;i="4.68,342,1312156800"; d="scan'208";a="554935" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 07 Sep 2011 00:59:46 +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 p870xkUL027922; Wed, 7 Sep 2011 00:59:46 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E6640FC.8080108@jitsi.org> Date: Tue, 6 Sep 2011 18:59:45 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4B62E0EE-DA11-49A0-AB59-3AB1C6DF2B1C@cisco.com> References: <4E6640FC.8080108@jitsi.org> To: Emil Ivov X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 00:58:01 -0000 On Sep 6, 2011, at 9:49 AM, Emil Ivov wrote: >>=20 >>=20 >> 1) The media negotiations will be done using the same SDP >> offer/answer semantics that are used in SIP. >=20 > Does this cover media format negotiation only or does it also cover > transport negotiation? I believe you once mentioned you were a fan of > "sending ICE candidates as they become available" and for that to = happen > we'd probably need something more XMPP-like than SIP/SDP-like. The SDP offer / answer cover both and in fact mix them together in a way = that is a bit hard to untangle, so yes, what I am proposing here is = that it would cover both.=20 In general, I am a fan of the separating the setup of the ICE transport = channels from the negotiation of what goes over them but I think we are = just too late at this point to really get into doing that and I don't = see much support for it. The hard part of this is how to design a = signaling GW that does not require a media GW but can map between this = and SIP. Thought we might be able to do this, and I think it would be = architecturally cleaner, it's a lot more complicated to done. I don't = see the work happening to make something like this happen in a time span = where it will be relevant. I think people are just looking for something = much closer to existing implementations in Chrome and Firefox.=20 From fluffy@cisco.com Tue Sep 6 18:43: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 A704121F8DFA for ; Tue, 6 Sep 2011 18:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.274 X-Spam-Level: X-Spam-Status: No, score=-103.274 tagged_above=-999 required=5 tests=[AWL=-0.675, 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 tzV513lXdN48 for ; Tue, 6 Sep 2011 18:43:38 -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 97ACF21F8D4E for ; Tue, 6 Sep 2011 18:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=10648; q=dns/txt; s=iport; t=1315359927; x=1316569527; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Ov8RP0e7LsNw2JEjKBV/FYYjyOWrdILa3hU90qF6u44=; b=jXKWt6Atx1TndDs6f/ntUUb4GikRlfKrYwiiHkfhCH4TuckVtP2F1PKZ eP1YsFi0LKd7PSt24IE6HUqjMT3RkG45lG7XUMVu9FBXUL+4IswNhm4+S p/RSq5b3nsLrwbSW/qR+lk8XFGnAzYde3N1SkwqJfVBypJZz6DSi0XHN0 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADjMZk6rRDoH/2dsb2JhbABDqAp4gUYBAQEBAgESASc/BQsLGC5XBi4Hh1GYfQGfVIYKYASHa4tDhQ+MHQ X-IronPort-AV: E=Sophos;i="4.68,342,1312156800"; d="scan'208";a="561255" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 07 Sep 2011 01:45: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 p871jPZs007162; Wed, 7 Sep 2011 01:45:26 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E663A35.7000507@skype.net> Date: Tue, 6 Sep 2011 19:45:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2E243EBA-3A4C-420F-A1CF-B62374FFEF66@cisco.com> References: <4E663A35.7000507@skype.net> To: Matthew Kaufman X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 01:43:39 -0000 sorry this is becoming too deep inline but, uh, inline ... On Sep 6, 2011, at 9:20 AM, Matthew Kaufman wrote: > On 9/6/2011 7:46 AM, Cullen Jennings wrote: >> In my roll as an individual contributor, I want to propose some text = that I think we can get rough consensus on around that helps specify = which parts of the signaling issues we agree on and which we don't. >>=20 >> At the last meeting, my read of the the room was there was a fair = amount of agreement in the room that offer / answer semantics with SDP = are what we want to use. I don't think there was was broad agreement on = if one should use SIP or not, or for that matter jingle. If we can nail = down this decisions as the direction the WG is going, it will really = help make progress. What I would like to do is propose some following = principles in the text below. If we have agreement on these, then they = would go into the overview document and help guide the design of other = documents. I want to highlight that none of the principles below imply = that we would need to use SIP in the browsers - the principals would all = work fine if we there was signaling gateway in the web server that = converged SIP to whatever proprietary HTML / JS / HTTP that the = applications wanted to use between the browser and the web server. >>=20 >>=20 >>=20 >> 1) The media negotiations will be done using the same SDP = offer/answer semantics that are used in SIP. >=20 > I think this would be unfortunate. We have an opportunity here to not = repeat this mistake. >=20 > And *if* we go down this road, we need additional language around = things like exposing the capabilities via an API that doesn't start the = offer/answer process itself. (Use case: determine if a browser has an = appropriate camera and encoder before suggesting that they call the = customer service rep for a live chat.) So obviously I agree with that use case but two points here 1) I'm not = excluding other API being needed for extra information that is = efficiently local. I was only talking about the actual media negotiation = so even if we do media negotiation with SDP, one could still have = separate API for all kinds of things including mute my microphone that = did not use SDP. 2) I think the one way to get capabilities in JS is to = ask for an SDP offer, and as soon as you get it cancel the transaction = and not cary on. That way you get the capabilities and then stop.=20 >=20 >=20 >>=20 >> 2) It will be possible to gateway between legacy SIP devices that = support ICE and appropriate RTP / SDP mechanisms and codecs without = using a media gateway. A signaling gateway to convert between the = signaling on the web side to the SIP signaling may be needed. >=20 > Agree. >=20 >>=20 >> 3) When a new codec is specified, and the SPD for the new codec is = specified in the MMUSIC WG, no other standardization would should be = required for it to be possible to use that in the web browsers. >=20 > I would be ok with reusing the SDP parameter string as specified as a = parameter to the API, but I don't think it should be a blob of SDP that = combines both the codec parameters *and* the connection/ICE parameters, = *and* I think that offer/answer is the wrong model. Not sure what you mean by SDP parameter string. If you mean just the = parameters for the given codec, then i view that as about 1% of SDP and = would not describe that as using SDP at all. For example, if you wanted = to negotiate FEC, that would not cover it.=20 >=20 > However, see below... >=20 >> Adding a new codecs which might have new SDP parameters should not = change the APIs between the browser and javascript application. As soon = as the browsers support the new codec, old applications written before = the codecs was specified should automatically be able to use the new = codec where appropriate with no changes to the JS applications. >=20 > This is a good idea. But then where do all the parameters that = *weren't* specified in the MMUSIC WG go? (Like "force Opus codec to = music mode", or "change your motion estimation algorithm") Note that my writing of above was just wrong as Colin pointed out but to = your point ... I think this type of stuff goes in other hints in the API = that try and tell the browser what the application is trying to achieve. = So I think it is fine for JS to tell the browser assume the audio is = spoken voice, or music but I was not viewing this as something that was = happening as part of the media negotiation because there is no need to = communicate from one browser to the other browser. It is local not = something negotiated over the signaling protocol.=20 >=20 >>=20 >>=20 >> People has looked at alternatives to all these in a fair amount of = detail. For example, we have considered alternatives to the SDP offer / = answer such as the advertisement proposal draft = (draft-peterson-sipcore-advprop-01) and discussed that several times in = the WG. >=20 > This is mixing up the API and the wire protocol. If people want to use = SDP offer/answer between the browser and the web server, that's fine, = but that doesn't mean we need to bake SDP offer/answer into the = Javascript API. (And it certainly doesn't mean we need to mix up the = layers, with connection properties in the SDP *and* encoder properties = in the same SDP... done properly, these would go to/from different = Javascript objects anyway.) I'm far less concerned about the syntax but I am discussing is the = semantics of what we need to be able to represent in the various = information flows. What I think when you think about this this way, I'm = not mixing them up much. If the JS API supported a superset of all the = semantics information flow of off/ans and adv/prop, then yes you can do = both. If it does not, then you can't. But an equally important flow is = what happens on the signaling GW. We have seen from the SIP SBC = experience that you can't ignore this and wish it away. We need to be = sure what will map, and what won't map or we don't really know we have a = solution.=20 >=20 > Likewise, advprop should be able to be supported as well... with a = different set of Javascript talking to the same APIs. >=20 >> The primary issues identified with this was concerns over mapping = this to legacy SDP. >=20 > This makes the assumption that the primary use case will have things = that speak only SDP offer/answer on the far side. I think that's a very = IETF + SIP + legacy point of view, which is an unfortunate way to = approach the future of communications as enabled by web applications. I'm not assuming anything about this being the primary use case. I'm = assuming it is an important use case. If it were not, we would do this = totally differently probably starting with not using RTP, certainly not = using SDP or offer/answer, and I'd argue for a p2p (in the overlay = network sense of the term) form rendezvous - there would be people on = the list point out if we use used HIP, everything would be done. We are = not doing that because it is an import use case. The reason it is = important is because that is the way we connect this to the existing = voice and video communication infrastructure that currently supports = well over 4 billion users and probably over 5 billion. We already have a = boat load of solutions to this problem if we don't care about legacy. = That Flash stuff seems to be in lots of browsers and work fine to other = browsers - but I want more than that. For the same reason IPV6 device = that can't connect to anything V4 are much less interesting than devices = that can connect to both, I want interoperability with the past (meaning = all the existing deployments) and path for an interesting future. Either = one by itself is not enough.=20 >=20 > I think that as long as the browser *or* the server *can* map it to = SDP offer/answer when needed, that is sufficient. Ignoring my rant in previous paragraph - I view as necessary that it be = mappable, and it needs to be clear how and what parts of it are mapped. = I think we are on the same page that the signaling GW should not need to = be a media GW. I'm not real wrapped up about how the signaling GW is = split between the browser, web server, or even some third network = element.=20 >=20 >> Similarly people have considered a replacement for SDP in the SDPng = work which was eventually abandoned due to the difficulty of having a = incentive for implementations to migrate from SDP to SDPng. >=20 > Obviously can't use something that was abandoned. >=20 >>=20 >> We have also considered just sending audio and video directly over = something like DTLS and not suing RTP. >=20 > That would break point 2 above. >=20 >> The WG has clearly rejected this due to a variety of reasons - the = desire not to to have the operating expense of media gateway and = reduction in quality of experience is obviously a high priority goal for = the designs of the RTP multiplexing draft. >=20 > Agree. >=20 >>=20 >> The JS API is being developed by W3C but when proposing APIs that = should violate the third principal, such as the the API in section 4 of = draft-jennings-rtcweb-api-00, it is clear that many people that are more = from the browser and web application world do not want such an API. >=20 > Too many negatives for me to parse. Let me try to restate with less negatives.=20 I acknowledge the JS API is being developed by the W3C and not the the = IETF. So I want to be careful and not imply that this IETF WG is the = right WG to make decisions about the API. Given the apologies in = advance, I am going to go and discuss the W3C API in this WG.=20 Section 4 of draft-jennings-rtcweb-api-00 did propose an API that is = along the lines of what you has been arguing for. It is adv/prop type = API. Now I suspect that you would refractor this API to have pass JSON = object instead of having a bunch of parameters to the function calls but = it would still roughly be the type of API I think you are talking about. = I may be completely confused on the type of API you are proposing but = we can sort that out. In many ways, this API is modeled after some of = the design of MGCP.=20 The important thing is that most the web application developers and = browser developers I have talked to are not keen on this type of API. = They much prefer the API in the current W3C draft.=20 >=20 > Matthew Kaufman >=20 >=20 From oej@edvina.net Wed Sep 7 00:06: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 C85B911E8073 for ; Wed, 7 Sep 2011 00:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 iBCjn0sCRTuk for ; Wed, 7 Sep 2011 00:06:03 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id DDAE521F8C0D for ; Wed, 7 Sep 2011 00:06:02 -0700 (PDT) Received: from [192.168.40.76] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id D8486754BCE4; Wed, 7 Sep 2011 07:07:40 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> Date: Wed, 7 Sep 2011 09:07:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> To: "Asveren, Tolga" X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 07:06:03 -0000 6 sep 2011 kl. 21:24 skrev Asveren, Tolga: > What about semantics (adding just a X-header won't help there) or how = much SIP would be left anyhow if all semantical control is exposed = through the API? >=20 > I think bridged line appearance is a good test to run against = different models. >=20 Well, I tried to stay neutral but examples likes this makes me not want = SIP in the browser. DTMF, Early Media, bridge line apperances and other = PSTN legacy will make the implementation too focused on classical = telephony and we'll spend too much time implementing features that are = application specific and we can implement in controlling applications, = client or server-side.=20 Cullen tried to make a draft with "limited" SIP (maybe "SIP Lite") but = it will be hard to protect that from the myriad of extensions that add = PSTN functionality that's not really needed to set up multimedia calls = between two browser users. It may be needed for gatewaying to legacy = systems, but if we don't "stop Olle in the gate" - verbatim translation = of a Swedish saying that propably doesn't mean much to most people on = the list - I think we will never be done. Of course, being a SIP developer, I started off with thinking that SIP = in the browser was the default route. I am beginning to understand that = the browser is the user interface part we all need, the media handler. = We all have different requirements on how to control that media GUI and = to get anywhere I am beginning to think the logic for signalling to set = up rendevouz points and manage sessions has to move "somewhere else" = where we can implement SIP, XMPP or some other protocol that fulfills = the need of our respective application. To fearlessly jump into another can of worms, I still think we should = have confidentiality - SRTP - by default. We know that these = applications will run on a myriad of devices on a myriad of networks and = it will not work to let users have to decided whether or not they want = confidentiality. If Skype did not have confidentiality by default, there = would be articles every summer and xmas in the evening taboloids about = how easy it is to listen in to your neighbours calls and that would have = hurted Skype badly.=20 /O > Thanks, > Tolga >=20 >=20 > -----Original Message----- > From: rtcweb-bounces@ietf.org on behalf of Olle E. Johansson > Sent: Tue 9/6/2011 2:47 PM > To: Matthew Kaufman > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remoterecording - RTC-Web client acting as SIPREC session = recordingclient] >=20 >=20 > 6 sep 2011 kl. 20:40 skrev Matthew Kaufman: >=20 >> On 9/6/11 11:36 AM, Ravindran Parthasarathi wrote: >>> Matthew, >>>=20 >>> Even in case of SIP, there is no need of standardization in case it = is within single webserver(skype). SIP supports x-header or proprietary = header to extend the way you want it for providing innovative = functionality. >>=20 >> Not if SIP is baked in to the browser it doesn't. If the browser = implements a SIP phone in native code, I have no way of adding = "x-header" or anything else. I live with the functionality provided by = the browser. > That's an implementation detail. One can easily add an API call to add = headers on the outbound INVITE. >=20 >>=20 >> If on the other hand, you want SIP implemented in Javascript then = sure, if a developer wants to use it, great. If they want to extend it, = that's fine too. And if they'd rather use another model, they are free = to do that. Just as you would expect from a *platform*. >>=20 >>> There is no extension barrier from SIP perspective but it ensure = that basic call works across web servers. For example, skype browser = user will able to talk to gmail real-time user even though all skype = functionality are not supported. >> See above. >>>=20 >>> In case you have the points why HTTP allows innovation but SIP will = not, let us discuss in detail. >>=20 >> See above. I want you to be free to use SIP, but not *required* to = use SIP. >>=20 >> And there's some security reasons that I'd rather you tunnel it over = HTTP rather than opening up your ability to send UDP packets to port = 5060. > SIP runs on TCP and TLS ports too. >=20 > I am not arguing for either side, just correcting some details... >=20 > /O >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From harald@alvestrand.no Wed Sep 7 02:01: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 19B4A21F8781 for ; Wed, 7 Sep 2011 02:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.405 X-Spam-Level: X-Spam-Status: No, score=-107.405 tagged_above=-999 required=5 tests=[AWL=3.193, 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 Vm6Na4FpcH+L for ; Wed, 7 Sep 2011 02:01:17 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 14C0021F8782 for ; Wed, 7 Sep 2011 02:01:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4C7DB39E112 for ; Wed, 7 Sep 2011 11:03:05 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrGQMvSv1E9M for ; Wed, 7 Sep 2011 11:03:04 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id A46A239E072 for ; Wed, 7 Sep 2011 11:03:04 +0200 (CEST) Message-ID: <4E673348.2020408@alvestrand.no> Date: Wed, 07 Sep 2011 11:03:04 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E649FBD.1090001@alvestrand.no> In-Reply-To: <4E649FBD.1090001@alvestrand.no> Content-Type: multipart/alternative; boundary="------------070905060907050509000308" Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-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: Wed, 07 Sep 2011 09:01:18 -0000 This is a multi-part message in MIME format. --------------070905060907050509000308 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 09/05/11 12:09, Harald Alvestrand wrote: > There is a congestion control algorithm inside the Google WebRTC > codebase that hasn't been documented publicly before, and might be > interesting as input when we get around to discussing what congestion > control should be mandatory-to-implement in this group. > > It's not forwarded as a candidate for what the result should be; I > think there can be better solutions (see the "further work" section in > this draft). > > The code is available through www.webrtc.org, and the IPR statements > covering the code are found here: > https://sites.google.com/site/webrtc/license-rights Slightly offtopic, but I got a question about where the code is found in the repository ... here are the most important links: http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/bandwidth_management.h http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/bandwidth_management.cc http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/overuse_detector.h http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/overuse_detector.cc http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/remote_rate_control.h http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/remote_rate_control.cc http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/Bitrate.h http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/bitrate.cc Enjoy! --------------070905060907050509000308 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 09/05/11 12:09, Harald Alvestrand wrote:
There is a congestion control algorithm inside the Google WebRTC codebase that hasn't been documented publicly before, and might be interesting as input when we get around to discussing what congestion control should be mandatory-to-implement in this group.

It's not forwarded as a candidate for what the result should be; I think there can be better solutions (see the "further work" section in this draft).

The code is available through www.webrtc.org,  and the IPR statements covering the code are found here: https://sites.google.com/site/webrtc/license-rights
Slightly offtopic, but I got a question about where the code is found in the repository ... here are the most important links:

http://code.google.com/p/webrtc/source/browse/trunk/src/modules/rtp_rtcp/source/bandwidth_management.cc
Enjoy!

--------------070905060907050509000308-- From harald@alvestrand.no Wed Sep 7 04:09: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 16EBE21F8B15 for ; Wed, 7 Sep 2011 04:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.487 X-Spam-Level: X-Spam-Status: No, score=-107.487 tagged_above=-999 required=5 tests=[AWL=3.112, 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 goSTF3CHuNsD for ; Wed, 7 Sep 2011 04:09:06 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 75FE321F8AF8 for ; Wed, 7 Sep 2011 04:09:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1B22B39E112; Wed, 7 Sep 2011 13:10:53 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkD-yNfjcPpc; Wed, 7 Sep 2011 13:10:52 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id AA2F839E072; Wed, 7 Sep 2011 13:10:52 +0200 (CEST) Message-ID: <4E67513C.3030600@alvestrand.no> Date: Wed, 07 Sep 2011 13:10:52 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Matthew Kaufman References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> <4E666785.7040409@skype.net> In-Reply-To: <4E666785.7040409@skype.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 11:09:07 -0000 On 09/06/11 20:33, Matthew Kaufman wrote: > Because SIP requires standards activities before adding any useful > functionality. I'll point to one of my favorites here: bridged line > appearances. Despite lots of effort to fix this, there still isn't a > way to do this reliably. And yet, if I created a web application using > HTTP signaling and Javascript APIs on a web browser that provides a > *platform* and not just a "phone", I could create a system in which > bridged line appearances work well if I so desired with just a little > bit of programming. Since more people than I may be confused, I'm forking a subthread... what is a bridged line appearance, and why is it hard to do in SIP? My terminology cache is totally blank. From harald@alvestrand.no Wed Sep 7 04:32: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 3F40921F8B8C for ; Wed, 7 Sep 2011 04:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.565 X-Spam-Level: X-Spam-Status: No, score=-107.565 tagged_above=-999 required=5 tests=[AWL=3.034, 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 u+0rybL8HbDa for ; Wed, 7 Sep 2011 04:32:37 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 646D721F8B84 for ; Wed, 7 Sep 2011 04:32:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 284D739E112; Wed, 7 Sep 2011 13:34:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQ+lr-+uzTbv; Wed, 7 Sep 2011 13:34:25 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 9A41E39E072; Wed, 7 Sep 2011 13:34:25 +0200 (CEST) Message-ID: <4E6756C1.9060207@alvestrand.no> Date: Wed, 07 Sep 2011 13:34:25 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 11:32:38 -0000 Getting everyone confused by not doing a deep inline answer, but=20 replying to the first message on the thread...... On 09/06/11 16:46, Cullen Jennings wrote: > In my roll as an individual contributor, I want to propose some text th= at I think we can get rough consensus on around that helps specify which = parts of the signaling issues we agree on and which we don't. > > At the last meeting, my read of the the room was there was a fair amoun= t of agreement in the room that offer / answer semantics with SDP are wh= at we want to use. I don't think there was was broad agreement on if one = should use SIP or not, or for that matter jingle. If we can nail down thi= s decisions as the direction the WG is going, it will really help make pr= ogress. What I would like to do is propose some following principles in t= he text below. If we have agreement on these, then they would go into the= overview document and help guide the design of other documents. I want t= o highlight that none of the principles below imply that we would need to= use SIP in the browsers - the principals would all work fine if we there= was signaling gateway in the web server that converged SIP to whatever p= roprietary HTML / JS / HTTP that the applications wanted to use between = the browser and the web server. > > > > 1) The media negotiations will be done using the same SDP offer/answer = semantics that are used in SIP. To be precise - you're suggesting that we use RFC 3264 offer/answer=20 semantics. (That RFC is 25 pages long. RFC 3261, the core SIP document,=20 is 269 pages, and is NOT a normative reference from 3264. I am anxious=20 to avoid having a normative dependency on 3261.) I agree with this. > 2) It will be possible to gateway between legacy SIP devices that suppo= rt ICE and appropriate RTP / SDP mechanisms and codecs without using a me= dia gateway. A signaling gateway to convert between the signaling on the = web side to the SIP signaling may be needed. I agree with this - I think the "may be needed" will turn out to be=20 "will be needed", but some portion of that gateway can be implemented by = Javascript running in the browser, if desirable. > 3) When a new codec is specified, and the SPD for the new codec is spec= ified in the MMUSIC WG, no other standardization would should be required= for it to be possible to use that in the web browsers. Adding a new code= cs which might have new SDP parameters should not change the APIs between= the browser and javascript application. As soon as the browsers support = the new codec, old applications written before the codecs was specified s= hould automatically be able to use the new codec where appropriate with n= o changes to the JS applications. I agree with this (modulo spelling and WG name fixups). I decided that the fight against SDP was not worth fighting after=20 listening to the dozens of WGs doing SDP extensions for various=20 purposes, many of which might make sense to incorporate in a browser=20 platform, and concluding that SDP wouldn't hold still enough for us to=20 specify a gateway from/to it. Harald From emil@sip-communicator.org Wed Sep 7 05:00: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 E618E21F8C1E for ; Wed, 7 Sep 2011 05:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n84-Esisjy39 for ; Wed, 7 Sep 2011 05:00:23 -0700 (PDT) Received: from mail-ey0-f174.google.com (mail-ey0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2A24B21F8C17 for ; Wed, 7 Sep 2011 05:00:22 -0700 (PDT) Received: by eyx24 with SMTP id 24so4894004eyx.19 for ; Wed, 07 Sep 2011 05:02:11 -0700 (PDT) Received: by 10.213.9.70 with SMTP id k6mr2573449ebk.146.1315396931589; Wed, 07 Sep 2011 05:02:11 -0700 (PDT) Received: from camionet.local ([78.90.181.123]) by mx.google.com with ESMTPS id d59sm215769eea.3.2011.09.07.05.02.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Sep 2011 05:02:10 -0700 (PDT) Message-ID: <4E675D40.4020702@jitsi.org> Date: Wed, 07 Sep 2011 15:02:08 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; bg; rv:1.9.2.21) Gecko/20110830 Thunderbird/3.1.13 MIME-Version: 1.0 To: Cullen Jennings References: <4E6640FC.8080108@jitsi.org> <4B62E0EE-DA11-49A0-AB59-3AB1C6DF2B1C@cisco.com> In-Reply-To: <4B62E0EE-DA11-49A0-AB59-3AB1C6DF2B1C@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 12:00:24 -0000 =D0=9D=D0=B0 07.09.11 03:59, Cullen Jennings =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > On Sep 6, 2011, at 9:49 AM, Emil Ivov wrote: >>> 1) The media negotiations will be done using the same SDP=20 >>> offer/answer semantics that are used in SIP. >>=20 >> Does this cover media format negotiation only or does it also >> cover transport negotiation? I believe you once mentioned you were >> a fan of "sending ICE candidates as they become available" and for >> that to happen we'd probably need something more XMPP-like than >> SIP/SDP-like. >=20 > The SDP offer / answer cover both and in fact mix them together=20 Yup, hence my question. > in a way that is a bit hard to untangle, I suppose I was (again) thinking about something along the lines of Jingle where the separation is quite straightforward spec-wise. I do however understand your point about how this would make it complicated to have singnaling-only gateways with SIP ... and I do agree that this is important, so point taken. Thanks for explaining! Emil > so yes, what I am proposing here > is that it would cover both. >=20 > In general, I am a fan of the separating the setup of the ICE > transport channels from the negotiation of what goes over them but I > think we are just too late at this point to really get into doing > that and I don't see much support for it. The hard part of this is > how to design a signaling GW that does not require a media GW but can > map between this and SIP. Thought we might be able to do this, and I > think it would be architecturally cleaner, it's a lot more > complicated to done. I don't see the work happening to make something > like this happen in a time span where it will be relevant. I think > people are just looking for something much closer to existing > implementations in Chrome and Firefox. >=20 >=20 >=20 --=20 http://jitsi.org From matthew.kaufman@skype.net Wed Sep 7 07:15: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 ACDCD21F8B72 for ; Wed, 7 Sep 2011 07:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, 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 X5-NcFdRdWKU for ; Wed, 7 Sep 2011 07:15:20 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3AF21F8B4D for ; Wed, 7 Sep 2011 07:15:20 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 219D716F6; Wed, 7 Sep 2011 16:17:08 +0200 (CEST) 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=IjHOLHHKF4ZXOH aNbMiWmWUjSq4=; b=XmZjy69qetljvfX87ECzQynYpmo6lN1c/PQrbzqUey7ZiR 4fS4ClEQAUnUlsN1uWzH1OYG69mGKxKV6bgJByUj7hQALY9v9AAzYm9J4sO8p3MQ 5lr7rrqGcy5uTn1NBuciF+Gdubk1F5k50v1AvnTPQvm4dnipdrSV+0/1uypaM= 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=jVSz5zGunRmJdCUVry0rsl FaSU03nglNtccyvD4kMACKi8AR/fpGYzY9M+m3pGBjD8Mfue+BudleCIWnMJU2vs ye038ttDe2+RtvxfYuLPo6bOP/6HuQ7Y2kU1namrafDbWKpssG79sgEufSAj1bLq RkIDzMkfv3V7T/ci5590U= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 16D05CF; Wed, 7 Sep 2011 16:17:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id B188135080A4; Wed, 7 Sep 2011 16:17:07 +0200 (CEST) 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 iPRY2EFpvi9a; Wed, 7 Sep 2011 16:17:06 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id B2617350809D; Wed, 7 Sep 2011 16:17:05 +0200 (CEST) Message-ID: <4E677CB8.40203@skype.net> Date: Wed, 07 Sep 2011 07:16:24 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Harald Alvestrand References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> <4E666785.7040409@skype.net> <4E67513C.3030600@alvestrand.no> In-Reply-To: <4E67513C.3030600@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 14:15:21 -0000 On 9/7/2011 4:10 AM, Harald Alvestrand wrote: > > Since more people than I may be confused, I'm forking a subthread... > > what is a bridged line appearance, and why is it hard to do in SIP? > > My terminology cache is totally blank. > Key system (and home phone) emulation requires two things that are hard to do (because there's no final specification, not because it is impossible) (and because there's 3+ alternatives, and almost no phones implement more than one of them) in SIP: 1. Shared line appearance This is where you can be on a call on one handset, see that the line is in use at the other handset. Place the call on hold at the first, pick it up at the second. In business PBX cases, this is used for executive/assistant cases. In key system emulation it is used for "Bob, pick up the call holding on line 3". And for home phones it is the usual "put the phone on hold in the kitchen, pick it up in the den." (My wife wanted this functionality, so I had to add proprietary support for shared line appearance on my home PBX.) 2. Bridged line appearance This is where you can be on a call on one handset, see that line is in use at the other handset, and pick up the second handset to join the call. In the business PBX and key system case this is sometimes used for supervisors to join a call to help, but the real common case is the home phones... "kids, go pick up the extension in the living room and talk to grandma." With POTS, this works by simply paralleling two handsets on the same copper pair. For SIP it requires everything shared line appearance does *plus* automatic barge-in + conference on pickup. The BLISS WG has been working, for a long time, on taking the various interim proposals and creating a standard out of them, but we're still not there... and yet without it, there's no way to use phones from two different vendors to accomplish this. Whereas with WebRTC implemented *without SIP*, it is fairly easy to build a web app that runs on multiple browsers from multiple vendors and implements this. So this type of ability to innovate and implement applications without going through the standards process is why we *definitely* don't want SIP baked in to the browser. Not to be confused with the arguments against SDP offer/answer, which is only slightly affected by the above use cases (in that you can do smarter things at the bridge for bridged line appearance if you aren't doing a reinvite/re-offer/re-answer but instead have on hand all the capabilities of the first device when the second goes to join). Matthew Kaufman From matthew.kaufman@skype.net Wed Sep 7 07:17: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 8602621F8C5D for ; Wed, 7 Sep 2011 07:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.17 X-Spam-Level: X-Spam-Status: No, score=-5.17 tagged_above=-999 required=5 tests=[AWL=1.429, 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 NytmwZGhSbki for ; Wed, 7 Sep 2011 07:17:49 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id F3F7021F8BE5 for ; Wed, 7 Sep 2011 07:17:48 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 15C6416F6; Wed, 7 Sep 2011 16:19:38 +0200 (CEST) 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=A5AfQ0AjmdiaR/ L9M2JlnHSSiBE=; b=t+5wvvJvfJbKEAlsV3sK7F7o5Q5uxUZCPbOlWx/bBvbmc1 4qc/TAEUhhqeztRHitRC8EgF39i9mFBYPIo5w6wvWl4iVB6ax3x+LGyqlNal2NMP Dk/rVuoKVXO2hr53W5iUU8nIb01eeD8/Hr/jEcVguHqhOARpaxqFTt7tvQytI= 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=MSWmWdtX8ifEC9L7NblEs6 doeojE7D0W28kVebEJ7wBldqNcCkK1OM4AwzCrv+5401A8+tWLsjI1bxnX6bHRGJ TEkqOnVtzhdfCbgzpOEd9BBJv6HuIr3uCiLrv6XaaU3OZ4f9fqsoVepx9OaKExIp qjNZiRr35tzsnB3g4abfU= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 145B0CF; Wed, 7 Sep 2011 16:19:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id D86EB35080CD; Wed, 7 Sep 2011 16:19:37 +0200 (CEST) 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 kBhnCQM2+Krg; Wed, 7 Sep 2011 16:19:37 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id D13AD35080CC; Wed, 7 Sep 2011 16:19:36 +0200 (CEST) Message-ID: <4E677D4F.8050105@skype.net> Date: Wed, 07 Sep 2011 07:18:55 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Harald Alvestrand References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> <4E666785.7040409@skype.net> <4E67513C.3030600@alvestrand.no> <4E677CB8.40203@skype.net> In-Reply-To: <4E677CB8.40203@skype.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 14:17:49 -0000 On 9/7/2011 7:16 AM, Matthew Kaufman wrote: > > Whereas with WebRTC implemented *without SIP*, it is fairly easy to > build a web app that runs on multiple browsers from multiple vendors > and implements this. > > So this type of ability to innovate and implement applications without > going through the standards process is why we *definitely* don't want > SIP baked in to the browser. And note that this is directly parallel to the "innovate like Gmail" discussion. It is trivial for Gmail to change the look and feel and behavior of the "delete" button to implement an email paradigm of "keep everything, search to find it" (and have it work the same way no matter who the browser vendor is)... but this wouldn't have been the case if Gmail were forced to use the browser's built-in IMAP implementation. Matthew Kaufman From fluffy@cisco.com Wed Sep 7 07:57: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 16B6D21F8B55 for ; Wed, 7 Sep 2011 07:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.267 X-Spam-Level: X-Spam-Status: No, score=-103.267 tagged_above=-999 required=5 tests=[AWL=-0.668, 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 2LPbxbSW2I1B for ; Wed, 7 Sep 2011 07:57:42 -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 DE27721F8B52 for ; Wed, 7 Sep 2011 07:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3013; q=dns/txt; s=iport; t=1315407572; x=1316617172; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=E/6VJHHZBuQFKVUKUSP8aTHqrZETxH3IppfBPjLi8cw=; b=XDsiR0PEWHasDIl1Vtq+GXfXOcFjRajjYM6nK7oaeZVZUyvrRX6CMra5 S+1FtHueVUUN1ugg4Tw0dpRJ0zqcer3kNZUVtWnetJwkGwsh3r1LTgfCg 8xkWzmVuRMTDdYgCz86MT0x7xHVYQvzbrWWVzjYxnV7cw+D2OzDJQYRN7 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIKGZ06rRDoJ/2dsb2JhbABDp214gUYBAQEBAgESAScuEQULCxIGIwtJDgY1h1OYbgGeS4YLYASHbItGhRKMIg X-IronPort-AV: E=Sophos;i="4.68,345,1312156800"; d="scan'208";a="679192" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 07 Sep 2011 14:59:32 +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 p87ExVsE030255; Wed, 7 Sep 2011 14:59:32 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E677CB8.40203@skype.net> Date: Wed, 7 Sep 2011 08:59:31 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5DD808C2-D4ED-45E4-8D18-02613281A62D@cisco.com> References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> <4E666785.7040409@skype.net> <4E67513C.3030600@alvestrand.no> <4E677CB8.40203@skype.net> To: Matthew Kaufman X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 14:57:47 -0000 On Sep 7, 2011, at 8:16 AM, Matthew Kaufman wrote: > On 9/7/2011 4:10 AM, Harald Alvestrand wrote: >>=20 >> Since more people than I may be confused, I'm forking a subthread... >>=20 >> what is a bridged line appearance, and why is it hard to do in SIP? >>=20 >> My terminology cache is totally blank. >>=20 >=20 > Key system (and home phone) emulation requires two things that are = hard to do (because there's no final specification, not because it is = impossible) (and because there's 3+ alternatives, and almost no phones = implement more than one of them) in SIP: >=20 > 1. Shared line appearance >=20 > This is where you can be on a call on one handset, see that the line = is in use at the other handset. Place the call on hold at the first, = pick it up at the second. >=20 > In business PBX cases, this is used for executive/assistant cases. In = key system emulation it is used for "Bob, pick up the call holding on = line 3". And for home phones it is the usual "put the phone on hold in = the kitchen, pick it up in the den." (My wife wanted this functionality, = so I had to add proprietary support for shared line appearance on my = home PBX.) >=20 > 2. Bridged line appearance >=20 > This is where you can be on a call on one handset, see that line is in = use at the other handset, and pick up the second handset to join the = call. >=20 > In the business PBX and key system case this is sometimes used for = supervisors to join a call to help, but the real common case is the home = phones... "kids, go pick up the extension in the living room and talk to = grandma." >=20 > With POTS, this works by simply paralleling two handsets on the same = copper pair. For SIP it requires everything shared line appearance does = *plus* automatic barge-in + conference on pickup. >=20 > The BLISS WG has been working, for a long time, on taking the various = interim proposals and creating a standard out of them, but we're still = not there... and yet without it, there's no way to use phones from two = different vendors to accomplish this. >=20 > Whereas with WebRTC implemented *without SIP*, it is fairly easy to = build a web app that runs on multiple browsers from multiple vendors and = implements this. I've sort of been humoring you but I'm going to push this one a bit. I = think you are wrong.=20 Give me one reasons why it would be any harder to do if the browser did = SIP than if it did the type of API you are talking about. I think you = are just wrong here. The web app in the JS and in the web server would = still just use SIP to set up media the way it wanted - just like you = would do with the other API. No one is proposing we use the BLISS shared = line appearance or anything like that - we are proposing that when A = wants to say what codecs to use for sending media to B, use that part of = SIP.=20 (oh, and you could replace SIP with the word Jingle in the above = paragraph and it would equally true) From fluffy@cisco.com Wed Sep 7 07: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 0E60C21F8B62 for ; Wed, 7 Sep 2011 07:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.26 X-Spam-Level: X-Spam-Status: No, score=-103.26 tagged_above=-999 required=5 tests=[AWL=-0.661, 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 JjRDiv7dBUda for ; Wed, 7 Sep 2011 07:59:03 -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 8D9B321F8B55 for ; Wed, 7 Sep 2011 07:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1068; q=dns/txt; s=iport; t=1315407653; x=1316617253; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=WSU7xmHbnJRJTef25mh4HRagdd/+Cb97ifKXlbvHPQ8=; b=VRN4jNkWicE/2TJyWMi37EivgKzTWx9bvU0ri4RTR3sTLAUUbrk/TAcd SV8w9ZXjLNDaxIb5rUEnmeSnlF52q92eTsxleavolF3yAciXl/KrRSwEM hp9Cck339pGrl8Rb0oCbRDHrzmapmhus6pQZVoMvRxIDkX4yS1aa2K1Kf 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIKGZ06rRDoJ/2dsb2JhbABDp214gUYBAQEBAgESASc/BQsLEgYjC0kOBjWHU5huAZ5LhgtgBIdsi0aFEowi X-IronPort-AV: E=Sophos;i="4.68,345,1312156800"; d="scan'208";a="679589" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 07 Sep 2011 15:00:53 +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 p87F0qNM031361; Wed, 7 Sep 2011 15:00:52 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E677D4F.8050105@skype.net> Date: Wed, 7 Sep 2011 09:00:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> <4E666785.7040409@skype.net> <4E67513C.3030600@alvestrand.no> <4E677CB8.40203@skype.net> <4E677D4F.8050105@skype.net> To: Matthew Kaufman X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 14:59:04 -0000 On Sep 7, 2011, at 8:18 AM, Matthew Kaufman wrote: > On 9/7/2011 7:16 AM, Matthew Kaufman wrote: >>=20 >> Whereas with WebRTC implemented *without SIP*, it is fairly easy to = build a web app that runs on multiple browsers from multiple vendors and = implements this. >>=20 >> So this type of ability to innovate and implement applications = without going through the standards process is why we *definitely* don't = want SIP baked in to the browser. >=20 > And note that this is directly parallel to the "innovate like Gmail" = discussion. It is trivial for Gmail to change the look and feel and = behavior of the "delete" button to implement an email paradigm of "keep = everything, search to find it" (and have it work the same way no matter = who the browser vendor is)... but this wouldn't have been the case if = Gmail were forced to use the browser's built-in IMAP implementation. again - as I have mentioned before, that a silly analogy. I know it is = rhetorically nice but seriously, why do you think it is a reasonable = parallel? From fluffy@cisco.com Wed Sep 7 08:03: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 DFECD21F8B56 for ; Wed, 7 Sep 2011 08:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.253 X-Spam-Level: X-Spam-Status: No, score=-103.253 tagged_above=-999 required=5 tests=[AWL=-0.654, 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 sHBF4VzkGxfH for ; Wed, 7 Sep 2011 08:03:01 -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 70BA721F8A56 for ; Wed, 7 Sep 2011 08:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2094; q=dns/txt; s=iport; t=1315407891; x=1316617491; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6tRkkpvIUrwbwdNIK4HqCuUglhxTwQRPD5H5KNAK1GU=; b=L2MZQP1V+yM74FSA6aX8vimTDni5GT8cfFgLtQV+nF0hOa/sphDpjbcw dMj+SQ7Kk4+pi4jh6Ete2GKu0vLUnkYw7aBDfEDpAABq4iuG5WPCoMYOJ Cwd9x8XfE44qxjX20DhhgZ2FXhyOGJH7hZJWnoi3QyV6Iag501aZ822Uc A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHqHZ06rRDoG/2dsb2JhbABEp214gUYBAQEBAgEBAQEPASc0CwULCxguJzAGCgkih1MEmGcBnkuGC2AEh2yLRoUSjCI X-IronPort-AV: E=Sophos;i="4.68,345,1312156800"; d="scan'208";a="680774" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 07 Sep 2011 15:04:47 +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 p87F4kfQ008271; Wed, 7 Sep 2011 15:04:46 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E665588.5000700@mozilla.com> Date: Wed, 7 Sep 2011 09:04:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E259484.20509@ericsson.com>, <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com>, <4E26B742.6050606@jitsi.org>, <62C71813-83B4-44D3-8E54-28262311CDB3@cisco.com> <4E27BE02.7090606@ericsson.com> <9F9278CB1892FB48BF35CB5CC3992478A5395C720E@HKGMBOXPRD01.polycom.com> <4E2EB82C.30709@alvestrand.no> <4E643E39.8020205@skype.net> <4E665588.5000700@mozilla.com> To: Christopher Blizzard X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Support for websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 15:03:02 -0000 Sooner or later, I do think we should talk about how to spoof RTP = through firewalls that only allow HTTP traffic. Certainly websockets = would be worth looking at but I suspect we will find that it was not = designed for transfer of large high bandwidth material (like video) and = that something similar but different is needed.=20 On Sep 6, 2011, at 11:16 AM, Christopher Blizzard wrote: > On 9/4/2011 8:12 PM, Matthew Kaufman wrote: >>=20 >>=20 >> I think there's a legitimate question as to how transmission of media = over TCP should work. I believe that the existing code bases all assume = that if you get IP addresses, you use them; if you get IP addresses for = TURN servers you talk to them over UDP and use TURN for relaying; and if = you get IP addresses for TURNS servers you talk to them over TLS/TCP and = use them for relaying. Therefore the only TCP transport is = TURN-over-TLS-over-TCP. >>=20 >> Is that sufficient and reasonable, or should media-over-websockets = (or something else) be how TCP transmission of media works? >=20 > It's important to note that WebSockets aren't raw sockets in the = classic TCP or POSIX sense. So a conversation about transmission of = media over TCP doesn't really apply to WebSockets, exactly. It's true = that since WS is over TCP that it's reliable and ordered. What would be = interesting would be a discussion of how to take media data coming in = over a WebSocket and feed it to a consumer that could display that = media, as well as the reverse. But an API discussion feels like = something that's more that's something that belongs at the W3C. >=20 > If we wanted a standardized representation in WS that might happen = here, but it's not something that's strictly required. Well-built APIs = to encoders and decoders could mean that it's up to page implementers to = figure out how to package the data, manipulated by JS. >=20 > --Chris > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From tim@phonefromhere.com Wed Sep 7 08:16: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 8A40221F8C7C for ; Wed, 7 Sep 2011 08:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bkilj3roVevQ for ; Wed, 7 Sep 2011 08:15:59 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 8569821F8C49 for ; Wed, 7 Sep 2011 08:15:59 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id DC15937A902; Wed, 7 Sep 2011 16:30:39 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <5DD808C2-D4ED-45E4-8D18-02613281A62D@cisco.com> Date: Wed, 7 Sep 2011 16:17:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> <4E666785.7040409@skype.net> <4E67513C.3030600@alvestrand.no> <4E677CB8.40203@skype.net> <5DD808C2-D4ED-45E4-8D18-02613281A62D@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 15:16:00 -0000 On 7 Sep 2011, at 15:59, Cullen Jennings wrote: >=20 > On Sep 7, 2011, at 8:16 AM, Matthew Kaufman wrote: >=20 >> On 9/7/2011 4:10 AM, Harald Alvestrand wrote: >>>=20 >>> Since more people than I may be confused, I'm forking a subthread... >>>=20 >>> what is a bridged line appearance, and why is it hard to do in SIP? >>>=20 >>> My terminology cache is totally blank. >>>=20 >>=20 >> Key system (and home phone) emulation requires two things that are = hard to do (because there's no final specification, not because it is = impossible) (and because there's 3+ alternatives, and almost no phones = implement more than one of them) in SIP: >>=20 >> 1. Shared line appearance >>=20 >> This is where you can be on a call on one handset, see that the line = is in use at the other handset. Place the call on hold at the first, = pick it up at the second. >>=20 >> In business PBX cases, this is used for executive/assistant cases. In = key system emulation it is used for "Bob, pick up the call holding on = line 3". And for home phones it is the usual "put the phone on hold in = the kitchen, pick it up in the den." (My wife wanted this functionality, = so I had to add proprietary support for shared line appearance on my = home PBX.) >>=20 >> 2. Bridged line appearance >>=20 >> This is where you can be on a call on one handset, see that line is = in use at the other handset, and pick up the second handset to join the = call. >>=20 >> In the business PBX and key system case this is sometimes used for = supervisors to join a call to help, but the real common case is the home = phones... "kids, go pick up the extension in the living room and talk to = grandma." >>=20 >> With POTS, this works by simply paralleling two handsets on the same = copper pair. For SIP it requires everything shared line appearance does = *plus* automatic barge-in + conference on pickup. >>=20 >> The BLISS WG has been working, for a long time, on taking the various = interim proposals and creating a standard out of them, but we're still = not there... and yet without it, there's no way to use phones from two = different vendors to accomplish this. >>=20 >> Whereas with WebRTC implemented *without SIP*, it is fairly easy to = build a web app that runs on multiple browsers from multiple vendors and = implements this. >=20 > I've sort of been humoring you but I'm going to push this one a bit. I = think you are wrong.=20 >=20 > Give me one reasons why it would be any harder to do if the browser = did SIP than if it did the type of API you are talking about. I think = you are just wrong here. The web app in the JS and in the web server = would still just use SIP to set up media the way it wanted - just like = you would do with the other API. No one is proposing we use the BLISS = shared line appearance or anything like that - we are proposing that = when A wants to say what codecs to use for sending media to B, use that = part of SIP.=20 >=20 > (oh, and you could replace SIP with the word Jingle in the above = paragraph and it would equally true) But try that paragraph with BRI or 'RFC 5456' or 'Freeswitch's XML = socket' or ASCF's ICE over HTTPS and it sounds a bit weird. Why ?=20 what is the difference between being locked into one of them vs SIP? Arguably SIP comes with more expectations and baggage than any of the = above and there is the risk. Folks will embed a full SIP stack before we know it - and the mere existence of a market in SBCs shows why = that would be 'a bad thing' (tm) Tim. (speaking for himself). From pkyzivat@alum.mit.edu Wed Sep 7 08:16: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 6EF8321F85F7 for ; Wed, 7 Sep 2011 08:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[AWL=-1.080, BAYES_00=-2.599, MANGLED_ONLINE=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 O+7dF47CnAIw for ; Wed, 7 Sep 2011 08:16:07 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD6F21F855F for ; Wed, 7 Sep 2011 08:16:06 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta09.westchester.pa.mail.comcast.net with comcast id VrD31h0021vXlb859rHxoN; Wed, 07 Sep 2011 15:17:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta17.westchester.pa.mail.comcast.net with comcast id VrHv1h01e0tdiYw3drHwfz; Wed, 07 Sep 2011 15:17:57 +0000 Message-ID: <4E678B44.9080208@alum.mit.edu> Date: Wed, 07 Sep 2011 11:18:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> <4E666785.7040409@skype.net> <4E67513C.3030600@alvestrand.no> <4E677CB8.40203@skype.net> In-Reply-To: <4E677CB8.40203@skype.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 15:16:08 -0000 Matthew, Good summary. I agree that webrtc provides flexibility in how to implement the UI portions of these features with generic webrtc clients. But it doesn't make these features trivial to implement. In particular, the bridged line appearance still requires that a conference be established. With generic rtcweb clients, that probably means a central mixer. Setting that up is relatively easy if there is a central media termination point in rtcweb server, and it *has* mixer capabilities. My point is not that rtcweb doesn't help with this case - just that these features that are so trivial in analog telephony just aren't so simple with voip, no matter how you do it. Thanks, Paul On 9/7/11 10:16 AM, Matthew Kaufman wrote: > On 9/7/2011 4:10 AM, Harald Alvestrand wrote: >> >> Since more people than I may be confused, I'm forking a subthread... >> >> what is a bridged line appearance, and why is it hard to do in SIP? >> >> My terminology cache is totally blank. >> > > Key system (and home phone) emulation requires two things that are hard > to do (because there's no final specification, not because it is > impossible) (and because there's 3+ alternatives, and almost no phones > implement more than one of them) in SIP: > > 1. Shared line appearance > > This is where you can be on a call on one handset, see that the line is > in use at the other handset. Place the call on hold at the first, pick > it up at the second. > > In business PBX cases, this is used for executive/assistant cases. In > key system emulation it is used for "Bob, pick up the call holding on > line 3". And for home phones it is the usual "put the phone on hold in > the kitchen, pick it up in the den." (My wife wanted this functionality, > so I had to add proprietary support for shared line appearance on my > home PBX.) > > 2. Bridged line appearance > > This is where you can be on a call on one handset, see that line is in > use at the other handset, and pick up the second handset to join the call. > > In the business PBX and key system case this is sometimes used for > supervisors to join a call to help, but the real common case is the home > phones... "kids, go pick up the extension in the living room and talk to > grandma." > > With POTS, this works by simply paralleling two handsets on the same > copper pair. For SIP it requires everything shared line appearance does > *plus* automatic barge-in + conference on pickup. > > The BLISS WG has been working, for a long time, on taking the various > interim proposals and creating a standard out of them, but we're still > not there... and yet without it, there's no way to use phones from two > different vendors to accomplish this. > > Whereas with WebRTC implemented *without SIP*, it is fairly easy to > build a web app that runs on multiple browsers from multiple vendors and > implements this. > > So this type of ability to innovate and implement applications without > going through the standards process is why we *definitely* don't want > SIP baked in to the browser. > > Not to be confused with the arguments against SDP offer/answer, which is > only slightly affected by the above use cases (in that you can do > smarter things at the bridge for bridged line appearance if you aren't > doing a reinvite/re-offer/re-answer but instead have on hand all the > capabilities of the first device when the second goes to join). > > Matthew Kaufman > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From fluffy@cisco.com Wed Sep 7 08:16: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 EA16D21F8A57 for ; Wed, 7 Sep 2011 08:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.246 X-Spam-Level: X-Spam-Status: No, score=-103.246 tagged_above=-999 required=5 tests=[AWL=-0.648, 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 5t-eRvdh6Lf2 for ; Wed, 7 Sep 2011 08:16:36 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2046F21F869E for ; Wed, 7 Sep 2011 08:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=8322; q=dns/txt; s=iport; t=1315408706; x=1316618306; h=from:subject:date:references:to:message-id:mime-version; bh=tjUde5eFeRjWArfgQ+k7iUCqvpDhT4UxiG9naWYUOk8=; b=TJ2GwLGaDiBBhwqrxF6PQMtbsBASh/b472TtkHPoXsJBdDHZKuYRAcbA FQJ3Ykp3fvFWaOiwdZf5QirWpZh2pC3AWlj1CajB/SAwkbr73ml+aWkN6 eEG9Tluq33VtiUOH8D0nYs9ulA1AAa77EitnxrLUcbhzAsVBWupNqkS5v M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPiJZ06rRDoJ/2dsb2JhbAAqFwOnbniBRgEBAQECARIBHDcYCx8YBAwKVgEDFiKHUwQjmDcBnkyDTxAGgiZgBIdsi0aFEoRrhlFm X-IronPort-AV: E=Sophos;i="4.68,346,1312156800"; d="scan'208,217";a="683327" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 07 Sep 2011 15:18:25 +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 p87FIPtg010570 for ; Wed, 7 Sep 2011 15:18:25 GMT From: Cullen Jennings Content-Type: multipart/alternative; boundary=Apple-Mail-3--53427481 Date: Wed, 7 Sep 2011 09:18:25 -0600 References: <202988688.1314227811055.JavaMail.nobody@jsj6wl005.webex.com> To: rtcweb@ietf.org Message-Id: <69DF79D2-66B4-4E51-873F-0D25C9BBFEB9@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] WebEX details for tomorrows RTCWeb call X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 15:16:41 -0000 --Apple-Mail-3--53427481 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The easiest way to join is use the URL=20 > = https://cisco.webex.com/ciscosales/j.php?ED=3D172621142&UID=3D0&PW=3DNMDQz= ZjU1N2M0&RT=3DMiM0=20 then have webex phone you at your phone number.=20 >=20 >=20 > Cullen Jennings invites you to attend this online meeting.=20 >=20 > Topic: IETF RTCWeb 81.5=20 > Date: Thursday, September 8, 2011=20 > Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)=20 > Meeting Number: 203 523 321=20 > Meeting Password: ietf=20 >=20 >=20 > -------------------------------------------------------=20 > To join the online meeting (Now from mobile devices!)=20 > -------------------------------------------------------=20 > 1. Go to = https://cisco.webex.com/ciscosales/j.php?ED=3D172621142&UID=3D0&PW=3DNMDQz= ZjU1N2M0&RT=3DMiM0=20 > 2. Enter your name and email address.=20 > 3. Enter the meeting password: ietf=20 > 4. Click "Join Now".=20 >=20 > To view in other time zones or languages, please click the link:=20 > = https://cisco.webex.com/ciscosales/j.php?ED=3D172621142&UID=3D0&PW=3DNMDQz= ZjU1N2M0&ORT=3DMiM0=20 >=20 > ----------------------------------------------------------------=20 > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes=20 > ----------------------------------------------------------------=20 >=20 > The affected toll free numbers are: (866) 432-9903 for the San = Jose/Milpitas area and (866) 349-3520 for the RTP area.=20 >=20 > Please dial the local access number for your area from the list below:=20= > - San Jose/Milpitas (408) area: 525-6800=20 > - RTP (919) area: 392-3330=20 >=20 > -------------------------------------------------------=20 > To join the teleconference only=20 > -------------------------------------------------------=20 > 1. Dial into Cisco WebEx (view all Global Access Numbers at=20 > http://cisco.com/en/US/about/doing_business/conferencing/index.html=20 > 2. Follow the prompts to enter the Meeting Number (listed above) or = Access Code followed by the # sign.=20 >=20 > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330=20 >=20 > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117=20 >=20 > India: +91.80.4350.1111 Germany: +49.619.6773.9002=20 >=20 > Japan: +81.3.5763.9394 China: +86.10.8515.5666=20 >=20 > -------------------------------------------------------=20 > For assistance=20 > -------------------------------------------------------=20 > 1. Go to https://cisco.webex.com/ciscosales/mc=20 > 2. On the left navigation bar, click "Support".=20 >=20 > You can contact me at:=20 > fluffy@cisco.com=20 > 1-408-902 3341=20 >=20 > To add this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 > = https://cisco.webex.com/ciscosales/j.php?ED=3D172621142&UID=3D0&ICS=3DMI&L= D=3D1&RD=3D2&ST=3D1&SHA2=3DqNpPAgB6G-X9gjfKoTbP5Qyw4R4rpfHlcc8nuO4rxrU=3D&= RT=3DMiM0=20 >=20 > The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to = https://cisco.webex.com/ciscosales/systemdiagnosis.php=20 >=20 --Apple-Mail-3--53427481 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii https://cisco.webex.com/ciscosales/j.php?ED=3D172621142&= amp;UID=3D0&PW=3DNMDQzZjU1N2M0&RT=3DMiM0 
then have webex phone you at your phone = number. 



=
Cullen Jennings invites you to attend this online meeting.
=
Topic: IETF RTCWeb 81.5
Date: Thursday, September 8, 2011
= Time: 7:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
= Meeting Number: 203 523 321
Meeting Password: ietf


= -------------------------------------------------------
To join the = online meeting (Now from mobile devices!)
= -------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D172621142&= amp;UID=3D0&PW=3DNMDQzZjU1N2M0&RT=3DMiM0
2. Enter your = name and email address.
3. Enter the meeting password: ietf
4. = Click "Join Now".

To view in other time zones or languages, = please click the link:
https://cisco.webex.com/ciscosales/j.php?ED=3D172621142&= amp;UID=3D0&PW=3DNMDQzZjU1N2M0&ORT=3DMiM0

= ----------------------------------------------------------------
= ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
= ----------------------------------------------------------------
=
The affected toll free numbers are: (866) 432-9903 for the San = Jose/Milpitas area and (866) 349-3520 for the RTP area.

Please = dial the local access number for your area from the list below:
- = San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330 =

-------------------------------------------------------
= To join the teleconference only
= -------------------------------------------------------
1. Dial = into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing= /index.html
2. Follow the prompts to enter the Meeting Number = (listed above) or Access Code followed by the # sign.

San = Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: = +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: = +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: = +81.3.5763.9394 China: +86.10.8515.5666

= -------------------------------------------------------
For = assistance
------------------------------------------------------- =
1. Go to https://cisco.webex.com/ciscosales/mc
2. On = the left navigation bar, click "Support".

You can contact me = at:
fluffy@cisco.com
= 1-408-902 3341

To add this meeting to your calendar program = (for example Microsoft Outlook), click this link:
https://cisco.webex.com/ciscosales/j.php?ED=3D172621142&= amp;UID=3D0&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DqNpPA= gB6G-X9gjfKoTbP5Qyw4R4rpfHlcc8nuO4rxrU=3D&RT=3DMiM0

= The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to https://cisco.webex.com/ciscosales/systemdiagnosis.php


= --Apple-Mail-3--53427481-- From harald@alvestrand.no Wed Sep 7 08:24: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 9647221F8AF1 for ; Wed, 7 Sep 2011 08:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.639 X-Spam-Level: X-Spam-Status: No, score=-107.639 tagged_above=-999 required=5 tests=[AWL=2.960, 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 yMzYwhPcXJK4 for ; Wed, 7 Sep 2011 08:24:43 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D27FF21F8AF3 for ; Wed, 7 Sep 2011 08:24:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 25D5D39E112 for ; Wed, 7 Sep 2011 17:26:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aTwNwXm1Q2U for ; Wed, 7 Sep 2011 17:26:26 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C6EEF39E072 for ; Wed, 7 Sep 2011 17:26:26 +0200 (CEST) Message-ID: <4E678D22.4060203@alvestrand.no> Date: Wed, 07 Sep 2011 17:26:26 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E259484.20509@ericsson.com>, <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com>, <4E26B742.6050606@jitsi.org>, <62C71813-83B4-44D3-8E54-28262311CDB3@cisco.com> <4E27BE02.7090606@ericsson.com> <9F9278CB1892FB48BF35CB5CC3992478A5395C720E@HKGMBOXPRD01.polycom.com> <4E2EB82C.30709@alvestrand.no> <4E643E39.8020205@skype.net> <4E665588.5000700@mozilla.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Support for websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 15:24:43 -0000 On 09/07/11 17:04, Cullen Jennings wrote: > Sooner or later, I do think we should talk about how to spoof RTP through firewalls that only allow HTTP traffic. Certainly websockets would be worth looking at but I suspect we will find that it was not designed for transfer of large high bandwidth material (like video) and that something similar but different is needed. The huge difference between websockets and a real-time RTP connection is that in a real-time connection, you drop packets if you get behind. In websockets, you deliver everything that made it to the "send" call. Apart from that, I think it's fine - it's got a "message" concept that can be used to tell packets apart; just shove each RTP packet into its own WS "message" and go. RFC 1006 did that back in the 1980s. The extra cycles spent "masking" are irritating, but unlikely to be fatal. Now, if the send buffers were controllable and visible, the sender side could emulate RTP by dropping the packets rather than calling "send()" when congestion occurs. Don't know if such interfaces exists. From ted.ietf@gmail.com Wed Sep 7 09:27: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 9E93D21F8B23 for ; Wed, 7 Sep 2011 09:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N13AQx2xiHMa for ; Wed, 7 Sep 2011 09:27:17 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF58621F8B20 for ; Wed, 7 Sep 2011 09:27:16 -0700 (PDT) Received: by qyk34 with SMTP id 34so1475371qyk.10 for ; Wed, 07 Sep 2011 09:29:06 -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=WChzedGVs5cA5m3bw03mMfmOk/Ss+Glf4mZHVe6N59g=; b=bYdFwLNhD9fva9gMWOvazv/bhU2P8iAVVoUlH5t+cRa+XoFkam1Rl7xQ21WBaHUX2k 1cW/fN6banT3Jx/owT8FnJoQJePu0r/+PrAb8IfBKvKUlnVBimFI7xbZ7Z3r0DtsEx01 LDxvOEgKH2xiW9VQXn2gsyRJCrmpp8IdAlVOk= MIME-Version: 1.0 Received: by 10.229.176.106 with SMTP id bd42mr5248277qcb.28.1315412946470; Wed, 07 Sep 2011 09:29:06 -0700 (PDT) Received: by 10.229.239.7 with HTTP; Wed, 7 Sep 2011 09:29:06 -0700 (PDT) Date: Wed, 7 Sep 2011 09:29:06 -0700 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=0016e68de1c468492e04ac5c7166 Subject: [rtcweb] Updated Agenda, meeting materials X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 16:27:17 -0000 --0016e68de1c468492e04ac5c7166 Content-Type: text/plain; charset=ISO-8859-1 Hi Folks, The meeting materials manager does not yet have an 81.5 entry for this interim meeting, so I will be uploading any slides received to the IETF 82 area. We'll get that sorted out with the secretariat to reflect reality better in due time, but in the mean time, you can look for rtcweb slide decks in http://www.ietf.org/proceedings/82/slides/ . Unfortunately, the titles don't get reflected in the file names, so you'll need to grab anything you see. Please also note that some drafts have been updated, including http://datatracker.ietf.org/doc/draft-rescorla-rtcweb-security/ . Because we have not yet adopted those as WG drafts, the notice didn't go the WG. For the Agenda, we currently plan to swap the signalling and security sections, in part because some folks may not make the full four hours. Since the congestion control document did come in, we're currently planning: Use Cases (1 hr) --20 minutes on Recording (John Elwell) --40 Review and discussion of other use cases proposed on mailing list and in-draft (Use case draft author team) Signalling (1 hr) --15 minutes Issue Overview (Matthew Kaufmann) --15 minutes Offer/Answer architectural text (Cullen Jennings) --30 minutes discussion Security (1 hr) --Discussion of what assurance we wish to provide to which parties (Eric Rescorla) Terminology Mapping (30 minutes) --Mapping WebRTC constructs to RTCWeb terms (Magnus) Congestion Control (30 minutes) --One congestion control approach (Harald) regards, Ted, Cullen, Magnus --0016e68de1c468492e04ac5c7166 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Folks,

The meeting materials manager does not yet have an 81.5 en= try for this interim meeting, so I will be uploading any slides received to= the IETF 82 area.=A0 We'll get that sorted out with the secretariat to= reflect reality better in due time, but in the mean time, you can look for= rtcweb slide decks in http://www.ietf.org/proceedings/82/slides/ .=A0 Unfortunately, the t= itles don't get reflected in the file names, so you'll need to grab= anything you see.=A0 Please also note that some drafts have been updated, = including http://datatracker.ietf.org/doc/draft-rescorla-rtcweb-security/<= /a> .=A0 Because we have not yet adopted those as WG drafts, the notice did= n't go the WG.

For the Agenda, we currently plan to swap the signalling and security s= ections, in part because some folks may not make the full four hours.=A0 Si= nce the congestion control document did come in, we're currently planni= ng:

Use Cases (1 hr)
--20 minutes on=A0 Recording (John Elwell)
--40 = Review and discussion of other use cases proposed on mailing list and in-dr= aft (Use case draft author team)
Signalling (1 hr)
--15 minutes Issue= Overview (Matthew Kaufmann)
--15 minutes Offer/Answer architectural text (Cullen Jennings)
--30 minu= tes discussion
Security (1 hr)
--Discussion of what assurance we wish= to provide to which parties (Eric Rescorla)
Terminology Mapping (30 min= utes)
--Mapping WebRTC constructs to RTCWeb terms (Magnus)
Congestion Control = (30 minutes)
--One congestion control approach (Harald)


regar= ds,

Ted, Cullen, Magnus
--0016e68de1c468492e04ac5c7166-- From fluffy@cisco.com Wed Sep 7 09:39: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 B2C2021F8C79 for ; Wed, 7 Sep 2011 09:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.24 X-Spam-Level: X-Spam-Status: No, score=-103.24 tagged_above=-999 required=5 tests=[AWL=-0.641, 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 5+zqipOkAx8d for ; Wed, 7 Sep 2011 09:39:14 -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 3C8BD21F8B1C for ; Wed, 7 Sep 2011 09:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=178; q=dns/txt; s=iport; t=1315413662; x=1316623262; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=L64wS0j2VRNo4WzO4ETxHU/uoWYvjXaky+9Vl3TNImc=; b=ir+opJUg6tS7AfITrnWq5+NjnALhqvqQUtgKLlTHFZyzDzqwJtNiXUx0 5XFetQjCv2zCoL/exTie/XbGWv8R2xKidaMynZKpg6CZaChoi1tBVjS1b 06YiEDeCYf+Fjet35/xhV5vvW+rVNvbKAtJ7k/6val4CsTdsVpklyxhp3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYHANSdZ06rRDoI/2dsb2JhbABEmSyDZIpeeIFfASeCModXmACBIwGeTIYLYASHbItGhRKEa4c3 X-IronPort-AV: E=Sophos;i="4.68,346,1312156800"; d="scan'208";a="699867" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 07 Sep 2011 16:41:02 +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 p87Gf1sR006974 for ; Wed, 7 Sep 2011 16:41:01 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 7 Sep 2011 10:41:01 -0600 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [rtcweb] 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: Wed, 07 Sep 2011 16:39:14 -0000 I see that EKR published an updated security draft at http://tools.ietf.org/html/draft-rescorla-rtcweb-security-01 Just wanted to point that out to the list. Cullen From roman@telurix.com Wed Sep 7 09:46: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 CC23F21F8B4F for ; Wed, 7 Sep 2011 09:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tg+zoLrOhfAA for ; Wed, 7 Sep 2011 09:46:46 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7E19421F8B4E for ; Wed, 7 Sep 2011 09:46:46 -0700 (PDT) Received: by gwb17 with SMTP id 17so4638518gwb.15 for ; Wed, 07 Sep 2011 09:48:36 -0700 (PDT) Received: by 10.150.177.8 with SMTP id z8mr815836ybe.342.1315414115887; Wed, 07 Sep 2011 09:48:35 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id f5sm591709ybf.16.2011.09.07.09.48.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Sep 2011 09:48:32 -0700 (PDT) Received: by ywe9 with SMTP id 9so391982ywe.31 for ; Wed, 07 Sep 2011 09:48:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.132 with SMTP id k4mr2496057pbo.456.1315414111207; Wed, 07 Sep 2011 09:48:31 -0700 (PDT) Received: by 10.68.43.136 with HTTP; Wed, 7 Sep 2011 09:48:31 -0700 (PDT) In-Reply-To: References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> Date: Wed, 7 Sep 2011 12:48:31 -0400 Message-ID: From: Roman Shpount To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=bcaec51a7700d4bffe04ac5cb6de Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 16:46:47 -0000 --bcaec51a7700d4bffe04ac5cb6de Content-Type: text/plain; charset=ISO-8859-1 Just to adding my two cents on why SIP must not be used: SIP was designed for a very different use case then rtcWeb. SIP was designed to run over UDP on a network with no NAT. It was intended as a light weight protocol to implement IP phones on the corporate networks. It was designed for devices with limited resources and limited and fixed functionality. There was a significant amount of effort to add support for SIP over NAT, but this is far from being complete. Getting SIP over TCP to work from NAT environments is still a challenge. Unfortunately you do need SIP over TCP to support ICE due to the increased offer size. In fact, I am not aware of any system that implements SIP over TCP over NAT (RFC 5626) in combination with ICE. On the other hand, rtcWeb is designed for large number of clients running behind NAT. We do not have the same limitations on the end user device performance. There is no real reason to use UDP as primary signaling protocol. Unlike on IP phones, HTTP client and JavaScript are already available and will not create an additional implementation burden. Thus, I think we should keep the offer/answer and use HTTP and JavaScript to implement the signaling. _____________ Roman Shpount On Wed, Sep 7, 2011 at 3:07 AM, Olle E. Johansson wrote: > > 6 sep 2011 kl. 21:24 skrev Asveren, Tolga: > > > What about semantics (adding just a X-header won't help there) or how > much SIP would be left anyhow if all semantical control is exposed through > the API? > > > > I think bridged line appearance is a good test to run against different > models. > > > Well, I tried to stay neutral but examples likes this makes me not want SIP > in the browser. DTMF, Early Media, bridge line apperances and other PSTN > legacy will make the implementation too focused on classical telephony and > we'll spend too much time implementing features that are application > specific and we can implement in controlling applications, client or > server-side. > > Cullen tried to make a draft with "limited" SIP (maybe "SIP Lite") but it > will be hard to protect that from the myriad of extensions that add PSTN > functionality that's not really needed to set up multimedia calls between > two browser users. It may be needed for gatewaying to legacy systems, but if > we don't "stop Olle in the gate" - verbatim translation of a Swedish saying > that propably doesn't mean much to most people on the list - I think we will > never be done. > > Of course, being a SIP developer, I started off with thinking that SIP in > the browser was the default route. I am beginning to understand that the > browser is the user interface part we all need, the media handler. We all > have different requirements on how to control that media GUI and to get > anywhere I am beginning to think the logic for signalling to set up > rendevouz points and manage sessions has to move "somewhere else" where we > can implement SIP, XMPP or some other protocol that fulfills the need of our > respective application. > > To fearlessly jump into another can of worms, I still think we should have > confidentiality - SRTP - by default. We know that these applications will > run on a myriad of devices on a myriad of networks and it will not work to > let users have to decided whether or not they want confidentiality. If Skype > did not have confidentiality by default, there would be articles every > summer and xmas in the evening taboloids about how easy it is to listen in > to your neighbours calls and that would have hurted Skype badly. > > /O > > > > Thanks, > > Tolga > > > > > > -----Original Message----- > > From: rtcweb-bounces@ietf.org on behalf of Olle E. Johansson > > Sent: Tue 9/6/2011 2:47 PM > > To: Matthew Kaufman > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: > Remoterecording - RTC-Web client acting as SIPREC session > recordingclient] > > > > > > 6 sep 2011 kl. 20:40 skrev Matthew Kaufman: > > > >> On 9/6/11 11:36 AM, Ravindran Parthasarathi wrote: > >>> Matthew, > >>> > >>> Even in case of SIP, there is no need of standardization in case it is > within single webserver(skype). SIP supports x-header or proprietary header > to extend the way you want it for providing innovative functionality. > >> > >> Not if SIP is baked in to the browser it doesn't. If the browser > implements a SIP phone in native code, I have no way of adding "x-header" or > anything else. I live with the functionality provided by the browser. > > That's an implementation detail. One can easily add an API call to add > headers on the outbound INVITE. > > > >> > >> If on the other hand, you want SIP implemented in Javascript then sure, > if a developer wants to use it, great. If they want to extend it, that's > fine too. And if they'd rather use another model, they are free to do that. > Just as you would expect from a *platform*. > >> > >>> There is no extension barrier from SIP perspective but it ensure that > basic call works across web servers. For example, skype browser user will > able to talk to gmail real-time user even though all skype functionality are > not supported. > >> See above. > >>> > >>> In case you have the points why HTTP allows innovation but SIP will > not, let us discuss in detail. > >> > >> See above. I want you to be free to use SIP, but not *required* to use > SIP. > >> > >> And there's some security reasons that I'd rather you tunnel it over > HTTP rather than opening up your ability to send UDP packets to port 5060. > > SIP runs on TCP and TLS ports too. > > > > I am not arguing for either side, just correcting some details... > > > > /O > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > --- > * Olle E Johansson - oej@edvina.net > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec51a7700d4bffe04ac5cb6de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just to adding my two cents on why SIP must not be used: SIP was designed f= or a very different use case then rtcWeb. SIP was designed to run over UDP = on a network with no NAT. It was intended as a light weight protocol to imp= lement IP phones on the corporate networks. It was designed for devices wit= h limited resources and limited and fixed functionality. There was a signif= icant amount of effort to add support for SIP over NAT, but this is far fro= m being complete. Getting SIP over TCP to work from NAT environments is sti= ll a challenge. Unfortunately you do need SIP over TCP to support ICE due t= o the increased offer size. In fact, I am not aware of any system that impl= ements SIP over TCP over NAT (RFC 5626) in combination with ICE.

On the other hand, rtcWeb is designed for large number of clients runni= ng behind NAT. We do not have the same limitations on the end user device p= erformance. There is no real reason to use UDP as primary signaling protoco= l. Unlike on IP phones, HTTP client and JavaScript are already available an= d will not create an additional implementation burden. Thus, I think we sho= uld keep the offer/answer and use HTTP and JavaScript to implement the sign= aling.
_____________
Roman Shpount


On Wed, Sep 7, 2011 at 3:07 AM, Olle E. = Johansson <oej@edvin= a.net> wrote:

6 sep 2011 kl. 21:24 skrev Asveren, Tolga:

> What about semantics (adding just a X-header won't help there) or = how much SIP would be left anyhow if all semantical control is exposed thro= ugh the API?
>
> I think bridged line appearance is a good test to run against differen= t models.
>
Well, I tried to stay neutral but examples likes this makes me not want SIP= in the browser. DTMF, Early Media, bridge line apperances and other PSTN l= egacy will make the implementation too focused on classical telephony and w= e'll spend too much time implementing features that are application spe= cific and we can implement in controlling applications, client or server-si= de.

Cullen tried to make a draft with "limited" SIP (maybe "SIP = Lite") but it will be hard to protect that from the myriad of extensio= ns that add PSTN functionality that's not really needed to set up multi= media calls between two browser users. It may be needed for gatewaying to l= egacy systems, but if we don't "stop Olle in the gate" - verb= atim translation of a Swedish saying that propably doesn't mean much to= most people on the list - I think we will never be done.

Of course, being a SIP developer, I started off with thinking that SIP in t= he browser was the default route. I am beginning to understand that the bro= wser is the user interface part we all need, the media handler. We all have= different requirements on how to control that media GUI and to get anywher= e I am beginning to think the logic for signalling to set up rendevouz poin= ts and manage sessions has to move "somewhere else" where we can = implement SIP, XMPP or some other protocol that fulfills the need of our re= spective application.

To fearlessly =A0jump into another can of worms, I still think we should ha= ve confidentiality - SRTP - by default. We know that these applications wil= l run on a myriad of devices on a myriad of networks and it will not work t= o let users have to decided whether or not they want confidentiality. If Sk= ype did not have confidentiality by default, there would be articles every = summer and xmas in the evening taboloids about how easy it is to listen in = to your neighbours calls and that would have hurted Skype badly.

/O


> Thanks,
> Tolga
>
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.o= rg on behalf of Olle E. Johansson
> Sent: Tue 9/6/2011 2:47 PM
> To: Matthew Kaufman
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoter= ecording - RTC-Web client acting as =A0 =A0 SIPREC =A0session recordingclie= nt]
>
>
> 6 sep 2011 kl. 20:40 skrev Matthew Kaufman:
>
>> On 9/6/11 11:36 AM, Ravindran Parthasarathi wrote:
>>> Matthew,
>>>
>>> Even in case of SIP, there is no need of standardization in ca= se it is within single webserver(skype). SIP supports x-header or proprieta= ry header to extend the way you want it for providing innovative functional= ity.
>>
>> Not if SIP is baked in to the browser it doesn't. If the brows= er implements a SIP phone in native code, I have no way of adding "x-h= eader" or anything else. I live with the functionality provided by the= browser.
> That's an implementation detail. One can easily add an API call to= add headers on the outbound INVITE.
>
>>
>> If on the other hand, you want SIP implemented in Javascript then = sure, if a developer wants to use it, great. If they want to extend it, tha= t's fine too. And if they'd rather use another model, they are free= to do that. Just as you would expect from a *platform*.
>>
>>> There is no extension barrier from SIP perspective but it ensu= re that basic call works across web servers. For example, skype browser use= r will able to talk to gmail real-time user even though all skype functiona= lity are not supported.
>> See above.
>>>
>>> In case you have the points why HTTP allows innovation but SIP= will not, let us discuss in detail.
>>
>> See above. I want you to be free to use SIP, but not *required* to= use SIP.
>>
>> And there's some security reasons that I'd rather you tunn= el it over HTTP rather than opening up your ability to send UDP packets to = port 5060.
> SIP runs on TCP and TLS ports too.
>
> I am not arguing for either side, just correcting some details...
>
> /O
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

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



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

--bcaec51a7700d4bffe04ac5cb6de-- From igor.faynberg@alcatel-lucent.com Wed Sep 7 09:52: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 6D5FF21F8C72 for ; Wed, 7 Sep 2011 09:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A85Heki8HlXE for ; Wed, 7 Sep 2011 09:52:02 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id ADE5421F8C3A for ; Wed, 7 Sep 2011 09:52:02 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p87Grp4n014090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 11:53:51 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p87Grofp007614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Sep 2011 11:53:51 -0500 Received: from [135.222.134.166] (USMUYN0L055118.mh.lucent.com [135.222.134.166]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p87GrnmI009196; Wed, 7 Sep 2011 11:53:50 -0500 (CDT) Message-ID: <4E67A19D.2070409@alcatel-lucent.com> Date: Wed, 07 Sep 2011 12:53:49 -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: Matthew Kaufman References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> In-Reply-To: <4E668FB3.9020601@skype.net> Content-Type: multipart/alternative; boundary="------------080906060506080300000004" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 16:52:03 -0000 This is a multi-part message in MIME format. --------------080906060506080300000004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Not that I disagree with any single thing that Matthew said in his detailed respond, which I very much appreciate, but 1) I don't see why any other protocol will be easier to change a priori in order to meet the "innovation" requirements (I use quotes because I believe we need to see actual requirements before deciding that any protocol needs to change) 2) I believe we must address compatibility. For instance, with so much investment in by mobile operators in SIP-based IMS, the wireless handsets need to support it. There are two approaches: One, which Justin just mentioned is to rely on WebSocket (this is actually what I wrote about a while ago); the second is to put a core SIP skeleton in the browser so that the actual headers can be completed by an application. I think that we ought to investigate both (in my opinion, the second one will make life easier for developers). I wonder if we can agree on a requirement that the browser must have sufficient set of capabilities to support development of SIP in the application. Ultimately, this is what I want to ensure. Igor On 9/6/2011 5:25 PM, Matthew Kaufman wrote: > On 9/6/11 6:13 AM, Igor Faynberg wrote: >> I find this reasoning hard to understand. First, the SIP standard >> has been around for a decade. What new standardization is needed? > > The issue is whenever you wish to innovate and add functionality. > > See the long, long list of RFCs that extend SIP. For some examples: > RFC3515 - Refer method > RFC3842 - Message waiting > RFC3891 - Replaces header > RFC3911 - Join header > RFC3960 - Early media > RFC4411 - Reason header for preemption > > Never mind all the things that aren't even finished... > > draft-ietf-bliss-shared-appearances > draft-ietf-bliss-call-park-extension > > true bridged line appearances > > etc > > etc > > If all you want is a basic point-to-point phone, there's a short list > of RFCs you implement and you're done. But that isn't a platform for > innovation... it is just a phone. > > Matthew Kaufman > --------------080906060506080300000004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Not that I disagree with any single thing that  Matthew said in his detailed respond, which I very much appreciate, but

1) I don't see why any other protocol will be easier to change a priori in order to meet the "innovation" requirements (I use quotes because I believe we need to see actual requirements before deciding that any protocol needs to change)

2) I believe we must address compatibility. For instance, with so much investment in by mobile operators in SIP-based IMS, the wireless handsets need to support it.

There are two approaches:  One, which Justin just mentioned is to rely on WebSocket (this is actually what I wrote about a while ago);  the second is to put a core SIP skeleton in the browser so that the actual headers can be completed by an application.

I think that we ought to investigate both (in my opinion, the second one will make life easier for developers).

I wonder if we can agree on a requirement that the browser must have sufficient set of capabilities to support development of SIP in the application.  Ultimately, this is what I want to ensure.

Igor



On 9/6/2011 5:25 PM, Matthew Kaufman wrote:
On 9/6/11 6:13 AM, Igor Faynberg wrote:
I find this reasoning hard to understand.  First, the SIP standard has been around for a decade. What new standardization is needed?

The issue is whenever you wish to innovate and add functionality.

See the long, long list of RFCs that extend SIP. For some examples:
RFC3515 - Refer method
RFC3842 - Message waiting
RFC3891 - Replaces header
RFC3911 - Join header
RFC3960 - Early media
RFC4411 - Reason header for preemption

Never mind all the things that aren't even finished...

draft-ietf-bliss-shared-appearances
draft-ietf-bliss-call-park-extension

true bridged line appearances

etc

etc

If all you want is a basic point-to-point phone, there's a short list of RFCs you implement and you're done. But that isn't a platform for innovation... it is just a phone.

Matthew Kaufman

--------------080906060506080300000004-- From igor.faynberg@alcatel-lucent.com Wed Sep 7 09:56: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 C5E7B21F8C49 for ; Wed, 7 Sep 2011 09:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 MaVNcvEb40ui for ; Wed, 7 Sep 2011 09:56:35 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3614121F8AFB for ; Wed, 7 Sep 2011 09:56:35 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p87GwOPA016767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Sep 2011 11:58:24 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p87GwOFP009775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Sep 2011 11:58:24 -0500 Received: from [135.222.134.166] (USMUYN0L055118.mh.lucent.com [135.222.134.166]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p87GwNRp012954; Wed, 7 Sep 2011 11:58:23 -0500 (CDT) Message-ID: <4E67A2AF.4090008@alcatel-lucent.com> Date: Wed, 07 Sep 2011 12:58:23 -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: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 16:56:35 -0000 On 9/7/2011 3:07 AM, Olle E. Johansson wrote: > ...I am beginning to think the logic for signalling to set up rendevouz points and manage sessions has to move "somewhere else" where we can implement SIP, XMPP or some other protocol that fulfills the need of our respective application. Yes, as long as the browser will support moving this logic somewhere else. > ...To fearlessly jump into another can of worms, I still think we should have confidentiality - SRTP - by default... Eric had many interesting things to say about this. I definitely think we ought to explore this point. Igor From pravindran@sonusnet.com Wed Sep 7 10:27: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 0DDFB21F8BD8 for ; Wed, 7 Sep 2011 10:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.101, 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 3Wyp9f5-pCKe for ; Wed, 7 Sep 2011 10:27:49 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 32BDC21F8B70 for ; Wed, 7 Sep 2011 10:27:49 -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 p87HU41h011811; Wed, 7 Sep 2011 13:30:04 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Sep 2011 13:29:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6D83.AA13C87E" Date: Wed, 7 Sep 2011 22:59:14 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> In-Reply-To: <4E668FB3.9020601@skype.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] Thread-Index: Acxs23hg/0/Jv1DpTUqND6bBZLCykAAkE8Cg References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> From: "Ravindran Parthasarathi" To: "Matthew Kaufman" , X-OriginalArrivalTime: 07 Sep 2011 17:29:17.0662 (UTC) FILETIME=[ABC157E0:01CC6D83] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 17:27:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6D83.AA13C87E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Matthew, =20 When I asked for SIP, I have meant RFC 3261 only. The basic reason for asking SIP is to make the basic call works between browser to browser across web servers. Without SIP in browser, it is not going happen. Innovative application is going to be proprietary whether it is HTTP or SIP or any other protocol for that matter. =20 My reasoning are as follows: 1) SIP makes browser more intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG.=20 2) The importance of basic call interop is that there is no need of many individual id like skype id, Google id and yahoo id by everyone in the world to communicate others. I wish to have single id like e-mail id to be maintained by browser-to-browser users to communicate with others. 3) SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provider. 4) There is no need to build two different signaling logic in VoIP servers for each service. Your own example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible to avoided by having one signaling protocol. =20 In RTCWEB does not standardize the signaling protocol interface between browsers, the interop across webservers is next to impossible and it will be restricted to single webserver (company) only. Please let me know in case I'm missing something here. =20 Thanks Partha =20 From: Matthew Kaufman [mailto:matthew.kaufman@skype.net]=20 Sent: Wednesday, September 07, 2011 2:55 AM To: igor.faynberg@alcatel-lucent.com Cc: Ravindran Parthasarathi; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] =20 On 9/6/11 6:13 AM, Igor Faynberg wrote:=20 I find this reasoning hard to understand. First, the SIP standard has been around for a decade. What new standardization is needed? The issue is whenever you wish to innovate and add functionality. See the long, long list of RFCs that extend SIP. For some examples: RFC3515 - Refer method RFC3842 - Message waiting RFC3891 - Replaces header RFC3911 - Join header RFC3960 - Early media RFC4411 - Reason header for preemption Never mind all the things that aren't even finished... draft-ietf-bliss-shared-appearances draft-ietf-bliss-call-park-extension true bridged line appearances etc etc If all you want is a basic point-to-point phone, there's a short list of RFCs you implement and you're done. But that isn't a platform for innovation... it is just a phone. Matthew Kaufman ------_=_NextPart_001_01CC6D83.AA13C87E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Matthew,

 

When I asked for SIP, I have meant RFC 3261 only. The = basic reason for asking SIP is to make the basic call works between browser to browser across web servers. Without SIP in browser, it is not going = happen. Innovative application is going to be proprietary whether it is HTTP or SIP or any = other protocol for that matter.

 

My reasoning are as follows:

1)      SIP makes browser more intelligence compare to dump = signaling mechanism like MEGACO and browser acts as MG.

2)      The importance of basic call interop is that there is no = need of many individual id like skype id, Google id  and yahoo id by = everyone in the world to communicate others. I wish to have single id like e-mail id = to be maintained by browser-to-browser users to communicate with others. =

3)      SIP helps to interop for basic call with other existing = realtime application in Enterprise & Telecom provider.

4)      There is no need to build two different signaling logic = in VoIP servers for each service. Your own example of Bridge line appearance = will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation = is depend on HTTP metadata. It is possible to avoided by having one signaling = protocol.

 

In RTCWEB does not standardize the signaling protocol = interface between browsers, the interop across webservers is next to impossible = and it will be restricted to single webserver (company) only. Please let  = me know in case I’m missing something here.

 

Thanks

Partha

 

From: Matthew Kaufman [mailto:matthew.kaufman@skype.net]
Sent: Wednesday, September 07, 2011 2:55 AM
To: igor.faynberg@alcatel-lucent.com
Cc: Ravindran Parthasarathi; rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remote recording - RTC-Web client acting as SIPREC session recording = client]

 

On 9/6/11 6:13 AM, Igor Faynberg wrote: =

I find this reasoning hard to understand.  = First, the SIP standard has been around for a decade. What new standardization is = needed?


The issue is whenever you wish to innovate and add functionality.

See the long, long list of RFCs that extend SIP. For some examples:
RFC3515 - Refer method
RFC3842 - Message waiting
RFC3891 - Replaces header
RFC3911 - Join header
RFC3960 - Early media
RFC4411 - Reason header for preemption

Never mind all the things that aren't even finished...

draft-ietf-bliss-shared-appearances
draft-ietf-bliss-call-park-extension

true bridged line appearances

etc

etc

If all you want is a basic point-to-point phone, there's a short list of = RFCs you implement and you're done. But that isn't a platform for = innovation... it is just a phone.

Matthew Kaufman

------_=_NextPart_001_01CC6D83.AA13C87E-- From harald@alvestrand.no Wed Sep 7 10:41: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 3283A21F8C95 for ; Wed, 7 Sep 2011 10:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.776 X-Spam-Level: X-Spam-Status: No, score=-107.776 tagged_above=-999 required=5 tests=[AWL=2.822, 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 RdgOOcfZEdf7 for ; Wed, 7 Sep 2011 10:41:37 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5F12A21F8C93 for ; Wed, 7 Sep 2011 10:41:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D88A839E112; Wed, 7 Sep 2011 19:43:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k83rRXCyu0Qb; Wed, 7 Sep 2011 19:43:25 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 86D5539E072; Wed, 7 Sep 2011 19:43:25 +0200 (CEST) Message-ID: <4E67AD3D.9000005@alvestrand.no> Date: Wed, 07 Sep 2011 19:43:25 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> Content-Type: multipart/alternative; boundary="------------080305010903000801030803" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 17:41:39 -0000 This is a multi-part message in MIME format. --------------080305010903000801030803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/07/11 19:29, Ravindran Parthasarathi wrote: > > Matthew, > > When I asked for SIP, I have meant RFC 3261 only. > This is 269 pages, and has 26 normative dependencies including S/MIME. It's not a small dependency. > > The basic reason for asking SIP is to make the basic call works > between browser to browser across web servers. Without SIP in browser, > it is not going happen. Innovative application is going to be > proprietary whether it is HTTP or SIP or any other protocol for that > matter. > > My reasoning are as follows: > > 1)SIP makes browser more intelligence compare to dump signaling > mechanism like MEGACO and browser acts as MG. > Why does that "intelligence" need to be in the browser, rather than in the Javascript? > > 2)The importance of basic call interop is that there is no need of > many individual id like skype id, Google id and yahoo id by everyone > in the world to communicate others. I wish to have single id like > e-mail id to be maintained by browser-to-browser users to communicate > with others. > This only makes sense for applications that fit the "call an identified party" paradigm. > > 3)SIP helps to interop for basic call with other existing realtime > application in Enterprise & Telecom provider. > > 4)There is no need to build two different signaling logic in VoIP > servers for each service. Your own example of Bridge line appearance > will need two implementation by the single vendor because desktop > application or hardphone implementation based on SIP and browser based > implementation is depend on HTTP metadata. It is possible to avoided > by having one signaling protocol. > One protocol can be achieved by multiple applications choosing to implement one protocol. It doesn't have to be enforced by the prtoocol being embedded in the browser. > > In RTCWEB does not standardize the signaling protocol interface > between browsers, the interop across webservers is next to impossible > and it will be restricted to single webserver (company) only. Please > let me know in case I?m missing something here. > I think the main thing you are missing is that there are many applications that people want to build on top of RTCWEB that are not telephones, and will not fit with telephone-based paradigms. --------------080305010903000801030803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On 09/07/11 19:29, Ravindran Parthasarathi wrote:

Matthew,

When I asked for SIP, I have meant RFC 3261 only.

This is 269 pages, and has 26 normative dependencies including S/MIME. It's not a small dependency.

The basic reason for asking SIP is to make the basic call works between browser to browser across web servers. Without SIP in browser, it is not going happen. Innovative application is going to be proprietary whether it is HTTP or SIP or any other protocol for that matter.

My reasoning are as follows:

1) SIP makes browser more intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG.

Why does that "intelligence" need to be in the browser, rather than in the Javascript?

2) The importance of basic call interop is that there is no need of many individual id like skype id, Google id and yahoo id by everyone in the world to communicate others. I wish to have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.

This only makes sense for applications that fit the "call an identified party" paradigm.

3) SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provider.

4) There is no need to build two different signaling logic in VoIP servers for each service. Your own example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible to avoided by having one signaling protocol.

One protocol can be achieved by multiple applications choosing to implement one protocol.
It doesn't have to be enforced by the prtoocol being embedded in the browser.

In RTCWEB does not standardize the signaling protocol interface between browsers, the interop across webservers is next to impossible and it will be restricted to single webserver (company) only. Please let me know in case I’m missing something here.


I think the main thing you are missing is that there are many applications that people want to build on top of RTCWEB that are not telephones, and will not fit with telephone-based paradigms.

--------------080305010903000801030803-- From Markus.Isomaki@nokia.com Wed Sep 7 10:56: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 D863021F8AD2 for ; Wed, 7 Sep 2011 10:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13l4CB3qx6JH for ; Wed, 7 Sep 2011 10:56:32 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 203F221F8582 for ; Wed, 7 Sep 2011 10:56:23 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p87HvT1D018712; Wed, 7 Sep 2011 20:58:10 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Sep 2011 20:57:24 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 7 Sep 2011 19:57:23 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.204]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0323.007; Wed, 7 Sep 2011 19:57:17 +0200 From: To: , , Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] Thread-Index: AQHMbYPDJYJLPpTTvE+7wKEj7j+fd5VCLpSA Date: Wed, 7 Sep 2011 17:57:16 +0000 Message-ID: References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> 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: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB7620AA9D6008AM1MPN1043mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 Sep 2011 17:57:24.0586 (UTC) FILETIME=[993D84A0:01CC6D87] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 17:56:36 -0000 --_000_E44893DD4E290745BB608EB23FDDB7620AA9D6008AM1MPN1043mgdn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The "web servers" in different domains could implement SIP and gateway call= s from one domain to another that way. I think it is a reasonable assumptio= n that basic voice calls (and maybe video) could interoperate between domai= ns in this way without requiring SIP in the browser. I mostly agree with Matthew's statements in this thread. I believe it is po= ssible for an application developer to implement "call setup" (the "signali= ng") already in today's browsers, and Websockets is going to make that even= a bit more efficient regardless of RTCWeb. So the RTCWeb should not focus = on that aspect, but the missing part, which is the real-time media transpor= t between browsers. It is not a totally crazy idea to have SIP in the browser, though. It could= be useful in many scenarios, like interacting with existing PBX or IMS inf= ra, while adding some cool web based stuff in the app on the side. But in t= he interest of making progress in the more critical parts, I would postpone= that standardization effort into the second phase of RTCWeb. Or maybe a ne= w WG like SIPWeb :) This is of course based on the na=EFve assumption that = the first phase of RTCWeb will not do anything that would prevent browsers = to support SIP later on. Markus From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= ext Ravindran Parthasarathi Sent: 07 September, 2011 20:29 To: Matthew Kaufman; igor.faynberg@alcatel-lucent.com Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recor= ding - RTC-Web client acting as SIPREC session recording client] Matthew, When I asked for SIP, I have meant RFC 3261 only. The basic reason for aski= ng SIP is to make the basic call works between browser to browser across we= b servers. Without SIP in browser, it is not going happen. Innovative appli= cation is going to be proprietary whether it is HTTP or SIP or any other pr= otocol for that matter. My reasoning are as follows: 1) SIP makes browser more intelligence compare to dump signaling mecha= nism like MEGACO and browser acts as MG. 2) The importance of basic call interop is that there is no need of ma= ny individual id like skype id, Google id and yahoo id by everyone in the = world to communicate others. I wish to have single id like e-mail id to be = maintained by browser-to-browser users to communicate with others. 3) SIP helps to interop for basic call with other existing realtime ap= plication in Enterprise & Telecom provider. 4) There is no need to build two different signaling logic in VoIP ser= vers for each service. Your own example of Bridge line appearance will need= two implementation by the single vendor because desktop application or har= dphone implementation based on SIP and browser based implementation is depe= nd on HTTP metadata. It is possible to avoided by having one signaling prot= ocol. In RTCWEB does not standardize the signaling protocol interface between bro= wsers, the interop across webservers is next to impossible and it will be r= estricted to single webserver (company) only. Please let me know in case I= 'm missing something here. Thanks Partha From: Matthew Kaufman [mailto:matthew.kaufman@skype.net] Sent: Wednesday, September 07, 2011 2:55 AM To: igor.faynberg@alcatel-lucent.com Cc: Ravindran Parthasarathi; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recor= ding - RTC-Web client acting as SIPREC session recording client] On 9/6/11 6:13 AM, Igor Faynberg wrote: I find this reasoning hard to understand. First, the SIP standard has been= around for a decade. What new standardization is needed? The issue is whenever you wish to innovate and add functionality. See the long, long list of RFCs that extend SIP. For some examples: RFC3515 - Refer method RFC3842 - Message waiting RFC3891 - Replaces header RFC3911 - Join header RFC3960 - Early media RFC4411 - Reason header for preemption Never mind all the things that aren't even finished... draft-ietf-bliss-shared-appearances draft-ietf-bliss-call-park-extension true bridged line appearances etc etc If all you want is a basic point-to-point phone, there's a short list of RF= Cs you implement and you're done. But that isn't a platform for innovation.= .. it is just a phone. Matthew Kaufman --_000_E44893DD4E290745BB608EB23FDDB7620AA9D6008AM1MPN1043mgdn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

The “web servers= 221; in different domains could implement SIP and gateway calls from one do= main to another that way. I think it is a reasonable assumption that basic voice calls (and maybe video) could interoperate between domains in = this way without requiring SIP in the browser.

 <= /p>

I mostly agree with Matth= ew’s statements in this thread. I believe it is possible for an appli= cation developer to implement “call setup” (the “signalin= g”) already in today’s browsers, and Websockets is going to make that even a bit= more efficient regardless of RTCWeb. So the RTCWeb should not focus on tha= t aspect, but the missing part, which is the real-time media transport betw= een browsers.

 <= /p>

It is not a totally crazy= idea to have SIP in the browser, though. It could be useful in many scenar= ios, like interacting with existing PBX or IMS infra, while adding some cool web based stuff in the app on the side. But in the intere= st of making progress in the more critical parts, I would postpone that sta= ndardization effort into the second phase of RTCWeb. Or maybe a new WG like= SIPWeb J This is of course based on the na=EFve= assumption that the first phase of RTCWeb will not do anything that would prevent browsers to support SIP later on.

 <= /p>

Markus<= /p>

 <= /p>

 <= /p>

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ie= tf.org] On Behalf Of ext Ravindran Parthasarathi
Sent: 07 September, 2011 20:29
To: Matthew Kaufman; igor.faynberg@alcatel-lucent.com
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remot= e recording - RTC-Web client acting as SIPREC session recording client]

 

Matthew,

 <= /p>

When I asked for SIP, I h= ave meant RFC 3261 only. The basic reason for asking SIP is to make the bas= ic call works between browser to browser across web servers. Without SIP in browser, it is not going happen. Innovative application is = going to be proprietary whether it is HTTP or SIP or any other protocol for= that matter.

 <= /p>

My reasoning are as follo= ws:

1)&nbs= p;     SIP makes browser= more intelligence compare to dump signaling mechanism like MEGACO and brow= ser acts as MG.

2)&nbs= p;     The importance of= basic call interop is that there is no need of many individual id like sky= pe id, Google id  and yahoo id by everyone in the world to communicate others. I wish to have single id like e-mail id to be maint= ained by browser-to-browser users to communicate with others.

3)&nbs= p;     SIP helps to inte= rop for basic call with other existing realtime application in Enterprise &= amp; Telecom provider.

4)&nbs= p;     There is no need = to build two different signaling logic in VoIP servers for each service. Yo= ur own example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardpho= ne implementation based on SIP and browser based implementation is depend o= n HTTP metadata. It is possible to avoided by having one signaling protocol= .

 <= /span>

In RTCWEB does not standa= rdize the signaling protocol interface between browsers, the interop across= webservers is next to impossible and it will be restricted to single webserver (company) only. Please let  me know in case IR= 17;m missing something here.

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

From: Matthew Kaufman [mailto:matthew.kaufman@skype.net= ]
Sent: Wednesday, September 07, 2011 2:55 AM
To: igor.faynberg@alcatel-lucent.com
Cc: Ravindran Parthasarathi; rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remot= e recording - RTC-Web client acting as SIPREC session recording client]

 

On 9/6/11 6:13 AM, Igor Faynberg wrote: <= /p>

I find this reasoning hard to understand.  Firs= t, the SIP standard has been around for a decade. What new standardization = is needed?


The issue is whenever you wish to innovate and add functionality.

See the long, long list of RFCs that extend SIP. For some examples:
RFC3515 - Refer method
RFC3842 - Message waiting
RFC3891 - Replaces header
RFC3911 - Join header
RFC3960 - Early media
RFC4411 - Reason header for preemption

Never mind all the things that aren't even finished...

draft-ietf-bliss-shared-appearances
draft-ietf-bliss-call-park-extension

true bridged line appearances

etc

etc

If all you want is a basic point-to-point phone, there's a short list of RF= Cs you implement and you're done. But that isn't a platform for innovation.= .. it is just a phone.

Matthew Kaufman

--_000_E44893DD4E290745BB608EB23FDDB7620AA9D6008AM1MPN1043mgdn_-- From mary.ietf.barnes@gmail.com Wed Sep 7 11: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 0757321F8D04 for ; Wed, 7 Sep 2011 11:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.502 X-Spam-Level: X-Spam-Status: No, score=-101.502 tagged_above=-999 required=5 tests=[AWL=-1.870, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_ONLINE=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAb--EZt4AVy for ; Wed, 7 Sep 2011 11:22:12 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED2ED21F8CF5 for ; Wed, 7 Sep 2011 11:22:11 -0700 (PDT) Received: by vxi29 with SMTP id 29so1146671vxi.31 for ; Wed, 07 Sep 2011 11:24:01 -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=wFMtRpM9BJTaY2E0nC8ICjfC+BMjY+KnsgXV5NQMuuY=; b=gHFsJAFFFPQGGfPVGjjnQLb9M3SNAn1OF5cffPVQdN5/5jnQGB8qYzhbfl2iNkPdyW 6rGnyuI52m2coc0KflBUpZa3QmDmZJdRxoC7/v3avEYk/cTssC9CyTugg+B7NPp0srNp T7fqiW0aX29AouVsDjYauaZ/RBkl4QBZliqtc= MIME-Version: 1.0 Received: by 10.52.184.168 with SMTP id ev8mr4136789vdc.291.1315419841641; Wed, 07 Sep 2011 11:24:01 -0700 (PDT) Received: by 10.52.35.2 with HTTP; Wed, 7 Sep 2011 11:24:01 -0700 (PDT) In-Reply-To: <4E678B44.9080208@alum.mit.edu> References: <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> <4E666785.7040409@skype.net> <4E67513C.3030600@alvestrand.no> <4E677CB8.40203@skype.net> <4E678B44.9080208@alum.mit.edu> Date: Wed, 7 Sep 2011 13:24:01 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=bcaec547ca4b643e5604ac5e0c16 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 18:22:13 -0000 --bcaec547ca4b643e5604ac5e0c16 Content-Type: text/plain; charset=ISO-8859-1 Just one comment below [MB]. Mary. On Wed, Sep 7, 2011 at 10:18 AM, Paul Kyzivat wrote: > Matthew, > > Good summary. > > I agree that webrtc provides flexibility in how to implement the UI > portions of these features with generic webrtc clients. But it doesn't make > these features trivial to implement. In particular, the bridged line > appearance still requires that a conference be established. With generic > rtcweb clients, that probably means a central mixer. Setting that up is > relatively easy if there is a central media termination point in rtcweb > server, and it *has* mixer capabilities. > > My point is not that rtcweb doesn't help with this case - just that these > features that are so trivial in analog telephony just aren't so simple with > voip, no matter how you do it. > [MB] These features we not trivial in analog telephony by any means (speaking as someone who wrote LOTS of code for these ancient telephony systems). IMHO, it's this misconception that the services and functionality in analog telephony systems was simple that's led to the difficulty in getting any operability for these services defined for SIP. Many of the legacy telephone systems were no more designed for a host of complex services than SIP was. However, it would have been nice if services had been considered in the initial design for SIP. While there is the concept that many services can be accomplished with basic SIP building blocks/headers, we have way too many situations where this has proven to not be at all simple. But, I don't think SIP/VoIP is any worse off than were the legacy systems. And, I agree with Paul there isn't any magic dust that will make it any easier for RTCWEB to support these features. [/MB] > > Thanks, > Paul > > > On 9/7/11 10:16 AM, Matthew Kaufman wrote: > >> On 9/7/2011 4:10 AM, Harald Alvestrand wrote: >> >>> >>> Since more people than I may be confused, I'm forking a subthread... >>> >>> what is a bridged line appearance, and why is it hard to do in SIP? >>> >>> My terminology cache is totally blank. >>> >>> >> Key system (and home phone) emulation requires two things that are hard >> to do (because there's no final specification, not because it is >> impossible) (and because there's 3+ alternatives, and almost no phones >> implement more than one of them) in SIP: >> >> 1. Shared line appearance >> >> This is where you can be on a call on one handset, see that the line is >> in use at the other handset. Place the call on hold at the first, pick >> it up at the second. >> >> In business PBX cases, this is used for executive/assistant cases. In >> key system emulation it is used for "Bob, pick up the call holding on >> line 3". And for home phones it is the usual "put the phone on hold in >> the kitchen, pick it up in the den." (My wife wanted this functionality, >> so I had to add proprietary support for shared line appearance on my >> home PBX.) >> >> 2. Bridged line appearance >> >> This is where you can be on a call on one handset, see that line is in >> use at the other handset, and pick up the second handset to join the call. >> >> In the business PBX and key system case this is sometimes used for >> supervisors to join a call to help, but the real common case is the home >> phones... "kids, go pick up the extension in the living room and talk to >> grandma." >> >> With POTS, this works by simply paralleling two handsets on the same >> copper pair. For SIP it requires everything shared line appearance does >> *plus* automatic barge-in + conference on pickup. >> >> The BLISS WG has been working, for a long time, on taking the various >> interim proposals and creating a standard out of them, but we're still >> not there... and yet without it, there's no way to use phones from two >> different vendors to accomplish this. >> >> Whereas with WebRTC implemented *without SIP*, it is fairly easy to >> build a web app that runs on multiple browsers from multiple vendors and >> implements this. >> >> So this type of ability to innovate and implement applications without >> going through the standards process is why we *definitely* don't want >> SIP baked in to the browser. >> >> Not to be confused with the arguments against SDP offer/answer, which is >> only slightly affected by the above use cases (in that you can do >> smarter things at the bridge for bridged line appearance if you aren't >> doing a reinvite/re-offer/re-answer but instead have on hand all the >> capabilities of the first device when the second goes to join). >> >> Matthew Kaufman >> ______________________________**_________________ >> 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 > --bcaec547ca4b643e5604ac5e0c16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just one comment below [MB].

Mary.

On Wed, Sep 7, 2011 at 10:18 AM, Paul Kyzivat <pkyzivat@alum.mit.edu>= ; wrote:
Matthew,

Good summary.

I agree that webrtc provides flexibility in how to implement the UI portion= s of these features with generic webrtc clients. But it doesn't make th= ese features trivial to implement. In particular, the bridged line appearan= ce still requires that a conference be established. With generic rtcweb cli= ents, that probably means a central mixer. Setting that up is relatively ea= sy if there is a central media termination point in rtcweb server, and it *= has* mixer capabilities.

My point is not that rtcweb doesn't help with this case - just that the= se features that are so trivial in analog telephony just aren't so simp= le with voip, no matter how you do it.
[MB] These feat= ures we not trivial in analog telephony by any means (speaking as someone w= ho wrote LOTS of code for these ancient telephony systems). =A0IMHO, it'= ;s this misconception that the services and functionality in analog telepho= ny systems was simple that's led to the difficulty in getting any opera= bility for these services defined for SIP. =A0Many of the legacy telephone = systems were no more designed for a host of complex services than SIP was. = =A0However, it would have been nice if services had been considered in the = initial design for SIP. =A0While there is the concept that many services ca= n be accomplished with basic SIP building blocks/headers, we have way too m= any situations where this has proven to not be at all simple. =A0But, I don= 't think SIP/VoIP is any worse off than were the legacy systems. And, I= agree with Paul there isn't any magic dust that will make it any easie= r for RTCWEB to support these features. =A0[/MB]

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul


On 9/7/11 10:16 AM, Matthew Kaufman wrote:
On 9/7/2011 4:10 AM, Harald Alvestrand wrote:

Since more people than I may be confused, I'm forking a subthread...
what is a bridged line appearance, and why is it hard to do in SIP?

My terminology cache is totally blank.


Key system (and home phone) emulation requires two things that are hard
to do (because there's no final specification, not because it is
impossible) (and because there's 3+ alternatives, and almost no phones<= br> implement more than one of them) in SIP:

1. Shared line appearance

This is where you can be on a call on one handset, see that the line is
in use at the other handset. Place the call on hold at the first, pick
it up at the second.

In business PBX cases, this is used for executive/assistant cases. In
key system emulation it is used for "Bob, pick up the call holding on<= br> line 3". And for home phones it is the usual "put the phone on ho= ld in
the kitchen, pick it up in the den." (My wife wanted this functionalit= y,
so I had to add proprietary support for shared line appearance on my
home PBX.)

2. Bridged line appearance

This is where you can be on a call on one handset, see that line is in
use at the other handset, and pick up the second handset to join the call.<= br>
In the business PBX and key system case this is sometimes used for
supervisors to join a call to help, but the real common case is the home phones... "kids, go pick up the extension in the living room and talk = to
grandma."

With POTS, this works by simply paralleling two handsets on the same
copper pair. For SIP it requires everything shared line appearance does
*plus* automatic barge-in + conference on pickup.

The BLISS WG has been working, for a long time, on taking the various
interim proposals and creating a standard out of them, but we're still<= br> not there... and yet without it, there's no way to use phones from two<= br> different vendors to accomplish this.

Whereas with WebRTC implemented *without SIP*, it is fairly easy to
build a web app that runs on multiple browsers from multiple vendors and implements this.

So this type of ability to innovate and implement applications without
going through the standards process is why we *definitely* don't want SIP baked in to the browser.

Not to be confused with the arguments against SDP offer/answer, which is only slightly affected by the above use cases (in that you can do
smarter things at the bridge for bridged line appearance if you aren't<= br> doing a reinvite/re-offer/re-answer but instead have on hand all the
capabilities of the first device when the second goes to join).

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

--bcaec547ca4b643e5604ac5e0c16-- From randell-ietf@jesup.org Wed Sep 7 12:21: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 21C3521F8B16 for ; Wed, 7 Sep 2011 12:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 NXSMc1Rc7G9B for ; Wed, 7 Sep 2011 12:21:19 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9D01121F8B13 for ; Wed, 7 Sep 2011 12:21:17 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R1NiF-0007OT-La for rtcweb@ietf.org; Wed, 07 Sep 2011 14:23:07 -0500 Message-ID: <4E67C3EE.50707@jesup.org> Date: Wed, 07 Sep 2011 15:20:14 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.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] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 19:21:20 -0000 On 9/7/2011 3:07 AM, Olle E. Johansson wrote: > 6 sep 2011 kl. 21:24 skrev Asveren, Tolga: > >> What about semantics (adding just a X-header won't help there) or how much SIP would be left anyhow if all semantical control is exposed through the API? >> >> I think bridged line appearance is a good test to run against different models. >> > Well, I tried to stay neutral but examples likes this makes me not want SIP in the browser. DTMF, Early Media, bridge line apperances and other PSTN legacy will make the implementation too focused on classical telephony and we'll spend too much time implementing features that are application specific and we can implement in controlling applications, client or server-side. > > Cullen tried to make a draft with "limited" SIP (maybe "SIP Lite") but it will be hard to protect that from the myriad of extensions that add PSTN functionality that's not really needed to set up multimedia calls between two browser users. It may be needed for gatewaying to legacy systems, but if we don't "stop Olle in the gate" - verbatim translation of a Swedish saying that propably doesn't mean much to most people on the list - I think we will never be done. > > Of course, being a SIP developer, I started off with thinking that SIP in the browser was the default route. I am beginning to understand that the browser is the user interface part we all need, the media handler. We all have different requirements on how to control that media GUI and to get anywhere I am beginning to think the logic for signalling to set up rendevouz points and manage sessions has to move "somewhere else" where we can implement SIP, XMPP or some other protocol that fulfills the need of our respective application. I also started from the same point - assume SIP. SIP gives you all the things that the zillions of hours and emails to define it and define extensions and secure it provides, without having to reinvent all those wheels (or ask app developers to reinvent them). Why go through the horrible pain of choosing something else, or why throw the app developers to the wolves to fend for themselves? However... Two things have swayed me. The primary one is the suggestion of Offer/Answer in the browser. This breaks out the important negotiation piece that almost any application would need, and while not perfect, SDP O/A is a zillion times simpler than SIP with all the extensions one could use. The other thing that swayed me was thinking about federation and the apps that will be built with this. A webrtc app talks to its (web)server, other webrtc clients running the app that talk to the server, and to other webrtc applications/networks that federate with it (and their clients). Federation is in the same hands as the person who provides/wrote the app. If they have no interest in federation you can't force it, and they may have no use for all the fancy SIP standards. On the other hand, if they *want* to either provide access to the wider communication net that is the PSTN network, now or in the future, or they want easy federation with other networks, it behooves them to use SIP or something very close to it or equivalent/convertible (at a basic level at least) to it. So what conclusions do I draw from this? 1) O/A via SDP in the browser simplifies a lot of things (including handling new codecs, etc). It doesn't extremely limit an application, though we should think about how an application can interact with the fmtp/etc parameters used. 2) SIP as a *separate* item that can be cleanly and easily *added* to a webrtc app to handle the call setup/etc is a good idea. This means a webrtc app could use something else, or roll its own. Many would use SIP. This would require (limited) SIP to be available as part of webrtc in the browser - but as an option, not as a mandate. An application could use an extended SIP client via JS or other mechanism. Basic SIP would need to be in all webrtc implementations so the apps could rely on having the option. This would make building apps & services that can (optionally) call PSTN phones easy (very easy perhaps), while not limiting the ability of app developers to innovate. It also makes it easier to build servers to handle webrtc apps. -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Wed Sep 7 12:21: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 B849E21F8B4F for ; Wed, 7 Sep 2011 12:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 llPKC7H0uwAf for ; Wed, 7 Sep 2011 12:21: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 3032821F8B30 for ; Wed, 7 Sep 2011 12:21:26 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R1NiO-0007Rg-Mt for rtcweb@ietf.org; Wed, 07 Sep 2011 14:23:16 -0500 Message-ID: <4E67C3F7.7020304@jesup.org> Date: Wed, 07 Sep 2011 15:20:23 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.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: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 19:21:26 -0000 Splitting the two topics.... On 9/7/2011 3:07 AM, Olle E. Johansson wrote: > To fearlessly jump into another can of worms, I still think we should have confidentiality - SRTP - by default. We know that these applications will run on a myriad of devices on a myriad of networks and it will not work to let users have to decided whether or not they want confidentiality. If Skype did not have confidentiality by default, there would be articles every summer and xmas in the evening taboloids about how easy it is to listen in to your neighbours calls and that would have hurted Skype badly. > There is a strong argument for this. The strongest argument for the other side is you don't need a media gateway to talk to non-WebRTC endpoints, just a signalling gateway. This means less delay potentially (especially if the application provider has gateways only in one geographic location) and less expense for the server provider for a pretty common usecase (gateway to PSTN). The delay could be a significant issue. It was also brought up that some usecases for internal PBX/business use would not need/prefer forced encryption. As mentioned at the meeting, encrypting to the media gateway only gets you a modicum of privacy (though it might protect you from the "neighbor's wifi capture" case). You could make forced-encryption the default, and allow the application control over whether to allow it is turned off for specific cases, like a PSTN call, or under the server's control. Signalling is secure, so it could even use a direct optional downgrade from SAVP* to AVP* (i.e. similar to the best-effort-strp draft) It's a tough call - guaranteed (local) security is nice, but I worry about those relay cases like taiwan->USA media gateway->taiwan. Not a huge deal on signaling/call-setup, but media... -- Randell Jesup randell-ietf@jesup.org From oej@edvina.net Wed Sep 7 12:58: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 5827221F8CD0 for ; Wed, 7 Sep 2011 12:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 cVJ7zg7lpAeM for ; Wed, 7 Sep 2011 12:58:02 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBD021F8CCE for ; Wed, 7 Sep 2011 12:58:02 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id A6518754BCE4; Wed, 7 Sep 2011 19:59:46 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <4E67C3F7.7020304@jesup.org> Date: Wed, 7 Sep 2011 21:59:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8233FBBB-26CE-4822-81A4-65F86A4E8666@edvina.net> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 19:58:03 -0000 7 sep 2011 kl. 21:20 skrev Randell Jesup: > Splitting the two topics.... >=20 >=20 > On 9/7/2011 3:07 AM, Olle E. Johansson wrote: >=20 >> To fearlessly jump into another can of worms, I still think we = should have confidentiality - SRTP - by default. We know that these = applications will run on a myriad of devices on a myriad of networks and = it will not work to let users have to decided whether or not they want = confidentiality. If Skype did not have confidentiality by default, there = would be articles every summer and xmas in the evening taboloids about = how easy it is to listen in to your neighbours calls and that would have = hurted Skype badly. >>=20 >=20 > There is a strong argument for this. The strongest argument for the = other side is you don't need a media gateway to talk to non-WebRTC = endpoints, just a signalling gateway. This means less delay potentially = (especially if the application provider has gateways only in one = geographic location) and less expense for the server provider for a = pretty common usecase (gateway to PSTN). The delay could be a = significant issue. > It was also brought up that some usecases for internal PBX/business = use would not need/prefer forced encryption. As mentioned at the = meeting, encrypting to the media gateway only gets you a modicum of = privacy (though it might protect you from the "neighbor's wifi capture" = case). >=20 > You could make forced-encryption the default, and allow the = application control over whether to allow it is turned off for specific = cases, like a PSTN call, or under the server's control. =20 If that's the case, we have to force a UI directive that all browsers = adapt - like the green bar for EV certs - so the user is aware that = confidentiality is missing. I don't really see a reason why servers = would disable this. Weather or not they are media endpoints and if they = use encryption on the other session leg is propably out of scope. Our = history with the SIPS: uri has shown how hard it is to try to build a = secure architecture with middlemen involved.=20 > Signalling is secure, so it could even use a direct optional downgrade = from SAVP* to AVP* (i.e. similar to the best-effort-strp draft) How can you assert that signalling is secure? When, how? >=20 > It's a tough call - guaranteed (local) security is nice, but I worry = about those relay cases like taiwan->USA media gateway->taiwan. Not a = huge deal on signaling/call-setup, but media... I think that if we try to require secure media all the way through = servers and gateways, we are setting the bar way too high for rtcweb. If = we can handle the media that the browser handles in the local RTP = streams and force that to a secure level, we have reached a good = platform to continue to work with.=20 In order to be able to proceed with confidentiality as a requirement, we = have to discuss key exchange for the SRTP streams. I think there are at = least two ways forward - to remove it from signalling path and go for an = inband key exchange a la ZRTP or declare it out of scope for RTCweb and = let the various protocols handle key exchange in different ways. Its = going to be very hard for users to judge how secure an application is = regardless of solution. Can you explain the difference between SIP SDES = and ZRTP for your "normal" users? The security guy in me would of course = recommend in-band so that the intermediary servers never see my key. The = web guy says "oh yeah, but most of the calls will be between you and my = conference mixer or media gateway anyway, so what's the difference?" I also think that secure identites (a la RFC4474 for SIP) should also be = out of scope for RTCweb, but something we can continue to work with when = building the applications and protocols that use rtcweb as a media = handler. This is still an issue in SIP, XMPP and many other protocols = and something we really need for realtime communication. /O= From dzonatas@gmail.com Wed Sep 7 12:59: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 AB31421F8CE2 for ; Wed, 7 Sep 2011 12:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.066 X-Spam-Level: X-Spam-Status: No, score=-4.066 tagged_above=-999 required=5 tests=[AWL=-0.467, 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 AiRHKs9zSky8 for ; Wed, 7 Sep 2011 12:59:51 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B59E221F8CE0 for ; Wed, 7 Sep 2011 12:59:51 -0700 (PDT) Received: by yxj20 with SMTP id 20so19354yxj.31 for ; Wed, 07 Sep 2011 13:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xxjc8RCcPBcPH2ZVf1O3MSBSFqtb+WAoWFmnx8DVxKk=; b=BRHZDGrVzt81w7PL/sC41gnrtHPQEz/v/LOC21aTUxLQ3vtogIZv1nZoKteQdLTtDs f2GUdccesbA3fPByYskVmQWybNO8HOj1j96CvGqvFXVLRVDJkBySsQ1sBK9rcXPc0msA iXr2FwxuEKT+9Ba575+eHdhpr/VnG1ML31Nao= Received: by 10.42.97.4 with SMTP id l4mr2631097icn.221.1315425701566; Wed, 07 Sep 2011 13:01:41 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id el2sm1155333ibb.10.2011.09.07.13.01.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Sep 2011 13:01:40 -0700 (PDT) Message-ID: <4E67CE16.40403@gmail.com> Date: Wed, 07 Sep 2011 13:03:34 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> In-Reply-To: <4E67C3F7.7020304@jesup.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 19:59:52 -0000 On 09/07/2011 12:20 PM, Randell Jesup wrote: > Splitting the two topics.... > > > On 9/7/2011 3:07 AM, Olle E. Johansson wrote: > >> To fearlessly jump into another can of worms, I still think we >> should have confidentiality - SRTP - by default. We know that these >> applications will run on a myriad of devices on a myriad of networks >> and it will not work to let users have to decided whether or not they >> want confidentiality. If Skype did not have confidentiality by >> default, there would be articles every summer and xmas in the evening >> taboloids about how easy it is to listen in to your neighbours calls >> and that would have hurted Skype badly. >> > > There is a strong argument for this. The strongest argument for the > other side is you don't need a media gateway to talk to non-WebRTC > endpoints, just a signalling gateway. This means less delay > potentially (especially if the application provider has gateways only > in one geographic location) and less expense for the server provider > for a pretty common usecase (gateway to PSTN). The delay could be a > significant issue. > It was also brought up that some usecases for internal PBX/business > use would not need/prefer forced encryption. As mentioned at the > meeting, encrypting to the media gateway only gets you a modicum of > privacy (though it might protect you from the "neighbor's wifi > capture" case). > > You could make forced-encryption the default, and allow the > application control over whether to allow it is turned off for > specific cases, like a PSTN call, or under the server's control. > Signalling is secure, so it could even use a direct optional downgrade > from SAVP* to AVP* (i.e. similar to the best-effort-strp draft) > > It's a tough call - guaranteed (local) security is nice, but I worry > about those relay cases like taiwan->USA media gateway->taiwan. Not a > huge deal on signaling/call-setup, but media... > > Flip-side: contracts already force encryption, and that is one reason why people do not want contracts; they want open wi-fi so neighbors have no walls across net points. Developers fear those pitchforks when they could have used security other than contract-stated default. That messes up everybody elses units not on those contacts, so you are back to ICE or force each person back to single connection to trunk internet lines and stateful-hubs (i.e. rtcweb on the base phone, not the hand-set, with audio-whitespaces or the base phone unit acts as DSL-filter end-point.). -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From oej@edvina.net Wed Sep 7 13:08: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 DF81121F8CF8 for ; Wed, 7 Sep 2011 13:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOnTEA1Du6N5 for ; Wed, 7 Sep 2011 13:08:42 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id B0F8C21F84DD for ; Wed, 7 Sep 2011 13:08:41 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 72C08754BCE4; Wed, 7 Sep 2011 20:10:30 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_712D3B89-C5B4-4C71-94A9-DB6DF5C84481" From: "Olle E. Johansson" In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> Date: Wed, 7 Sep 2011 22:10:29 +0200 Message-Id: <4A8BC6BF-6D21-4F83-B5B7-AEAD2F377719@edvina.net> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> To: "Ravindran Parthasarathi" X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 20:08:43 -0000 --Apple-Mail=_712D3B89-C5B4-4C71-94A9-DB6DF5C84481 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 7 sep 2011 kl. 19:29 skrev Ravindran Parthasarathi: > Matthew, > =20 > When I asked for SIP, I have meant RFC 3261 only. The basic reason for = asking SIP is to make the basic call works between browser to browser = across web servers. Without SIP in browser, it is not going happen. = Innovative application is going to be proprietary whether it is HTTP or = SIP or any other protocol for that matter. > =20 > My reasoning are as follows: > 1) SIP makes browser more intelligence compare to dump signaling = mechanism like MEGACO and browser acts as MG. > 2) The importance of basic call interop is that there is no need = of many individual id like skype id, Google id and yahoo id by everyone = in the world to communicate others. I wish to have single id like e-mail = id to be maintained by browser-to-browser users to communicate with = others. > 3) SIP helps to interop for basic call with other existing = realtime application in Enterprise & Telecom provider. > 4) There is no need to build two different signaling logic in = VoIP servers for each service. Your own example of Bridge line = appearance will need two implementation by the single vendor because = desktop application or hardphone implementation based on SIP and browser = based implementation is depend on HTTP metadata. It is possible to = avoided by having one signaling protocol. > =20 > In RTCWEB does not standardize the signaling protocol interface = between browsers, the interop across webservers is next to impossible = and it will be restricted to single webserver (company) only. Please let = me know in case I=92m missing something here. Ravindran, I don't follow the logic here. If you have SIP in the browser, the web = server will only be involved when loading the web page. SIP will take = care of the rest. In order to explain my current view (which might change): Try to divide = a sip phone in two parts. One part handles the multimedia - codecs, = encryption, qos (RTCP). The other part handles sessions - setup, = teardown, transfers etc. The way I see it (which is my personal view, = not this lists) is that rtcweb is the media handler. We can build = various controlling applications on client and server side, using the = protocol we like - it could be SIP but also a range of other protocols, = including proprietary protocols. I do hope that SIP wins here of course. = I don't think we should fight another round of session management = protocol wars in rtcweb - but that opinion is based on the architecture = I described here. Getting what we need to be able to set up media sessions in a web = browser from applications like Asterisk is a great win. We have what we = need to handle the session management part :-) I hope this helps you to understand my view that SIP should not be part = of the rtcweb set of standards. It is not about whether SIP can be in = the browser or not, it's just about putting some sort of scope limit on = this IETF project. SIP can still be implemented - and will propably be - = in the browser. At my first SIPit in Stockholm many years ago, I tested = with someone who already at that time had a SIP client in the browser. Cheers, /O --Apple-Mail=_712D3B89-C5B4-4C71-94A9-DB6DF5C84481 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
7 sep 2011 kl. 19:29 skrev Ravindran = Parthasarathi:

 
When I = asked for SIP, I have meant RFC 3261 only. The basic reason for asking = SIP is to make the basic call works between browser to browser across = web servers. Without SIP in browser, it is not going happen. Innovative = application is going to be proprietary whether it is HTTP or SIP or any = other protocol for that matter.
My reasoning are as = follows:
1) SIP makes browser more intelligence compare to dump = signaling mechanism like MEGACO and browser acts as = MG.
2) The importance of basic call interop is that there = is no need of many individual id like skype id, Google id  and = yahoo id by everyone in the world to communicate others. I wish to have = single id like e-mail id to be maintained by browser-to-browser users to = communicate with others.
3) SIP helps to interop for basic call with other = existing realtime application in Enterprise & Telecom = provider.
4) There is no need to build two different signaling = logic in VoIP servers for each service. Your own example of Bridge line = appearance will need two implementation by the single vendor because = desktop application or hardphone implementation based on SIP and browser = based implementation is depend on HTTP metadata. It is possible to = avoided by having one signaling protocol.
In RTCWEB does not standardize the signaling = protocol interface between browsers, the interop across webservers is = next to impossible and it will be restricted to single webserver = (company) only. Please let  me know in case I=92m missing something = here.

Ravindran,
I don't follow the logic here. If you have SIP in = the browser, the web server will only be involved when loading the web = page. SIP will take care of the rest.

In order = to explain my current view (which might change): Try to divide a sip = phone in two parts. One part handles the multimedia - codecs, = encryption, qos (RTCP). The other part handles sessions - setup, = teardown, transfers etc. The way I see it (which is my personal view, = not this lists) is that rtcweb is the media handler. We can build = various controlling applications on client and server side, using the = protocol we like - it could be SIP but also a range of other protocols, = including proprietary protocols. I do hope that SIP wins here of course. = I don't think we should fight another round of session management = protocol wars in rtcweb - but that opinion is based on the architecture = I described here.

Getting what we need to be = able to set up media sessions in a web browser from applications like = Asterisk is a great win. We have what we need to handle the session = management part :-)

I hope this helps you to = understand my view that SIP should not be part of the rtcweb set of = standards. It is not about whether SIP can be in the browser or not, = it's just about putting some sort of scope limit on this IETF project. = SIP can still be implemented - and will propably be - in the browser. At = my first SIPit in Stockholm many years ago, I tested with someone who = already at that time had a SIP client in the = browser.

Cheers,
/O

= --Apple-Mail=_712D3B89-C5B4-4C71-94A9-DB6DF5C84481-- From henry.sinnreich@gmail.com Wed Sep 7 13:14: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 9EF4B21F8CF0 for ; Wed, 7 Sep 2011 13:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.129 X-Spam-Level: X-Spam-Status: No, score=-3.129 tagged_above=-999 required=5 tests=[AWL=0.470, 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 0lq7zGLPK9eO for ; Wed, 7 Sep 2011 13:14:29 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 6487B21F8AD9 for ; Wed, 7 Sep 2011 13:14:29 -0700 (PDT) Received: by gxk9 with SMTP id 9so218457gxk.40 for ; Wed, 07 Sep 2011 13:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=ZdUmTb1TYZ+3n11+5rBiknREvxvbj9ICcsh5alXKX+0=; b=ueGOFf4WyQ7QW/F7DqDYHyH3yclbYTThPreXbmY+yi9RHg/5mZ58EXCFfcPEz3LEpb eptEVpi1puAUzViU/dtEg7WT5GbHu4jLpg5kVWAMT3FiYEuvM+Gg94sLv+XXUqQivKrb 4t3yXjqhTiHEuP4HBiE6lPRpFyXdu86FsROYE= Received: by 10.236.136.234 with SMTP id w70mr17207965yhi.21.1315426579476; Wed, 07 Sep 2011 13:16:19 -0700 (PDT) Received: from [192.168.15.2] (cpe-76-184-224-113.tx.res.rr.com [76.184.224.113]) by mx.google.com with ESMTPS id x65sm1048083yhh.26.2011.09.07.13.16.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Sep 2011 13:16:18 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 07 Sep 2011 15:16:15 -0500 From: Henry Sinnreich To: Cullen Jennings , Matthew Kaufman Message-ID: Thread-Topic: [rtcweb] Use of offer / answer semantics Thread-Index: Acxtmv6NF25WY7BFsEiOFoT+Rst4ig== In-Reply-To: <2E243EBA-3A4C-420F-A1CF-B62374FFEF66@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 20:14:30 -0000 Cullen makes here some important points to keep in mind as another option, though I agree SIP to be the primary usage scenario. People implementing HIP (avoiding ICE) and some proprietary VM such a Flash or Silverlight (there will always be some that are years ahead of standards) may get much higher commercial quality products in much shorter time, that is at much lower development cost. Why can't such an option not even be allowed here? Thanks, Henry On 9/6/11 8:45 PM, "Cullen Jennings" wrote: > > sorry this is becoming too deep inline but, uh, inline ... > > > On Sep 6, 2011, at 9:20 AM, Matthew Kaufman wrote: > >> On 9/6/2011 7:46 AM, Cullen Jennings wrote: >>> In my roll as an individual contributor, I want to propose some text that I >>> think we can get rough consensus on around that helps specify which parts of >>> the signaling issues we agree on and which we don't. >>> >>> At the last meeting, my read of the the room was there was a fair amount of >>> agreement in the room that offer / answer semantics with SDP are what we >>> want to use. I don't think there was was broad agreement on if one should >>> use SIP or not, or for that matter jingle. If we can nail down this >>> decisions as the direction the WG is going, it will really help make >>> progress. What I would like to do is propose some following principles in >>> the text below. If we have agreement on these, then they would go into the >>> overview document and help guide the design of other documents. I want to >>> highlight that none of the principles below imply that we would need to use >>> SIP in the browsers - the principals would all work fine if we there was >>> signaling gateway in the web server that converged SIP to whatever >>> proprietary HTML / JS / HTTP that the applications wanted to use between >>> the browser and the web server. >>> >>> >>> >>> 1) The media negotiations will be done using the same SDP offer/answer >>> semantics that are used in SIP. >> >> I think this would be unfortunate. We have an opportunity here to not repeat >> this mistake. >> >> And *if* we go down this road, we need additional language around things like >> exposing the capabilities via an API that doesn't start the offer/answer >> process itself. (Use case: determine if a browser has an appropriate camera >> and encoder before suggesting that they call the customer service rep for a >> live chat.) > > So obviously I agree with that use case but two points here 1) I'm not > excluding other API being needed for extra information that is efficiently > local. I was only talking about the actual media negotiation so even if we do > media negotiation with SDP, one could still have separate API for all kinds of > things including mute my microphone that did not use SDP. 2) I think the one > way to get capabilities in JS is to ask for an SDP offer, and as soon as you > get it cancel the transaction and not cary on. That way you get the > capabilities and then stop. > >> >> >>> >>> 2) It will be possible to gateway between legacy SIP devices that support >>> ICE and appropriate RTP / SDP mechanisms and codecs without using a media >>> gateway. A signaling gateway to convert between the signaling on the web >>> side to the SIP signaling may be needed. >> >> Agree. >> >>> >>> 3) When a new codec is specified, and the SPD for the new codec is specified >>> in the MMUSIC WG, no other standardization would should be required for it >>> to be possible to use that in the web browsers. >> >> I would be ok with reusing the SDP parameter string as specified as a >> parameter to the API, but I don't think it should be a blob of SDP that >> combines both the codec parameters *and* the connection/ICE parameters, *and* >> I think that offer/answer is the wrong model. > > Not sure what you mean by SDP parameter string. If you mean just the > parameters for the given codec, then i view that as about 1% of SDP and would > not describe that as using SDP at all. For example, if you wanted to negotiate > FEC, that would not cover it. > >> >> However, see below... >> >>> Adding a new codecs which might have new SDP parameters should not change >>> the APIs between the browser and javascript application. As soon as the >>> browsers support the new codec, old applications written before the codecs >>> was specified should automatically be able to use the new codec where >>> appropriate with no changes to the JS applications. >> >> This is a good idea. But then where do all the parameters that *weren't* >> specified in the MMUSIC WG go? (Like "force Opus codec to music mode", or >> "change your motion estimation algorithm") > > Note that my writing of above was just wrong as Colin pointed out but to your > point ... I think this type of stuff goes in other hints in the API that try > and tell the browser what the application is trying to achieve. So I think it > is fine for JS to tell the browser assume the audio is spoken voice, or music > but I was not viewing this as something that was happening as part of the > media negotiation because there is no need to communicate from one browser to > the other browser. It is local not something negotiated over the signaling > protocol. > >> >>> >>> >>> People has looked at alternatives to all these in a fair amount of detail. >>> For example, we have considered alternatives to the SDP offer / answer such >>> as the advertisement proposal draft (draft-peterson-sipcore-advprop-01) and >>> discussed that several times in the WG. >> >> This is mixing up the API and the wire protocol. If people want to use SDP >> offer/answer between the browser and the web server, that's fine, but that >> doesn't mean we need to bake SDP offer/answer into the Javascript API. (And >> it certainly doesn't mean we need to mix up the layers, with connection >> properties in the SDP *and* encoder properties in the same SDP... done >> properly, these would go to/from different Javascript objects anyway.) > > I'm far less concerned about the syntax but I am discussing is the semantics > of what we need to be able to represent in the various information flows. What > I think when you think about this this way, I'm not mixing them up much. If > the JS API supported a superset of all the semantics information flow of > off/ans and adv/prop, then yes you can do both. If it does not, then you > can't. But an equally important flow is what happens on the signaling GW. We > have seen from the SIP SBC experience that you can't ignore this and wish it > away. We need to be sure what will map, and what won't map or we don't really > know we have a solution. > >> >> Likewise, advprop should be able to be supported as well... with a different >> set of Javascript talking to the same APIs. >> >>> The primary issues identified with this was concerns over mapping this to >>> legacy SDP. >> >> This makes the assumption that the primary use case will have things that >> speak only SDP offer/answer on the far side. I think that's a very IETF + SIP >> + legacy point of view, which is an unfortunate way to approach the future of >> communications as enabled by web applications. > > I'm not assuming anything about this being the primary use case. I'm assuming > it is an important use case. If it were not, we would do this totally > differently probably starting with not using RTP, certainly not using SDP or > offer/answer, and I'd argue for a p2p (in the overlay network sense of the > term) form rendezvous - there would be people on the list point out if we use > used HIP, everything would be done. We are not doing that because it is an > import use case. The reason it is important is because that is the way we > connect this to the existing voice and video communication infrastructure that > currently supports well over 4 billion users and probably over 5 billion. We > already have a boat load of solutions to this problem if we don't care about > legacy. That Flash stuff seems to be in lots of browsers and work fine to > other browsers - but I want more than that. For the same reason IPV6 device > that can't connect to anything V4 are much less interesting than devices that > c > an connect to both, I want interoperability with the past (meaning all the > existing deployments) and path for an interesting future. Either one by itself > is not enough. > >> >> I think that as long as the browser *or* the server *can* map it to SDP >> offer/answer when needed, that is sufficient. > > Ignoring my rant in previous paragraph - I view as necessary that it be > mappable, and it needs to be clear how and what parts of it are mapped. I > think we are on the same page that the signaling GW should not need to be a > media GW. I'm not real wrapped up about how the signaling GW is split between > the browser, web server, or even some third network element. > > >> >>> Similarly people have considered a replacement for SDP in the SDPng work >>> which was eventually abandoned due to the difficulty of having a incentive >>> for implementations to migrate from SDP to SDPng. >> >> Obviously can't use something that was abandoned. >> >>> >>> We have also considered just sending audio and video directly over something >>> like DTLS and not suing RTP. >> >> That would break point 2 above. >> >>> The WG has clearly rejected this due to a variety of reasons - the desire >>> not to to have the operating expense of media gateway and reduction in >>> quality of experience is obviously a high priority goal for the designs of >>> the RTP multiplexing draft. >> >> Agree. >> >>> >>> The JS API is being developed by W3C but when proposing APIs that should >>> violate the third principal, such as the the API in section 4 of >>> draft-jennings-rtcweb-api-00, it is clear that many people that are more >>> from the browser and web application world do not want such an API. >> >> Too many negatives for me to parse. > > Let me try to restate with less negatives. > > I acknowledge the JS API is being developed by the W3C and not the the IETF. > So I want to be careful and not imply that this IETF WG is the right WG to > make decisions about the API. Given the apologies in advance, I am going to go > and discuss the W3C API in this WG. > > Section 4 of draft-jennings-rtcweb-api-00 did propose an API that is along the > lines of what you has been arguing for. It is adv/prop type API. Now I suspect > that you would refractor this API to have pass JSON object instead of having a > bunch of parameters to the function calls but it would still roughly be the > type of API I think you are talking about. I may be completely confused on > the type of API you are proposing but we can sort that out. In many ways, this > API is modeled after some of the design of MGCP. > > The important thing is that most the web application developers and browser > developers I have talked to are not keen on this type of API. They much prefer > the API in the current W3C draft. > > >> >> Matthew Kaufman >> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From oej@edvina.net Wed Sep 7 13:15: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 AEC6821F8D3B for ; Wed, 7 Sep 2011 13:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YHzcPLIcCDd for ; Wed, 7 Sep 2011 13:15:29 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 54A1221F8AD9 for ; Wed, 7 Sep 2011 13:15:29 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 1BAD7754BCE4; Wed, 7 Sep 2011 20:17:18 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_7778A77F-13C8-484D-BD48-4B23F8365241" From: "Olle E. Johansson" In-Reply-To: <4E67AD3D.9000005@alvestrand.no> Date: Wed, 7 Sep 2011 22:17:17 +0200 Message-Id: <1CF14854-93F7-42D2-9EC4-20F9A25D33C2@edvina.net> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 20:15:30 -0000 --Apple-Mail=_7778A77F-13C8-484D-BD48-4B23F8365241 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 7 sep 2011 kl. 19:43 skrev Harald Alvestrand: > On 09/07/11 19:29, Ravindran Parthasarathi wrote: >>=20 >> Matthew, >> =20 >> When I asked for SIP, I have meant RFC 3261 only. > This is 269 pages, and has 26 normative dependencies including S/MIME. = It's not a small dependency. Agree. That RFC is way too focused on ONE application, the phone call. >>=20 >> 4) There is no need to build two different signaling logic in = VoIP servers for each service. Your own example of Bridge line = appearance will need two implementation by the single vendor because = desktop application or hardphone implementation based on SIP and browser = based implementation is depend on HTTP metadata. It is possible to = avoided by having one signaling protocol. > One protocol can be achieved by multiple applications choosing to = implement one protocol. > It doesn't have to be enforced by the prtoocol being embedded in the = browser. Right.=20 >> =20 >> In RTCWEB does not standardize the signaling protocol interface = between browsers, the interop across webservers is next to impossible = and it will be restricted to single webserver (company) only. Please let = me know in case I=92m missing something here. >=20 > I think the main thing you are missing is that there are many = applications that people want to build on top of RTCWEB that are not = telephones, and will not fit with telephone-based paradigms. SIP has already been integrated with years of work of telephone-based = paradigms. It's there and we have it. Let's not force that into RTCweb = because it will make it way too complex and be an issue when it comes to = interoperability between browsers, because most will implement selected = parts only (like in SIP today). We don't want that. I already face that interoperability problem each time I attend SIPit - = which btw is open for registration at www.sipit.net for all of you that = work with development of SIP apps and devices and need to test = interoperability ;-)=20 /O --Apple-Mail=_7778A77F-13C8-484D-BD48-4B23F8365241 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
=20 =20
On 09/07/11 19:29, Ravindran Parthasarathi wrote:

Matthew,

 

When I asked for SIP, I have meant RFC 3261 = only.

This is 269 pages, and has 26 normative dependencies including S/MIME. It's not a small dependency.
Agree. = That RFC is way too focused on ONE application, the phone = call.


4)      There is no need to build two different signaling logic in VoIP servers for each service. Your own example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible to avoided by having one signaling protocol.

One protocol can be achieved by multiple applications choosing to implement one protocol.
It doesn't have to be enforced by the prtoocol being embedded in the = browser.
Right. 

 

In RTCWEB does not standardize the signaling protocol interface between browsers, the interop across webservers is next to impossible and it will be restricted to single webserver (company) only. Please let  me know in case I=92m missing something here.


I think the main thing you are missing is that there are many applications that people want to build on top of RTCWEB that are not telephones, and will not fit with telephone-based = paradigms.

SIP has already been = integrated with years of work of telephone-based paradigms. It's there = and we have it. Let's not force that into RTCweb because it will make it = way too complex and be an issue when it comes to interoperability = between browsers, because most will implement selected parts only (like = in SIP today). We don't want that.

I already = face that interoperability problem each time I attend SIPit - which btw = is open for registration at www.sipit.net for all of you that work = with development of SIP apps and devices and need to test = interoperability = ;-) 

/O

= --Apple-Mail=_7778A77F-13C8-484D-BD48-4B23F8365241-- From dzonatas@gmail.com Wed Sep 7 13:16: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 AB36221F8AD9 for ; Wed, 7 Sep 2011 13:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=-1.845, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCSZkkUGPkWi for ; Wed, 7 Sep 2011 13:16:13 -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 BF58621F8AD3 for ; Wed, 7 Sep 2011 13:16:13 -0700 (PDT) Received: by gyd12 with SMTP id 12so31961gyd.31 for ; Wed, 07 Sep 2011 13:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gybC6em03gPkgroVSH9bUlRpqP+6onl+h2Ji8Jo1Rnk=; b=mUkdGEwRcKofrKveuhK3eSIkyXLC++ZTji0TcnNn1yz/ePGuGqSEo3hYJmJyYYhC0x FNA8msy1XMN6WhWUn8JRqqqrZ0E4bbWaQ882eRZlICXdodcMHZaSab+0ZCN1WGtmUma1 oSPXnWBo+rbFynjiIBcD0dqem/RwXyY0zspeQ= Received: by 10.236.78.200 with SMTP id g48mr36066240yhe.12.1315426681603; Wed, 07 Sep 2011 13:18:01 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id v45sm1084493yhe.12.2011.09.07.13.18.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Sep 2011 13:18:01 -0700 (PDT) Message-ID: <4E67D1EA.2060909@gmail.com> Date: Wed, 07 Sep 2011 13:19:54 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <8233FBBB-26CE-4822-81A4-65F86A4E8666@edvina.net> In-Reply-To: <8233FBBB-26CE-4822-81A4-65F86A4E8666@edvina.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 20:16:15 -0000 On 09/07/2011 12:59 PM, Olle E. Johansson wrote: > >> Signalling is secure, so it could even use a direct optional downgrade from SAVP* to AVP* (i.e. similar to the best-effort-strp draft) >> > How can you assert that signalling is secure? When, how? > > Real-time is the assertion and is not secure unless we volunteer for double entry-systems. "Forward-looking statements..."... "do" you want signal quality enforcement? "...and questions." Do you compare them to market value quotes and the number of votes for their rate of appearance? I think subscribers of this WG want security for mere difference on the floor; eggshell areas defy rate of gravity, or imagine the cone of silence gone wild. By scalar value. -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From jonathan@vidyo.com Wed Sep 7 13:16: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 A289721F8B35 for ; Wed, 7 Sep 2011 13:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 yGSWmebOo0dL for ; Wed, 7 Sep 2011 13:16:44 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id F374221F8AD2 for ; Wed, 7 Sep 2011 13:16:39 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 5E33D416DE9; Wed, 7 Sep 2011 16:18:21 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id DB7A2416C14; Wed, 7 Sep 2011 16:18:07 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Wed, 7 Sep 2011 16:18:07 -0400 From: Jonathan Lennox To: Randell Jesup Date: Wed, 7 Sep 2011 16:18:06 -0400 Thread-Topic: [rtcweb] Encryption mandate (and offer/answer) Thread-Index: Acxtm0DqCbR+QDMlQjm0HYi+uYT9jA== Message-ID: References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> In-Reply-To: <4E67C3F7.7020304@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 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Encryption mandate (and offer/answer) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 20:16:44 -0000 On Sep 7, 2011, at 3:20 PM, Randell Jesup wrote: > You could make forced-encryption the default, and allow the application=20 > control over whether to allow it is turned off for specific cases, like=20 > a PSTN call, or under the server's control. Signalling is secure, so it= =20 > could even use a direct optional downgrade from SAVP* to AVP* (i.e.=20 > similar to the best-effort-strp draft) This has implications for the parallel thread about the use of SDP offer/an= swer. The solution MMUSIC has standardized for best-effort SRTP is SDP CapNeg, RF= C 5939. Do we want to require CapNeg support in browsers? -- Jonathan Lennox jonathan@vidyo.com From blizzard@mozilla.com Wed Sep 7 13:18: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 540E221F8D5B for ; Wed, 7 Sep 2011 13:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 4hGz4zjSYYD6 for ; Wed, 7 Sep 2011 13:18:15 -0700 (PDT) Received: from mail.mozilla.com (corp01.sj.mozilla.com [63.245.208.141]) by ietfa.amsl.com (Postfix) with ESMTP id C5CA221F8D5A for ; Wed, 7 Sep 2011 13:18:15 -0700 (PDT) Received: from [10.250.4.144] (corp-240.mv.mozilla.com [63.245.220.240]) by mail.mozilla.com (Postfix) with ESMTPSA id 080F5AE6465A; Wed, 7 Sep 2011 13:20:05 -0700 (PDT) Message-ID: <4E67D1F4.10002@mozilla.com> Date: Wed, 07 Sep 2011 13:20:04 -0700 From: Christopher Blizzard User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Randell Jesup References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> In-Reply-To: <4E67C3F7.7020304@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 20:18:16 -0000 On 9/7/2011 12:20 PM, Randell Jesup wrote: > Splitting the two topics.... > > > On 9/7/2011 3:07 AM, Olle E. Johansson wrote: > >> To fearlessly jump into another can of worms, I still think we >> should have confidentiality - SRTP - by default. We know that these >> applications will run on a myriad of devices on a myriad of networks >> and it will not work to let users have to decided whether or not they >> want confidentiality. If Skype did not have confidentiality by >> default, there would be articles every summer and xmas in the evening >> taboloids about how easy it is to listen in to your neighbours calls >> and that would have hurted Skype badly. >> > > There is a strong argument for this. The strongest argument for the > other side is you don't need a media gateway to talk to non-WebRTC > endpoints, just a signalling gateway. This means less delay > potentially (especially if the application provider has gateways only > in one geographic location) and less expense for the server provider > for a pretty common usecase (gateway to PSTN). The delay could be a > significant issue. > It was also brought up that some usecases for internal PBX/business > use would not need/prefer forced encryption. As mentioned at the > meeting, encrypting to the media gateway only gets you a modicum of > privacy (though it might protect you from the "neighbor's wifi > capture" case). > > You could make forced-encryption the default, and allow the > application control over whether to allow it is turned off for > specific cases, like a PSTN call, or under the server's control. > Signalling is secure, so it could even use a direct optional downgrade > from SAVP* to AVP* (i.e. similar to the best-effort-strp draft) > > It's a tough call - guaranteed (local) security is nice, but I worry > about those relay cases like taiwan->USA media gateway->taiwan. Not a > huge deal on signaling/call-setup, but media... > > I want secure-by-default, maybe even secure-only. Even if it's not secure-only there's also an important UI consideration depending how we end up doing that in browsers. In the past we've made the secure mode special (the lock icon in the early days, now the green/blue bar) but I think that we should be making the insecure mode special. That is, always mark a connection as very clearly unencrypted via UI affordances. Just like banks "wanting to know how to get the lock icon" we should be making call sites "wanting to know how to get rid of that huge ugly warning that makes us look bad." Once again, I would much prefer secure-only, but I'll take secure-by-default across browsers if I can get it. --Chris From igor.faynberg@alcatel-lucent.com Wed Sep 7 13:18: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 0B8EB21F8D55 for ; Wed, 7 Sep 2011 13:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 KFnwL2cbSvBJ for ; Wed, 7 Sep 2011 13:18:34 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 14F7521F8D43 for ; Wed, 7 Sep 2011 13:18:33 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p87KKNrx003919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Sep 2011 15:20:23 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p87KKN2K015710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Sep 2011 15:20:23 -0500 Received: from [135.222.134.166] (USMUYN0L055118.mh.lucent.com [135.222.134.166]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p87KKMrD007688; Wed, 7 Sep 2011 15:20:23 -0500 (CDT) Message-ID: <4E67D206.9010908@alcatel-lucent.com> Date: Wed, 07 Sep 2011 16:20:22 -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: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67CE16.40403@gmail.com> In-Reply-To: <4E67CE16.40403@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 20:18:35 -0000 On 9/7/2011 4:03 PM, Dzonatas Sol wrote: > .... > Flip-side: contracts already force encryption, and that is one reason > why people do not want contracts; they want open wi-fi so neighbors > have no walls across net points. I admit, I am not one of these people... And where the neighbors can get in, anyone else can, too. From dzonatas@gmail.com Wed Sep 7 13:45: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 4F8AF21F8C95 for ; Wed, 7 Sep 2011 13:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.018 X-Spam-Level: X-Spam-Status: No, score=-4.018 tagged_above=-999 required=5 tests=[AWL=-0.419, 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 IYFEqVbKhcSC for ; Wed, 7 Sep 2011 13:45:00 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id C286A21F8B6E for ; Wed, 7 Sep 2011 13:45:00 -0700 (PDT) Received: by gxk9 with SMTP id 9so254395gxk.40 for ; Wed, 07 Sep 2011 13:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Rgjyn+C+eDnsOYB7IcZtVuKRGGp8fVM95WPt40DAFqI=; b=LMocjpeza0K7pP6skhnBDJYUgrSm72rj/qyFDsZbUdoqLJydKGSzf1CbHy7xpCav5C FLud21vFcG6FEFH0fs7VJ1L5rXUuuKkFKy86RjgP4CMDyVsrARpOmf2x43pg9vbHuuen hLgxc7BbIHDU7VeYGJs6IZz+ZH65vj2E9n2gY= Received: by 10.151.40.17 with SMTP id s17mr59880ybj.140.1315428410892; Wed, 07 Sep 2011 13:46:50 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id 20sm2115257anl.12.2011.09.07.13.46.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Sep 2011 13:46:50 -0700 (PDT) Message-ID: <4E67D8AC.3030409@gmail.com> Date: Wed, 07 Sep 2011 13:48:44 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67CE16.40403@gmail.com> <4E67D206.9010908@alcatel-lucent.com> In-Reply-To: <4E67D206.9010908@alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 20:45:01 -0000 On 09/07/2011 01:20 PM, Igor Faynberg wrote: > > > On 9/7/2011 4:03 PM, Dzonatas Sol wrote: >> .... >> Flip-side: contracts already force encryption, and that is one reason >> why people do not want contracts; they want open wi-fi so neighbors >> have no walls across net points. > > I admit, I am not one of these people... And where the neighbors can > get in, anyone else can, too. > Experience only: we grew-up in areas without fences, only barb-wire, or "posts". In these fenced-in neighborhoods, I'm tired of the need "to pitch" openness to "anyone"; I sound evangelical now, yet others say street-smart. Good difference? -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From igor.faynberg@alcatel-lucent.com Wed Sep 7 13:52: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 17EA321F8CF5 for ; Wed, 7 Sep 2011 13:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 u2JOieYatSIn for ; Wed, 7 Sep 2011 13:52:52 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id E379321F8CF0 for ; Wed, 7 Sep 2011 13:52:51 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p87Ksfuk025690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 7 Sep 2011 15:54:42 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p87KsfjD003051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 7 Sep 2011 15:54:41 -0500 Received: from [135.222.134.166] (USMUYN0L055118.mh.lucent.com [135.222.134.166]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p87KsfMC004309; Wed, 7 Sep 2011 15:54:41 -0500 (CDT) Message-ID: <4E67DA11.7070203@alcatel-lucent.com> Date: Wed, 07 Sep 2011 16:54:41 -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: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67CE16.40403@gmail.com> <4E67D206.9010908@alcatel-lucent.com> <4E67D8AC.3030409@gmail.com> In-Reply-To: <4E67D8AC.3030409@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 20:52:53 -0000 :) On 9/7/2011 4:48 PM, Dzonatas Sol wrote: > On 09/07/2011 01:20 PM, Igor Faynberg wrote: >> >> >> On 9/7/2011 4:03 PM, Dzonatas Sol wrote: >>> .... >>> Flip-side: contracts already force encryption, and that is one >>> reason why people do not want contracts; they want open wi-fi so >>> neighbors have no walls across net points. >> >> I admit, I am not one of these people... And where the neighbors can >> get in, anyone else can, too. >> > > Experience only: we grew-up in areas without fences, only barb-wire, > or "posts". In these fenced-in neighborhoods, I'm tired of the need > "to pitch" openness to "anyone"; I sound evangelical now, yet others > say street-smart. > > Good difference? > From randell-ietf@jesup.org Wed Sep 7 14:58: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 7AA2121F8DCD for ; Wed, 7 Sep 2011 14:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dHG-kegzQR1 for ; Wed, 7 Sep 2011 14:58:37 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0771821F8DE0 for ; Wed, 7 Sep 2011 14:58:33 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R1QAN-0003sf-GJ; Wed, 07 Sep 2011 17:00:19 -0500 Message-ID: <4E67E8C5.30409@jesup.org> Date: Wed, 07 Sep 2011 17:57:25 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Christopher Blizzard References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67D1F4.10002@mozilla.com> In-Reply-To: <4E67D1F4.10002@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: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 21:58:40 -0000 On 9/7/2011 4:20 PM, Christopher Blizzard wrote: > On 9/7/2011 12:20 PM, Randell Jesup wrote: >> Splitting the two topics.... >> >> >> On 9/7/2011 3:07 AM, Olle E. Johansson wrote: >> >>> To fearlessly jump into another can of worms, I still think we >>> should have confidentiality - SRTP - by default. We know that these >>> applications will run on a myriad of devices on a myriad of networks >>> and it will not work to let users have to decided whether or not >>> they want confidentiality. If Skype did not have confidentiality by >>> default, there would be articles every summer and xmas in the >>> evening taboloids about how easy it is to listen in to your >>> neighbours calls and that would have hurted Skype badly. >>> >> >> There is a strong argument for this. The strongest argument for the >> other side is you don't need a media gateway to talk to non-WebRTC >> endpoints, just a signalling gateway. This means less delay >> potentially (especially if the application provider has gateways only >> in one geographic location) and less expense for the server provider >> for a pretty common usecase (gateway to PSTN). The delay could be a >> significant issue. >> It was also brought up that some usecases for internal PBX/business >> use would not need/prefer forced encryption. As mentioned at the >> meeting, encrypting to the media gateway only gets you a modicum of >> privacy (though it might protect you from the "neighbor's wifi >> capture" case). >> >> You could make forced-encryption the default, and allow the >> application control over whether to allow it is turned off for >> specific cases, like a PSTN call, or under the server's control. >> Signalling is secure, so it could even use a direct optional >> downgrade from SAVP* to AVP* (i.e. similar to the best-effort-strp >> draft) >> >> It's a tough call - guaranteed (local) security is nice, but I worry >> about those relay cases like taiwan->USA media gateway->taiwan. Not >> a huge deal on signaling/call-setup, but media... >> >> > > I want secure-by-default, maybe even secure-only. > > Even if it's not secure-only there's also an important UI > consideration depending how we end up doing that in browsers. In the > past we've made the secure mode special (the lock icon in the early > days, now the green/blue bar) but I think that we should be making the > insecure mode special. That is, always mark a connection as very > clearly unencrypted via UI affordances. Just like banks "wanting to > know how to get the lock icon" we should be making call sites "wanting > to know how to get rid of that huge ugly warning that makes us look bad." A "listening-ear" icon maybe? :-) Agreed on defaults, maybe on secure-only. I should note that if it's secure-to-media-gateway, that doesn't tell you if it's secure past that point, so the lack of the "listening-ear" icon doesn't really mean it's *really* secure. We discussed this some at the last IETF I think. If you can verify the receiver at the other end you may have more assurance about who you're talking to... but that's a tough question on it's own. My experience is that media gateways a great for NAT traversal, and are so-so to sucking for conversational quality unless they're very close to one or the other endpoint (and may not be great there), and they can have serious costs associated with them for the service. > > Once again, I would much prefer secure-only, but I'll take > secure-by-default across browsers if I can get it. > The proposal would put it under control of the application to allow; presumably only an app that included in their service access to legacy media endpoints would do so. I'll note that allowing this has minimal (not zero) security impact as this is UDP; a bigger issue with this might be ICE. Currently the ICE requirement make this idea rather moot, unless the app can control that too (typically this is used to connect to PSTN gateways that you don't need ICE to access). Without ICE there may be larger security issues per ekr's draft that just showed up; though I'll note that UDP isn't generally a major method of DoS or attack on a site. It might be used in theory for SPIT though; if that's a real threat in any volume that may kill this idea. -- Randell Jesup randell-ietf@jesup.org From matthew.kaufman@skype.net Wed Sep 7 15:02: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 1AABD21F8DAA for ; Wed, 7 Sep 2011 15:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.296 X-Spam-Level: X-Spam-Status: No, score=-5.296 tagged_above=-999 required=5 tests=[AWL=1.303, 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 XwAF6lYXhoXU for ; Wed, 7 Sep 2011 15:02:25 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5E14821F8DA5 for ; Wed, 7 Sep 2011 15:02:25 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 7F4287FD; Thu, 8 Sep 2011 00:04:14 +0200 (CEST) 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=2ZdGBTjZB/rv8d rwVxQM/v7Uzag=; b=ulY6EBeLAX5eCIHzIBeqoTZ056pLAEnj3VIB4JkZuiRP1r sR8w6qLYZyK1Gow3Z+qNaufXdRTOoZLjrhndUyPLJfFQhOVOSP6rfBXOvqsqzy5z Ai1cPpVXGFas1ttj7FGcXdGXldKMZ/Iey/YVsE9Z8/H3ualJQmSijAXJgb8ms= 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=bjYLG4kN1nZWV/ZuMQENPR GDmqCPdh/KmmPGn6BtVpa9+DaDdcR8oVsPnbTuvIcjwqrORyU+po0+UZtATPElNN HvdM6etLOu2Ho9pThMvmftxHLqfFELj3mfC5LVwcIxfjvD+9MY7NuPSNAH1slCzz kfZ+ImNGEADHgX644x3GU= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 7D8067F6; Thu, 8 Sep 2011 00:04:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 5E3C835081CC; Thu, 8 Sep 2011 00:04:14 +0200 (CEST) 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 tsc+uT4ypcNR; Thu, 8 Sep 2011 00:04:13 +0200 (CEST) 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 04D0A35081D8; Thu, 8 Sep 2011 00:04:12 +0200 (CEST) Message-ID: <4E67EA5B.605@skype.net> Date: Wed, 07 Sep 2011 15:04:11 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Cullen Jennings References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> <4E666785.7040409@skype.net> <4E67513C.3030600@alvestrand.no> <4E677CB8.40203@skype.net> <5DD808C2-D4ED-45E4-8D18-02613281A62D@cisco.com> In-Reply-To: <5DD808C2-D4ED-45E4-8D18-02613281A62D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 22:02:26 -0000 On 9/7/11 7:59 AM, Cullen Jennings wrote: > > Give me one reasons why it would be any harder to do if the browser did SIP than if it did the type of API you are talking about. I think you are just wrong here. The web app in the JS and in the web server would still just use SIP to set up media the way it wanted - just like you would do with the other API. No one is proposing we use the BLISS shared line appearance or anything like that - we are proposing that when A wants to say what codecs to use for sending media to B, use that part of SIP. The problem with using "that part of SIP" is that you're at the top of a very very slippery slope. You want "just SIP"? With early media? PRACK? Refer? ...? And then what happens when people try to write applications that have a real SIP server at the far end that doesn't know what to do with something that supports "just SIP" without any of its essentially-mandatory extensions? Matthew Kaufman From matthew.kaufman@skype.net Wed Sep 7 15:03: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 1E48121F8DF9 for ; Wed, 7 Sep 2011 15:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.368 X-Spam-Level: X-Spam-Status: No, score=-5.368 tagged_above=-999 required=5 tests=[AWL=1.231, 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 CDjxGQNqlYm6 for ; Wed, 7 Sep 2011 15:03:53 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC5B21F8DF8 for ; Wed, 7 Sep 2011 15:03:53 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 8F25D7FD; Thu, 8 Sep 2011 00:05:43 +0200 (CEST) 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=mmNPLtz5Zf6kul EH+uTGKglCKl8=; b=M6fpoeP1bNqn/Ma3KlQaPDUZqEKKKWwS3/8nFRmITeFYvE AlNgrLeDLzns6zS6MWqYeqjOiC7GUXKMLTr29Y0/IEdt2L4uoK7NERcnRsPqNtev Lo/VVz2TJTTeRccw87W0U3M/ECiGBzvtmK8Dofk+JPaR6V4t4SjYFVwNhThAo= 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=E4mYupjC0Lj2WNzKbqhn3B ineDYRkQVJ5zLuroHN7+eQQrgeez4F62/ANAHnrWSKGDU2x7oF1bVPBDA5GVykic WR3pDwLOgw7BclVAWybatmK0sju+2vOwpi73YJqGQe11LjD+BHt8D5LDYw7SGuQh idKY6iTL10UW7oK5Y2sSE= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 8DABA7F6; Thu, 8 Sep 2011 00:05:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 6B74A35081D8; Thu, 8 Sep 2011 00:05:43 +0200 (CEST) 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 DqGkHfaw59j3; Thu, 8 Sep 2011 00:05:43 +0200 (CEST) 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 5C90335081E6; Thu, 8 Sep 2011 00:05:42 +0200 (CEST) Message-ID: <4E67EAB4.20706@skype.net> Date: Wed, 07 Sep 2011 15:05:40 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Cullen Jennings References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> <4E666785.7040409@skype.net> <4E67513C.3030600@alvestrand.no> <4E677CB8.40203@skype.net> <4E677D4F.8050105@skype.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 22:03:54 -0000 On 9/7/11 8:00 AM, Cullen Jennings wrote: > On Sep 7, 2011, at 8:18 AM, Matthew Kaufman wrote: > > And note that this is directly parallel to the "innovate like Gmail" discussion. It is trivial for Gmail to change the look and feel and behavior of the "delete" button to implement an email paradigm of "keep everything, search to find it" (and have it work the same way no matter who the browser vendor is)... but this wouldn't have been the case if Gmail were forced to use the browser's built-in IMAP implementation. > again - as I have mentioned before, that a silly analogy. I know it is rhetorically nice but seriously, why do you think it is a reasonable parallel? > "Baking a phone into the browser" is exactly the same as "baking an IMAP client into the browser". What some have asked for is an API as simple as "sipPhone.call()" and "sipPhone.hangup()", and that's what I'm addressing. Matthew Kaufman From matthew.kaufman@skype.net Wed Sep 7 15:08: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 970A821F8D2D for ; Wed, 7 Sep 2011 15:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.433 X-Spam-Level: X-Spam-Status: No, score=-5.433 tagged_above=-999 required=5 tests=[AWL=1.166, 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 1NUHa1TEoRDF for ; Wed, 7 Sep 2011 15:08:36 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id A59A121F8D21 for ; Wed, 7 Sep 2011 15:08:36 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id A727D7FD; Thu, 8 Sep 2011 00:10:26 +0200 (CEST) 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=UTPm7GiKhYc6+f XeLot0C1NL2q8=; b=SQuB4rFDMOiE6xJAdfpw52uKiQrbDktIGo/UcggCxii2tH DJZyinDO8MaNQTWTZYyJI7Y+GPJXTa/tkpS8YRanEMfWoQDupxfLFdD1pl4n4k3a 8GtR+5Ti6aBzs3HK/N/1RA4uN3jPMmUF6KrF8sowaVFXFMQ8R2KBpHH7dHgDY= 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=N1iI5TaqI/sdmHGrM5zecI DXpRX1XyxHgNORUgskC173YxLq+rgmnycmuHX8GpU6s9bX6jfBMZ6sn5ZEUp7VDv pBSQRfOdaG2swJqjdtL0GCDCuPUo7ZmgH/vUcODquLYUS/w2lL+bPssxMyHmcIbx lhFb/S7TIeaIVgEqAWdhA= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id A252E7F6; Thu, 8 Sep 2011 00:10:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 67938350787D; Thu, 8 Sep 2011 00:10:26 +0200 (CEST) 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 OkXPXz0EUGlV; Thu, 8 Sep 2011 00:10:25 +0200 (CEST) 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 E9AB535081CC; Thu, 8 Sep 2011 00:10:24 +0200 (CEST) Message-ID: <4E67EBCF.5050206@skype.net> Date: Wed, 07 Sep 2011 15:10:23 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Paul Kyzivat References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> <4E666785.7040409@skype.net> <4E67513C.3030600@alvestrand.no> <4E677CB8.40203@skype.net> <4E678B44.9080208@alum.mit.edu> In-Reply-To: <4E678B44.9080208@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 22:08:37 -0000 On 9/7/11 8:18 AM, Paul Kyzivat wrote: > Matthew, > > Good summary. > > I agree that webrtc provides flexibility in how to implement the UI > portions of these features with generic webrtc clients. But it doesn't > make these features trivial to implement. I didn't say that it did. But the flexibility does allow the feature to be implemented in whatever combination of client-side Javascript and server-side programming you wish. > In particular, the bridged line appearance still requires that a > conference be established. With generic rtcweb clients, that probably > means a central mixer. Setting that up is relatively easy if there is > a central media termination point in rtcweb server, and it *has* mixer > capabilities. Agree. > > My point is not that rtcweb doesn't help with this case - just that > these features that are so trivial in analog telephony just aren't so > simple with voip, no matter how you do it. Also agree. The real difference comes with the programming model. With a SIP phone, to add bridged line appearance support you need to write a new spec (that doesn't exist), get consensus around that spec, and then upgrade the phone firmware. With an SCCP (Skinny) phone, to add bridged line appearance support you simply write some additional code that runs at the server end that changes when the lights are commanded to turn on and off, controls what happens when a lit line button is pushed, and commands the phone to send the right kind of media to the right place. There is no reason why we should make a web browser, which has the added advantage of a local execution environment for Javascript, *less* capable than the aforementioned server-controlled phone. Matthew Kaufman From matthew.kaufman@skype.net Wed Sep 7 15:09: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 96FCE21F8D6C for ; Wed, 7 Sep 2011 15:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.491 X-Spam-Level: X-Spam-Status: No, score=-5.491 tagged_above=-999 required=5 tests=[AWL=1.108, 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 6Mql2hODnBSk for ; Wed, 7 Sep 2011 15:09:53 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id AFCF821F8D21 for ; Wed, 7 Sep 2011 15:09:52 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 3A2BE7FD; Thu, 8 Sep 2011 00:11:35 +0200 (CEST) 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=BQMIYpQX1mjDi2 ZUp5diHZ42c1c=; b=gu9E8wAv7PLhQrDtSYQPiXpe6bv0rsDOuQYWVJIVU5wL6t NxM7UvVLvOMgB5gfpx+fwXRP/Xk4/U68EtjrB7bbhaZx2KSBjaYzi8dn7nGmKNqA 9FkOMcBx9kPy2P/20XO1bP6edEZu956xVcrw7tFrHME+MkMZDv6K1FZE+L5A0= 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=RqY0ClanewlVnar3E/Lz0L i62vA5/EIMPc/eRXJxxP8mnJErg2zHIPotgEkgcU0mzLsA8sR796l5Rn2J8V/0qj H+Y1aYsiFb7DpqYCMljm8tZQDlvBWEjOKkPSg10rIT/wXfeVTt28/ZQTsuCzZjxk 3Ycr8GvIKPAksjbhLQOV4= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 38AB57F6; Thu, 8 Sep 2011 00:11:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 1AC2135080AD; Thu, 8 Sep 2011 00:11:35 +0200 (CEST) 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 hjI6IrtYTPw8; Thu, 8 Sep 2011 00:11:34 +0200 (CEST) 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 0233A350787D; Thu, 8 Sep 2011 00:11:33 +0200 (CEST) Message-ID: <4E67EC14.8050808@skype.net> Date: Wed, 07 Sep 2011 15:11:32 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <4E259484.20509@ericsson.com>, <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com>, <4E26B742.6050606@jitsi.org>, <62C71813-83B4-44D3-8E54-28262311CDB3@cisco.com> <4E27BE02.7090606@ericsson.com> <9F9278CB1892FB48BF35CB5CC3992478A5395C720E@HKGMBOXPRD01.polycom.com> <4E2EB82C.30709@alvestrand.no> <4E643E39.8020205@skype.net> <4E665588.5000700@mozilla.com> <4E678D22.4060203@alvestrand.no> In-Reply-To: <4E678D22.4060203@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Support for websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 22:09:55 -0000 On 9/7/11 8:26 AM, Harald Alvestrand wrote: > On 09/07/11 17:04, Cullen Jennings wrote: >> Sooner or later, I do think we should talk about how to spoof RTP >> through firewalls that only allow HTTP traffic. Certainly websockets >> would be worth looking at but I suspect we will find that it was not >> designed for transfer of large high bandwidth material (like video) >> and that something similar but different is needed. > The huge difference between websockets and a real-time RTP connection > is that in a real-time connection, you drop packets if you get behind. > In websockets, you deliver everything that made it to the "send" call. This is also true of TURN-over-TLS-over-TCP, as is in the current spec for the TCP fallback. However TURN-over-TLS-over-TCP doesn't look like HTTP to firewalls that only allow HTTP traffic. Matthew Kaufman From matthew.kaufman@skype.net Wed Sep 7 15: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 86D8721F8BAC for ; Wed, 7 Sep 2011 15:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.544 X-Spam-Level: X-Spam-Status: No, score=-5.544 tagged_above=-999 required=5 tests=[AWL=1.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR8RCUz2vAqs for ; Wed, 7 Sep 2011 15:21:32 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 0233821F8B4F for ; Wed, 7 Sep 2011 15:21:32 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id C94C47FD; Thu, 8 Sep 2011 00:23:21 +0200 (CEST) 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; s=mx; bh=30JvQbc4OQdm3UMdWM9YauMOEeg=; b=qC/10HZXL vTMcgr82Sb8+Zc7VE5RDr6NvCtOtecozJofPOECcS3kkjBnz5yVxHMjp75ECYJNW ZHxc2KSZDpWQ9PpXVi1w6EZ2p1lKlXK8fLnGw0iaGQeD9nu0GcIn678pO9yNRKl0 7pviqjh2IEVJ3nsuXbPpzmzUGqi43VR6qU= 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; q=dns; s=mx; b=cQHETtxM6Dtalnt6Xt0Rn2GjwmvjOAbnoTFZ6POp7LDPDw7g rTs1ACfQrGN1QJedMnLt1t+VrDjDq3OLu385d3qOWop7pxQOY0pxQKDK0ESYLEYw 9FZgrfbRQc7PJXsVddEYapJ008p1G6owA8Hn46PZsEForxJj3SuXH+hpdyc= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id C706C7F6; Thu, 8 Sep 2011 00:23:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 91E7335081E5; Thu, 8 Sep 2011 00:23:21 +0200 (CEST) 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 g1gmbbdxlcPi; Thu, 8 Sep 2011 00:23:17 +0200 (CEST) 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 A627935081CC; Thu, 8 Sep 2011 00:23:16 +0200 (CEST) Message-ID: <4E67EED2.2000207@skype.net> Date: Wed, 07 Sep 2011 15:23:14 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> Content-Type: multipart/alternative; boundary="------------050600040003040407050503" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 22:21:35 -0000 This is a multi-part message in MIME format. --------------050600040003040407050503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/7/11 10:29 AM, Ravindran Parthasarathi wrote: > > Matthew, > > When I asked for SIP, I have meant RFC 3261 only. > As I pointed out earlier, this is the top of a very slippery slope. Certainly you must have meant 3261 + early media + PRACK (for instance), yes? > The basic reason for asking SIP is to make the basic call works > between browser to browser across web servers. > SIP is in no way required to make this happen. > Without SIP in browser, it is not going happen. > Totally disagree. > > Innovative application is going to be proprietary whether it is HTTP > or SIP or any other protocol for that matter. > True. But having to reverse-engineer out the phone part is really painful for the application developer who is trying to build something else. > My reasoning are as follows: > > 1)SIP makes browser more intelligence compare to dump signaling > mechanism like MEGACO and browser acts as MG. > SIP in the browser makes the browser less *flexible* than an API with more direct control over the internal objects (camera, codec, network connection) and yet no more intelligent, as the browser has a runtime that can be programmed to do anything you want at the client side. > 2)The importance of basic call interop is that there is no need of > many individual id like skype id, Google id and yahoo id by everyone > in the world to communicate others. I wish to have single id like > e-mail id to be maintained by browser-to-browser users to communicate > with others. > This isn't going to happen, and is even closer to my fears about "IMAP in the browser" expressed earlier. > 3)SIP helps to interop for basic call with other existing realtime > application in Enterprise & Telecom provider. > So what? I hope people understand that RTCWEB could be about so much more than enterprise and telecom providers doing two-party phone calls. Among other things, you can build augmented reality systems out of it (see how Flash streaming has been used similarly), multi-party experiences that aren't calls (Google hangouts), and many other applications we haven't even thought of yet... as long as we don't cripple the APIs. > > 4)There is no need to build two different signaling logic in VoIP > servers for each service. Your own example of Bridge line appearance > will need two implementation by the single vendor because desktop > application or hardphone implementation based on SIP and browser based > implementation is depend on HTTP metadata. It is possible to avoided > by having one signaling protocol. > It doesn't even work over that "one signaling protocol", so that doesn't help. And again, there is no reason that a web site providing RTC applications to/from a browser need necessarily be serving "SIP phones" as clients as well. Maybe that just isn't the business they're in. > > In RTCWEB does not standardize the signaling protocol interface > between browsers, the interop across webservers is next to impossible > Totally disagree. We need to standardize the *media transport* between the browsers, and W3C needs to standardize the *API* by which we can send Javascript to the browser that executes the same way on every browser, but that doesn't mean the signaling protocol needs to be specified any more than IETF needed to intervene to ensure that the XML or JSON data that goes between your browser and Gmail is the same as the data that goes between your browser and Yahoo mail when you're using each to compose email messages. > and it will be restricted to single webserver (company) only. > Disagree. Just like Gmail and Yahoo mail can send messages to each other's users over a standard protocol for federation, so can RTCWEB. In fact, SIP is probably a great choice for inter-provider trunking. And conveniently, we plan to support the same *media transport* that other SIP devices use (RTP), so there'll be even more interoperability than just browser-to-browser federated between providers. > Please let me know in case I'm missing something here. > See above. Matthew Kaufman --------------050600040003040407050503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/7/11 10:29 AM, Ravindran Parthasarathi wrote:

Matthew,

 

When I asked for SIP, I have meant RFC 3261 only.


As I pointed out earlier, this is the top of a very slippery slope.

Certainly you must have meant 3261 + early media + PRACK (for instance), yes?

The basic reason for asking SIP is to make the basic call works between browser to browser across web servers.


SIP is in no way required to make this happen.

Without SIP in browser, it is not going happen.


Totally disagree.

Innovative application is going to be proprietary whether it is HTTP or SIP or any other protocol for that matter.


True. But having to reverse-engineer out the phone part is really painful for the application developer who is trying to build something else.

 

My reasoning are as follows:

1)      SIP makes browser more intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG.


SIP in the browser makes the browser less *flexible* than an API with more direct control over the internal objects (camera, codec, network connection) and yet no more intelligent, as the browser has a runtime that can be programmed to do anything you want at the client side.

2)      The importance of basic call interop is that there is no need of many individual id like skype id, Google id  and yahoo id by everyone in the world to communicate others. I wish to have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.


This isn't going to happen, and is even closer to my fears about "IMAP in the browser" expressed earlier.

3)      SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provider.


So what? I hope people understand that RTCWEB could be about so much more than enterprise and telecom providers doing two-party phone calls.

Among other things, you can build augmented reality systems out of it (see how Flash streaming has been used similarly), multi-party experiences that aren't calls (Google hangouts), and many other applications we haven't even thought of yet... as long as we don't cripple the APIs.

4)      There is no need to build two different signaling logic in VoIP servers for each service. Your own example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible to avoided by having one signaling protocol.


It doesn't even work over that "one signaling protocol", so that doesn't help. And again, there is no reason that a web site providing RTC applications to/from a browser need necessarily be serving "SIP phones" as clients as well. Maybe that just isn't the business they're in.

 

In RTCWEB does not standardize the signaling protocol interface between browsers, the interop across webservers is next to impossible


Totally disagree. We need to standardize the *media transport* between the browsers, and W3C needs to standardize the *API* by which we can send Javascript to the browser that executes the same way on every browser, but that doesn't mean the signaling protocol needs to be specified any more than IETF needed to intervene to ensure that the XML or JSON data that goes between your browser and Gmail is the same as the data that goes between your browser and Yahoo mail when you're using each to compose email messages.

and it will be restricted to single webserver (company) only.


Disagree. Just like Gmail and Yahoo mail can send messages to each other's users over a standard protocol for federation, so can RTCWEB. In fact, SIP is probably a great choice for inter-provider trunking. And conveniently, we plan to support the same *media transport* that other SIP devices use (RTP), so there'll be even more interoperability than just browser-to-browser federated between providers.

Please let  me know in case I’m missing something here.


See above.

Matthew Kaufman

--------------050600040003040407050503-- From matthew.kaufman@skype.net Wed Sep 7 15:29: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 ED7AB21F8E23 for ; Wed, 7 Sep 2011 15:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.592 X-Spam-Level: X-Spam-Status: No, score=-5.592 tagged_above=-999 required=5 tests=[AWL=1.007, 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 3wXHqrKIRio1 for ; Wed, 7 Sep 2011 15:29:12 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id EF22221F8744 for ; Wed, 7 Sep 2011 15:29:11 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 080A1CF; Thu, 8 Sep 2011 00:31:02 +0200 (CEST) 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=ansQYTKyAproi1 MLIvF1ynr9S7o=; b=ifFhH1X8yi2A6nHGaeDf0BfjZrKbgNoSN6XNxhYGX6WQ1P J2xYp9cCqG36WwxucuKhcwqemGbKMya3ELdendy0OJYPcOzZNXkSYogkRwkEtyvx lHOFMyQmgSxoKk4NQpmhTNPliGN4oK1XEf3fNmrP9vC20iBhMGP5eo3EURVUY= 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=UnY8vHryRDR7neHq9oIvwD IyoNre4zL8x7Xn7y9f9+/V5/Ud/bDj9zGHlMS0giRz7VzUnTehxwDAcU2obJ02/m KB8Innk6TB2O96E8fs9mjZfMRMvNqcDEWzQijBiBZ43IwuD29j2n2FVEUfKr1fte jJWGwVeBLHlfL0zDd92Ns= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id F1EDC7FD; Thu, 8 Sep 2011 00:31:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id CEB6635081E5; Thu, 8 Sep 2011 00:31:01 +0200 (CEST) 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 ObRcgly53MUW; Thu, 8 Sep 2011 00:31:01 +0200 (CEST) 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 575D83507EF9; Thu, 8 Sep 2011 00:31:00 +0200 (CEST) Message-ID: <4E67F0A2.1070308@skype.net> Date: Wed, 07 Sep 2011 15:30:58 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Randell Jesup References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3EE.50707@jesup.org> In-Reply-To: <4E67C3EE.50707@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 22:29:13 -0000 On 9/7/11 12:20 PM, Randell Jesup wrote: > > I also started from the same point - assume SIP. SIP gives you all > the things that the zillions of hours and emails to define it and > define extensions and secure it provides, without having to reinvent > all those wheels (or ask app developers to reinvent them). Why go > through the horrible pain of choosing something else, or why throw the > app developers to the wolves to fend for themselves? > > However... > > Two things have swayed me. The primary one is the suggestion of > Offer/Answer in the browser. This breaks out the important > negotiation piece that almost any application would need, and while > not perfect, SDP O/A is a zillion times simpler than SIP with all the > extensions one could use. I agree with this. While I am also opposed to SDP O/A, these are two unrelated arguments to have... and not baking a SIP phone into the browser is *more* important than avoiding a repeat of the offer/answer problems. > > The other thing that swayed me was thinking about federation and the > apps that will be built with this. A webrtc app talks to its > (web)server, other webrtc clients running the app that talk to the > server, and to other webrtc applications/networks that federate with > it (and their clients). > > Federation is in the same hands as the person who provides/wrote the > app. If they have no interest in federation you can't force it, and > they may have no use for all the fancy SIP standards. And for numerous types of apps (think: server-based augmented reality systems), "federation" doesn't even make sense. > > On the other hand, if they *want* to either provide access to the > wider communication net that is the PSTN network, now or in the > future, or they want easy federation with other networks, it behooves > them to use SIP or something very close to it or > equivalent/convertible (at a basic level at least) to it. > > So what conclusions do I draw from this? > > 1) O/A via SDP in the browser simplifies a lot of things (including > handling new codecs, etc). It doesn't extremely limit an application, > though we should think about how an application can interact with the > fmtp/etc parameters used. I agree that it would simplify some interop cases, but at an unfortunate cost in lack of flexibility and functionality. Still not nearly as bad as if we put a full SIP stack in there though. > > 2) SIP as a *separate* item that can be cleanly and easily *added* to > a webrtc app to handle the call setup/etc is a good idea. I would be open to looking at this again, *after* RTC is already in browsers and successful, to see if it actually solves a real use case. Matthew Kaufman From randell-ietf@jesup.org Wed Sep 7 15:29: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 268C921F8E2F for ; Wed, 7 Sep 2011 15:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7GUEHBg5MCU for ; Wed, 7 Sep 2011 15:29:23 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A84D621F8E2E for ; Wed, 7 Sep 2011 15:29:23 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R1QeI-0004uV-0O; Wed, 07 Sep 2011 17:31:14 -0500 Message-ID: <4E67F003.6000108@jesup.org> Date: Wed, 07 Sep 2011 18:28:19 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Jonathan Lennox References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@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: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Encryption mandate (and offer/answer) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 22:29:24 -0000 On 9/7/2011 4:18 PM, Jonathan Lennox wrote: > On Sep 7, 2011, at 3:20 PM, Randell Jesup wrote: >> You could make forced-encryption the default, and allow the application >> control over whether to allow it is turned off for specific cases, like >> a PSTN call, or under the server's control. Signalling is secure, so it >> could even use a direct optional downgrade from SAVP* to AVP* (i.e. >> similar to the best-effort-strp draft) > This has implications for the parallel thread about the use of SDP offer/answer. > > The solution MMUSIC has standardized for best-effort SRTP is SDP CapNeg, RFC 5939. Do we want to require CapNeg support in browsers? Yeah, ok, I'm not going there. :-) It's probably not needed for this use-case anyways. -- Randell Jesup randell-ietf@jesup.org From matthew.kaufman@skype.net Wed Sep 7 15:30: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 5F8EB21F8E23 for ; Wed, 7 Sep 2011 15:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.636 X-Spam-Level: X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[AWL=0.963, 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 XjRIAdX2-vyv for ; Wed, 7 Sep 2011 15:30:57 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 8B58521F8744 for ; Wed, 7 Sep 2011 15:30:57 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 331C9CF; Thu, 8 Sep 2011 00:32:47 +0200 (CEST) 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=hrSIWoFKAkSeyg rHsuIUnBS6uSw=; b=cEk/KKki5P+LTAlxH4pLdIbIn45j7I3tMzv93RomOYMWu5 lAchk4IQJpWTCUCkvJF8NASUguGfuz2h3++SzqGvEWRyFYi6Te+78L6A1BwADkET PKbJ7UEWD21r1lQe5fVTTmZ1jc7m+BZO6Z3vzzwx51Q6hCRI7SVToscWM2D0A= 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=WYDv3+gHhXMWBFoHolY9W5 OvtPr3AKZXOrPv5peDiuUQ+ve7oE1zamRckR8XlhPbwtjufsjWwuGM9ZR3eY4m3a tvSqwfQFzqxcpuFajG7JKSkyjWS4wcG0Wdi18bpCAi/izKzcGJRFb+mOdIFX9RjL 0wEhvIpz1+dlJNkdJ6ZV4= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 2806F7FD; Thu, 8 Sep 2011 00:32:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 0EAA13507A38; Thu, 8 Sep 2011 00:32:47 +0200 (CEST) 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 BRnC+rO9MGpo; Thu, 8 Sep 2011 00:32:46 +0200 (CEST) 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 66BD635081E9; Thu, 8 Sep 2011 00:32:45 +0200 (CEST) Message-ID: <4E67F10B.5060807@skype.net> Date: Wed, 07 Sep 2011 15:32:43 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Olle E. Johansson" References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <8233FBBB-26CE-4822-81A4-65F86A4E8666@edvina.net> In-Reply-To: <8233FBBB-26CE-4822-81A4-65F86A4E8666@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 22:30:58 -0000 On 9/7/11 12:59 PM, Olle E. Johansson wrote: > 7 sep 2011 kl. 21:20 skrev Randell Jesup: > >> Splitting the two topics.... >> >> >> On 9/7/2011 3:07 AM, Olle E. Johansson wrote: >> >>> To fearlessly jump into another can of worms, I still think we should have confidentiality - SRTP - by default. We know that these applications will run on a myriad of devices on a myriad of networks and it will not work to let users have to decided whether or not they want confidentiality. If Skype did not have confidentiality by default, there would be articles every summer and xmas in the evening taboloids about how easy it is to listen in to your neighbours calls and that would have hurted Skype badly. >>> >> There is a strong argument for this. The strongest argument for the other side is you don't need a media gateway to talk to non-WebRTC endpoints, just a signalling gateway. This means less delay potentially (especially if the application provider has gateways only in one geographic location) and less expense for the server provider for a pretty common usecase (gateway to PSTN). The delay could be a significant issue. >> It was also brought up that some usecases for internal PBX/business use would not need/prefer forced encryption. As mentioned at the meeting, encrypting to the media gateway only gets you a modicum of privacy (though it might protect you from the "neighbor's wifi capture" case). >> >> You could make forced-encryption the default, and allow the application control over whether to allow it is turned off for specific cases, like a PSTN call, or under the server's control. > If that's the case, we have to force a UI directive that all browsers adapt - like the green bar for EV certs - so the user is aware that confidentiality is missing. ... I started to address this issue in my security inspector draft. Feel free to comment on this so we can improve upon those requirements. Also, I think we want to have confidentiality with a specific set of requirements, namely those that you get if you use DTLS-SRTP with DH and AES, not just "SRTP". Matthew Kaufman From randell-ietf@jesup.org Wed Sep 7 15:40: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 3F92C21F8D67 for ; Wed, 7 Sep 2011 15:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 vV9E8mU+mt9D for ; Wed, 7 Sep 2011 15:40:22 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id AD2AA21F8D64 for ; Wed, 7 Sep 2011 15:40:22 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R1Qou-0007QZ-6i; Wed, 07 Sep 2011 17:42:12 -0500 Message-ID: <4E67F296.3020007@jesup.org> Date: Wed, 07 Sep 2011 18:39:18 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: "Olle E. Johansson" References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <8233FBBB-26CE-4822-81A4-65F86A4E8666@edvina.net> In-Reply-To: <8233FBBB-26CE-4822-81A4-65F86A4E8666@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 22:40:23 -0000 On 9/7/2011 3:59 PM, Olle E. Johansson wrote: > 7 sep 2011 kl. 21:20 skrev Randell Jesup: > >> Signalling is secure, so it could even use a direct optional downgrade from SAVP* to AVP* (i.e. similar to the best-effort-strp draft) > How can you assert that signalling is secure? When, how? I'm assuming the signalling is occurring as SIP over an HTTPS connection to the server, or SIP-over-TLS - haven't really given it a lot of thought other than this connection is securable is we start with an HTTPS connection to the server. >> It's a tough call - guaranteed (local) security is nice, but I worry about those relay cases like taiwan->USA media gateway->taiwan. Not a huge deal on signaling/call-setup, but media... > I think that if we try to require secure media all the way through servers and gateways, we are setting the bar way too high for rtcweb. If we can handle the media that the browser handles in the local RTP streams and force that to a secure level, we have reached a good platform to continue to work with. > > In order to be able to proceed with confidentiality as a requirement, we have to discuss key exchange for the SRTP streams. I think there are at least two ways forward - to remove it from signalling path and go for an inband key exchange a la ZRTP or declare it out of scope for RTCweb and let the various protocols handle key exchange in different ways. Its going to be very hard for users to judge how secure an application is regardless of solution. Can you explain the difference between SIP SDES and ZRTP for your "normal" users? The security guy in me would of course recommend in-band so that the intermediary servers never see my key. The web guy says "oh yeah, but most of the calls will be between you and my conference mixer or media gateway anyway, so what's the difference?" > > I also think that secure identites (a la RFC4474 for SIP) should also be out of scope for RTCweb, but something we can continue to work with when building the applications and protocols that use rtcweb as a media handler. This is still an issue in SIP, XMPP and many other protocols and something we really need for realtime communication. All good issues for discussion (there's been some before) that I don't have time to respond to right now. -- Randell Jesup randell-ietf@jesup.org From dzonatas@gmail.com Wed Sep 7 15:52: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 E91B921F8DBA for ; Wed, 7 Sep 2011 15:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=-1.543, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNbFw91XQ6wQ for ; Wed, 7 Sep 2011 15:52:06 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B16021F8DB1 for ; Wed, 7 Sep 2011 15:52:06 -0700 (PDT) Received: by yie12 with SMTP id 12so153349yie.31 for ; Wed, 07 Sep 2011 15:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3i6Jt3KsfBEkweNszNDbyrOr+VbGBXX7Mp9kvcKzs0s=; b=lH3rF3MexG6hrK8CeBhnglD4mjP8kh83Sp1p7WxYkAnHmNE7kH2VPfoSVk4y9HIR9X A14JqKxP5etMoGGk7efglsjuTtII+o2XlFCCLflHWwgW/yuki7N+JKhCCffNC38D+Y6s Eq9YOx/oO2+6oLXeZ/np8J2WABjv9HADzE0BE= Received: by 10.236.200.195 with SMTP id z43mr35731497yhn.127.1315436036480; Wed, 07 Sep 2011 15:53:56 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id o43sm1735208yhe.11.2011.09.07.15.53.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Sep 2011 15:53:56 -0700 (PDT) Message-ID: <4E67F676.4080305@gmail.com> Date: Wed, 07 Sep 2011 15:55:50 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67CE16.40403@gmail.com> <4E67D206.9010908@alcatel-lucent.com> <4E67D8AC.3030409@gmail.com> <4E67DA11.7070203@alcatel-lucent.com> In-Reply-To: <4E67DA11.7070203@alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 22:52:07 -0000 Then the outside bank wall is the ROI, not silly when you compare real-time events to JPEG 2K. Security at the bank-teller, or ATM, what nobody thinks about anymore. We want proof that the double-entry system works between the hand-held mobile unit and ATMs such that the way they "solve tether-ball" TOGETHER is standard. Maybe no more lines at the bank; it's "wait state", like DDoS. Should our bank ATMs recognize our car proximities? Congestion. Then we consider if the precursory model is "being commented upon". Do we have world-wide security approved by the world bank? And, analogue-E911? Described within IETF that works flying over celltowers. I think the term "low-hanging fruit" is derogatory, culturally. I think we can still say "digital-only" if you want secure-by-default, or decide on import/export portal material across-state in cubic security units, or scale to virtual "entertainment" rooms. How about logoff-to-delete-all login-certificates; simple un-federialization for security compromises: "not silly when" everybody does not want their "on-logoff" exploited for connection quality and state recovery. AI is not on the agenda, yet maybe auto-mute *coughs* from the signals is? As well as, other recognized input by familiar auto-typists, and finish the book cover with two images, or half by difference in geolocation. I digress and flip-it-back, or expect further discussion on geo-mimes as SSRC, yet the forward-looking state would be by syllabic mimes for security. Maybe we still need some clear "technocratic" value for comparison with SSRC. Maybe this is just some description of one relational database without auto-increment, yet by auto-algorithm already given and stored. Next generation of steady-cam that is schema-aware on quadcopter with quad-cores: hardware-chron shared in APU bridged with one virtual core of the multi-core CPU. Simply, 55' TV with RC-control of 800x600 cam such that the feedback window position moves within larger display area instead of one always-centered stabilized-viewport. Helps to lay this out in 12D separation for the kernel with 6D of people you never met: a stack. The federal model puts the concepts in virtual bubbles, where security by binary is already known, globally. Servers want to simulate the "circles" put on Real3D, yet I see no certification that this technology is ready for BSD, yet bizarre'd for *cough* "fruit". I don't think their patent is gonna expire. We can ramble on about digital-only security without algorithms as passwords, yet we need ones like above for default security. I question security technologies that orders qubits within the limits of binary systems. I read this up and down and feel like I cross the line if I aim the PIP cam and track body sections, as that is easier language for others to help themselves. :) On 09/07/2011 01:54 PM, Igor Faynberg wrote: > :) > > On 9/7/2011 4:48 PM, Dzonatas Sol wrote: >> On 09/07/2011 01:20 PM, Igor Faynberg wrote: >>> >>> >>> On 9/7/2011 4:03 PM, Dzonatas Sol wrote: >>>> .... >>>> Flip-side: contracts already force encryption, and that is one >>>> reason why people do not want contracts; they want open wi-fi so >>>> neighbors have no walls across net points. >>> >>> I admit, I am not one of these people... And where the neighbors can >>> get in, anyone else can, too. >>> >> >> Experience only: we grew-up in areas without fences, only barb-wire, >> or "posts". In these fenced-in neighborhoods, I'm tired of the need >> "to pitch" openness to "anyone"; I sound evangelical now, yet others >> say street-smart. >> >> Good difference? >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From pkyzivat@alum.mit.edu Wed Sep 7 16:36: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 2A5A921F8B77 for ; Wed, 7 Sep 2011 16:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_00=-2.599, MANGLED_ONLINE=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 tqWPYINBT6gW for ; Wed, 7 Sep 2011 16:36:04 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 45D9721F8B6B for ; Wed, 7 Sep 2011 16:36:02 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta01.westchester.pa.mail.comcast.net with comcast id Vzdo1h0051YDfWL51zdtXo; Wed, 07 Sep 2011 23:37:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta20.westchester.pa.mail.comcast.net with comcast id Vzds1h00j0tdiYw3gzdsap; Wed, 07 Sep 2011 23:37:53 +0000 Message-ID: <4E680071.6080800@alum.mit.edu> Date: Wed, 07 Sep 2011 19:38:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mary Barnes References: <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> <4E666785.7040409@skype.net> <4E67513C.3030600@alvestrand.no> <4E677CB8.40203@skype.net> <4E678B44.9080208@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 07 Sep 2011 23:36:05 -0000 Mary, My assertion that the analog implementation of these features was easy was in reference to support of multiple "extensions" on a single analog line, as Matthew mentioned earlier, where shared line appearances and bridging come "for free", though with some limitations. I realize that it got considerably more complex with analog PBXs. Thanks, Paul On 9/7/11 2:24 PM, Mary Barnes wrote: > Just one comment below [MB]. > > Mary. > > On Wed, Sep 7, 2011 at 10:18 AM, Paul Kyzivat > wrote: > > Matthew, > > Good summary. > > I agree that webrtc provides flexibility in how to implement the UI > portions of these features with generic webrtc clients. But it > doesn't make these features trivial to implement. In particular, the > bridged line appearance still requires that a conference be > established. With generic rtcweb clients, that probably means a > central mixer. Setting that up is relatively easy if there is a > central media termination point in rtcweb server, and it *has* mixer > capabilities. > > My point is not that rtcweb doesn't help with this case - just that > these features that are so trivial in analog telephony just aren't > so simple with voip, no matter how you do it. > > [MB] These features we not trivial in analog telephony by any means > (speaking as someone who wrote LOTS of code for these ancient telephony > systems). IMHO, it's this misconception that the services and > functionality in analog telephony systems was simple that's led to the > difficulty in getting any operability for these services defined for > SIP. Many of the legacy telephone systems were no more designed for a > host of complex services than SIP was. However, it would have been nice > if services had been considered in the initial design for SIP. While > there is the concept that many services can be accomplished with basic > SIP building blocks/headers, we have way too many situations where this > has proven to not be at all simple. But, I don't think SIP/VoIP is any > worse off than were the legacy systems. And, I agree with Paul there > isn't any magic dust that will make it any easier for RTCWEB to support > these features. [/MB] > > > Thanks, > Paul > > > On 9/7/11 10:16 AM, Matthew Kaufman wrote: > > On 9/7/2011 4:10 AM, Harald Alvestrand wrote: > > > Since more people than I may be confused, I'm forking a > subthread... > > what is a bridged line appearance, and why is it hard to do > in SIP? > > My terminology cache is totally blank. > > > Key system (and home phone) emulation requires two things that > are hard > to do (because there's no final specification, not because it is > impossible) (and because there's 3+ alternatives, and almost no > phones > implement more than one of them) in SIP: > > 1. Shared line appearance > > This is where you can be on a call on one handset, see that the > line is > in use at the other handset. Place the call on hold at the > first, pick > it up at the second. > > In business PBX cases, this is used for executive/assistant > cases. In > key system emulation it is used for "Bob, pick up the call > holding on > line 3". And for home phones it is the usual "put the phone on > hold in > the kitchen, pick it up in the den." (My wife wanted this > functionality, > so I had to add proprietary support for shared line appearance on my > home PBX.) > > 2. Bridged line appearance > > This is where you can be on a call on one handset, see that line > is in > use at the other handset, and pick up the second handset to join > the call. > > In the business PBX and key system case this is sometimes used for > supervisors to join a call to help, but the real common case is > the home > phones... "kids, go pick up the extension in the living room and > talk to > grandma." > > With POTS, this works by simply paralleling two handsets on the same > copper pair. For SIP it requires everything shared line > appearance does > *plus* automatic barge-in + conference on pickup. > > The BLISS WG has been working, for a long time, on taking the > various > interim proposals and creating a standard out of them, but we're > still > not there... and yet without it, there's no way to use phones > from two > different vendors to accomplish this. > > Whereas with WebRTC implemented *without SIP*, it is fairly easy to > build a web app that runs on multiple browsers from multiple > vendors and > implements this. > > So this type of ability to innovate and implement applications > without > going through the standards process is why we *definitely* don't > want > SIP baked in to the browser. > > Not to be confused with the arguments against SDP offer/answer, > which is > only slightly affected by the above use cases (in that you can do > smarter things at the bridge for bridged line appearance if you > aren't > doing a reinvite/re-offer/re-answer but instead have on hand all the > capabilities of the first device when the second goes to join). > > Matthew Kaufman > _________________________________________________ > 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 pkyzivat@alum.mit.edu Wed Sep 7 17:11: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 6942C21F8C72 for ; Wed, 7 Sep 2011 17:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 uTko9BXvUzoD for ; Wed, 7 Sep 2011 17:11:51 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 280EB21F8C34 for ; Wed, 7 Sep 2011 17:11:50 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta14.westchester.pa.mail.comcast.net with comcast id Vvmv1h0071c6gX85E0Dizn; Thu, 08 Sep 2011 00:13:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta23.westchester.pa.mail.comcast.net with comcast id W0Dg1h0210tdiYw3j0Dh73; Thu, 08 Sep 2011 00:13:42 +0000 Message-ID: <4E6808D5.7090709@alum.mit.edu> Date: Wed, 07 Sep 2011 20:14:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67D1F4.10002@mozilla.com> In-Reply-To: <4E67D1F4.10002@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 00:11:52 -0000 Chris, I agree with you that the UI indication of security is important. But its also *hard* for this application, for a variety of reasons: - While it may be easy for the browser to know if the media stream is itself secured, its hard (impossible) to know that its secured to its ultimate end point. That is the problem with intermediaries. - it may turn out that not all the streams in the "call" have the same degree of security. Of course this can all be dealt with via proper definition of what the UI indication means, and doesn't mean. But doing that will just render it meaningless to many users. To be widely understood, the indication will need to be simple, and closely aligned with what people "expect". Consider a stream that is secured to a PSTN gateway, and then travels over the PSTN to somebody's phone. Should that be considered a "secure" call? Or an "insecure" call? Or somewhere between those? Its going to be hard work to figure out what can both be reliably reported to users and also be understandable and meaningful to users. Thanks, Paul On 9/7/11 4:20 PM, Christopher Blizzard wrote: > On 9/7/2011 12:20 PM, Randell Jesup wrote: >> Splitting the two topics.... >> >> >> On 9/7/2011 3:07 AM, Olle E. Johansson wrote: >> >>> To fearlessly jump into another can of worms, I still think we should >>> have confidentiality - SRTP - by default. We know that these >>> applications will run on a myriad of devices on a myriad of networks >>> and it will not work to let users have to decided whether or not they >>> want confidentiality. If Skype did not have confidentiality by >>> default, there would be articles every summer and xmas in the evening >>> taboloids about how easy it is to listen in to your neighbours calls >>> and that would have hurted Skype badly. >>> >> >> There is a strong argument for this. The strongest argument for the >> other side is you don't need a media gateway to talk to non-WebRTC >> endpoints, just a signalling gateway. This means less delay >> potentially (especially if the application provider has gateways only >> in one geographic location) and less expense for the server provider >> for a pretty common usecase (gateway to PSTN). The delay could be a >> significant issue. >> It was also brought up that some usecases for internal PBX/business >> use would not need/prefer forced encryption. As mentioned at the >> meeting, encrypting to the media gateway only gets you a modicum of >> privacy (though it might protect you from the "neighbor's wifi >> capture" case). >> >> You could make forced-encryption the default, and allow the >> application control over whether to allow it is turned off for >> specific cases, like a PSTN call, or under the server's control. >> Signalling is secure, so it could even use a direct optional downgrade >> from SAVP* to AVP* (i.e. similar to the best-effort-strp draft) >> >> It's a tough call - guaranteed (local) security is nice, but I worry >> about those relay cases like taiwan->USA media gateway->taiwan. Not a >> huge deal on signaling/call-setup, but media... >> >> > > I want secure-by-default, maybe even secure-only. > > Even if it's not secure-only there's also an important UI consideration > depending how we end up doing that in browsers. In the past we've made > the secure mode special (the lock icon in the early days, now the > green/blue bar) but I think that we should be making the insecure mode > special. That is, always mark a connection as very clearly unencrypted > via UI affordances. Just like banks "wanting to know how to get the lock > icon" we should be making call sites "wanting to know how to get rid of > that huge ugly warning that makes us look bad." > > Once again, I would much prefer secure-only, but I'll take > secure-by-default across browsers if I can get it. > > --Chris > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From cbran@cisco.com Wed Sep 7 17:41: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 D9E7B21F8C71 for ; Wed, 7 Sep 2011 17:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=-3.333, 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 S6Fhev2FJs5O for ; Wed, 7 Sep 2011 17:41:48 -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 3A5B221F8C6F for ; Wed, 7 Sep 2011 17:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cbran@cisco.com; l=1106; q=dns/txt; s=iport; t=1315442619; x=1316652219; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=jVTZmDeTubivO78jKiPpEszn8ezSjaSmM9CbkrpFnQI=; b=N2jhDYHz2GyE8CMcA0oFFPsLpoX7Cr5bduAjae5UM1RKIwbZTdqak6RL cwNUVhgjC2sV4SuHdrCBY75vda5tXwjuArDXBlBmu944SNYJtxCsqKn9L 5z9N5W289dSFObViz5CdU3ql5ooE+cZsRl/U0xX2R1vervm+5/0rhvVMA E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUHAGkPaE6rRDoI/2dsb2JhbABDmTCOQniBRgEBAQEDEgEnAgE6FAEICQgDAQJ8AQEFAwEBBBMih1eYHoEjAZ4shmsEh2yEUoZ0hRuEYoc5 X-IronPort-AV: E=Sophos;i="4.68,348,1312156800"; d="scan'208";a="817007" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 08 Sep 2011 00:43:28 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p880hSBL027745 for ; Thu, 8 Sep 2011 00:43:28 GMT Received: from xmb-sjc-228.amer.cisco.com ([128.107.191.125]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Sep 2011 17:43:28 -0700 Received: from 10.20.222.55 ([10.20.222.55]) by xmb-sjc-228.amer.cisco.com ([128.107.191.125]) with Microsoft Exchange Server HTTP-DAV ; Thu, 8 Sep 2011 00:43:28 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 07 Sep 2011 17:43:30 -0700 From: cbran To: Message-ID: Thread-Topic: New Version Notification for draft-cbran-rtcweb-nat-01.txt Thread-Index: AcxtwFQoH1zx5WoEW0GT3Z4/xqTLJA== In-Reply-To: <20110908002606.14289.74237.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Sep 2011 00:43:28.0441 (UTC) FILETIME=[533AC290:01CC6DC0] Subject: [rtcweb] FW: New Version Notification for draft-cbran-rtcweb-nat-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, 08 Sep 2011 00:41:49 -0000 Hi All, As an action item from IETF 81, I have merged together the NAT traversal drafts from Matthew and myself. Below is a link to the 01 version of the draft. http://tools.ietf.org/html/draft-cbran-rtcweb-nat-01 Comments most welcome. -Cary ------ Forwarded Message From: Date: Wed, 07 Sep 2011 17:26:06 -0700 To: Cary Bran Cc: , Cary Bran , , Subject: New Version Notification for draft-cbran-rtcweb-nat-01.txt A new version of I-D, draft-cbran-rtcweb-nat-01.txt has been successfully submitted by Cary Bran and posted to the IETF repository. Filename: draft-cbran-rtcweb-nat Revision: 01 Title: RTC-Web Network Address Translation Creation date: 2011-09-06 WG ID: Individual Submission Number of pages: 12 Abstract: This document outlines the network address translation (NAT) mechanisms and requirements for RTC-Web client applications. The IETF Secretariat ------ End of Forwarded Message From silviapfeiffer1@gmail.com Wed Sep 7 18:14: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 6459421F8CD9 for ; Wed, 7 Sep 2011 18:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 0oGASuy9dsqa for ; Wed, 7 Sep 2011 18:14:15 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB2621F8CAF for ; Wed, 7 Sep 2011 18:14:15 -0700 (PDT) Received: by gwb17 with SMTP id 17so359874gwb.15 for ; Wed, 07 Sep 2011 18:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=g2IMd7YZznr/NZ2UJYBuPhHTNsqJpfHX2CyG/Any9Ks=; b=rjqZRUQTYqSpK8kqB39WpVMkSxB+w+ZqOaVr27WWq8/C5V14pjNYw3t0wdFVr5ZolX D7rqJRCf33fX/msuhwr1FCMsEQ/XYwbBzh2nCotJhld2YNH+ZKasxFWmTw3uGDCd9mYu VlSRh46ohC72lDGjZds2DDSSeCXmJp+3gHqrQ= Received: by 10.236.76.225 with SMTP id b61mr337228yhe.92.1315444566066; Wed, 07 Sep 2011 18:16:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.203.5 with HTTP; Wed, 7 Sep 2011 18:15:46 -0700 (PDT) In-Reply-To: <4E67F0A2.1070308@skype.net> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3EE.50707@jesup.org> <4E67F0A2.1070308@skype.net> From: Silvia Pfeiffer Date: Thu, 8 Sep 2011 11:15:46 +1000 Message-ID: To: Matthew Kaufman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 01:14:16 -0000 If implementations count for anything, check out: http://phono.com/ and https://docs.google.com/present/view?id=3D0AcNAXuadeXIxZGY4NDl4Z2RfNTlod3Br= OXNjZA&hl=3Den&pli=3D1 They use SIP with web sockets. Cheers, Silvia. On Thu, Sep 8, 2011 at 8:30 AM, Matthew Kaufman wrote: > On 9/7/11 12:20 PM, Randell Jesup wrote: >> >> I also started from the same point - assume SIP. =A0SIP gives you all th= e >> things that the zillions of hours and emails to define it and define >> extensions and secure it provides, without having to reinvent all those >> wheels (or ask app developers to reinvent them). =A0Why go through the >> horrible pain of choosing something else, or why throw the app developer= s to >> the wolves to fend for themselves? >> >> However... >> >> Two things have swayed me. =A0The primary one is the suggestion of >> Offer/Answer in the browser. =A0This breaks out the important negotiatio= n >> piece that almost any application would need, and while not perfect, SDP= O/A >> is a zillion times simpler than SIP with all the extensions one could us= e. > > I agree with this. While I am also opposed to SDP O/A, these are two > unrelated arguments to have... and not baking a SIP phone into the browse= r > is *more* important than avoiding a repeat of the offer/answer problems. > >> >> The other thing that swayed me was thinking about federation and the app= s >> that will be built with this. =A0A webrtc app talks to its (web)server, = other >> webrtc clients running the app that talk to the server, and to other web= rtc >> applications/networks that federate with it (and their clients). >> >> Federation is in the same hands as the person who provides/wrote the app= . >> =A0If they have no interest in federation you can't force it, and they m= ay >> have no use for all the fancy SIP standards. > > And for numerous types of apps (think: server-based augmented reality > systems), "federation" doesn't even make sense. > >> >> On the other hand, if they *want* to either provide access to the wider >> communication net that is the PSTN network, now or in the future, or the= y >> want easy federation with other networks, it behooves them to use SIP or >> something very close to it or equivalent/convertible (at a basic level a= t >> least) to it. >> >> So what conclusions do I draw from this? >> >> 1) O/A via SDP in the browser simplifies a lot of things (including >> handling new codecs, etc). =A0It doesn't extremely limit an application, >> though we should think about how an application can interact with the >> fmtp/etc parameters used. > > I agree that it would simplify some interop cases, but at an unfortunate > cost in lack of flexibility and functionality. Still not nearly as bad as= if > we put a full SIP stack in there though. > >> >> 2) SIP as a *separate* item that can be cleanly and easily *added* to a >> webrtc app to handle the call setup/etc is a good idea. > > I would be open to looking at this again, *after* RTC is already in brows= ers > and successful, to see if it actually solves a real use case. > > Matthew Kaufman > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From cb.list6@gmail.com Wed Sep 7 18:38: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 1BD0D21F8B48 for ; Wed, 7 Sep 2011 18:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.832 X-Spam-Level: X-Spam-Status: No, score=-3.832 tagged_above=-999 required=5 tests=[AWL=-0.234, 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 VERhxzvff72i for ; Wed, 7 Sep 2011 18:38:35 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 812FE21F8B43 for ; Wed, 7 Sep 2011 18:38:35 -0700 (PDT) Received: by pzk33 with SMTP id 33so1823070pzk.18 for ; Wed, 07 Sep 2011 18:40:26 -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=f3OCCXuUlXbZ3rcEhQUPfQuGUu4rwgEBYZBIsfPSz2E=; b=lwrdsonpff4TAodCeOA0jIKy4u3cZ0JfcyKbdRMo+LhhRHacrirB9+ss2mq1Y2W26C BZRO3B0BCbvpP/Aol6rc2RTBCtx0xGFSIKeBIG4ImT3XJ74pbYiEj4AYRKn208XlPuEa ArFACUcb1eyTRPuQxShPQCso3FI6YnW851k68= MIME-Version: 1.0 Received: by 10.68.157.230 with SMTP id wp6mr186008pbb.428.1315446026263; Wed, 07 Sep 2011 18:40:26 -0700 (PDT) Received: by 10.143.41.1 with HTTP; Wed, 7 Sep 2011 18:40:26 -0700 (PDT) Received: by 10.143.41.1 with HTTP; Wed, 7 Sep 2011 18:40:26 -0700 (PDT) In-Reply-To: References: <20110908002606.14289.74237.idtracker@ietfa.amsl.com> Date: Wed, 7 Sep 2011 18:40:26 -0700 Message-ID: From: Cameron Byrne To: cbran Content-Type: multipart/alternative; boundary=f46d042f938e1dde1b04ac642536 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] FW: New Version Notification for draft-cbran-rtcweb-nat-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, 08 Sep 2011 01:38:36 -0000 --f46d042f938e1dde1b04ac642536 Content-Type: text/plain; charset=ISO-8859-1 On Sep 7, 2011 5:43 PM, "cbran" wrote: > > Hi All, > > As an action item from IETF 81, I have merged together the NAT traversal > drafts from Matthew and myself. Below is a link to the 01 version of the > draft. > > http://tools.ietf.org/html/draft-cbran-rtcweb-nat-01 > > Comments most welcome. > > -Cary Thanks for posting this. An increasingly common usecase will be network based nat64 protocol translation. I know of multiple large mobile phone providers headed down this path. So can we work in support for rfc 6146 and/or 6156? Cameron > ------ Forwarded Message > From: > Date: Wed, 07 Sep 2011 17:26:06 -0700 > To: Cary Bran > Cc: , Cary Bran , > , > Subject: New Version Notification for draft-cbran-rtcweb-nat-01.txt > > A new version of I-D, draft-cbran-rtcweb-nat-01.txt has been successfully > submitted by Cary Bran and posted to the IETF repository. > > Filename: draft-cbran-rtcweb-nat > Revision: 01 > Title: RTC-Web Network Address Translation > Creation date: 2011-09-06 > WG ID: Individual Submission > Number of pages: 12 > > Abstract: > This document outlines the network address translation (NAT) > mechanisms and requirements for RTC-Web client applications. > > > > > The IETF Secretariat > > ------ End of Forwarded Message > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --f46d042f938e1dde1b04ac642536 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 7, 2011 5:43 PM, "cbran" <cbran@cisco.com> wrote:
>
> Hi All,
>
> As an action item from IETF 81, I have merged together the NAT travers= al
> drafts from Matthew and myself. =A0Below is a link to the 01 version o= f the
> draft.
>
> http:= //tools.ietf.org/html/draft-cbran-rtcweb-nat-01
>
> Comments most welcome.
>
> -Cary

Thanks for posting this.=A0 An increasingly common usecase will be netwo= rk based nat64 protocol translation. I know of multiple large mobile phone = providers headed down this path.=A0 So can we work in support for rfc 6146 = and/or 6156?

Cameron

> ------ Forwarded Message
> From: <internet-drafts@= ietf.org>
> Date: Wed, 07 Sep 2011 17:26:06 -0700
> To: Cary Bran <cbran@cisco.com>
> Cc: <fluffy@cisco.com>, = Cary Bran <cbran@cisco.com>, > <matthew.kaufman@skype= .net>, <jdrosen@skype.net>
> Subject: New Version Notification for draft-cbran-rtcweb-nat-01.txt >
> A new version of I-D, draft-cbran-rtcweb-nat-01.txt has been successfu= lly
> submitted by Cary Bran and posted to the IETF repository.
>
> Filename: =A0draft-cbran-rtcweb-nat
> Revision: =A001
> Title: =A0 RTC-Web Network Address Translation
> Creation date: =A02011-09-06
> WG ID: =A0 Individual Submission
> Number of pages: 12
>
> Abstract:
> =A0 This document outlines the network address translation (NAT)
> =A0 mechanisms and requirements for RTC-Web client applications.
>
>
>
>
> The IETF Secretariat
>
> ------ End of Forwarded Message
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--f46d042f938e1dde1b04ac642536-- From blizzard@mozilla.com Wed Sep 7 21:06: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 6D7ED21F8B08 for ; Wed, 7 Sep 2011 21:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZV+n9t7bg-8A for ; Wed, 7 Sep 2011 21:06:08 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4A021F852E for ; Wed, 7 Sep 2011 21:06:08 -0700 (PDT) Received: from [192.168.1.12] (173-228-106-53.dsl.dynamic.sonic.net [173.228.106.53]) (Authenticated sender: blizzard@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id E17DE4AEDE3; Wed, 7 Sep 2011 21:07:57 -0700 (PDT) Message-ID: <4E6796CF.2060807@mozilla.com> Date: Wed, 07 Sep 2011 09:07:43 -0700 From: Christopher Blizzard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Paul Kyzivat References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67D1F4.10002@mozilla.com> <4E6808D5.7090709@alum.mit.edu> In-Reply-To: <4E6808D5.7090709@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 04:06:08 -0000 On 9/7/2011 5:14 PM, Paul Kyzivat wrote: > Its going to be hard work to figure out what can both be reliably > reported to users and also be understandable and meaningful to users. Indeed. It suffers from the same problem that self-signed certs suffer from. That is, you can't guarantee end to end encryption unless you know who you are talking to. And in our current system requires 3rd party signings to do that, which as we've seen over the last couple of weeks is not always...great. Do we want to try and tackle that here? (I'm guessing not!) --Chris From pravindran@sonusnet.com Wed Sep 7 21:33: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 65DD521F8AFC for ; Wed, 7 Sep 2011 21:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.094, 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 dHLnFPM9+Tao for ; Wed, 7 Sep 2011 21:33:14 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1A75B21F8AF1 for ; Wed, 7 Sep 2011 21:33:14 -0700 (PDT) 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 p884ZT31024362; Thu, 8 Sep 2011 00:35:29 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 00:34:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6DE0.A949D016" Date: Thu, 8 Sep 2011 10:04:55 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0906@sonusinmail02.sonusnet.com> In-Reply-To: <4E67EED2.2000207@skype.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] Thread-Index: AcxtrMQfnV/jTVtjQ2ynrmKrMW+h2wAL5brw References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67EED2.2000207@skype.net> From: "Ravindran Parthasarathi" To: "Matthew Kaufman" X-OriginalArrivalTime: 08 Sep 2011 04:34:59.0798 (UTC) FILETIME=[AB1F9F60:01CC6DE0] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 04:33:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6DE0.A949D016 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Matthew, =20 Could you please let me know why early media MUST exist in browser to browser communication. Remote ringback (18x with SDP) is less used in lot of existing SIP deployments as well. I'm talking about RFC 3261 User Agent (UA) functionality in browser which helps browser to browser real-time communication using RTCWeb1.0. SIP phone is very different from SIP UA which is using HTTP as a configuration interface.=20 =20 Also, RTCWEB client + RTCWeb server makes to feel a modern exchange in web world (Plain Old Telephony System phone with exchange architecture). I think so because POTS phones are dumb which does not know its identity and every event like offhook, onhook has to passed to exchange whereas RTCWeb client (browser) has to pass every event to webserver and webserver has whole intelligence to make it work. In case it is local exchange (same site like skype), there will be no need of signaling but the identity is outside the single site, it is not defined and it is outside the scope of RTCWEb. =20 Please read inline. =20 Thanks Partha =20 From: Matthew Kaufman [mailto:matthew.kaufman@skype.net]=20 Sent: Thursday, September 08, 2011 3:53 AM To: Ravindran Parthasarathi Cc: igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] =20 On 9/7/11 10:29 AM, Ravindran Parthasarathi wrote:=20 Matthew, =20 When I asked for SIP, I have meant RFC 3261 only.=20 As I pointed out earlier, this is the top of a very slippery slope. Certainly you must have meant 3261 + early media + PRACK (for instance), yes? The basic reason for asking SIP is to make the basic call works between browser to browser across web servers. SIP is in no way required to make this happen. [Partha] Please explain in more detail why so. =20 Without SIP in browser, it is not going happen.=20 Totally disagree. Innovative application is going to be proprietary whether it is HTTP or SIP or any other protocol for that matter. True. But having to reverse-engineer out the phone part is really painful for the application developer who is trying to build something else. [Partha] I have worked in multiple SIP UA implementation which is not restricted to telecom or unified communication as part of one of best selling SIP UA stack company. I'm really wondering why phone to be reverse Engineered. I'm wondering why browser is not possible to acts as SIP UA.=20 =20 =20 My reasoning are as follows: SIP makes browser more intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG.=20 SIP in the browser makes the browser less *flexible* than an API with more direct control over the internal objects (camera, codec, network connection) and yet no more intelligent, as the browser has a runtime that can be programmed to do anything you want at the client side. [Partha] I'm talking abt SIP UA framework which provides Javascript API. There is no flexibility issue here because Javascript API will have all the control which you are interested. The importance of basic call interop is that there is no need of many individual id like skype id, Google id and yahoo id by everyone in the world to communicate others. I wish to have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.=20 This isn't going to happen, and is even closer to my fears about "IMAP in the browser" expressed earlier. [Partha] they are different. SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provider. So what? I hope people understand that RTCWEB could be about so much more than enterprise and telecom providers doing two-party phone calls. Among other things, you can build augmented reality systems out of it (see how Flash streaming has been used similarly), multi-party experiences that aren't calls (Google hangouts), and many other applications we haven't even thought of yet... as long as we don't cripple the APIs. There is no need to build two different signaling logic in VoIP servers for each service. Your own example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible to avoided by having one signaling protocol. It doesn't even work over that "one signaling protocol", so that doesn't help. And again, there is no reason that a web site providing RTC applications to/from a browser need necessarily be serving "SIP phones" as clients as well. Maybe that just isn't the business they're in. =20 In RTCWEB does not standardize the signaling protocol interface between browsers, the interop across webservers is next to impossible Totally disagree. We need to standardize the *media transport* between the browsers, and W3C needs to standardize the *API* by which we can send Javascript to the browser that executes the same way on every browser, but that doesn't mean the signaling protocol needs to be specified any more than IETF needed to intervene to ensure that the XML or JSON data that goes between your browser and Gmail is the same as the data that goes between your browser and Yahoo mail when you're using each to compose email messages. [Partha] Please note that I'm talking about viewer about partha.com to start the real-time communication with partha with his (Android) browser if they are interested. To achieve this, partha.com webdeveloper has no need to build call control in case SIP exists in both browsers.=20 and it will be restricted to single webserver (company) only.=20 Disagree. Just like Gmail and Yahoo mail can send messages to each other's users over a standard protocol for federation, so can RTCWEB. In fact, SIP is probably a great choice for inter-provider trunking. And conveniently, we plan to support the same *media transport* that other SIP devices use (RTP), so there'll be even more interoperability than just browser-to-browser federated between providers. Please let me know in case I'm missing something here. See above. Matthew Kaufman ------_=_NextPart_001_01CC6DE0.A949D016 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Matthew,

 

Could you please let me know why early media MUST exist = in browser to browser communication. Remote ringback (18x with SDP) is less used in = lot of existing SIP deployments as well. I’m talking about RFC 3261 User = Agent (UA) functionality in browser which helps browser to browser real-time communication using RTCWeb1.0. SIP phone is very different from SIP UA = which is using HTTP as a configuration interface.

 

Also, RTCWEB client + RTCWeb server makes to feel a = modern exchange in web world (Plain Old Telephony System phone with exchange architecture). I think so because POTS phones are dumb which does not = know its identity and every event like offhook, onhook has to passed to exchange whereas = RTCWeb client (browser) has to pass every event to webserver and webserver has = whole intelligence to make it work. In case it is local exchange (same site = like skype), there will be no need of signaling but the identity is outside the = single site, it is not defined and it is outside the scope of = RTCWEb.

 

Please read inline.

 

Thanks

Partha

 

From: Matthew Kaufman [mailto:matthew.kaufman@skype.net]
Sent: Thursday, September 08, 2011 3:53 AM
To: Ravindran Parthasarathi
Cc: igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remote recording - RTC-Web client acting as SIPREC session recording = client]

 

On 9/7/11 10:29 AM, Ravindran Parthasarathi wrote: =

Matthew,

 

When I asked for SIP, I have meant RFC 3261 only.


As I pointed out earlier, this is the top of a very slippery slope.

Certainly you must have meant 3261 + early media + PRACK (for instance), = yes?


The basic reason for asking SIP is to make the basic call works between = browser to browser across web servers.


SIP is in no way required to make this happen.

[Partha] Please explain in more detail why = so.

 




Without SIP in browser, it is not going happen.


Totally disagree.

Innovative application is going to be proprietary whether it is HTTP or SIP or any = other protocol for that matter.


True. But having to reverse-engineer out the phone part is really = painful for the application developer who is trying to build something else.

[Partha] I have worked in multiple SIP UA implementation = which is not restricted to telecom or unified communication as part of one of = best selling SIP UA stack company. I’m really wondering why phone to be reverse Engineered. I’m wondering why browser is not possible to = acts as SIP UA.

 




 

My reasoning are as follows:

SIP makes browser more = intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG. =


SIP in the browser makes the browser less *flexible* than an API with = more direct control over the internal objects (camera, codec, network = connection) and yet no more intelligent, as the browser has a runtime that can be programmed to do anything you want at the client side.

[Partha] I’m talking abt SIP UA framework which = provides Javascript API. There is no flexibility issue here because Javascript = API will have all the control which you are = interested.




The importance of basic call = interop is that there is no need of many individual id like skype id, Google = id  and yahoo id by everyone in the world to communicate others. I wish to = have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.


This isn't going to happen, and is even closer to my fears about = "IMAP in the browser" expressed earlier.

[Partha] they are = different.




SIP helps to interop for = basic call with other existing realtime application in Enterprise & Telecom = provider.


So what? I hope people understand that RTCWEB could be about so much = more than enterprise and telecom providers doing two-party phone calls.

Among other things, you can build augmented reality systems out of it = (see how Flash streaming has been used similarly), multi-party experiences that = aren't calls (Google hangouts), and many other applications we haven't even = thought of yet... as long as we don't cripple the APIs.

There is no need to build two different signaling logic in VoIP servers for each service. Your own = example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible = to avoided by having one signaling protocol.


It doesn't even work over that "one signaling protocol", so = that doesn't help. And again, there is no reason that a web site providing = RTC applications to/from a browser need necessarily be serving "SIP phones" as clients as well. Maybe that just isn't the business = they're in.

 

In RTCWEB does not standardize the signaling protocol interface between = browsers, the interop across webservers is next to = impossible


Totally disagree. We need to standardize the *media transport* between = the browsers, and W3C needs to standardize the *API* by which we can send Javascript to the browser that executes the same way on every browser, = but that doesn't mean the signaling protocol needs to be specified any more than = IETF needed to intervene to ensure that the XML or JSON data that goes = between your browser and Gmail is the same as the data that goes between your browser = and Yahoo mail when you're using each to compose email messages.

[Partha] Please note that I’m talking about viewer = about partha.com to start the real-time communication with partha with his (Android) = browser if they are interested. To achieve this, partha.com webdeveloper has no = need to build call control in case SIP exists in both browsers. =




and it will be restricted to single webserver (company) only. =


Disagree. Just like Gmail and Yahoo mail can send messages to each = other's users over a standard protocol for federation, so can RTCWEB. In fact, = SIP is probably a great choice for inter-provider trunking. And conveniently, = we plan to support the same *media transport* that other SIP devices use (RTP), = so there'll be even more interoperability than just browser-to-browser = federated between providers.


Please let  me know in case I’m missing = something here.


See above.

Matthew Kaufman

------_=_NextPart_001_01CC6DE0.A949D016-- From bernard_aboba@hotmail.com Wed Sep 7 21:43: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 D461821F8BB1 for ; Wed, 7 Sep 2011 21:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[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 8OQorlEIHDk0 for ; Wed, 7 Sep 2011 21:43:37 -0700 (PDT) Received: from blu0-omc1-s21.blu0.hotmail.com (blu0-omc1-s21.blu0.hotmail.com [65.55.116.32]) by ietfa.amsl.com (Postfix) with ESMTP id F131221F8BAE for ; Wed, 7 Sep 2011 21:43:36 -0700 (PDT) Received: from BLU152-W50 ([65.55.116.9]) by blu0-omc1-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Sep 2011 21:45:28 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_1327175e-311a-44fd-b17e-6189dc38585e_" X-Originating-IP: [70.88.131.169] From: Bernard Aboba To: , Date: Wed, 7 Sep 2011 21:45:27 -0700 Importance: Normal In-Reply-To: <4E6756C1.9060207@alvestrand.no> References: , <4E6756C1.9060207@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 08 Sep 2011 04:45:28.0468 (UTC) FILETIME=[21D70D40:01CC6DE2] Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 04:43:37 -0000 --_1327175e-311a-44fd-b17e-6189dc38585e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > 1) The media negotiations will be done using the same SDP offer/answer = semantics that are used in SIP. > To be precise - you're suggesting that we use RFC 3264 offer/answer=20 > semantics. (That RFC is 25 pages long. RFC 3261=2C the core SIP document= =2C=20 > is 269 pages=2C and is NOT a normative reference from 3264. I am anxious= =20 > to avoid having a normative dependency on 3261.) >=20 > I agree with this. [BA] I do *not* agree that RTCWEB should have to support every aspect of SD= P offer/answer. Basic offer/answer=2C sure. All potential corner cases? = Not necessarily.=20 > > 2) It will be possible to gateway between legacy SIP devices that suppo= rt ICE and appropriate RTP / SDP mechanisms and codecs without using a medi= a gateway. A signaling gateway to convert between the signaling on the web = side to the SIP signaling may be needed. > I agree with this - I think the "may be needed" will turn out to be=20 > "will be needed"=2C but some portion of that gateway can be implemented b= y=20 > Javascript running in the browser=2C if desirable. [BA] This seems like a good principle=2C but I'm not clear that it will wor= k with all use cases. For example=2C what happens in the E911 use cases wh= en an RTCWEB implementation attempts to make a call to a PSAP implementing = NENA i3 Stage 3? If you don't have a media gateway=2C then the browser wil= l need to implement one of the mandated codecs on the PSAP side. So in tho= se use cases=2C eliminating the media gateway implies making G.711 and H.26= 4 mandatory-to-implement. =20 > > 3) When a new codec is specified=2C and the SDP for the new codec is sp= ecified in the MMUSIC WG=2C no other standardization would should be requir= ed for it to be possible to use that in the web browsers. Adding a new code= cs which might have new SDP parameters should not change the APIs between t= he browser and javascript application. As soon as the browsers support the = new codec=2C old applications written before the codecs was specified shoul= d automatically be able to use the new codec where appropriate with no chan= ges to the JS applications. > I agree with this (modulo spelling and WG name fixups). [BA] Agree with "no new standardization". But that doesn't mean that appli= cations will automatically "just work"=2C right? That's a much harder requ= irement. > I decided that the fight against SDP was not worth fighting after=20 > listening to the dozens of WGs doing SDP extensions for various=20 > purposes=2C many of which might make sense to incorporate in a browser=20 > platform=2C and concluding that SDP wouldn't hold still enough for us to= =20 > specify a gateway from/to it. [BA] Agree that it's not worth fighting=2C but making it clear what we do a= nd do not support will be a "fight" of sorts. That is=2C unless you're wil= ling to require that the browser be able to *everything* enabled by RFC 326= 4. Personally=2C I don't think that is worthwhile. = --_1327175e-311a-44fd-b17e-6189dc38585e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B >=3B 1) The media negotiations will be done using the sam= e SDP offer/answer semantics that are used in SIP.
>=3B To be precise = - you're suggesting that we use RFC 3264 offer/answer
>=3B semantics.= (That RFC is 25 pages long. RFC 3261=2C the core SIP document=2C
>= =3B is 269 pages=2C and is NOT a normative reference from 3264. I am anxiou= s
>=3B to avoid having a normative dependency on 3261.)
>=3B >=3B I agree with this.

[BA] I do *not* agree that RTCWEB should = have to support every aspect of SDP offer/answer. =3B =3B Basic off= er/answer=2C sure. =3B All potential corner cases? =3B Not necessar= ily.

>=3B >=3B 2) It will be possible to gateway between legacy= SIP devices that support ICE and appropriate RTP / SDP mechanisms and code= cs without using a media gateway. A signaling gateway to convert between th= e signaling on the web side to the SIP signaling may be needed.

>= =3B I agree with this - I think the "may be needed" will turn out to be >=3B "will be needed"=2C but some portion of that gateway can be impleme= nted by
>=3B Javascript running in the browser=2C if desirable.
[BA] This seems like a good principle=2C but I'm not clear that it will w= ork with all use cases. =3B For example=2C what happens in the E911 use= cases when an RTCWEB implementation attempts to make a call to a PSAP impl= ementing NENA i3 Stage 3? =3B If you don't have a media gateway=2C then= the browser will need to implement one of the mandated codecs on the PSAP = side. =3B So in those use cases=2C eliminating the media gateway implie= s making G.711 and H.264 mandatory-to-implement. =3B

>=3B >= =3B 3) When a new codec is specified=2C and the SDP for the new codec is sp= ecified in the MMUSIC WG=2C no other standardization would should be requir= ed for it to be possible to use that in the web browsers. Adding a new code= cs which might have new SDP parameters should not change the APIs between t= he browser and javascript application. As soon as the browsers support the = new codec=2C old applications written before the codecs was specified shoul= d automatically be able to use the new codec where appropriate with no chan= ges to the JS applications.
>=3B I agree with this (modulo spelling an= d WG name fixups).

[BA] Agree with "no new standardization". =3B= But that doesn't mean that applications will automatically "just work"=2C = right? =3B That's a much harder requirement.

>=3B I decided th= at the fight against SDP was not worth fighting after
>=3B listening = to the dozens of WGs doing SDP extensions for various
>=3B purposes= =2C many of which might make sense to incorporate in a browser
>=3B p= latform=2C and concluding that SDP wouldn't hold still enough for us to >=3B specify a gateway from/to it.

[BA] Agree that it's not worth= fighting=2C but making it clear what we do and do not support will be a "f= ight" of sorts. =3B That is=2C unless you're willing to require that th= e browser be able to *everything* enabled by RFC 3264. =3B Personally= =2C I don't think that is worthwhile.
= --_1327175e-311a-44fd-b17e-6189dc38585e_-- From pravindran@sonusnet.com Wed Sep 7 22:08: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 3433C21F8AE1 for ; Wed, 7 Sep 2011 22:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.092, 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 fjAKzD5hM3gC for ; Wed, 7 Sep 2011 22:08:41 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0607421F8AA9 for ; Wed, 7 Sep 2011 22:08:40 -0700 (PDT) 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 p885Arub014526; Thu, 8 Sep 2011 01:10:53 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 01:09:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6DE5.8BBF4954" Date: Thu, 8 Sep 2011 10:39:53 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> In-Reply-To: <4E67AD3D.9000005@alvestrand.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] Thread-Index: Acxthaosiavud1zsSamyaYYSIHCFZAAXPe+g References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> From: "Ravindran Parthasarathi" To: "Harald Alvestrand" X-OriginalArrivalTime: 08 Sep 2011 05:09:57.0585 (UTC) FILETIME=[8D808410:01CC6DE5] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 05:08:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6DE5.8BBF4954 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Harald, =20 For browser as a SIP UA application, browser has to no need to compliant with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also agree with you that browser-to-browser communication, I could not see the strong reason for supporting S/MIME. As part of the RTCWeb architecture & solution, we will able to explore the SIP UA requirement for making browser SIP compliant. Say for example, forking does not make sense in case of browser as SIP UA application, forked response will be rejected with CANCEL in browser without Javascript intervention. The main requirement is to build the right SIP UA framework in browser by which Javascript developer will be able to use to the maximum extent without impacting the basic 2 two party communication in the internet. =20 =20 As mailed in another thread, RTCWEB client + RTCWeb server makes to feel a modern exchange in web world (Plain Old Telephony System phone with exchange architecture). I think so because POTS phones are dumb which does not know its identity and every event like offhook, onhook has to passed to exchange (webserver) whereas RTCWeb client (browser) has to pass every event to webserver and webserver has whole intelligence to make it work. I got this feel more when someone is talking about MEGACO or MGCP between RTCWEB client & webserver. My understanding is that SIP does not fit well to legacy telephone-based paradigm by any means but MEGACO or MGCP are the better choice which maps to SS7 architecture well. I'm interested in seeing RTCWeb client perform the basic routing rather than webserver does the routing on behalf of RTCWEb client. =20 I agree with you that in case it is local exchange (same site like skype or Google hangout) communication, there will be no need of signaling but I'm interested in communication with one of the Google real-time user in internet without having any Google id. I believe that SIP will make it work. =20 Thanks Partha =20 From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Wednesday, September 07, 2011 11:13 PM To: Ravindran Parthasarathi Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] =20 On 09/07/11 19:29, Ravindran Parthasarathi wrote:=20 Matthew, =20 When I asked for SIP, I have meant RFC 3261 only. This is 269 pages, and has 26 normative dependencies including S/MIME. It's not a small dependency. The basic reason for asking SIP is to make the basic call works between browser to browser across web servers. Without SIP in browser, it is not going happen. Innovative application is going to be proprietary whether it is HTTP or SIP or any other protocol for that matter. =20 My reasoning are as follows: SIP makes browser more intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG.=20 Why does that "intelligence" need to be in the browser, rather than in the Javascript? The importance of basic call interop is that there is no need of many individual id like skype id, Google id and yahoo id by everyone in the world to communicate others. I wish to have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.=20 This only makes sense for applications that fit the "call an identified party" paradigm. SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provider. There is no need to build two different signaling logic in VoIP servers for each service. Your own example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible to avoided by having one signaling protocol. One protocol can be achieved by multiple applications choosing to implement one protocol. It doesn't have to be enforced by the prtoocol being embedded in the browser. =20 In RTCWEB does not standardize the signaling protocol interface between browsers, the interop across webservers is next to impossible and it will be restricted to single webserver (company) only. Please let me know in case I'm missing something here. I think the main thing you are missing is that there are many applications that people want to build on top of RTCWEB that are not telephones, and will not fit with telephone-based paradigms. ------_=_NextPart_001_01CC6DE5.8BBF4954 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Harald,

 

For browser as a SIP UA application, browser has to no = need to compliant with 269 pages of RFC 3261 as proxy core is irrelevant to it. = I also agree with you that browser-to-browser communication, I could not see = the strong reason for supporting S/MIME. As part of the RTCWeb architecture = & solution, we will able to explore the SIP UA requirement for making = browser SIP compliant. Say for example, forking does not make sense in case of = browser as SIP UA application, forked response will be rejected with CANCEL in = browser without Javascript intervention. The main requirement is to build the = right SIP UA framework in browser by which Javascript developer will be able to = use to the maximum extent without impacting the basic 2 two party communication = in the internet. 

 

As mailed in another thread, RTCWEB client + RTCWeb = server makes to feel a modern exchange in web world (Plain Old Telephony System = phone with exchange architecture). I think so because POTS phones are dumb = which does not know its identity and every event like offhook, onhook has to passed = to exchange (webserver) whereas RTCWeb client (browser) has to pass every = event to webserver and webserver has whole intelligence to make it work. I got = this feel more when someone is talking about MEGACO or MGCP between RTCWEB client = & webserver. My understanding is that SIP does not fit well to legacy telephone-based paradigm by any means but MEGACO or MGCP are the better choice which = maps to SS7 architecture well. I’m interested in seeing RTCWeb client = perform the basic routing rather than webserver does the routing on behalf of RTCWEb = client.

 

I agree with you that in case it is local exchange (same = site like skype or Google hangout) communication, there will be no need of = signaling but I’m interested in communication with one of the Google = real-time user in internet without having any Google id.  I believe that SIP will = make it work.

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Wednesday, September 07, 2011 11:13 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; = rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remote recording - RTC-Web client acting as SIPREC session recording = client]

 

On 09/07/11 19:29, Ravindran Parthasarathi wrote: =

Matthew,

 

When I asked for SIP, I have meant RFC 3261 only.

This is 269 pages, and has 26 normative = dependencies including S/MIME. It's not a small dependency.



The basic reason for asking SIP is to make the basic call works between = browser to browser across web servers. Without SIP in browser, it is not going = happen. Innovative application is going to be proprietary whether it is HTTP or = SIP or any other protocol for that matter.

 

My reasoning are as follows:

SIP makes browser more = intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG. =

Why does that "intelligence" need to be = in the browser, rather than in the Javascript?

The importance of basic call = interop is that there is no need of many individual id like skype id, Google = id  and yahoo id by everyone in the world to communicate others. I wish to = have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.

This only makes sense for applications that fit the "call an identified party" paradigm.

SIP helps to interop for = basic call with other existing realtime application in Enterprise & Telecom = provider.

There is no need to build two different signaling logic in VoIP servers for each service. Your own = example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible = to avoided by having one signaling protocol.

One protocol can be achieved by multiple = applications choosing to implement one protocol.
It doesn't have to be enforced by the prtoocol being embedded in the = browser.

 

In RTCWEB does not standardize the signaling protocol interface between = browsers, the interop across webservers is next to impossible and it will be = restricted to single webserver (company) only. Please let  me know in case = I’m missing something here.


I think the main thing you are missing is that there are many = applications that people want to build on top of RTCWEB that are not telephones, and will = not fit with telephone-based paradigms.

------_=_NextPart_001_01CC6DE5.8BBF4954-- From salvatore.loreto@ericsson.com Wed Sep 7 22:24: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 A623D21F8B7F for ; Wed, 7 Sep 2011 22:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 85pyxGGNyUMV for ; Wed, 7 Sep 2011 22:24:33 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9C28D21F8B7D for ; Wed, 7 Sep 2011 22:24:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-93-4e6851fe4e52 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 44.38.02839.EF1586E4; Thu, 8 Sep 2011 07:26:22 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Thu, 8 Sep 2011 07:26:22 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C474324D8 for ; Thu, 8 Sep 2011 08:26:21 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7DB155120C for ; Thu, 8 Sep 2011 08:26:21 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 32F434E64F for ; Thu, 8 Sep 2011 08:26:21 +0300 (EEST) Message-ID: <4E6851FC.6030201@ericsson.com> Date: Thu, 8 Sep 2011 08:26:20 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.21) Gecko/20110830 Thunderbird/3.1.13 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E259484.20509@ericsson.com>, <37897D97-85A9-4B21-85C3-A7E9BE1EF3E7@cisco.com>, <4E26B742.6050606@jitsi.org>, <62C71813-83B4-44D3-8E54-28262311CDB3@cisco.com> <4E27BE02.7090606@ericsson.com> <9F9278CB1892FB48BF35CB5CC3992478A5395C720E@HKGMBOXPRD01.polycom.com> <4E2EB82C.30709@alvestrand.no> <4E643E39.8020205@skype.net> <4E665588.5000700@mozilla.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Support for websockets X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 05:24:33 -0000 On 9/7/11 6:04 PM, Cullen Jennings wrote: > Sooner or later, I do think we should talk about how to spoof RTP through firewalls that only allow HTTP traffic. Certainly websockets would be worth looking at but I suspect we will find that it was not designed for transfer of large high bandwidth material (like video) surprisingly enough it can transfer large high bandwidth files /Sal > and that something similar but different is needed. > > On Sep 6, 2011, at 11:16 AM, Christopher Blizzard wrote: > >> On 9/4/2011 8:12 PM, Matthew Kaufman wrote: >>> >>> I think there's a legitimate question as to how transmission of media over TCP should work. I believe that the existing code bases all assume that if you get IP addresses, you use them; if you get IP addresses for TURN servers you talk to them over UDP and use TURN for relaying; and if you get IP addresses for TURNS servers you talk to them over TLS/TCP and use them for relaying. Therefore the only TCP transport is TURN-over-TLS-over-TCP. >>> >>> Is that sufficient and reasonable, or should media-over-websockets (or something else) be how TCP transmission of media works? >> It's important to note that WebSockets aren't raw sockets in the classic TCP or POSIX sense. So a conversation about transmission of media over TCP doesn't really apply to WebSockets, exactly. It's true that since WS is over TCP that it's reliable and ordered. What would be interesting would be a discussion of how to take media data coming in over a WebSocket and feed it to a consumer that could display that media, as well as the reverse. But an API discussion feels like something that's more that's something that belongs at the W3C. >> >> If we wanted a standardized representation in WS that might happen here, but it's not something that's strictly required. Well-built APIs to encoders and decoders could mean that it's up to page implementers to figure out how to package the data, manipulated by JS. >> >> --Chris >> _______________________________________________ >> 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 oej@edvina.net Wed Sep 7 22:41: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 0005121F8AD3 for ; Wed, 7 Sep 2011 22:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_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 5J8DwibQLZS9 for ; Wed, 7 Sep 2011 22:41:25 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id DDD7C21F88B7 for ; Wed, 7 Sep 2011 22:41:24 -0700 (PDT) Received: from [IPv6:2001:470:1f15:d79:d02b:3c00:edc1:4846] (unknown [IPv6:2001:470:1f15:d79:d02b:3c00:edc1:4846]) by smtp7.webway.se (Postfix) with ESMTPA id 46384754BCE4; Thu, 8 Sep 2011 05:43:12 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <4E67F296.3020007@jesup.org> Date: Thu, 8 Sep 2011 07:43:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <8233FBBB-26CE-4822-81A4-65F86A4E8666@edvina.net> <4E67F296.3020007@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 05:41:26 -0000 8 sep 2011 kl. 00:39 skrev Randell Jesup: > On 9/7/2011 3:59 PM, Olle E. Johansson wrote: >> 7 sep 2011 kl. 21:20 skrev Randell Jesup: >>=20 >>> Signalling is secure, so it could even use a direct optional = downgrade from SAVP* to AVP* (i.e. similar to the best-effort-strp = draft) >> How can you assert that signalling is secure? When, how? >=20 > I'm assuming the signalling is occurring as SIP over an HTTPS = connection to the server, or SIP-over-TLS - haven't really given it a = lot of thought other than this connection is securable is we start with = an HTTPS connection to the server. That only guarantees confidentiality the first hop of signalling, = provided that the TLS certificates was properly verified. That's a long = way from assuming that signalling is secure. /O= From oej@edvina.net Wed Sep 7 22:46: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 EB28921F8797 for ; Wed, 7 Sep 2011 22:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQNp956YOasZ for ; Wed, 7 Sep 2011 22:46:10 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA0021F856B for ; Wed, 7 Sep 2011 22:46:09 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 69F46754BCE4; Thu, 8 Sep 2011 05:47:59 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_2BB515AC-D4BF-4BDD-8572-45BEBCD9D706" From: "Olle E. Johansson" In-Reply-To: <4E6808D5.7090709@alum.mit.edu> Date: Thu, 8 Sep 2011 07:48:01 +0200 Message-Id: <95877BC0-B0AA-4B20-9C2E-C16076BBE96E@edvina.net> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67D1F4.10002@mozilla.com> <4E6808D5.7090709@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 05:46:11 -0000 --Apple-Mail=_2BB515AC-D4BF-4BDD-8572-45BEBCD9D706 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 8 sep 2011 kl. 02:14 skrev Paul Kyzivat: > Chris, >=20 > I agree with you that the UI indication of security is important. > But its also *hard* for this application, for a variety of reasons: >=20 > - While it may be easy for the browser to know if the media stream > is itself secured, its hard (impossible) to know that its secured > to its ultimate end point. That is the problem with intermediaries. >=20 > - it may turn out that not all the streams in the "call" have the > same degree of security. >=20 > Of course this can all be dealt with via proper definition of what the = UI indication means, and doesn't mean. But doing that will just render = it meaningless to many users. To be widely understood, the indication = will need to be simple, and closely aligned with what people "expect". >=20 > Consider a stream that is secured to a PSTN gateway, and then travels = over the PSTN to somebody's phone. Should that be considered a "secure" = call? Or an "insecure" call? Or somewhere between those? >=20 > Its going to be hard work to figure out what can both be reliably = reported to users and also be understandable and meaningful to users. >=20 Agree. I see your way of thinking as an argument to make all sessions = confidential, encrypted by default. We can't reliable define a "secure = call" and separate insecure sessions from secure sessions. Which mean = that a UI indication won't mean anything. We can just make sure that the = first hop is protected, the rest is up to the application that operates = the media session. /O > Thanks, > Paul >=20 >=20 > On 9/7/11 4:20 PM, Christopher Blizzard wrote: >> On 9/7/2011 12:20 PM, Randell Jesup wrote: >>> Splitting the two topics.... >>>=20 >>>=20 >>> On 9/7/2011 3:07 AM, Olle E. Johansson wrote: >>>=20 >>>> To fearlessly jump into another can of worms, I still think we = should >>>> have confidentiality - SRTP - by default. We know that these >>>> applications will run on a myriad of devices on a myriad of = networks >>>> and it will not work to let users have to decided whether or not = they >>>> want confidentiality. If Skype did not have confidentiality by >>>> default, there would be articles every summer and xmas in the = evening >>>> taboloids about how easy it is to listen in to your neighbours = calls >>>> and that would have hurted Skype badly. >>>>=20 >>>=20 >>> There is a strong argument for this. The strongest argument for the >>> other side is you don't need a media gateway to talk to non-WebRTC >>> endpoints, just a signalling gateway. This means less delay >>> potentially (especially if the application provider has gateways = only >>> in one geographic location) and less expense for the server provider >>> for a pretty common usecase (gateway to PSTN). The delay could be a >>> significant issue. >>> It was also brought up that some usecases for internal PBX/business >>> use would not need/prefer forced encryption. As mentioned at the >>> meeting, encrypting to the media gateway only gets you a modicum of >>> privacy (though it might protect you from the "neighbor's wifi >>> capture" case). >>>=20 >>> You could make forced-encryption the default, and allow the >>> application control over whether to allow it is turned off for >>> specific cases, like a PSTN call, or under the server's control. >>> Signalling is secure, so it could even use a direct optional = downgrade >>> from SAVP* to AVP* (i.e. similar to the best-effort-strp draft) >>>=20 >>> It's a tough call - guaranteed (local) security is nice, but I worry >>> about those relay cases like taiwan->USA media gateway->taiwan. Not = a >>> huge deal on signaling/call-setup, but media... >>>=20 >>>=20 >>=20 >> I want secure-by-default, maybe even secure-only. >>=20 >> Even if it's not secure-only there's also an important UI = consideration >> depending how we end up doing that in browsers. In the past we've = made >> the secure mode special (the lock icon in the early days, now the >> green/blue bar) but I think that we should be making the insecure = mode >> special. That is, always mark a connection as very clearly = unencrypted >> via UI affordances. Just like banks "wanting to know how to get the = lock >> icon" we should be making call sites "wanting to know how to get rid = of >> that huge ugly warning that makes us look bad." >>=20 >> Once again, I would much prefer secure-only, but I'll take >> secure-by-default across browsers if I can get it. >>=20 >> --Chris >> _______________________________________________ >> 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 --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden --Apple-Mail=_2BB515AC-D4BF-4BDD-8572-45BEBCD9D706 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Chris,

I agree with you that the UI indication = of security is important.
But its also *hard* for this application, = for a variety of reasons:

- While it may be easy for the browser = to know if the media stream
 is itself secured, its hard = (impossible) to know that its secured
 to its ultimate end = point. That is the problem with intermediaries.

- it may turn out = that not all the streams in the "call" have the
 same degree of = security.

Of course this can all be dealt with via proper = definition of what the UI indication means, and doesn't mean. But doing = that will just render it meaningless to many users. To be widely = understood, the indication will need to be simple, and closely aligned = with what people "expect".

Consider a stream that is secured to a = PSTN gateway, and then travels over the PSTN to somebody's phone. Should = that be considered a "secure" call? Or an "insecure" call? Or somewhere = between those?

Its going to be hard work to figure out what can = both be reliably reported to users and also be understandable and = meaningful to users.

Agree. I see your way of = thinking as an argument to make all sessions confidential, encrypted by = default. We can't reliable define a "secure call" and separate insecure = sessions from secure sessions. Which mean that a UI indication won't = mean anything. We can just make sure that the first hop is protected, = the rest is up to the application that operates the media = session.

/O
Thanks,
= Paul


On 9/7/11 4:20 PM, Christopher Blizzard = wrote:
On 9/7/2011 12:20 PM, Randell Jesup = wrote:
Splitting the two = topics....


On 9/7/2011 3:07 AM, Olle E. = Johansson wrote:

To = fearlessly jump into another can of worms, I still think we = should
have = confidentiality - SRTP - by default. We know that = these
applications will run on a myriad of devices on a myriad = of networks
and it = will not work to let users have to decided whether or not = they
want = confidentiality. If Skype did not have confidentiality = by
default,= there would be articles every summer and xmas in the = evening
taboloids about how easy it is to listen in to your = neighbours calls
and = that would have hurted Skype = badly.


There is a strong argument for = this. The strongest argument for = the
other side is you don't need a media gateway to talk to = non-WebRTC
endpoints, just a signalling = gateway. This means less delay
potentially (especially if the = application provider has gateways = only
in one geographic location) and less expense for the = server provider
for a pretty common usecase = (gateway to PSTN). The delay could be = a
significant = issue.
It was also brought up that some usecases for internal = PBX/business
use would not need/prefer forced = encryption. As mentioned at the
meeting, encrypting to the media = gateway only gets you a modicum = of
privacy (though it might protect you from the "neighbor's = wifi
capture" case).

You could make forced-encryption = the default, and allow the
application control over whether = to allow it is turned off for
specific cases, like a PSTN = call, or under the server's = control.
Signalling is secure, so it = could even use a direct optional = downgrade
from SAVP* to AVP* (i.e. similar = to the best-effort-strp draft)

It's a tough call - guaranteed = (local) security is nice, but I = worry
about those relay cases like taiwan->USA media = gateway->taiwan. Not a
huge deal on = signaling/call-setup, but = media...



I want = secure-by-default, maybe even secure-only.

Even if it's = not secure-only there's also an important UI = consideration
depending how we = end up doing that in browsers. In the past we've = made
the secure mode special = (the lock icon in the early days, now the
green/blue bar) but I think that we should be making the = insecure mode
special. That = is, always mark a connection as very clearly = unencrypted
via UI = affordances. Just like banks "wanting to know how to get the = lock
icon" we should be making = call sites "wanting to know how to get rid = of
that huge ugly warning that = makes us look bad."

Once again, I = would much prefer secure-only, but I'll take
secure-by-default across browsers if I can get = it.

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


_______________________________________= ________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.or= g/mailman/listinfo/rtcweb

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



= --Apple-Mail=_2BB515AC-D4BF-4BDD-8572-45BEBCD9D706-- From oej@edvina.net Wed Sep 7 22:49: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 4FC6921F87D6 for ; Wed, 7 Sep 2011 22:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 1eWUBg6l0dUG for ; Wed, 7 Sep 2011 22:49:17 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id D0FB521F872A for ; Wed, 7 Sep 2011 22:49:16 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id B9872754BCE4; Thu, 8 Sep 2011 05:51:06 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_29810BCB-1653-4F3E-A830-95E0A969D26D" From: "Olle E. Johansson" In-Reply-To: Date: Thu, 8 Sep 2011 07:51:08 +0200 Message-Id: References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3EE.50707@jesup.org> <4E67F0A2.1070308@skype.net> To: Silvia Pfeiffer X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 05:49:18 -0000 --Apple-Mail=_29810BCB-1653-4F3E-A830-95E0A969D26D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 8 sep 2011 kl. 03:15 skrev Silvia Pfeiffer: > If implementations count for anything, check out: >=20 > http://phono.com/ > and > = https://docs.google.com/present/view?id=3D0AcNAXuadeXIxZGY4NDl4Z2RfNTlod3B= rOXNjZA&hl=3Den&pli=3D1 >=20 > They use SIP with web sockets. Nice. That will make it easy to hook in the rtcweb/webrtc media layer. Now, I don't see clearly if you want to argue for or against SIP as part = of rtcweb standards with these examples, but that may be my biased eyes = reading... ;-) /O >=20 > Cheers, > Silvia. >=20 >=20 > On Thu, Sep 8, 2011 at 8:30 AM, Matthew Kaufman > wrote: >> On 9/7/11 12:20 PM, Randell Jesup wrote: >>>=20 >>> I also started from the same point - assume SIP. SIP gives you all = the >>> things that the zillions of hours and emails to define it and define >>> extensions and secure it provides, without having to reinvent all = those >>> wheels (or ask app developers to reinvent them). Why go through the >>> horrible pain of choosing something else, or why throw the app = developers to >>> the wolves to fend for themselves? >>>=20 >>> However... >>>=20 >>> Two things have swayed me. The primary one is the suggestion of >>> Offer/Answer in the browser. This breaks out the important = negotiation >>> piece that almost any application would need, and while not perfect, = SDP O/A >>> is a zillion times simpler than SIP with all the extensions one = could use. >>=20 >> I agree with this. While I am also opposed to SDP O/A, these are two >> unrelated arguments to have... and not baking a SIP phone into the = browser >> is *more* important than avoiding a repeat of the offer/answer = problems. >>=20 >>>=20 >>> The other thing that swayed me was thinking about federation and the = apps >>> that will be built with this. A webrtc app talks to its = (web)server, other >>> webrtc clients running the app that talk to the server, and to other = webrtc >>> applications/networks that federate with it (and their clients). >>>=20 >>> Federation is in the same hands as the person who provides/wrote the = app. >>> If they have no interest in federation you can't force it, and they = may >>> have no use for all the fancy SIP standards. >>=20 >> And for numerous types of apps (think: server-based augmented reality >> systems), "federation" doesn't even make sense. >>=20 >>>=20 >>> On the other hand, if they *want* to either provide access to the = wider >>> communication net that is the PSTN network, now or in the future, or = they >>> want easy federation with other networks, it behooves them to use = SIP or >>> something very close to it or equivalent/convertible (at a basic = level at >>> least) to it. >>>=20 >>> So what conclusions do I draw from this? >>>=20 >>> 1) O/A via SDP in the browser simplifies a lot of things (including >>> handling new codecs, etc). It doesn't extremely limit an = application, >>> though we should think about how an application can interact with = the >>> fmtp/etc parameters used. >>=20 >> I agree that it would simplify some interop cases, but at an = unfortunate >> cost in lack of flexibility and functionality. Still not nearly as = bad as if >> we put a full SIP stack in there though. >>=20 >>>=20 >>> 2) SIP as a *separate* item that can be cleanly and easily *added* = to a >>> webrtc app to handle the call setup/etc is a good idea. >>=20 >> I would be open to looking at this again, *after* RTC is already in = browsers >> and successful, to see if it actually solves a real use case. >>=20 >> Matthew Kaufman >>=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 --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden --Apple-Mail=_29810BCB-1653-4F3E-A830-95E0A969D26D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
If = implementations count for anything, check out:

http://phono.com/
and
https://docs.go= ogle.com/present/view?id=3D0AcNAXuadeXIxZGY4NDl4Z2RfNTlod3BrOXNjZA&hl=3D= en&pli=3D1

They use SIP with web = sockets.

Nice. That will make it = easy to hook in the rtcweb/webrtc media = layer.

Now, I don't see clearly if you want to = argue for or against SIP as part of rtcweb standards with these = examples, but that may be my biased eyes reading... = ;-)

/O

Cheers,
Silvia.


On Thu, Sep 8, 2011 = at 8:30 AM, Matthew Kaufman
<matthew.kaufman@skype.net>= ; wrote:
On 9/7/11 12:20 PM, Randell Jesup = wrote:

I also started from the same = point - assume SIP.  SIP gives you all = the
things that the zillions of hours and emails to define it = and define
extensions and secure it = provides, without having to reinvent all = those
wheels (or ask app developers to reinvent them).  Why = go through the
horrible pain of choosing = something else, or why throw the app developers = to
the wolves to fend for = themselves?

However...

Two things have swayed me. =  The primary one is the suggestion = of
Offer/Answer in the browser.  This breaks out the = important negotiation
piece that almost any = application would need, and while not perfect, SDP = O/A
is a zillion times simpler than SIP with all the = extensions one could use.

I agree with = this. While I am also opposed to SDP O/A, these are = two
unrelated arguments to = have... and not baking a SIP phone into the = browser
is *more* important = than avoiding a repeat of the offer/answer = problems.


The other thing that swayed me = was thinking about federation and the = apps
that will be built with this.  A webrtc app talks to = its (web)server, other
webrtc clients running the app = that talk to the server, and to other = webrtc
applications/networks that federate with it (and their = clients).

Federation is in the same hands = as the person who provides/wrote the = app.
 If they have no interest in federation you can't = force it, and they may
have no use for all the fancy = SIP standards.

And for = numerous types of apps (think: server-based augmented = reality
systems), "federation" = doesn't even make sense.


On the other hand, if they = *want* to either provide access to the = wider
communication net that is the PSTN network, now or in the = future, or they
want easy federation with other = networks, it behooves them to use SIP = or
something very close to it or equivalent/convertible (at a = basic level at
least) to = it.

So what conclusions do I draw = from this?

1) O/A via SDP in the browser = simplifies a lot of things = (including
handling new codecs, etc). =  It doesn't extremely limit an = application,
though we should think about how = an application can interact with = the
fmtp/etc parameters = used.

I agree that it = would simplify some interop cases, but at an = unfortunate
cost in lack of = flexibility and functionality. Still not nearly as bad as = if
we put a full SIP stack in = there though.


2) SIP as a *separate* item that = can be cleanly and easily *added* to = a
webrtc app to handle the call setup/etc is a good = idea.

I would be open = to looking at this again, *after* RTC is already in = browsers
and successful, to = see if it actually solves a real use case.

Matthew = Kaufman

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

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

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



= --Apple-Mail=_29810BCB-1653-4F3E-A830-95E0A969D26D-- From silviapfeiffer1@gmail.com Wed Sep 7 23: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 AF88F21F8C00 for ; Wed, 7 Sep 2011 23:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i15PqVAYe0Yt for ; Wed, 7 Sep 2011 23:18:01 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEBD21F8BC3 for ; Wed, 7 Sep 2011 23:18:01 -0700 (PDT) Received: by gxk9 with SMTP id 9so689014gxk.40 for ; Wed, 07 Sep 2011 23:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=J4MRLXWHHiPBQnXkR6TIAnPYdzGeZuKYmrKNugAZ60o=; b=SkcSeeb0tKaj9TNHnKsaFibdpEFtmlnXXrFlgT45oknXisUSzwhOAUACGCTD+H+JOf lT7ls85zH4JUbuV/aBnzUCu4EQ25azv00JvLha3Bc6JLK778KfzT/mP50Gyr2KKRbNV/ ifxkoO4nNR2hyRW+rYQ4ICPkc2ga+zpE2DfbU= Received: by 10.236.76.225 with SMTP id b61mr1613457yhe.92.1315462792149; Wed, 07 Sep 2011 23:19:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.203.5 with HTTP; Wed, 7 Sep 2011 23:19:32 -0700 (PDT) In-Reply-To: References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3EE.50707@jesup.org> <4E67F0A2.1070308@skype.net> From: Silvia Pfeiffer Date: Thu, 8 Sep 2011 16:19:32 +1000 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 06:18:02 -0000 I'm arguing for leaving it out, since obviously it's already possible to support it in the browser through web sockets. We wouldn't put SMPTE support into browsers either just to be able to read email in browsers. I wonder: if you are arguing for it, what is it that is not possible with such a JS implementation that would require introduction of a totally new technology into the browser (with all associated security risks)? Silvia. On Thu, Sep 8, 2011 at 3:51 PM, Olle E. Johansson wrote: > > 8 sep 2011 kl. 03:15 skrev Silvia Pfeiffer: > > If implementations count for anything, check out: > > http://phono.com/ > and > https://docs.google.com/present/view?id=3D0AcNAXuadeXIxZGY4NDl4Z2RfNTlod3= BrOXNjZA&hl=3Den&pli=3D1 > > They use SIP with web sockets. > > Nice. That will make it easy to hook in the rtcweb/webrtc media layer. > Now, I don't see clearly if you want to argue for or against SIP as part = of > rtcweb standards with these examples, but that may be my biased eyes > reading... ;-) > /O > > Cheers, > Silvia. > > > On Thu, Sep 8, 2011 at 8:30 AM, Matthew Kaufman > wrote: > > On 9/7/11 12:20 PM, Randell Jesup wrote: > > I also started from the same point - assume SIP. =A0SIP gives you all the > > things that the zillions of hours and emails to define it and define > > extensions and secure it provides, without having to reinvent all those > > wheels (or ask app developers to reinvent them). =A0Why go through the > > horrible pain of choosing something else, or why throw the app developers= to > > the wolves to fend for themselves? > > However... > > Two things have swayed me. =A0The primary one is the suggestion of > > Offer/Answer in the browser. =A0This breaks out the important negotiation > > piece that almost any application would need, and while not perfect, SDP = O/A > > is a zillion times simpler than SIP with all the extensions one could use= . > > I agree with this. While I am also opposed to SDP O/A, these are two > > unrelated arguments to have... and not baking a SIP phone into the browse= r > > is *more* important than avoiding a repeat of the offer/answer problems. > > > The other thing that swayed me was thinking about federation and the apps > > that will be built with this. =A0A webrtc app talks to its (web)server, o= ther > > webrtc clients running the app that talk to the server, and to other webr= tc > > applications/networks that federate with it (and their clients). > > Federation is in the same hands as the person who provides/wrote the app. > > =A0If they have no interest in federation you can't force it, and they ma= y > > have no use for all the fancy SIP standards. > > And for numerous types of apps (think: server-based augmented reality > > systems), "federation" doesn't even make sense. > > > On the other hand, if they *want* to either provide access to the wider > > communication net that is the PSTN network, now or in the future, or they > > want easy federation with other networks, it behooves them to use SIP or > > something very close to it or equivalent/convertible (at a basic level at > > least) to it. > > So what conclusions do I draw from this? > > 1) O/A via SDP in the browser simplifies a lot of things (including > > handling new codecs, etc). =A0It doesn't extremely limit an application, > > though we should think about how an application can interact with the > > fmtp/etc parameters used. > > I agree that it would simplify some interop cases, but at an unfortunate > > cost in lack of flexibility and functionality. Still not nearly as bad as= if > > we put a full SIP stack in there though. > > > 2) SIP as a *separate* item that can be cleanly and easily *added* to a > > webrtc app to handle the call setup/etc is a good idea. > > I would be open to looking at this again, *after* RTC is already in brows= ers > > and successful, to see if it actually solves a real use case. > > Matthew Kaufman > > _______________________________________________ > > 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 -=A0oej@edvina.net > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden > > > From randell-ietf@jesup.org Wed Sep 7 23:22: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 97A5921F8C40 for ; Wed, 7 Sep 2011 23:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 4B3fj+5dTznH for ; Wed, 7 Sep 2011 23:22:08 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C40EB21F8C11 for ; Wed, 7 Sep 2011 23:22:08 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R1Y1n-0005eK-5D; Thu, 08 Sep 2011 01:23:59 -0500 Message-ID: <4E685ED0.3010602@jesup.org> Date: Thu, 08 Sep 2011 02:21:04 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: "Olle E. Johansson" References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <8233FBBB-26CE-4822-81A4-65F86A4E8666@edvina.net> <4E67F296.3020007@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: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 06:22:09 -0000 On 9/8/2011 1:43 AM, Olle E. Johansson wrote: > >>> 7 sep 2011 kl. 21:20 skrev Randell Jesup: >>> >>>> Signalling is secure, so it could even use a direct optional downgrade from SAVP* to AVP* (i.e. similar to the best-effort-strp draft) >>> How can you assert that signalling is secure? When, how? >> I'm assuming the signalling is occurring as SIP over an HTTPS connection to the server, or SIP-over-TLS - haven't really given it a lot of thought other than this connection is securable is we start with an HTTPS connection to the server. > That only guarantees confidentiality the first hop of signalling, provided that the TLS certificates was properly verified. That's a long way from assuming that signalling is secure. > Well, as this is rtcweb, the application knows it's talking to the service associated with the app directly, so there should be no intermediaries in the SIP fashion between the app and the service it provides. I hadn't meant to have my statement apply to "federated" connections between services, which is where your objection would primarily come in. (There is the issue of "can someone spoof https://foo.com/"; the answer *should* be no, and if so then that first hop is secure). But this may be moot anyways given my response to Jonathan Lennox on this topic about Cap-Neg (shudder). -- Randell Jesup randell-ietf@jesup.org From christer.holmberg@ericsson.com Wed Sep 7 23: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 58F6321F8B74 for ; Wed, 7 Sep 2011 23:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 2GUbe1NZTFQi for ; Wed, 7 Sep 2011 23:33:14 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9237521F8B5D for ; Wed, 7 Sep 2011 23:33:14 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-d5-4e686219ed8c Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id FC.C0.02839.912686E4; Thu, 8 Sep 2011 08:35:05 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 8 Sep 2011 08:35:05 +0200 From: Christer Holmberg To: Randell Jesup , Jonathan Lennox Date: Thu, 8 Sep 2011 08:35:04 +0200 Thread-Topic: AVPF [was: [rtcweb] Encryption mandate (and offer/answer)] Thread-Index: AcxtrdxMz9T5EPlJRReppyAV+Xdn8AAQw9BA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> In-Reply-To: <4E67F003.6000108@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 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 06:33:15 -0000 =20 Hi, >>>You could make forced-encryption the default, and allow the=20 >>>application control over whether to allow it is turned off for=20 >>>specific cases, like a PSTN call, or under the server's control. =20 >>>Signalling is secure, so it could even use a direct=20 >>>optional downgrade from SAVP* to AVP* (i.e. >>>similar to the best-effort-strp draft) >>This has implications for the parallel thread about the use=20 >>of SDP offer/answer. >> >>The solution MMUSIC has standardized for best-effort SRTP=20 >>is SDP CapNeg, RFC 5939. Do we want to require CapNeg=20 >>support in browsers? >=20 >Yeah, ok, I'm not going there. :-) It's probably not needed=20 >for this use-case anyways. The same question exists for AVPF, which has been suggested to be mandated. Regards, Christer From harald@alvestrand.no Wed Sep 7 23:51: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 9034021F8C86 for ; Wed, 7 Sep 2011 23:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.091 X-Spam-Level: X-Spam-Status: No, score=-107.091 tagged_above=-999 required=5 tests=[AWL=3.507, 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 Wuvc1sG0Cf0s for ; Wed, 7 Sep 2011 23:51:37 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id DC70421F8C84 for ; Wed, 7 Sep 2011 23:51:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2A0F739E0F3; Thu, 8 Sep 2011 08:53:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqypeWXCKXk4; Thu, 8 Sep 2011 08:53:23 +0200 (CEST) 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 7842B39E074; Thu, 8 Sep 2011 08:53:23 +0200 (CEST) Message-ID: <4E686663.1050900@alvestrand.no> Date: Thu, 08 Sep 2011 08:53:23 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> Content-Type: multipart/alternative; boundary="------------080600020805090507010301" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 06:51:40 -0000 This is a multi-part message in MIME format. --------------080600020805090507010301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote: > > Harald, > > For browser as a SIP UA application, browser has to no need to > compliant with 269 pages of RFC 3261 as proxy core is irrelevant to > it. I also agree with you that browser-to-browser communication, I > could not see the strong reason for supporting S/MIME. As part of the > RTCWeb architecture & solution, we will able to explore the SIP UA > requirement for making browser SIP compliant. > So you're advocating for creating a "SIP lite" subset that RTCWEB browsers implement. I think we have been down this road before, and it's not a happy one. But sure - if you want us to implement some part of SIP, *please start stating what part* rather than making wooly statements. Subsets are Real Hard Work. > > Say for example, forking does not make sense in case of browser as SIP > UA application, forked response will be rejected with CANCEL in > browser without Javascript intervention. The main requirement is to > build the right SIP UA framework in browser by which Javascript > developer will be able to use to the maximum extent without impacting > the basic 2 two party communication in the internet. > > As mailed in another thread, RTCWEB client + RTCWeb server makes to > feel a modern exchange in web world (Plain Old Telephony System phone > with exchange architecture). I think so because POTS phones are dumb > which does not know its identity and every event like offhook, onhook > has to passed to exchange (webserver) whereas RTCWeb client (browser) > has to pass every event to webserver and webserver has whole > intelligence to make it work. > Don't forget that the RTCWEB client (the browser) contains an open, fully programmable application platform - the Javascript engine. That's a HUGE difference to the POTS phone. > > I got this feel more when someone is talking about MEGACO or MGCP > between RTCWEB client & webserver. My understanding is that SIP does > not fit well to legacy telephone-based paradigm by any means but > MEGACO or MGCP are the better choice which maps to SS7 architecture > well. I'm interested in seeing RTCWeb client perform the basic routing > rather than webserver does the routing on behalf of RTCWEb client. > > I agree with you that in case it is local exchange (same site like > skype or Google hangout) communication, there will be no need of > signaling but I'm interested in communication with one of the Google > real-time user in internet without having any Google id. I believe > that SIP will make it work. > If by saying "the Google real time user in Internet", you mean a Google Talk user, you have that already. It's called Google Voice. It uses SIP, but not in the browser. Talking to someone who doesn't want to talk to you is an use case we don't intend to support. > > Thanks > > Partha > > *From:*Harald Alvestrand [mailto:harald@alvestrand.no] > *Sent:* Wednesday, September 07, 2011 11:13 PM > *To:* Ravindran Parthasarathi > *Cc:* Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org > *Subject:* Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: > Remote recording - RTC-Web client acting as SIPREC session recording > client] > > On 09/07/11 19:29, Ravindran Parthasarathi wrote: > > Matthew, > > When I asked for SIP, I have meant RFC 3261 only. > > This is 269 pages, and has 26 normative dependencies including S/MIME. > It's not a small dependency. > > > > The basic reason for asking SIP is to make the basic call works > between browser to browser across web servers. Without SIP in browser, > it is not going happen. Innovative application is going to be > proprietary whether it is HTTP or SIP or any other protocol for that > matter. > > My reasoning are as follows: > > SIP makes browser more intelligence compare to dump signaling > mechanism like MEGACO and browser acts as MG. > > Why does that "intelligence" need to be in the browser, rather than in > the Javascript? > > The importance of basic call interop is that there is no need of many > individual id like skype id, Google id and yahoo id by everyone in > the world to communicate others. I wish to have single id like e-mail > id to be maintained by browser-to-browser users to communicate with > others. > > This only makes sense for applications that fit the "call an > identified party" paradigm. > > SIP helps to interop for basic call with other existing realtime > application in Enterprise & Telecom provider. > > There is no need to build two different signaling logic in VoIP > servers for each service. Your own example of Bridge line appearance > will need two implementation by the single vendor because desktop > application or hardphone implementation based on SIP and browser based > implementation is depend on HTTP metadata. It is possible to avoided > by having one signaling protocol. > > One protocol can be achieved by multiple applications choosing to > implement one protocol. > It doesn't have to be enforced by the prtoocol being embedded in the > browser. > > In RTCWEB does not standardize the signaling protocol interface > between browsers, the interop across webservers is next to impossible > and it will be restricted to single webserver (company) only. Please > let me know in case I'm missing something here. > > > I think the main thing you are missing is that there are many > applications that people want to build on top of RTCWEB that are not > telephones, and will not fit with telephone-based paradigms. > --------------080600020805090507010301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote:

Harald,

 

For browser as a SIP UA application, browser has to no need to compliant with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also agree with you that browser-to-browser communication, I could not see the strong reason for supporting S/MIME. As part of the RTCWeb architecture & solution, we will able to explore the SIP UA requirement for making browser SIP compliant.

So you're advocating for creating a "SIP lite" subset that RTCWEB browsers implement.
I think we have been down this road before, and it's not a happy one.
But sure - if you want us to implement some part of SIP, *please start stating what part* rather than making wooly statements.

Subsets are Real Hard Work.

Say for example, forking does not make sense in case of browser as SIP UA application, forked response will be rejected with CANCEL in browser without Javascript intervention. The main requirement is to build the right SIP UA framework in browser by which Javascript developer will be able to use to the maximum extent without impacting the basic 2 two party communication in the internet. 

 

As mailed in another thread, RTCWEB client + RTCWeb server makes to feel a modern exchange in web world (Plain Old Telephony System phone with exchange architecture). I think so because POTS phones are dumb which does not know its identity and every event like offhook, onhook has to passed to exchange (webserver) whereas RTCWeb client (browser) has to pass every event to webserver and webserver has whole intelligence to make it work.

Don't forget that the RTCWEB client (the browser) contains an open, fully programmable application platform - the Javascript engine. That's a HUGE difference to the POTS phone.

I got this feel more when someone is talking about MEGACO or MGCP between RTCWEB client & webserver. My understanding is that SIP does not fit well to legacy telephone-based paradigm by any means but MEGACO or MGCP are the better choice which maps to SS7 architecture well. I’m interested in seeing RTCWeb client perform the basic routing rather than webserver does the routing on behalf of RTCWEb client.

 

I agree with you that in case it is local exchange (same site like skype or Google hangout) communication, there will be no need of signaling but I’m interested in communication with one of the Google real-time user in internet without having any Google id.  I believe that SIP will make it work.

If by saying "the Google real time user in Internet", you mean a Google Talk user, you have that already. It's called Google Voice. It uses SIP, but not in the browser.

Talking to someone who doesn't want to talk to you is an use case we don't intend to support.

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Wednesday, September 07, 2011 11:13 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]

 

On 09/07/11 19:29, Ravindran Parthasarathi wrote:

Matthew,

 

When I asked for SIP, I have meant RFC 3261 only.

This is 269 pages, and has 26 normative dependencies including S/MIME. It's not a small dependency.



The basic reason for asking SIP is to make the basic call works between browser to browser across web servers. Without SIP in browser, it is not going happen. Innovative application is going to be proprietary whether it is HTTP or SIP or any other protocol for that matter.

 

My reasoning are as follows:

SIP makes browser more intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG.

Why does that "intelligence" need to be in the browser, rather than in the Javascript?

The importance of basic call interop is that there is no need of many individual id like skype id, Google id  and yahoo id by everyone in the world to communicate others. I wish to have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.

This only makes sense for applications that fit the "call an identified party" paradigm.

SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provider.

There is no need to build two different signaling logic in VoIP servers for each service. Your own example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible to avoided by having one signaling protocol.

One protocol can be achieved by multiple applications choosing to implement one protocol.
It doesn't have to be enforced by the prtoocol being embedded in the browser.

 

In RTCWEB does not standardize the signaling protocol interface between browsers, the interop across webservers is next to impossible and it will be restricted to single webserver (company) only. Please let  me know in case I’m missing something here.


I think the main thing you are missing is that there are many applications that people want to build on top of RTCWEB that are not telephones, and will not fit with telephone-based paradigms.


--------------080600020805090507010301-- From oej@edvina.net Thu Sep 8 00:11: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 5AB6421F8B1A for ; Thu, 8 Sep 2011 00:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 TILw07GDEz2T for ; Thu, 8 Sep 2011 00:11:51 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id D6B5221F8802 for ; Thu, 8 Sep 2011 00:11:50 -0700 (PDT) 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 6B9A4754BCE4; Thu, 8 Sep 2011 07:13:38 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Thu, 8 Sep 2011 09:13:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3A9BCFFD-670F-49F0-9962-A00086B38FA7@edvina.net> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3EE.50707@jesup.org> <4E67F0A2.1070308@skype.net> To: Silvia Pfeiffer X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 07:12:00 -0000 8 sep 2011 kl. 08:19 skrev Silvia Pfeiffer: > I'm arguing for leaving it out, since obviously it's already possible > to support it in the browser through web sockets. We wouldn't put > SMPTE support into browsers either just to be able to read email in > browsers. >=20 > I wonder: if you are arguing for it, what is it that is not possible > with such a JS implementation that would require introduction of a > totally new technology into the browser (with all associated security > risks)? Oh, if you mean me I apologize for not being clear. I don't want SIP in = rtcweb at all. Your examples are good examples on my way of thinking = about rtcweb as a media layer for separate apps. That I want SIP to = power those apps is a another issue :-) /O >=20 > Silvia. >=20 >=20 > On Thu, Sep 8, 2011 at 3:51 PM, Olle E. Johansson = wrote: >>=20 >> 8 sep 2011 kl. 03:15 skrev Silvia Pfeiffer: >>=20 >> If implementations count for anything, check out: >>=20 >> http://phono.com/ >> and >> = https://docs.google.com/present/view?id=3D0AcNAXuadeXIxZGY4NDl4Z2RfNTlod3B= rOXNjZA&hl=3Den&pli=3D1 >>=20 >> They use SIP with web sockets. >>=20 >> Nice. That will make it easy to hook in the rtcweb/webrtc media = layer. >> Now, I don't see clearly if you want to argue for or against SIP as = part of >> rtcweb standards with these examples, but that may be my biased eyes >> reading... ;-) >> /O >>=20 >> Cheers, >> Silvia. >>=20 >>=20 >> On Thu, Sep 8, 2011 at 8:30 AM, Matthew Kaufman >> wrote: >>=20 >> On 9/7/11 12:20 PM, Randell Jesup wrote: >>=20 >> I also started from the same point - assume SIP. SIP gives you all = the >>=20 >> things that the zillions of hours and emails to define it and define >>=20 >> extensions and secure it provides, without having to reinvent all = those >>=20 >> wheels (or ask app developers to reinvent them). Why go through the >>=20 >> horrible pain of choosing something else, or why throw the app = developers to >>=20 >> the wolves to fend for themselves? >>=20 >> However... >>=20 >> Two things have swayed me. The primary one is the suggestion of >>=20 >> Offer/Answer in the browser. This breaks out the important = negotiation >>=20 >> piece that almost any application would need, and while not perfect, = SDP O/A >>=20 >> is a zillion times simpler than SIP with all the extensions one could = use. >>=20 >> I agree with this. While I am also opposed to SDP O/A, these are two >>=20 >> unrelated arguments to have... and not baking a SIP phone into the = browser >>=20 >> is *more* important than avoiding a repeat of the offer/answer = problems. >>=20 >>=20 >> The other thing that swayed me was thinking about federation and the = apps >>=20 >> that will be built with this. A webrtc app talks to its (web)server, = other >>=20 >> webrtc clients running the app that talk to the server, and to other = webrtc >>=20 >> applications/networks that federate with it (and their clients). >>=20 >> Federation is in the same hands as the person who provides/wrote the = app. >>=20 >> If they have no interest in federation you can't force it, and they = may >>=20 >> have no use for all the fancy SIP standards. >>=20 >> And for numerous types of apps (think: server-based augmented reality >>=20 >> systems), "federation" doesn't even make sense. >>=20 >>=20 >> On the other hand, if they *want* to either provide access to the = wider >>=20 >> communication net that is the PSTN network, now or in the future, or = they >>=20 >> want easy federation with other networks, it behooves them to use SIP = or >>=20 >> something very close to it or equivalent/convertible (at a basic = level at >>=20 >> least) to it. >>=20 >> So what conclusions do I draw from this? >>=20 >> 1) O/A via SDP in the browser simplifies a lot of things (including >>=20 >> handling new codecs, etc). It doesn't extremely limit an = application, >>=20 >> though we should think about how an application can interact with the >>=20 >> fmtp/etc parameters used. >>=20 >> I agree that it would simplify some interop cases, but at an = unfortunate >>=20 >> cost in lack of flexibility and functionality. Still not nearly as = bad as if >>=20 >> we put a full SIP stack in there though. >>=20 >>=20 >> 2) SIP as a *separate* item that can be cleanly and easily *added* to = a >>=20 >> webrtc app to handle the call setup/etc is a good idea. >>=20 >> I would be open to looking at this again, *after* RTC is already in = browsers >>=20 >> and successful, to see if it actually solves a real use case. >>=20 >> Matthew Kaufman >>=20 >> _______________________________________________ >>=20 >> rtcweb mailing list >>=20 >> rtcweb@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >> --- >> * Olle E Johansson - oej@edvina.net >> * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden >>=20 >>=20 >>=20 --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From bernard_aboba@hotmail.com Thu Sep 8 01:03: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 DD3C521F8B4B for ; Thu, 8 Sep 2011 01:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[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 0zMgwUaGsAvY for ; Thu, 8 Sep 2011 01:03:02 -0700 (PDT) Received: from blu0-omc3-s8.blu0.hotmail.com (blu0-omc3-s8.blu0.hotmail.com [65.55.116.83]) by ietfa.amsl.com (Postfix) with ESMTP id DF85521F8B35 for ; Thu, 8 Sep 2011 01:03:01 -0700 (PDT) Received: from BLU152-W54 ([65.55.116.74]) by blu0-omc3-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 01:04:52 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_07c49ff5-42e0-463a-bad0-e1935d4d3c0c_" X-Originating-IP: [70.88.131.169] From: Bernard Aboba To: Date: Thu, 8 Sep 2011 01:04:51 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 Sep 2011 08:04:52.0585 (UTC) FILETIME=[FD026D90:01CC6DFD] Subject: [rtcweb] draft-rescorla-rtcweb-security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 08:03:03 -0000 --_07c49ff5-42e0-463a-bad0-e1935d4d3c0c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Much of this document is very good=2C but the sections on ICE and masking a= ren't quite right. The security properties attributed to ICE only exist under a very carefully= circumscribed set of conditions. Unfortunately=2C Sections 4.2.1 and 4.2.= 2 aren't clear about this. The ICE exchange is fine for verifying willingness to accept a particular s= tream=2C assuming that the receiver provides an indication of willingness t= o receive. In part=2C this works because the specific characteristics of = the stream are negotiated in SDP offer/answer simultaneous with ICE. Howev= er=2C Section 4.2.1 isn't specific enough about what guarantees are provide= d by ICE and under what conditions. An ICE exchange doesn't enable "traffi= c"=3B at best it enables media with characteristics specified in SDP offer= /answer to be sent. =20 Section 4.2.2 says that masking is not necessary for UDP=2C but the logic b= ehind the statement needs more elaboration. There are lots of potentially n= asty things that can be done if a browser can send arbitrary datagrams to a= receiver=2C even if we postulate a STUN exchange. Things like: * Sending a datagram that might be mistaken for a DNS response=2C potential= ly poisoning the cache.=20 * Sending an SNMP set to a device. * Sourcing a routing packet (e.g. RIPv2).=20 It strikes me that Section 4.2.2 is needs to be more specific about the spe= cific threats and the conditions under which they are mitigated via ICE=2C = SDP offer/answer=2C etc. 4.2.1. ICE Verifying receiver consent requires some sort of explicit handshake=2C but conveniently we already need one in order to do NAT hole- punching. ICE [RFC5245] includes a handshake designed to verify that the receiving element wishes to receive traffic from the sender.=20 [BA] I believe that the requirement needs to be stronger -- that the receiver has agreed to specific traffic offered by the sender. So if the receiver agrees to receive audio and gets video instead=2C that isn't ok. Similarly=2C the guarantee shouldn't permit a browser to DoS a public STUN server=2C that merely by responding to a STUN request=2C hasn't indicated a willingness to receive any media at all. Overall=2C it's important that we get into the specific conditions under which ICE provides the security guarantees we need.=20 More on this later.=20 It is important to remember here that the site initiating ICE is presumed malicious=3B in order for the handshake to be secure the receiving element MUST demonstrate receipt/knowledge of some value not available to the site (thus preventing it from forging responses). In order to achieve this objective with ICE=2C the STUN transaction IDs must be generated by the browser and MUST NOT be made available to the initiating script=2C even via a diagnostic interface. 4.2.2. Masking Once consent is verified=2C there still is some concern about misinterpretation attacks as described by Huang et al.[huang-w2sp]. As long as communication is limited to UDP=2C then this risk is probably limited=2C thus masking is not required for UDP. I.e.=2C once communications consent has been verified=2C it is most likely safe to allow the implementation to send arbitrary UDP traffic to the chosen destination=2C provided that the STUN keepalives continue to succeed. [BA] Receiving a STUN keepalive (particularly one which is not authenticate= d) is not sufficient to protect against UDP-based attacks. =20 However=2C with TCP the risk of transparent proxies becomes much more severe. If TCP is to be used=2C then WebSockets style masking MUST be employed. = --_07c49ff5-42e0-463a-bad0-e1935d4d3c0c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Much of this document is very good=2C but the sections on ICE and masking a= ren't quite right.

The security properties attributed to ICE only ex= ist under a very carefully circumscribed set of conditions. =3B Unfortu= nately=2C Sections 4.2.1 and 4.2.2 aren't clear about this.

The ICE = exchange is fine for verifying willingness to accept a particular stream=2C= assuming that the receiver provides an indication of willingness to receiv= e. =3B =3B In part=2C this works because the specific characteristi= cs of the stream are negotiated in SDP offer/answer simultaneous with ICE.&= nbsp=3B However=2C Section 4.2.1 isn't specific enough about what guarantee= s are provided by ICE and under what conditions. =3B An ICE exchange do= esn't enable "traffic"=3B =3B at best it enables media with characteris= tics specified in SDP offer/answer to be sent.  =3B

Section 4.2= .2 says that masking is not necessary for UDP=2C but the logic behind the s= tatement needs more elaboration. There are lots of potentially nasty things= that can be done if a browser can send arbitrary datagrams to a receiver= =2C even if we postulate a STUN exchange. =3B Things like:

* Sen= ding a datagram that might be mistaken for a DNS response=2C potentially po= isoning the cache.
* Sending an SNMP set to a device.
* Sourcing a r= outing packet (e.g. RIPv2).

It strikes me that Section 4.2.2 is nee= ds to be more specific about the specific threats and the conditions under = which they are mitigated via ICE=2C SDP offer/answer=2C etc.


4.2.1<= /a>. ICE

 Verifying receiver consent requires some sort of explicit handshake=2C but conveniently we already need one in order to do NAT hole- punching. ICE [RF= C5245] includes a handshake designed to verify that the receiving element wishes to receive traffic from the sender.
[BA] I believe that the requirement needs to be stronger -- that
the re= ceiver has agreed to specific traffic offered
by the sender. So if the = receiver agrees to receive audio and gets
video instead=2C that isn't ok= . Similarly=2C the guarantee shouldn't
permit a browser to DoS a public= STUN server=2C that merely by responding
to a STUN request=2C hasn't in= dicated a willingness to receive any
media at all. Overall=2C it's impo= rtant that we get into the specific
conditions under which ICE provides = the security guarantees we need.
More on this later.

It is i= mportant to remember here that the site initiating ICE is presumed malicious=3B in order for the handshake to be secure the receiving element MUST demonstrate receipt/knowledge of some value not available to the site (thus preventing it from forging responses). In order to achieve this objective with ICE=2C the STUN transaction IDs must be generated by the browser and MUST NOT be made available to the initiating script=2C even via a diagnostic interface.

4.2.2. Masking

= Once consent is verified=2C there still is some concern about misinterpretation attacks as described by Huang et al.[huan= g-w2sp]. As long as communication is limited to UDP=2C then this risk is probably limited=2C thus masking is not required for UDP. I.e.=2C once communications consent has been verified=2C it is most likely safe to allow the implementation to send arbitrary UDP traffic to the chosen destination=2C provided that the STUN keepalives continue to succeed.
[BA] Receiving a STUN keepalive (particularly one which is not authent= icated)
is not sufficient to protect against UDP-based attacks.
 =3BHowever=2C with TCP the risk of transparent proxies becomes much= more severe. If TCP is to be used=2C then WebSockets style masking MUST be employed.

= --_07c49ff5-42e0-463a-bad0-e1935d4d3c0c_-- From holmer@google.com Thu Sep 8 01:12: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 953CB21F8B08 for ; Thu, 8 Sep 2011 01:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1R7SS6Z6UfSA for ; Thu, 8 Sep 2011 01:12:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id D5A0121F8B0D for ; Thu, 8 Sep 2011 01:12:39 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p888EU2x008653 for ; Thu, 8 Sep 2011 01:14:30 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315469670; bh=1m/8jxHEgGL1sjQa56FXC+l+HTY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type; b=cR+y66Hdbk4PKSlu9mzJF1KdyG7SChj1NyXbVo/rruoamtmizdecZ9jjg2rDxSqy5 +OT/F9K19VJkY8Q06VCMA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:content-type:x-system-of-record; b=Hcmj4ITg8bUSvPF5z8+wGoBAd1jgVtOX3piVFwkCXxHatg55Q8UHEay+5mkv3ImP5 Tf23Asbj2X9pufXb+pj2w== Received: from ewy5 (ewy5.prod.google.com [10.241.103.5]) by hpaq13.eem.corp.google.com with ESMTP id p888ETej027469 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 8 Sep 2011 01:14:29 -0700 Received: by ewy5 with SMTP id 5so231863ewy.34 for ; Thu, 08 Sep 2011 01:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=vu8XiMyu0Mh8y4NJ/ZbeYaoJz2dAnjRV2OXvdLiumWY=; b=RnMmJUSpJt+cYOTHelhcX/e5Lk4zfY2Q+30q3lPWA3fGeOVUA51XiUUHqKNIf3jwHX ncShE0opmvCTAYCLhWKQ== Received: by 10.213.2.141 with SMTP id 13mr172432ebj.50.1315469669580; Thu, 08 Sep 2011 01:14:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.2.141 with SMTP id 13mr172428ebj.50.1315469669283; Thu, 08 Sep 2011 01:14:29 -0700 (PDT) Received: by 10.213.114.84 with HTTP; Thu, 8 Sep 2011 01:14:29 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Sep 2011 10:14:29 +0200 Message-ID: From: Stefan Holmer To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=0015174be08059b79304ac69a6b1 X-System-Of-Record: true Subject: Re: [rtcweb] rtcweb Digest, Vol 7, Issue 16 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 08:12:43 -0000 --0015174be08059b79304ac69a6b1 Content-Type: text/plain; charset=ISO-8859-1 > ---------- Forwarded message ---------- > From: Randell Jesup > To: rtcweb@ietf.org > Date: Tue, 06 Sep 2011 18:21:42 -0400 > Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New > Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) > On 9/5/2011 6:09 AM, Harald Alvestrand wrote: > >> There is a congestion control algorithm inside the Google WebRTC codebase >> that hasn't been documented publicly before, and might be interesting as >> input when we get around to discussing what congestion control should be >> mandatory-to-implement in this group. >> > > Where is this in the webrtc drop? I looked but didn't see anything hooked > up to RTPReceiverVideo::**EstimateBandwidth(). There's something in this > genre for iSAC, though I didn't have time to look closely but it appears to > be somewhat specialized for iSAC. > Links to the code are available in this discuss-webrtc post. https://groups.google.com/group/discuss-webrtc/browse_thread/thread/37dcbba7e4697853 > > >> It's not forwarded as a candidate for what the result should be; I think >> there can be better solutions (see the "further work" section in this >> draft). >> > > Harald et al: this definitely answers my suggestion/request that we make > congestion control mandatory, and that we target something similar to > Radvision's NetSense, which this appears to have similar characteristics to. > > A few comments: > > In 3. (Receiver-side): > > When an over-use is detected the system transitions to the decrease > state, where the available bandwidth estimate is decreased to a > factor times the currently incoming bit rate. > > A_hat(i) = alpha*R_hat(i) > > alpha is typically chosen to be in the interval [0.8, 0.95]. > > > May I suggest that there's more information available here than a single > bit of "over-bandwidth". We have an estimate here how *much* we're > over-bandwidth, though cross-traffic and other fixed streams (audio) are > part of that too, so it needs to be used with a grain of salt - but that > slope is useful information. > You are right about that. I think it all boils down to how long you can tolerate to wait for the queues to drain. > > In either case we want to > measure the highest incoming rate during the under-use interval: > > R_max = max{R_hat(i)} for i in 1..K > > > where K is the number of frames of under-use before returning to the > normal state. R_max is a measure of the actual bandwidth available > and is a good guess of what bit rate we should be able to transmit > at. Therefore the available bandwidth will be set to Rmax when we > transition from the hold state to the increase state. > > This is good, but it might make sense to explain why this is the case (as > the draft does for other parts); I assume the argument is that if the delay > is reducing after a bottleneck, then from the router that was buffering to > us (usually just on the far end of the bottleneck) packets are flowing > through from there as fast as they can. > > In fact, the rate they're getting through *while* you're over-bandwidth is > actually the best estimate of total bandwidth you're likely to get. So in > fact you can estimate it well in all cases except when you're in "increase" > mode (buffers drained and stable), pretty much. > I agree. Another reason for estimating the total bandwidth while queues are draining is to get a more recent estimate than if we use the estimate we got while over-using. > > I would also suggest that the rate to use is R_max * gamma (where gamma < > 1.0) > Yes, I definitely agree here too, and that is actually what our implementation does. We should update the draft with that. > BTW, the description of directions here is confusing; the receiver is > determining the apparent bandwidth the sender should be using; "we should be > able to transmit at" is both wrong and confusing (probably should be "the > sender should be able to transmit at"). > > I agree. > > Sender-side control: 10% seems rather high. My experience was more > aggressive in the face of loss, both in the limit at which it reacts and the > amount it reduces - over maybe 5% loss I would cut sender bandwidth by 10 or > 15% on top of whatever the slope told me to do. > > Yes, these values can probably be better tuned. The purpose of the send-side estimator is to be a last way out if the receive-side estimator fails. The receiver has a better picture of whether the packet losses are a result of congestion or not, and as an improvement I think it makes sense to incorporate packet losses into the receive-side estimator (as you mentioned below). > > > Interop - the receiver could incorporate packet loss into the estimate > used for TMMBR, which might improve talking to senders who don't follow this > algorithm. We should consider how to handle cases that involve interop and > if and how to detect them; the algorithm may want to be different for those > cases. > > I think interop with endpoints which use other algorithms will work okay in one way, as long as they handle incoming TMMBR correctly. However, if the endpoint we're trying to interop with doesn't produce good estimates for TMMBR (close to the available bandwidth) we will rely only on the send-side algorithm. > > Future: > We very much want to merge all the info we can from all the streams, so we > can control where the bandwidth restrictions are applied instead of running > it on N streams independently. (For example, if we're sending two video > streams we may want to apportion the bandwidth according to their > size/framerate instead of equally, and we'll very much want to consider for > data channels (and perhaps media) a 'priority' factor ala RTFMP.) > > > I'll have more comments, but I need to turn into a pumpkin now and wanted > to get what I have on the wire. I haven't spent a lot of time fleshing them > out or editing, so take them as a starting point for discussion. > > > > >> The code is available through www.webrtc.org, and the IPR statements >> covering the code are found here: https://sites.google.com/site/** >> webrtc/license-rights >> >> Harald >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-alvestrand-rtcweb-** >> congestion-00.txt >> Date: Mon, 05 Sep 2011 03:03:38 -0700 >> From: internet-drafts@ietf.org >> To: harald@alvestrand.no >> CC: harald@alvestrand.no, holmer@google.com >> >> >> >> A new version of I-D, draft-alvestrand-rtcweb-**congestion-00.txt has >> been successfully submitted by Harald Alvestrand and posted to the IETF >> repository. >> >> Filename: draft-alvestrand-rtcweb-**congestion >> Revision: 00 >> Title: A Google Congestion Control for Real-Time Communication >> on the World Wide Web >> Creation date: 2011-09-05 >> WG ID: Individual Submission >> Number of pages: 14 >> >> Abstract: >> This document describes two methods of congestion control when using >> real-time communications on the World Wide Web (RTCWEB); one sender- >> based and one receiver-based. >> >> It is published to aid the discussion on mandatory-to-implement flow >> control for RTCWEB applications; initial discussion is expected in >> the RTCWEB WG's mailing list. >> >> >> >> > -- > Randell Jesup > randell-ietf@jesup.org > --0015174be08059b79304ac69a6b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

-= --------- Forwarded message ----------
From:=A0Randell Jesup <randell-ietf@jesup.org>
To:=A0rtcweb@ietf.org
Date:=A0Tue= , 06 Sep 2011 18:21:42 -0400
Subject:=A0Re: [rtcweb] An input for discus= sing congestion control (Fwd: New Version Notification for draft-alvestrand= -rtcweb-congestion-00.txt)
On 9/5/2011 6:09 AM, Harald Alvestrand wrote:
There is a congestion control algorithm inside the Google WebRTC codebase t= hat hasn't been documented publicly before, and might be interesting as= input when we get around to discussing what congestion control should be m= andatory-to-implement in this group.

Where is this in the webrtc drop? =A0I looked but didn't see anything h= ooked up to RTPReceiverVideo::EstimateBandwidth(). =A0There's so= mething in this genre for iSAC, though I didn't have time to look close= ly but it appears to be somewhat specialized for iSAC.

Links to the code are available in this di= scuss-webrtc post.
=A0


It's not forwarded as a candidate for what the result should be; I thin= k there can be better solutions (see the "further work" section i= n this draft).

Harald et al: this definitely answers my suggestion/request that we make co= ngestion control mandatory, and that we target something similar to Radvisi= on's NetSense, which this appears to have similar characteristics to.
A few comments:

In 3. (Receiver-side):

=A0 When an over-use is detected the system transitions to the decrease =A0 state, where the available bandwidth estimate is decreased to a
=A0 factor times the currently incoming bit rate.

=A0 =A0 A_hat(i) =3D alpha*R_hat(i)

=A0 alpha is typically chosen to be in the interval [0.8, 0.95].


May I suggest that there's more information available here than a singl= e bit of "over-bandwidth". =A0We have an estimate here how *much*= we're over-bandwidth, though cross-traffic and other fixed streams (au= dio) are part of that too, so it needs to be used with a grain of salt - bu= t that slope is useful information.

You are right about that. I think it all b= oils down to how long you can tolerate to wait for the queues to drain.
=A0

=A0 In either case we want to
=A0 measure the highest incoming rate during the under-use interval:

=A0 =A0 R_max =3D max{R_hat(i)} for i in 1..K


=A0 where K is the number of frames of under-use before returning to the =A0 normal state. =A0R_max is a measure of the actual bandwidth available<= br> =A0 and is a good guess of what bit rate we should be able to transmit
=A0 at. =A0Therefore the available bandwidth will be set to Rmax when we =A0 transition from the hold state to the increase state.

This is good, but it might make sense to explain why this is the case (as t= he draft does for other parts); I assume the argument is that if the delay = is reducing after a bottleneck, then from the router that was buffering to = us (usually just on the far end of the bottleneck) packets are flowing thro= ugh from there as fast as they can.

In fact, the rate they're getting through *while* you're over-bandw= idth is actually the best estimate of total bandwidth you're likely to = get. =A0So in fact you can estimate it well in all cases except when you= 9;re in "increase" mode (buffers drained and stable), pretty much= .

I agree. Another reason for estimating the= total bandwidth while queues are draining is to get a more recent estimate= than if we use the estimate we got while over-using.
=A0

I would also suggest that the rate to use is R_max * gamma (where gamma <= ; 1.0)
=A0
Yes, I definitely agree here too,= and that is actually what our implementation does. We should update the dr= aft with that.
=A0
BTW, the description of directions here is confusing; the receiver is deter= mining the apparent bandwidth the sender should be using; "we should b= e able to transmit at" is both wrong and confusing (probably should be= "the sender should be able to transmit at").


I agree.
=A0

Sender-side control: =A010% seems rather high. =A0My experience was more ag= gressive in the face of loss, both in the limit at which it reacts and the = amount it reduces - over maybe 5% loss I would cut sender bandwidth by 10 o= r 15% on top of whatever the slope told me to do.


Yes, these values can probably be bett= er tuned. The purpose of the send-side estimator is to be a last way out if= the receive-side estimator fails. The receiver has a better picture of whe= ther the packet losses are a result of congestion or not, and as an improve= ment I think it makes sense to incorporate packet losses into the receive-s= ide estimator (as you mentioned below).
=A0


Interop - =A0the receiver could incorporate packet loss into the estimate u= sed for TMMBR, which might improve talking to senders who don't follow = this algorithm. =A0We should consider how to handle cases that involve inte= rop and if and how to detect them; the algorithm may want to be different f= or those cases.


I think interop with endpoints which u= se other algorithms will work okay in one way, as long as they handle incom= ing TMMBR correctly. However, if the endpoint we're trying to interop w= ith doesn't produce good estimates for TMMBR (close to the available ba= ndwidth) we will rely only on the send-side algorithm.
=A0

Future:
We very much want to merge all the info we can from all the streams, so we = can control where the bandwidth restrictions are applied instead of running= it on N streams independently. =A0(For example, if we're sending two v= ideo streams we may want to apportion the bandwidth according to their size= /framerate instead of equally, and we'll very much want to consider for= data channels (and perhaps media) a 'priority' factor ala RTFMP.)<= br>

I'll have more comments, but I need to turn into a pumpkin now and want= ed to get what I have on the wire. =A0I haven't spent a lot of time fle= shing them out or editing, so take them as a starting point for discussion.=




The code is available through www.webrtc.org, =A0and the IPR statements covering the code are = found here: https://sites.google.com/site/webrtc/license-righ= ts

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

-------- Original Message --------
Subject: =A0 =A0 =A0 =A0New Version Notification for draft-alvestrand-rtcwe= b-congestion-00.txt
Date: =A0 Mon, 05 Sep 2011 03:03:38 -0700
From: =A0 int= ernet-drafts@ietf.org
To: =A0 =A0 haral= d@alvestrand.no
CC: =A0 =A0 haral= d@alvestrand.no, holmer@google.com



A new version of I-D, draft-alvestrand-rtcweb-congestion-00.txt has = been successfully submitted by Harald Alvestrand and posted to the IETF rep= ository.

Filename: =A0 =A0 =A0 =A0draft-alvestrand-rtcweb-congestion
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 A Google Congestion Control for Real-Time Commun= ication on the World Wide Web
Creation date: =A0 2011-09-05
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 14

Abstract:
=A0 =A0This document describes two methods of congestion control when usin= g
=A0 =A0real-time communications on the World Wide Web (RTCWEB); one sender= -
=A0 =A0based and one receiver-based.

=A0 =A0It is published to aid the discussion on mandatory-to-implement flo= w
=A0 =A0control for RTCWEB applications; initial discussion is expected in<= br> =A0 =A0the RTCWEB WG&#39;s mailing list.




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

--0015174be08059b79304ac69a6b1-- From silviapfeiffer1@gmail.com Thu Sep 8 01:45: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 8A2C221F8B9A for ; Thu, 8 Sep 2011 01:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W23Eb2QKqlEq for ; Thu, 8 Sep 2011 01:45:06 -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 D370321F8B8D for ; Thu, 8 Sep 2011 01:45:05 -0700 (PDT) Received: by ywe9 with SMTP id 9so494104ywe.31 for ; Thu, 08 Sep 2011 01:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sKKB7f5dRX4eueic4AMTQzwuJ19layZqNFihef32Bcc=; b=B0bNIwnBv9WYS4gd7BBa5Kc2mSh427jwd85VAxa2aKevgv+wxe9cd56cPgJqxe65ks Ul0SAaDLrPEj1gV9hQEZdxMiqRLwT90m0tIV/wZjGSpNmg4j2wRpb9aKqX5tGplpU/C+ bk9CSFuyg+LSThe9MeoxSuWveLtzTKSYep7c0= Received: by 10.236.76.225 with SMTP id b61mr2338445yhe.92.1315471616276; Thu, 08 Sep 2011 01:46:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.203.5 with HTTP; Thu, 8 Sep 2011 01:46:36 -0700 (PDT) In-Reply-To: <3A9BCFFD-670F-49F0-9962-A00086B38FA7@edvina.net> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3EE.50707@jesup.org> <4E67F0A2.1070308@skype.net> <3A9BCFFD-670F-49F0-9962-A00086B38FA7@edvina.net> From: Silvia Pfeiffer Date: Thu, 8 Sep 2011 18:46:36 +1000 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 08:45:06 -0000 On Thu, Sep 8, 2011 at 5:13 PM, Olle E. Johansson wrote: > > 8 sep 2011 kl. 08:19 skrev Silvia Pfeiffer: > >> I'm arguing for leaving it out, since obviously it's already possible >> to support it in the browser through web sockets. We wouldn't put >> SMPTE support into browsers either just to be able to read email in >> browsers. >> >> I wonder: if you are arguing for it, what is it that is not possible >> with such a JS implementation that would require introduction of a >> totally new technology into the browser (with all associated security >> risks)? > Oh, if you mean me I apologize for not being clear. I don't want SIP in rtcweb at all. Your examples are good examples on my way of thinking about rtcweb as a media layer for separate apps. That I want SIP to power those apps is a another issue :-) Sorry. :-) I was speaking to the larger community on this list, not you personally when I said that. Apologies. I think we totally agree. Cheers, Silvia. From dburnett@voxeo.com Thu Sep 8 02:16: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 6C88A21F8A69 for ; Thu, 8 Sep 2011 02:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjliSX3GYket for ; Thu, 8 Sep 2011 02:16:31 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by ietfa.amsl.com (Postfix) with ESMTP id D6DE821F8A64 for ; Thu, 8 Sep 2011 02:16:30 -0700 (PDT) Received: from [76.111.43.10] (account dburnett@voxeo.com HELO [192.168.15.103]) by voxeo.com (CommuniGate Pro SMTP 5.3.8) with ESMTPSA id 95321363; Thu, 08 Sep 2011 09:18:13 +0000 From: Dan Burnett Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Sep 2011 05:18:12 -0400 Message-Id: <0D3E4B73-39A0-41C6-93E6-88E46E9416FF@voxeo.com> To: public-webrtc@w3.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: [rtcweb] Review of draft-ietf-rtcweb-use-cases-and-requirements-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 09:16:32 -0000 A while ago I promised a full read-through review of the use cases and = requirements document [1], primarily from the API perspective, but I = have included other comments as well. The comments follow the order of the document. Some are editorial, and = some are more substantive. Section 4: As a general comment, the use cases occasionally stray more = into implementation rather than just being worded in terms of user = needs. This has driven some of my wording change suggestions below. 4.2.1.1: The wording is a bit unclear as to whether this use case is = for only a single peer-to-peer connection or for multiple connections. = In particular, it points out that for a session there is a self-view and = a remote view, but it's not clear at that point whether there might be = *multiple* remote views simultaneously in the session. However, later = on in this use case it states that "Any session participant can end the = session at any time." Then there are what appear to be examples of = different users, but it is not clear whether it only needs to be = possible for each of these kinds of users to be supported (singly), or = whether it must be possible to support communication with all = simultaneously. Since there is a separate use case for multiparty video communication = (4.2.7), I believe this use case should be cleaned up a bit. I suggest = the following text for this use case: ****** Two or more users have loaded a video communication web application into = their browsers, provided by the same service provider, and logged into = the service it provides. The web service publishes information about = user login status by pushing updates to the web application in the = browsers. When one online user selects a peer online user, a 1-1 video = communication session between the browsers of the two peers is = initiated. The invited user might accept or reject the session. During session establishment a self-view is displayed, and once the = session has been established the video sent from the remote peer is = displayed in addition to the self-view. During the session, each user = can select to remove and re-insert the self-view as often as desired. = Each user can also change the sizes of his/her two video displays during = the session. Each user can also pause sending of media (audio, video, = or both) and mute incoming media. It is essential that the communication cannot be eavesdropped. Either session participant can end the session at any time. The two users may be using communication devices of different makes, = with different operating systems and browsers from different vendors. One user has an unreliable Internet connection that sometimes loses = packets and sometimes goes down completely. One user is located behind a Network Address Translator (NAT). ****** 4.2.3.1: I recommend some minor editorial changes, so that the second = paragraph reads ****** The communication device used by one of the users has several network = adapters (Ethernet, WiFi, Cellular). The communication device is = accessing the Internet using Ethernet, but the user has to start a trip = during the session. The communication device automatically changes to = use WiFi when the Ethernet cable is removed and then moves to cellular = access to the Internet when moving out of WiFi coverage. The session = continues even though the access method changes. ****** 4.2.4.1: "previos" -> "previous". Also, the first use of "QoS" should = define the term, as in "Quality of Service (QoS)". Actually, QoS is more a derived functional requirement than a use case, = especially when that specific term is used anywhere near IETF folks. If = what the user wants is that the call continues at best available quality = (to the possible detriment of other users of the same = cell/dsl/whatever), we should say so. It may be the best way to do this = lies in the codec or protocol and not using existing QoS methods. 4.2.5.1: We should clarify that *in this use case*, the service = providers are choosing to exchange no more information about the users = than what can be carried using SIP. In other words, this is not = suggesting that all RTCWeb/WebRTC web application service providers must = restrict themselves only to exchanging information that can be carried = via SIP (whatever SIP means in this situation). For example, in general = the interoperability of sites could be done though any IM protocol, = e.g., combined with, say, oauth for identity. We should not be mandating = or preferring (even by implication) any specific protocol. If websites = choose to export presence and identity to support interoperability that = is up to them and does not necessarily require that the RTCWeb API = provide such a mechanism. I almost think that this implies a new, more precise requirement that = the Web API MUST NOT prevent two webapps that happen to choose to peer = with SIP from peering. That makes clearer what our baseline minimum is = without restricting the peering mechanisms of all webapps. I say = "clearer" rather than "clear" because "peer with SIP" is itself not very = precise, but I still think it's better than what we have now. I suggest a minor rewording of "Each web service publishes information about user login status for = users that have a relationship with the other user; how this is = established is out of scope." to something more concrete, e.g., "For each user Alice who has authorized another user Bob to receive = login status information, Alice's service publishes Alice's login status = information to Bob. How this authorization is defined and established = is out of scope." 4.2.6.1: "thumbnail ot" -> "thumbnail of". "can not" -> "cannot" 4.2.7.1: "simple video communication service" needs to reference 4.2.1. 4.2.8.1: The description should begin with "This use case is based on = the previous one." Also, "can not" -> "cannot" and "sound of the tank, = that file" -> "sound of the tank; that file". More substantially, the note in this section strongly suggests that the = WebRTC/RTCWeb groups must be responsible for the mixing of sound objects = with streams before rendering. It might be clearer to state that our = group's work MUST NOT prevent this and in fact should work with other = groups' definitions of HTML5 audio rendering. 4.3.1.1: "mobile phone used" -> "mobile phone is used". "can not" -> = "cannot". This use case is underspecified. What does it mean for a user to "place = and receive calls in the same way as when using a normal mobile phone"? = My mobile phone vibrates when I receive a call, and I can dial it by = pressing and holding a digit on the keypad. I don't even have a SIP = softphone on my desktop that can do either one. The login must also = allow the user to manage their account, pay bills, add services, etc. = More interestingly, it should be possible to write a portal web app = that, once the user is logged in, does not require the user to submit an = additional set of credentials to access the phone functionality. 4.3.2.1: I don't believe this use case goes far enough. The phone = experience should be sufficiently embedded in the page that the user's = context can be passed with the call, possibly resulting in a deep dial = into an IVR tree or a customer service representative not having to ask = questions that the user has already answered at the website level. The = key here is that we should be aspiring to a user experience that is = *better* than that of a PSTN call, not just equivalent.=20 4.3.3.1: "can not" -> "cannot". "All participant are authenticated" -> = "All participants are authenticated". "There exists several" -> "There = exist several". "one low resolution stream, the" -> "one low resolution = stream, and the". "c) each browser" -> "or c) each browser". "just an = high" -> "just a high". "reslution" -> "resolution". Also, we should probably note in this use case that the spatialization = could not only happen as part of the server-side mixing but also by = having the server tag the stream with spatialization info and having the = browser render it. F2: "in presence of" -> "in the presence of" F5: ditto F8: "any more" -> "anymore" F15: I think this is venturing out of scope. Perhaps a better phrasing = is "The webrtc browser component MUST interoperate with other HTML5 = methods for processing and mixing sound objects (media that is retrieved = from another source than the established media stream(s) with the = peer(s) with audio streams)." F18: While support for a minimum common codec is important, requiring = it to be commonly supported by existing legacy telephony services is = technically only a nice-to-have feature. One might consider gsm610 as = an alternative, for example. F19: The first letter needs to be capitalized. F24: "carried in SIP" is not sufficiently precise. More clarity here = might improve some of the discussions we are currently having. F26: "in presence of" -> "in the presence of" General comment about all of the API requirements in section 5.3: they = are not written as API requirements, but as *web application* = requirements. Since many of the requirements on the web application = could be met through means other than the WebRTC API, it is easy for = people to agree with the requirement but strongly disagree on whether = the API needs to be the *mechanism* by which the requirement is = satisfied. Although I have not reworded all of the requirements below, = I think it would be much clearer if we only wrote the requirements that = the Web API itself must satisfy as "The Web API MUST ...". For example, = "The Web API MUST inform a web application when a stream from a peer is = no longer received." I suspect that this will help make clear where we disagree on which = requirements must be addressed by the Web API itself and which must = merely not be prevented by the Web API (and thus could be satisfied = external to the WebRTC API). A8 and A10: It would be good to clarify here somewhere what the = difference is between pause/resume and cease/start for a stream. A14: As written this is not entirely in scope. Perhaps the following = phrasing would be more accurate? "The Web API MUST NOT prevent panning, mixing, and other processing for = individual streams." A15: This requirement is too specific in terms of how identifiers are = shared. Would the following perhaps be more accurate? "For each stream, the Web API MUST provide to both parties of the = communication an identifier for the stream that is a) the same at both = ends, b) serializable, and c) unique relative to all other stream = identifiers in use by either party." The word "serializable" is not exactly correct, but the idea I'm trying = to convey is that the identifier can safely be passed from one party to = the other and back again, via WebRTC calls or otherwise. A16: A minor nit here -- we probably should not use the word "datagram" = at this stage because of its implementation implications. What about = "In addition to the streams listed elsewhere, the Web API MUST provide a = mechanism for sending and receiving isolated discrete chunks of data." A17: Another minor nit -- presumably this only applies when the signal = is audio. Maybe we could reword as "For streams of type audio, it MUST = be possible for the web application author to indicate, via the Web API, = when the stream is speech." 7.2: All but the last paragraph here should be written as requirements = in section 5.2, not in the security considerations section. They need = to be not security afterthoughts but primary requirements for = implementations. Additionally, I think we should be more explicit about consent revision = to include revocation, i.e., "The browser is expected to provide = mechanisms for users to revise and even completely revoke consent to use = device resources such as cameras and microphones." Along the same lines, I believe we also discussed at the WebRTC meeting = in Quebec that the browser should provide a user-visible security = indicator (such as a padlock) indicating the encryption level of the = session. Maybe this should be a requirement? Also, "browser is needs" -> "browser needs". 7.3: This should be a requirement in section 5.3. Thanks, -- dan [1] = http://www.ietf.org/id/draft-ietf-rtcweb-use-cases-and-requirements-04.txt= From michael@voip.co.uk Thu Sep 8 02:32: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 7142021F8677 for ; Thu, 8 Sep 2011 02:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 DYpoG67I6ksU for ; Thu, 8 Sep 2011 02:32:13 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with SMTP id 96C4121F84EC for ; Thu, 8 Sep 2011 02:32:13 -0700 (PDT) Received: from mail-vx0-f172.google.com ([209.85.220.172]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTmiMAnpDb4yON9VugmkvLmE+wESRZMPG@postini.com; Thu, 08 Sep 2011 02:34:05 PDT Received: by mail-vx0-f172.google.com with SMTP id 29so555694vxi.31 for ; Thu, 08 Sep 2011 02:33:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.23.76 with SMTP id k12mr458657vdf.225.1315474434628; Thu, 08 Sep 2011 02:33:54 -0700 (PDT) Received: by 10.220.153.79 with HTTP; Thu, 8 Sep 2011 02:33:54 -0700 (PDT) In-Reply-To: <95877BC0-B0AA-4B20-9C2E-C16076BBE96E@edvina.net> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67D1F4.10002@mozilla.com> <4E6808D5.7090709@alum.mit.edu> <95877BC0-B0AA-4B20-9C2E-C16076BBE96E@edvina.net> Date: Thu, 8 Sep 2011 10:33:54 +0100 Message-ID: From: Michael Procter To: "Olle E. Johansson" , Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 09:32:14 -0000 Paul, Olle, Both of you correctly point out that determining when a session is secure is a very hard problem - one that is nigh-on impossible except for certain restricted scenarios. But I think we may have missed the change of emphasis in Chris' proposed UI change. Instead of marking a session as secure (which is hard to determine), he is suggesting marking it as insecure (which is easier!). If the signalling and media entering and leaving the browser are not secured by an appropriate mechanism, then the session should be marked as 'insecure'. If they are secured, then Chris' proposal would have no indication on the browser, which intuitively seems to match what we know about the session - secure to the server but 'who knows' after that. Whether that is good enough for you will depend on whether you trust the service you are using. Michael On 8 September 2011 06:48, Olle E. Johansson wrote: > > 8 sep 2011 kl. 02:14 skrev Paul Kyzivat: >> >> Chris, >> >> I agree with you that the UI indication of security is important. >> But its also *hard* for this application, for a variety of reasons: >> >> - While it may be easy for the browser to know if the media stream >> =A0is itself secured, its hard (impossible) to know that its secured >> =A0to its ultimate end point. That is the problem with intermediaries. >> >> - it may turn out that not all the streams in the "call" have the >> =A0same degree of security. >> >> Of course this can all be dealt with via proper definition of what the U= I >> indication means, and doesn't mean. But doing that will just render it >> meaningless to many users. To be widely understood, the indication will = need >> to be simple, and closely aligned with what people "expect". >> >> Consider a stream that is secured to a PSTN gateway, and then travels ov= er >> the PSTN to somebody's phone. Should that be considered a "secure" call?= Or >> an "insecure" call? Or somewhere between those? >> >> Its going to be hard work to figure out what can both be reliably report= ed >> to users and also be understandable and meaningful to users. >> > Agree. I see your way of thinking as an argument to make all sessions > confidential, encrypted by default. We can't reliable define a "secure ca= ll" > and separate insecure sessions from secure sessions. Which mean that a UI > indication won't mean anything. We can just make sure that the first hop = is > protected, the rest is up to the application that operates the media > session. > /O > On 9/7/11 4:20 PM, Christopher Blizzard wrote: > > I want secure-by-default, maybe even secure-only. > Even if it's not secure-only there's also an important UI consideration > depending how we end up doing that in browsers. In the past we've made > the secure mode special (the lock icon in the early days, now the > green/blue bar) but I think that we should be making the insecure mode > special. That is, always mark a connection as very clearly unencrypted > via UI affordances. Just like banks "wanting to know how to get the lock > icon" we should be making call sites "wanting to know how to get rid of > that huge ugly warning that makes us look bad." > > Once again, I would much prefer secure-only, but I'll take > secure-by-default across browsers if I can get it. > > --Chris From tim@phonefromhere.com Thu Sep 8 02:36: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 329FA21F8B2B for ; Thu, 8 Sep 2011 02:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 m7fd01l9RTTG for ; Thu, 8 Sep 2011 02:36:58 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 970CC21F8B24 for ; Thu, 8 Sep 2011 02:36:57 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 3A25B37A902; Thu, 8 Sep 2011 10:51:45 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-11-12595893 From: Tim Panton In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> Date: Thu, 8 Sep 2011 10:38:48 +0100 Message-Id: <78E46957-F8C3-4607-B781-73CC824EB0E1@phonefromhere.com> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> To: Ravindran Parthasarathi X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 09:36:59 -0000 --Apple-Mail-11-12595893 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 7 Sep 2011, at 18:29, Ravindran Parthasarathi wrote: > Matthew, > =20 > When I asked for SIP, I have meant RFC 3261 only. The basic reason for = asking SIP is to make the basic call works between browser to browser = across web servers. Without SIP in browser, it is not going happen. = Innovative application is going to be proprietary whether it is HTTP or = SIP or any other protocol for that matter. > =20 > My reasoning are as follows: > 1) SIP makes browser more intelligence compare to dump signaling = mechanism like MEGACO and browser acts as MG. You'd be astonished what you can implement in javascript, just because = it isn't baked into the browser, it doesn't mean the protocol will be dumb. Take a look at how phono.com = does XMPP for a proof by example. > 2) The importance of basic call interop is that there is no need = of many individual id like skype id, Google id and yahoo id by everyone = in the world to communicate others. I wish to have single id like e-mail = id to be maintained by browser-to-browser users to communicate with = others. Be very careful what you wish for. You really don't want the users of a = virtual video phone in Habbo Hotel to be able to accidentally call an = adult Chatroulette service just by typing the right SIP address. Web = services represent=20 communities with rules, any interop between those services needs to be = centrally authorised. > 3) SIP helps to interop for basic call with other existing = realtime application in Enterprise & Telecom provider. It really doesn't . I'd guess a very small % of SIP endpoints are = directly exposed to the internet, almost all are behind some sort of = SBC, adding a permissioning and auth filter layer. > 4) There is no need to build two different signaling logic in = VoIP servers for each service. Your own example of Bridge line = appearance will need two implementation by the single vendor because = desktop application or hardphone implementation based on SIP and browser = based implementation is depend on HTTP metadata. It is possible to = avoided by having one signaling protocol. The classic VoIP use-case is only a small (and diminishing) part of the = ways that rtcweb will be used.=20 Rtcweb will typically provide additional features to a community, not be = the focus itself. Look at audio in second-life as an example, it adds to the experience, but SL existed and works = without it. (And that's salient, SL is still one of the biggest providers of wideband calls!) > =20 > In RTCWEB does not standardize the signaling protocol interface = between browsers, the interop across webservers is next to impossible = and it will be restricted to single webserver (company) only. Please let = me know in case I=92m missing something here. Sites who's users wish to interop will do so via XMPP, SIP or SS7 or IMS = or whatever is appropriate. (A small GSM cell operator providing a portal app might choose to = interop at the SS7 level to gain billing etc) Sites that don't wish to interop won't and it should not be forced on = them. I don't want my bank calling my second life avatar. Tim. > =20 > Thanks > Partha > _______________________________________________ > =20 > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-11-12595893 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 7 Sep 2011, at 18:29, = Ravindran Parthasarathi wrote:

 
When I = asked for SIP, I have meant RFC 3261 only. The basic reason for asking = SIP is to make the basic call works between browser to browser across = web servers. Without SIP in browser, it is not going happen. Innovative = application is going to be proprietary whether it is HTTP or SIP or any = other protocol for that matter.
My reasoning are as = follows:
1)SIP makes browser more intelligence compare to dump = signaling mechanism like MEGACO and browser acts as = MG.

You'd be astonished = what you can implement in javascript, just because it isn't baked into = the browser,
it doesn't mean the protocol will be dumb. Take a = look at how phono.com does = XMPP for a proof by example.

2)The importance of basic call interop is that there = is no need of many individual id like skype id, Google id  and = yahoo id by everyone in the world to communicate others. I wish to have = single id like e-mail id to be maintained by browser-to-browser users to = communicate with = others.

Be= very careful what you wish for. You really don't want the users of a = virtual video phone in Habbo Hotel to be able to accidentally call an = adult Chatroulette service just by typing the right SIP address. Web = services represent 
communities with rules, any interop = between those services needs to be centrally = authorised.


3)SIP helps to interop for basic call with other = existing realtime application in Enterprise & Telecom = provider.

= It really doesn't . I'd guess a very small % of SIP endpoints are = directly exposed to the internet, almost all are behind some sort of = SBC, adding a permissioning and auth filter layer.

4)There is no need to build two different signaling = logic in VoIP servers for each service. Your own example of Bridge line = appearance will need two implementation by the single vendor because = desktop application or hardphone implementation based on SIP and browser = based implementation is depend on HTTP metadata. It is possible to = avoided by having one signaling = protocol.

= The classic VoIP use-case is only a small (and diminishing) part of the = ways that rtcweb will be used. 
Rtcweb will typically = provide additional features to a community, not be the focus itself. = Look at audio in second-life
as an example, it adds to the = experience, but SL existed and works without it. (And that's salient, SL = is still one of
the biggest providers of wideband = calls!)

 
In RTCWEB = does not standardize the signaling protocol interface between browsers, = the interop across webservers is next to impossible and it will be = restricted to single webserver (company) only. Please let  me know = in case I=92m missing something = here.

Site= s who's users wish to interop will do so via XMPP, SIP or SS7 or IMS or = whatever is appropriate.
(A small GSM cell operator providing = a portal app might choose to interop at the SS7 level to gain billing = etc)

Sites that don't wish to interop won't and it = should not be forced on them. I don't want my bank calling my second = life avatar.

<= /html>= --Apple-Mail-11-12595893-- From tim@phonefromhere.com Thu Sep 8 02:38: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 D22FF21F8B2B for ; Thu, 8 Sep 2011 02:38:55 -0700 (PDT) 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 IBtLBwtRuEEB for ; Thu, 8 Sep 2011 02:38:55 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA7521F8B24 for ; Thu, 8 Sep 2011 02:38:55 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 16EF937A902; Thu, 8 Sep 2011 10:53:43 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Tim Panton In-Reply-To: <2E243EBA-3A4C-420F-A1CF-B62374FFEF66@cisco.com> Date: Thu, 8 Sep 2011 10:40:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9B14D89F-3285-4A49-A733-364C054722CC@phonefromhere.com> References: <4E663A35.7000507@skype.net> <2E243EBA-3A4C-420F-A1CF-B62374FFEF66@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 09:38:55 -0000 On 7 Sep 2011, at 02:45, Cullen Jennings wrote: =85 snipped inc comment on excessive inlining ;-) =85.. >=20 > I'm not assuming anything about this being the primary use case. I'm = assuming it is an important use case. If it were not, we would do this = totally differently probably starting with not using RTP, certainly not = using SDP or offer/answer, and I'd argue for a p2p (in the overlay = network sense of the term) form rendezvous - there would be people on = the list point out if we use used HIP, everything would be done. We are = not doing that because it is an import use case. The reason it is = important is because that is the way we connect this to the existing = voice and video communication infrastructure that currently supports = well over 4 billion users and probably over 5 billion.=20 Just to be pedantic, it is _a_ way we can connect to the 5 billion. = Since a growing number of them are on GSM capable equipment, that could = be seen as an argument for an Um or SS7 or IMS stack.=20 My real point being that we can't expect a RTC capable web browser to be = able to directly address anything but a tiny proportion of them. A browser in an enterprise _might_ be able to = connect RTP point-to-point with a SIP desk phone in the same enterprise, = but only if it was on the same VLAN, which isn't common practice. So whilst it is an important use case, it is not going to see much = actual use (IMHO). Tim (speaking for himself)= From oej@edvina.net Thu Sep 8 02:43: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 B6B3021F8B08 for ; Thu, 8 Sep 2011 02:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=-0.132, 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 JFRZNeNnmyd4 for ; Thu, 8 Sep 2011 02:43:39 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id CF33221F8AF7 for ; Thu, 8 Sep 2011 02:43:38 -0700 (PDT) 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 D5EF9754BCE4; Thu, 8 Sep 2011 09:45:27 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: "Olle E. Johansson" In-Reply-To: <78E46957-F8C3-4607-B781-73CC824EB0E1@phonefromhere.com> Date: Thu, 8 Sep 2011 11:45:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <159793A7-6469-4686-B4F7-EDC5B3C77DF7@edvina.net> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <78E46957-F8C3-4607-B781-73CC824EB0E1@phonefromhere.com> To: Tim Panton X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 09:43:39 -0000 8 sep 2011 kl. 11:38 skrev Tim Panton: >=20 > On 7 Sep 2011, at 18:29, Ravindran Parthasarathi wrote: >=20 >> Matthew, >> =20 >> When I asked for SIP, I have meant RFC 3261 only. The basic reason = for asking SIP is to make the basic call works between browser to = browser across web servers. Without SIP in browser, it is not going = happen. Innovative application is going to be proprietary whether it is = HTTP or SIP or any other protocol for that matter. >> =20 >> My reasoning are as follows: >> 1) SIP makes browser more intelligence compare to dump signaling = mechanism like MEGACO and browser acts as MG. >=20 > You'd be astonished what you can implement in javascript, just because = it isn't baked into the browser, > it doesn't mean the protocol will be dumb. Take a look at how = phono.com does XMPP for a proof by example. >=20 >> 2) The importance of basic call interop is that there is no need = of many individual id like skype id, Google id and yahoo id by everyone = in the world to communicate others. I wish to have single id like e-mail = id to be maintained by browser-to-browser users to communicate with = others. >=20 > Be very careful what you wish for. You really don't want the users of = a virtual video phone in Habbo Hotel to be able to accidentally call an = adult Chatroulette service just by typing the right SIP address. Web = services represent=20 > communities with rules, any interop between those services needs to be = centrally authorised. ..or not authorised. Regardless, the decision about that is not in scope = for rtcweb in my opinion. >=20 >=20 >> 3) SIP helps to interop for basic call with other existing = realtime application in Enterprise & Telecom provider. >=20 > It really doesn't . I'd guess a very small % of SIP endpoints are = directly exposed to the internet, almost all are behind some sort of = SBC, adding a permissioning and auth filter layer. We can discuss for along time why SIP isn't used on the open Internet - = but that's just a good example on why we need to follow Skype and secure = all media streams. Hopefully we can build an open federation of SIP = services somewhere down the road, like the existing open XMPP = federation. That's in my opinion also out of scope of rtcweb. >=20 >> 4) There is no need to build two different signaling logic in = VoIP servers for each service. Your own example of Bridge line = appearance will need two implementation by the single vendor because = desktop application or hardphone implementation based on SIP and browser = based implementation is depend on HTTP metadata. It is possible to = avoided by having one signaling protocol. >=20 > The classic VoIP use-case is only a small (and diminishing) part of = the ways that rtcweb will be used.=20 > Rtcweb will typically provide additional features to a community, not = be the focus itself. Look at audio in second-life > as an example, it adds to the experience, but SL existed and works = without it. (And that's salient, SL is still one of > the biggest providers of wideband calls!) >=20 >> =20 >> In RTCWEB does not standardize the signaling protocol interface = between browsers, the interop across webservers is next to impossible = and it will be restricted to single webserver (company) only. Please let = me know in case I=92m missing something here. >=20 > Sites who's users wish to interop will do so via XMPP, SIP or SS7 or = IMS or whatever is appropriate. > (A small GSM cell operator providing a portal app might choose to = interop at the SS7 level to gain billing etc) >=20 > Sites that don't wish to interop won't and it should not be forced on = them. I don't want my bank calling my second life avatar. Hmm. Do you have a trust problem with the bank or the avatar? ;-) Agree that we need to keep rtcweb focused on the media handling and let = the application developers decide on signalling model. Personally, I = need it to interface with SIP and XMPP platforms so selecting either one = for inclusion in rtcweb would mean that I have to add gateways, which is = never a good solution. Let's try to keep signalling out of scope for = the rtcweb project. /O= From harald@alvestrand.no Thu Sep 8 03:08: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 39E4021F8A71 for ; Thu, 8 Sep 2011 03:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.22 X-Spam-Level: X-Spam-Status: No, score=-107.22 tagged_above=-999 required=5 tests=[AWL=2.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6NihsG8IuiC for ; Thu, 8 Sep 2011 03:08:58 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CB8AB21F8A6F for ; Thu, 8 Sep 2011 03:08:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CBCA739E0F3; Thu, 8 Sep 2011 12:10:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoVoSiKKDxbw; Thu, 8 Sep 2011 12:10:46 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id EC09639E074; Thu, 8 Sep 2011 12:10:45 +0200 (CEST) Message-ID: <4E6894A5.3090208@alvestrand.no> Date: Thu, 08 Sep 2011 12:10:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050404040003030709070309" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-rescorla-rtcweb-security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 10:08:59 -0000 This is a multi-part message in MIME format. --------------050404040003030709070309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/08/11 10:04, Bernard Aboba wrote: > Much of this document is very good, but the sections on ICE and > masking aren't quite right. > > The security properties attributed to ICE only exist under a very > carefully circumscribed set of conditions. Unfortunately, Sections > 4.2.1 and 4.2.2 aren't clear about this. > > The ICE exchange is fine for verifying willingness to accept a > particular stream, assuming that the receiver provides an indication > of willingness to receive. In part, this works because the specific > characteristics of the stream are negotiated in SDP offer/answer > simultaneous with ICE. However, Section 4.2.1 isn't specific enough > about what guarantees are provided by ICE and under what conditions. > An ICE exchange doesn't enable "traffic"; at best it enables media > with characteristics specified in SDP offer/answer to be sent. I think that what a completed ICE exchange provides is a guarantee that someone sending datagrams with the source address of has access to a) an incoming datagram sent to that , and b) a secret shared out-of-band. That's all. We have made the assumption that in correctly implemented applications, this means that the listener at is willing to receive media as negotiated in the same exchange as that which exchanged the shared secret. > > Section 4.2.2 says that masking is not necessary for UDP, but the > logic behind the statement needs more elaboration. There are lots of > potentially nasty things that can be done if a browser can send > arbitrary datagrams to a receiver, even if we postulate a STUN > exchange. Things like: > > * Sending a datagram that might be mistaken for a DNS response, > potentially poisoning the cache. This only works if we have completed the ICE exchange to the port that is listening for DNS responses. > * Sending an SNMP set to a device. This only works if we have completed the ICE exchange to port 161 on the device. > * Sourcing a routing packet (e.g. RIPv2). Again.... > > It strikes me that Section 4.2.2 is needs to be more specific about > the specific threats and the conditions under which they are mitigated > via ICE, SDP offer/answer, etc. More specific language is usually better. But in this particular instance, I have trouble interpreting the argument. > > > 4.2.1. ICE > > > > Verifying receiver consent requires some sort of explicit handshake, > but conveniently we already need one in order to do NAT hole- > punching. ICE [RFC5245 ] includes a handshake designed to verify that > the receiving element wishes to receive traffic from the sender. > > [BA] I believe that the requirement needs to be stronger -- that > the receiver has agreed to specific traffic offered > by the sender. So if the receiver agrees to receive audio and gets > video instead, that isn't ok. I believe this is outside what ICE can provide - the same issue exists if someone asks for 140x100 thumbnail video and gets 8K cinema resolution instead. Agreed that it needs addressing, but now we're into "have to obey constraints specified in the media negotiation" territory. > Similarly, the guarantee shouldn't > permit a browser to DoS a public STUN server, that merely by responding > to a STUN request, hasn't indicated a willingness to receive any > media at all. Overall, it's important that we get into the specific > conditions under which ICE provides the security guarantees we need. > More on this later. What exactly does a public STUN server respond to? Somehow I doubt that it completes an ICE handshake according to RFC 5245. > It is important to remember here that the site initiating ICE is > presumed malicious; in order for the handshake to be secure the > receiving element MUST demonstrate receipt/knowledge of some value > not available to the site (thus preventing it from forging > responses). In order to achieve this objective with ICE, the STUN > transaction IDs must be generated by the browser and MUST NOT be made > available to the initiating script, even via a diagnostic interface. > > > 4.2.2. Masking > > > > Once consent is verified, there still is some concern about > misinterpretation attacks as described by Huang et al.[huang-w2sp ]. > As long as communication is limited to UDP, then this risk is > probably limited, thus masking is not required for UDP. I.e., once > communications consent has been verified, it is most likely safe to > allow the implementation to send arbitrary UDP traffic to the chosen > destination, provided that the STUN keepalives continue to succeed. > > [BA] Receiving a STUN keepalive (particularly one which is not authenticated) > is not sufficient to protect against UDP-based attacks. Why not? Note - the RFC 5389 short term credential mechanism is mandatory for all ICE packets. I see no reason to relax this requirement. > However, with TCP the risk of transparent proxies becomes much more > severe. If TCP is to be used, then WebSockets style masking MUST be > employed. > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------050404040003030709070309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On 09/08/11 10:04, Bernard Aboba wrote:
Much of this document is very good, but the sections on ICE and masking aren't quite right.

The security properties attributed to ICE only exist under a very carefully circumscribed set of conditions. Unfortunately, Sections 4.2.1 and 4.2.2 aren't clear about this.

The ICE exchange is fine for verifying willingness to accept a particular stream, assuming that the receiver provides an indication of willingness to receive. In part, this works because the specific characteristics of the stream are negotiated in SDP offer/answer simultaneous with ICE. However, Section 4.2.1 isn't specific enough about what guarantees are provided by ICE and under what conditions. An ICE exchange doesn't enable "traffic"; at best it enables media with characteristics specified in SDP offer/answer to be sent.
I think that what a completed ICE exchange provides is a guarantee that someone sending datagrams with the source address of <IP+PORT> has access to a) an incoming datagram sent to that <IP+PORT>, and b) a secret shared out-of-band. That's all.

We have made the assumption that in correctly implemented applications, this means that the listener at <IP+PORT> is willing to receive media as negotiated in the same exchange as that which exchanged the shared secret.



Section 4.2.2 says that masking is not necessary for UDP, but the logic behind the statement needs more elaboration. There are lots of potentially nasty things that can be done if a browser can send arbitrary datagrams to a receiver, even if we postulate a STUN exchange. Things like:

* Sending a datagram that might be mistaken for a DNS response, potentially poisoning the cache.
This only works if we have completed the ICE exchange to the port that is listening for DNS responses.
* Sending an SNMP set to a device.
This only works if we have completed the ICE exchange to port 161 on the device.
* Sourcing a routing packet (e.g. RIPv2).
Again....

It strikes me that Section 4.2.2 is needs to be more specific about the specific threats and the conditions under which they are mitigated via ICE, SDP offer/answer, etc.
More specific language is usually better. But in this particular instance, I have trouble interpreting the argument.


4.2.1.  ICE


   Verifying receiver consent requires some sort of explicit handshake,
   but conveniently we already need one in order to do NAT hole-
   punching.  ICE [RFC5245] includes a handshake designed to verify that
   the receiving element wishes to receive traffic from the sender. 

[BA] I believe that the requirement needs to be stronger -- that
the receiver has agreed to specific traffic offered
by the sender.  So if the receiver agrees to receive audio and gets
video instead, that isn't ok.
I believe this is outside what ICE can provide - the same issue exists if someone asks for 140x100 thumbnail video and gets 8K cinema resolution instead.
Agreed that it needs addressing, but now we're into "have to obey constraints specified in the media negotiation" territory.
  Similarly, the guarantee shouldn't
permit a browser to DoS a public STUN server, that merely by responding
to a STUN request, hasn't indicated a willingness to receive any
media at all.  Overall, it's important that we get into the specific
conditions under which ICE provides the security guarantees we need. 
More on this later.
What exactly does a public STUN server respond to? Somehow I doubt that it completes an ICE handshake according to RFC 5245.

   It is important to remember here that the site initiating ICE is
   presumed malicious; in order for the handshake to be secure the
   receiving element MUST demonstrate receipt/knowledge of some value
   not available to the site (thus preventing it from forging
   responses).  In order to achieve this objective with ICE, the STUN
   transaction IDs must be generated by the browser and MUST NOT be made
   available to the initiating script, even via a diagnostic interface.

4.2.2.  Masking


   Once consent is verified, there still is some concern about
   misinterpretation attacks as described by Huang et al.[huang-w2sp].
   As long as communication is limited to UDP, then this risk is
   probably limited, thus masking is not required for UDP.  I.e., once
   communications consent has been verified, it is most likely safe to
   allow the implementation to send arbitrary UDP traffic to the chosen
   destination, provided that the STUN keepalives continue to succeed.

[BA] Receiving a STUN keepalive (particularly one which is not authenticated)
is not sufficient to protect against UDP-based attacks.
Why not?
Note - the RFC 5389 short term credential mechanism is mandatory for all ICE packets. I see no reason to relax this requirement.
  However, with TCP the risk of transparent proxies becomes much more
   severe.  If TCP is to be used, then WebSockets style masking MUST be
   employed.




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

--------------050404040003030709070309-- From harald@alvestrand.no Thu Sep 8 03:48: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 975E721F8B08 for ; Thu, 8 Sep 2011 03:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.888 X-Spam-Level: X-Spam-Status: No, score=-107.888 tagged_above=-999 required=5 tests=[AWL=2.710, 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 Q6fcpJyG+65e for ; Thu, 8 Sep 2011 03:48:45 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 75BB321F8B01 for ; Thu, 8 Sep 2011 03:48:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E0A9C39E0F3; Thu, 8 Sep 2011 12:50:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXTNxLCeWitp; Thu, 8 Sep 2011 12:50:36 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 0497139E074; Thu, 8 Sep 2011 12:50:36 +0200 (CEST) Message-ID: <4E689DFB.20105@alvestrand.no> Date: Thu, 08 Sep 2011 12:50:35 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Bernard Aboba References: , <4E6756C1.9060207@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090402070501080306060900" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 10:48:46 -0000 This is a multi-part message in MIME format. --------------090402070501080306060900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/08/11 06:45, Bernard Aboba wrote: > > > > 1) The media negotiations will be done using the same SDP > offer/answer semantics that are used in SIP. > > To be precise - you're suggesting that we use RFC 3264 offer/answer > > semantics. (That RFC is 25 pages long. RFC 3261, the core SIP document, > > is 269 pages, and is NOT a normative reference from 3264. I am anxious > > to avoid having a normative dependency on 3261.) > > > > I agree with this. > > [BA] I do *not* agree that RTCWEB should have to support every aspect > of SDP offer/answer. Basic offer/answer, sure. All potential corner > cases? Not necessarily. If we start off from: - RFC 3264 assuming that we support all of it, and then list the parts we don't want - RFC 3261 assuming we support none of it, and list the parts we do want we might have a better dialogue (or at least a more precise one). > > > > 2) It will be possible to gateway between legacy SIP devices that > support ICE and appropriate RTP / SDP mechanisms and codecs without > using a media gateway. A signaling gateway to convert between the > signaling on the web side to the SIP signaling may be needed. > > > I agree with this - I think the "may be needed" will turn out to be > > "will be needed", but some portion of that gateway can be > implemented by > > Javascript running in the browser, if desirable. > > [BA] This seems like a good principle, but I'm not clear that it will > work with all use cases. For example, what happens in the E911 use > cases when an RTCWEB implementation attempts to make a call to a PSAP > implementing NENA i3 Stage 3? If you don't have a media gateway, then > the browser will need to implement one of the mandated codecs on the > PSAP side. So in those use cases, eliminating the media gateway > implies making G.711 and H.264 mandatory-to-implement. Unless RTCWEB mandtory codecs have some overlap with the NENA i3 Stage 3 codecs, you have given a good argument for why NENA i3 Stage 3 devices should not be in the list of "legacy SIP devices that support ICE and appropriate RTP / SDP mechanisms and codecs". I'm still hoping that some day, someone will show up with a serial number and software version for a device they definitely think should be in the "legacy SIP devices that support ICE and appropriate RTP / SDP mechanisms and codecs" category. > > > > 3) When a new codec is specified, and the SDP for the new codec is > specified in the MMUSIC WG, no other standardization would should be > required for it to be possible to use that in the web browsers. Adding > a new codecs which might have new SDP parameters should not change the > APIs between the browser and javascript application. As soon as the > browsers support the new codec, old applications written before the > codecs was specified should automatically be able to use the new codec > where appropriate with no changes to the JS applications. > > I agree with this (modulo spelling and WG name fixups). > > [BA] Agree with "no new standardization". But that doesn't mean that > applications will automatically "just work", right? That's a much > harder requirement. Nothing ever "just works"..... but simple cases should continue to work. > > > I decided that the fight against SDP was not worth fighting after > > listening to the dozens of WGs doing SDP extensions for various > > purposes, many of which might make sense to incorporate in a browser > > platform, and concluding that SDP wouldn't hold still enough for us to > > specify a gateway from/to it. > > [BA] Agree that it's not worth fighting, but making it clear what we > do and do not support will be a "fight" of sorts. That is, unless > you're willing to require that the browser be able to *everything* > enabled by RFC 3264. Personally, I don't think that is worthwhile. I think we agree. Let's get down to specifics (in another thread). --------------090402070501080306060900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On 09/08/11 06:45, Bernard Aboba wrote:

> > 1) The media negotiations will be done using the same SDP offer/answer semantics that are used in SIP.
> To be precise - you're suggesting that we use RFC 3264 offer/answer
> semantics. (That RFC is 25 pages long. RFC 3261, the core SIP document,
> is 269 pages, and is NOT a normative reference from 3264. I am anxious
> to avoid having a normative dependency on 3261.)
>
> I agree with this.

[BA] I do *not* agree that RTCWEB should have to support every aspect of SDP offer/answer. Basic offer/answer, sure. All potential corner cases? Not necessarily.
If we start off from:
- RFC 3264 assuming that we support all of it, and then list the parts we don't want
- RFC 3261 assuming we support none of it, and list the parts we do want
we might have a better dialogue (or at least a more precise one).

> > 2) It will be possible to gateway between legacy SIP devices that support ICE and appropriate RTP / SDP mechanisms and codecs without using a media gateway. A signaling gateway to convert between the signaling on the web side to the SIP signaling may be needed.

> I agree with this - I think the "may be needed" will turn out to be
> "will be needed", but some portion of that gateway can be implemented by
> Javascript running in the browser, if desirable.

[BA] This seems like a good principle, but I'm not clear that it will work with all use cases. For example, what happens in the E911 use cases when an RTCWEB implementation attempts to make a call to a PSAP implementing NENA i3 Stage 3? If you don't have a media gateway, then the browser will need to implement one of the mandated codecs on the PSAP side. So in those use cases, eliminating the media gateway implies making G.711 and H.264 mandatory-to-implement.
Unless RTCWEB mandtory codecs have some overlap with the NENA i3 Stage 3 codecs, you have given a good argument for why NENA i3 Stage 3 devices should not be in the list of "legacy SIP devices that support ICE and appropriate RTP / SDP mechanisms and codecs".

I'm still hoping that some day, someone will show up with a serial number and software version for a device they definitely think should be in the "legacy SIP devices that support ICE and appropriate RTP / SDP mechanisms and codecs" category.

> > 3) When a new codec is specified, and the SDP for the new codec is specified in the MMUSIC WG, no other standardization would should be required for it to be possible to use that in the web browsers. Adding a new codecs which might have new SDP parameters should not change the APIs between the browser and javascript application. As soon as the browsers support the new codec, old applications written before the codecs was specified should automatically be able to use the new codec where appropriate with no changes to the JS applications.
> I agree with this (modulo spelling and WG name fixups).

[BA] Agree with "no new standardization". But that doesn't mean that applications will automatically "just work", right? That's a much harder requirement.
Nothing ever "just works"..... but simple cases should continue to work.

> I decided that the fight against SDP was not worth fighting after
> listening to the dozens of WGs doing SDP extensions for various
> purposes, many of which might make sense to incorporate in a browser
> platform, and concluding that SDP wouldn't hold still enough for us to
> specify a gateway from/to it.

[BA] Agree that it's not worth fighting, but making it clear what we do and do not support will be a "fight" of sorts. That is, unless you're willing to require that the browser be able to *everything* enabled by RFC 3264. Personally, I don't think that is worthwhile.
I think we agree. Let's get down to specifics (in another thread).

--------------090402070501080306060900-- From oej@edvina.net Thu Sep 8 03:59: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 4501621F8B24 for ; Thu, 8 Sep 2011 03:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=-0.105, 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 W-c4TIoZqJs4 for ; Thu, 8 Sep 2011 03:59:48 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id BA0EE21F8B0A for ; Thu, 8 Sep 2011 03:59:48 -0700 (PDT) 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 587BA754BCE4; Thu, 8 Sep 2011 11:01:38 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <4E689DFB.20105@alvestrand.no> Date: Thu, 8 Sep 2011 13:01:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <28436EE0-6D0F-4E23-B0D4-7FF60DCF5C52@edvina.net> References: , <4E6756C1.9060207@alvestrand.no> <4E689DFB.20105@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 10:59:49 -0000 8 sep 2011 kl. 12:50 skrev Harald Alvestrand: > I'm still hoping that some day, someone will show up with a serial = number and software version for a device they definitely think should be = in the "legacy SIP devices that support ICE and appropriate RTP / SDP = mechanisms and codecs" category. >>=20 We all hope for that to happen ;-) An issue here is that there's a wide gap between what the market offers = in terms of SIP device functionality and the IETF's vision. At some = point, I wish that the SIP forum copies the work of the XMPP Software = Foundation and tries to define standard SIP profiles for their members, = so we can move the market forward in terms of implementations. SIPit = events really help here as a means to educate SIP developers and put = some peer pressure on them. Sorry for being a bit off topic. Favorite topic, I guess ;-) /O= From christer.holmberg@ericsson.com Thu Sep 8 04:57: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 709FC21F8B5A for ; Thu, 8 Sep 2011 04:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 jjBcuzSYcuf6 for ; Thu, 8 Sep 2011 04:57:56 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4F07B21F8B36 for ; Thu, 8 Sep 2011 04:57:56 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-56-4e68ae3373ae Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DF.20.02839.33EA86E4; Thu, 8 Sep 2011 13:59:47 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 8 Sep 2011 13:59:47 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" , "ekr@rtfm.com" Date: Thu, 8 Sep 2011 13:57:46 +0200 Thread-Topic: SRTP for communications consent verification [was: [rtcweb] New security draft] Thread-Index: AcxtfPHaRrHtke9kSuW0q5N25C2KrAAoRY4w Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233E858B1@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== Subject: [rtcweb] SRTP for communications consent verification [was: 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: Thu, 08 Sep 2011 11:57:57 -0000 =20 Hi, One question regarding section 4.2 (Communications Consent Verification). When SRTP is used, could the security establishment procedure for SRTP also= be used for communications consent verification purpose? Regards, Christer > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: 7. syyskuuta 2011 19:41 > To: rtcweb@ietf.org > Subject: [rtcweb] New security draft >=20 >=20 > I see that EKR published an updated security draft at=20 >=20 > http://tools.ietf.org/html/draft-rescorla-rtcweb-security-01 >=20 > Just wanted to point that out to the list. >=20 > Cullen >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From harald@alvestrand.no Thu Sep 8 05:04: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 9B32321F8B6D for ; Thu, 8 Sep 2011 05:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.947 X-Spam-Level: X-Spam-Status: No, score=-107.947 tagged_above=-999 required=5 tests=[AWL=2.652, 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 54Dj6pcGpMPj for ; Thu, 8 Sep 2011 05:04:32 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1DF21F8B3E for ; Thu, 8 Sep 2011 05:04:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A650B39E0F3; Thu, 8 Sep 2011 14:06:23 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQCEFi6JH7O7; Thu, 8 Sep 2011 14:06:23 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 4A7AD39E074; Thu, 8 Sep 2011 14:06:23 +0200 (CEST) Message-ID: <4E68AFBE.8080802@alvestrand.no> Date: Thu, 08 Sep 2011 14:06:22 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852233E858B1@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233E858B1@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SRTP for communications consent verification [was: 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: Thu, 08 Sep 2011 12:04:32 -0000 On 09/08/11 13:57, Christer Holmberg wrote: > > Hi, > > One question regarding section 4.2 (Communications Consent Verification). > > When SRTP is used, could the security establishment procedure for SRTP also be used for communications consent verification purpose? > I don't think so, because if the other party lies about his IP address, this does not affect the key negotiation when the key negotiation is done out-of-band (with SDES). If using DTLS-SRTP, the ICE handshake has to complete before the keys can be negotiated, so verifying consent to communication comes for free with the ICE handshake anyway. From jonathan@vidyo.com Thu Sep 8 05:19: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 F216B21F8B7F for ; Thu, 8 Sep 2011 05:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 4qG-2uIWVqXf for ; Thu, 8 Sep 2011 05:19:31 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7C21E21F8B7D for ; Thu, 8 Sep 2011 05:19:31 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A7A18553B4C; Thu, 8 Sep 2011 08:21:19 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 45B4A553B59; Thu, 8 Sep 2011 08:21:19 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Thu, 8 Sep 2011 08:21:18 -0400 From: Jonathan Lennox To: Christer Holmberg , Randell Jesup Date: Thu, 8 Sep 2011 08:21:17 -0400 Thread-Topic: AVPF [was: [rtcweb] Encryption mandate (and offer/answer)] Thread-Index: AcxtrdxMz9T5EPlJRReppyAV+Xdn8AAQw9BAAAulCRA= Message-ID: References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@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 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 12:19:32 -0000 Indeed. More generally, the question is: should it be possible to send an offer tha= t by default does DTLS/SAVPF for RTCWeb, but also can fall back to other RT= P profiles to support legacy devices? If yes, then either browsers need to support CapNeg, or RTCWeb needs to use= something other than SDP Offer/Answer. If no, then supporting interop, without a media gateway, with other non-RTC= Web modes (e.g., no ICE, no rtcp mux, no audio/video mux, etc.) becomes IMO= a lot less compelling. =09 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Thursday, September 08, 2011 2:35 AM To: Randell Jesup; Jonathan Lennox Cc: rtcweb@ietf.org Subject: AVPF [was: [rtcweb] Encryption mandate (and offer/answer)] =20 Hi, >>>You could make forced-encryption the default, and allow the=20 >>>application control over whether to allow it is turned off for=20 >>>specific cases, like a PSTN call, or under the server's control. >>>Signalling is secure, so it could even use a direct optional=20 >>>downgrade from SAVP* to AVP* (i.e. >>>similar to the best-effort-strp draft) >>This has implications for the parallel thread about the use of SDP=20 >>offer/answer. >> >>The solution MMUSIC has standardized for best-effort SRTP is SDP=20 >>CapNeg, RFC 5939. Do we want to require CapNeg support in browsers? >=20 >Yeah, ok, I'm not going there. :-) It's probably not needed for this=20 >use-case anyways. The same question exists for AVPF, which has been suggested to be mandated. Regards, Christer From igor.faynberg@alcatel-lucent.com Thu Sep 8 06:53: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 2355421F8B87 for ; Thu, 8 Sep 2011 06:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.603 X-Spam-Level: X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTID426pvQeB for ; Thu, 8 Sep 2011 06:53:12 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8F221F844F for ; Thu, 8 Sep 2011 06:53:11 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p88Dt3sR021272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 8 Sep 2011 08:55:04 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p88Dt3Ph030918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 8 Sep 2011 08:55:03 -0500 Received: from [135.244.18.36] (faynberg.lra.lucent.com [135.244.18.36]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p88Dt2gA019207; Thu, 8 Sep 2011 08:55:03 -0500 (CDT) Message-ID: <4E68C935.2090607@alcatel-lucent.com> Date: Thu, 08 Sep 2011 09:55:01 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3EE.50707@jesup.org> <4E67F0A2.1070308@skype.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010704070200050806060500" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 13:53:14 -0000 This is a multi-part message in MIME format. --------------010704070200050806060500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Finally, I am getting an answer to my question! Thanks, Silvia! One question: Is it possible to get the full library source code? (I cannot find the this.phone.dial code, but this is the one that sends the INVITE as far as I figured out. Most important, I cannot find how notifications are handled.) Igor | | On 9/7/2011 9:15 PM, Silvia Pfeiffer wrote: > If implementations count for anything, check out: > > http://phono.com/ > and > https://docs.google.com/present/view?id=0AcNAXuadeXIxZGY4NDl4Z2RfNTlod3BrOXNjZA&hl=en&pli=1 > > They use SIP with web sockets. > > Cheers, > Silvia. > > > On Thu, Sep 8, 2011 at 8:30 AM, Matthew Kaufman > wrote: >> On 9/7/11 12:20 PM, Randell Jesup wrote: >>> I also started from the same point - assume SIP. SIP gives you all the >>> things that the zillions of hours and emails to define it and define >>> extensions and secure it provides, without having to reinvent all those >>> wheels (or ask app developers to reinvent them). Why go through the >>> horrible pain of choosing something else, or why throw the app developers to >>> the wolves to fend for themselves? >>> >>> However... >>> >>> Two things have swayed me. The primary one is the suggestion of >>> Offer/Answer in the browser. This breaks out the important negotiation >>> piece that almost any application would need, and while not perfect, SDP O/A >>> is a zillion times simpler than SIP with all the extensions one could use. >> I agree with this. While I am also opposed to SDP O/A, these are two >> unrelated arguments to have... and not baking a SIP phone into the browser >> is *more* important than avoiding a repeat of the offer/answer problems. >> >>> The other thing that swayed me was thinking about federation and the apps >>> that will be built with this. A webrtc app talks to its (web)server, other >>> webrtc clients running the app that talk to the server, and to other webrtc >>> applications/networks that federate with it (and their clients). >>> >>> Federation is in the same hands as the person who provides/wrote the app. >>> If they have no interest in federation you can't force it, and they may >>> have no use for all the fancy SIP standards. >> And for numerous types of apps (think: server-based augmented reality >> systems), "federation" doesn't even make sense. >> >>> On the other hand, if they *want* to either provide access to the wider >>> communication net that is the PSTN network, now or in the future, or they >>> want easy federation with other networks, it behooves them to use SIP or >>> something very close to it or equivalent/convertible (at a basic level at >>> least) to it. >>> >>> So what conclusions do I draw from this? >>> >>> 1) O/A via SDP in the browser simplifies a lot of things (including >>> handling new codecs, etc). It doesn't extremely limit an application, >>> though we should think about how an application can interact with the >>> fmtp/etc parameters used. >> I agree that it would simplify some interop cases, but at an unfortunate >> cost in lack of flexibility and functionality. Still not nearly as bad as if >> we put a full SIP stack in there though. >> >>> 2) SIP as a *separate* item that can be cleanly and easily *added* to a >>> webrtc app to handle the call setup/etc is a good idea. >> I would be open to looking at this again, *after* RTC is already in browsers >> and successful, to see if it actually solves a real use case. >> >> Matthew Kaufman >> >> _______________________________________________ >> 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 --------------010704070200050806060500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Finally, I am getting an answer to my question!  Thanks, Silvia!

One question: Is it possible to get the full library source code?  (I cannot find the this.phone.dial code, but this is the one that sends the INVITE as far as I figured out.  Most important, I cannot find how notifications are handled.)

Igor


On 9/7/2011 9:15 PM, Silvia Pfeiffer wrote: 
If implementations count for anything, check out:

http://phono.com/
and
https://docs.google.com/present/view?id=0AcNAXuadeXIxZGY4NDl4Z2RfNTlod3BrOXNjZA&hl=en&pli=1

They use SIP with web sockets.

Cheers,
Silvia.


On Thu, Sep 8, 2011 at 8:30 AM, Matthew Kaufman
<matthew.kaufman@skype.net> wrote:

On 9/7/11 12:20 PM, Randell Jesup wrote:

I also started from the same point - assume SIP.  SIP gives you all the
things that the zillions of hours and emails to define it and define
extensions and secure it provides, without having to reinvent all those
wheels (or ask app developers to reinvent them).  Why go through the
horrible pain of choosing something else, or why throw the app developers to
the wolves to fend for themselves?

However...

Two things have swayed me.  The primary one is the suggestion of
Offer/Answer in the browser.  This breaks out the important negotiation
piece that almost any application would need, and while not perfect, SDP O/A
is a zillion times simpler than SIP with all the extensions one could use.

I agree with this. While I am also opposed to SDP O/A, these are two
unrelated arguments to have... and not baking a SIP phone into the browser
is *more* important than avoiding a repeat of the offer/answer problems.


The other thing that swayed me was thinking about federation and the apps
that will be built with this.  A webrtc app talks to its (web)server, other
webrtc clients running the app that talk to the server, and to other webrtc
applications/networks that federate with it (and their clients).

Federation is in the same hands as the person who provides/wrote the app.
 If they have no interest in federation you can't force it, and they may
have no use for all the fancy SIP standards.

And for numerous types of apps (think: server-based augmented reality
systems), "federation" doesn't even make sense.


On the other hand, if they *want* to either provide access to the wider
communication net that is the PSTN network, now or in the future, or they
want easy federation with other networks, it behooves them to use SIP or
something very close to it or equivalent/convertible (at a basic level at
least) to it.

So what conclusions do I draw from this?

1) O/A via SDP in the browser simplifies a lot of things (including
handling new codecs, etc).  It doesn't extremely limit an application,
though we should think about how an application can interact with the
fmtp/etc parameters used.

I agree that it would simplify some interop cases, but at an unfortunate
cost in lack of flexibility and functionality. Still not nearly as bad as if
we put a full SIP stack in there though.


2) SIP as a *separate* item that can be cleanly and easily *added* to a
webrtc app to handle the call setup/etc is a good idea.

I would be open to looking at this again, *after* RTC is already in browsers
and successful, to see if it actually solves a real use case.

Matthew Kaufman

_______________________________________________
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
--------------010704070200050806060500-- From tim@phonefromhere.com Thu Sep 8 06:59: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 291AB21F8B7D for ; Thu, 8 Sep 2011 06:59:44 -0700 (PDT) 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 1PyK9pYdzxq2 for ; Thu, 8 Sep 2011 06:59:43 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 799BC21F8B74 for ; Thu, 8 Sep 2011 06:59:43 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 7B7C637A902; Thu, 8 Sep 2011 15:14:26 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <4E68C935.2090607@alcatel-lucent.com> Date: Thu, 8 Sep 2011 15:01:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <88632F61-941D-4557-9AFD-DE286C781942@phonefromhere.com> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3EE.50707@jesup.org> <4E67F0A2.1070308@skype.net> <4E68C935.2090607@alcatel-lucent.com> To: igor.faynberg@alcatel-lucent.com X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 13:59:44 -0000 On 8 Sep 2011, at 14:55, Igor Faynberg wrote: > Finally, I am getting an answer to my question! Thanks, Silvia! >=20 > One question: Is it possible to get the full library source code? (I = cannot find the this.phone.dial code, but this is the one that sends the = INVITE as far as I figured out. Most important, I cannot find how = notifications are handled.) >=20 > Igor The full source code is at: https://github.com/phono/PhonoSDK Tim.= From igor.faynberg@alcatel-lucent.com Thu Sep 8 07:02: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 9BCC121F8B71 for ; Thu, 8 Sep 2011 07:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.603 X-Spam-Level: X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fmj+Kwl5Lzyo for ; Thu, 8 Sep 2011 07:02:39 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 16B8921F8B67 for ; Thu, 8 Sep 2011 07:02:39 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p88E4RsN020519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 09:04:28 -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 p88E4QFC006097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Sep 2011 09:04:27 -0500 Received: from [135.244.18.36] (faynberg.lra.lucent.com [135.244.18.36]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p88E4OvS028935; Thu, 8 Sep 2011 09:04:25 -0500 (CDT) Message-ID: <4E68CB68.3020100@alcatel-lucent.com> Date: Thu, 08 Sep 2011 10:04:24 -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: Harald Alvestrand References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> In-Reply-To: <4E686663.1050900@alvestrand.no> Content-Type: multipart/alternative; boundary="------------020301070609050800030702" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 14:02:39 -0000 This is a multi-part message in MIME format. --------------020301070609050800030702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/8/2011 2:53 AM, Harald Alvestrand wrote: > ... > But sure - if you want us to implement some part of SIP, *please start > stating what part* rather than making wooly statements. I thought I had already proposed a subset: INVITE, SUBSCRIBE/NOTIFY, and REFER. Igor --------------020301070609050800030702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 9/8/2011 2:53 AM, Harald Alvestrand wrote:

...
But sure - if you want us to implement some part of SIP, *please start stating what part* rather than making wooly statements.

I thought I had already proposed a subset: INVITE, SUBSCRIBE/NOTIFY, and REFER.


Igor

--------------020301070609050800030702-- From sohel_khan777@yahoo.com Thu Sep 8 07:26: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 65BA221F8B0B for ; Thu, 8 Sep 2011 07:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U29IaTTeEA5r for ; Thu, 8 Sep 2011 07:26:51 -0700 (PDT) Received: from nm34-vm4.bullet.mail.bf1.yahoo.com (nm34-vm4.bullet.mail.bf1.yahoo.com [72.30.239.76]) by ietfa.amsl.com (Postfix) with SMTP id A8DA521F8AD9 for ; Thu, 8 Sep 2011 07:26:51 -0700 (PDT) Received: from [98.139.215.140] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 08 Sep 2011 14:28:38 -0000 Received: from [98.139.212.214] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 08 Sep 2011 14:28:38 -0000 Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 08 Sep 2011 14:28:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 766371.49663.bm@omp1023.mail.bf1.yahoo.com Received: (qmail 71146 invoked by uid 60001); 8 Sep 2011 14:28:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1315492118; bh=4kDN4+yM+zoKEP+ggP2R6U15Yuop0rzIRLIaMRt24tY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PZjaVbHGdv6eyUk4IMouDP7vABhunWbDRXRFDVrTGUJu+snZ4LWQZBRdON8KTcwzTtjHpf4Susg2P+mThTScGEyOlPQm/Z38SKHXBmfB5WZjM3pplIk3GnOfsc6QUxJMcLkGABmlhmkj3ZT0irz15VFNNmTXi+MS+Eg+LGi8WBQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SVWDy2W/6HuMVYBx64iCsMNCpfQ62m14N/9Cn9ep0cPvaoaD98Q1RaB6LoHRVqbrJIiAus24U8vLB/F3pDdn9Z3azvO2+j52nBgAUJFzBzTw5QN5PL26YaMZtC8zWJ9zMfitM1Fu73BIKuyo+tqyvqaLsZQBegWBZM7XwB2SfUM=; X-YMail-OSG: RrumfXAVM1l_twr5r5GlUd1l4yEEl.xIfNvLmwz6CaUlV4s 74Aek.aMU4LliZw.Pr3ZcwiYXyDStDK0JjL13OSxPIVLCjKlDdvbNe0uQsOv HzLWQam8Bj_CdRym36GjFecvNOXwk7_8R5VfFf.eJPX7N.j2HNq9ibtG9YkH e.9hSLGthI.BKo8EVgX6N0blMZYxRJ0_CLzAarGgNm_aJ2e.5kmxgyeBzipO YICrK9wq4ki2qD0cELWX0_T8sJgBpJvVQQZrLx1iXHthPsCtEDMIWncDSu2e cRZ5XmM7SCVtlFB3uqYGIYo3KDRF8DLlSwfCOhy1KRuvf5Iu4udS8rCC8FiE LqHh7AoQNpCgz5FhVLiqu5aj2Ii7O58AS3b5HpWUA20eqT0TLoVYqW4EaXDt j3croMCJmW7MBma0LvRvlykvpR0fgaesxz6a4h.9rdbAwVubqZ8OMeb06.Xe BIqYvoqzMww-- Received: from [68.87.42.110] by web162003.mail.bf1.yahoo.com via HTTP; Thu, 08 Sep 2011 07:28:38 PDT X-Mailer: YahooMailWebService/0.8.113.315625 References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <4E68CB68.3020100@alcatel-lucent.com> Message-ID: <1315492118.70069.YahooMailNeo@web162003.mail.bf1.yahoo.com> Date: Thu, 8 Sep 2011 07:28:38 -0700 (PDT) From: Sohel Khan To: "igor.faynberg@alcatel-lucent.com" , Harald Alvestrand In-Reply-To: <4E68CB68.3020100@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1017106480-1315492118=:70069" Cc: "rtcweb@ietf.org" Subject: [rtcweb] Meeting Bridge and Webex link for Sept 8th Meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sohel Khan List-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, 08 Sep 2011 14:26:52 -0000 --0-1017106480-1315492118=:70069 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0AI did not receive a Meeting Bridge or Webex link for Sept 8th virtual= meeting.=0AIf anyone can forward the link, I would appreciate.=0AThanks.= =A0=0A=0ARegards,=0ASohel Khan --0-1017106480-1315492118=:70069 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

I did not receive a Meeting Bridge or Webex link= for Sept 8th virtual meeting.
If anyone can forward the link, I would apprecia= te.
Thanks. 
 
Regards,
Sohel Khan
 



=  
--0-1017106480-1315492118=:70069-- From harald@alvestrand.no Thu Sep 8 07:28: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 7E57A21F8BDE for ; Thu, 8 Sep 2011 07:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.003 X-Spam-Level: X-Spam-Status: No, score=-108.003 tagged_above=-999 required=5 tests=[AWL=2.595, 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 AzURH8AVzteD for ; Thu, 8 Sep 2011 07:28:36 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A7B2D21F8B9F for ; Thu, 8 Sep 2011 07:28:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 91E5239E0F3; Thu, 8 Sep 2011 16:30:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AASqlNREWZVH; Thu, 8 Sep 2011 16:30:26 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id B87B439E074; Thu, 8 Sep 2011 16:30:26 +0200 (CEST) Message-ID: <4E68D182.2090003@alvestrand.no> Date: Thu, 08 Sep 2011 16:30:26 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <4E68CB68.3020100@alcatel-lucent.com> In-Reply-To: <4E68CB68.3020100@alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------000600020103020508060507" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 14:28:36 -0000 This is a multi-part message in MIME format. --------------000600020103020508060507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/08/11 16:04, Igor Faynberg wrote: > > > On 9/8/2011 2:53 AM, Harald Alvestrand wrote: >> > ... >> But sure - if you want us to implement some part of SIP, *please >> start stating what part* rather than making wooly statements. > > I thought I had already proposed a subset: INVITE, SUBSCRIBE/NOTIFY, > and REFER. That's the commands. What are the parameters? As I've said before, unless I've misunderstood what SUBSCRIBE/NOTIFY are for (I think they are just for presence), I want them totally outside the scope of RTCWEB; they are appropriate for implementation in Javascript if someone needs them. I don't know what REFER is for well enough to have an opinion of whether it's relevant. Harald --------------000600020103020508060507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On 09/08/11 16:04, Igor Faynberg wrote:


On 9/8/2011 2:53 AM, Harald Alvestrand wrote:

...
But sure - if you want us to implement some part of SIP, *please start stating what part* rather than making wooly statements.

I thought I had already proposed a subset: INVITE, SUBSCRIBE/NOTIFY, and REFER.

That's the commands. What are the parameters?

As I've said before, unless I've misunderstood what SUBSCRIBE/NOTIFY are for (I think they are just for presence), I want them totally outside the scope of RTCWEB; they are appropriate for implementation in Javascript if someone needs them.

I don't know what REFER is for well enough to have an opinion of whether it's relevant.

Harald

--------------000600020103020508060507-- From bernard_aboba@hotmail.com Thu Sep 8 07:42: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 6AAD421F8AEC for ; Thu, 8 Sep 2011 07:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[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 JUGDp3E0K9Pu for ; Thu, 8 Sep 2011 07:42:57 -0700 (PDT) Received: from blu0-omc1-s31.blu0.hotmail.com (blu0-omc1-s31.blu0.hotmail.com [65.55.116.42]) by ietfa.amsl.com (Postfix) with ESMTP id DA04221F8AEA for ; Thu, 8 Sep 2011 07:42:56 -0700 (PDT) Received: from BLU152-W65 ([65.55.116.9]) by blu0-omc1-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 07:44:49 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_c78752b1-26e9-43ea-81eb-c131845af97b_" X-Originating-IP: [70.88.131.169] From: Bernard Aboba To: , Date: Thu, 8 Sep 2011 07:44:48 -0700 Importance: Normal In-Reply-To: <4E68D182.2090003@alvestrand.no> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net>,<4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net>, <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com>, <4E67AD3D.9000005@alvestrand.no>, <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com>, <4E686663.1050900@alvestrand.no>, <4E68CB68.3020100@alcatel-lucent.com>, <4E68D182.2090003@alvestrand.no> MIME-Version: 1.0 X-OriginalArrivalTime: 08 Sep 2011 14:44:49.0307 (UTC) FILETIME=[DC2B9EB0:01CC6E35] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 14:42:57 -0000 --_c78752b1-26e9-43ea-81eb-c131845af97b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Harald said: "As I've said before=2C unless I've misunderstood what SUBSCRIBE/NOTIFY are for (I think they are just for presence)=2C I want them totally outside the scope of RTCWEB=3B they are appropriate for implementation in Javascript if someone needs them." =20 [BA] I had thought that someone posted a link to a SIP Javascript libra= ry that was designed to be used with jquery (similar to Strophe=2C but for = SIP). Has there been an argument demonstrating that this *has* to be nativ= e? Overall=2C I'm not sure why we're having this discussion. = --_c78752b1-26e9-43ea-81eb-c131845af97b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Harald said:

"As I've said before=2C unless I've misunderstood what SUBSCRIBE/NOTIFY are for (I think they are just for presence)=2C I want them totally outside the scope of RTCWEB=3B they are appropriate for implementation in Javascript if someone needs them."

[BA] I had thought that someone posted a link to a SIP Javascript libra= ry that was designed to be used with jquery (similar to Strophe=2C but for = SIP). =3B Has there been an argument demonstrating that this *has* to b= e native? =3B Overall=2C I'm not sure why we're having this discussion.=  =3B =3B
= --_c78752b1-26e9-43ea-81eb-c131845af97b_-- From igor.faynberg@alcatel-lucent.com Thu Sep 8 07:53: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 E13BD21F84B2 for ; Thu, 8 Sep 2011 07:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.603 X-Spam-Level: X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 EAmdQwpyk+yK for ; Thu, 8 Sep 2011 07:53:11 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5001F21F849D for ; Thu, 8 Sep 2011 07:53:10 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p88EsxCI028790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 09:54:59 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p88Esxci021711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Sep 2011 09:54:59 -0500 Received: from [135.244.18.36] (faynberg.lra.lucent.com [135.244.18.36]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p88EswxB020129; Thu, 8 Sep 2011 09:54:58 -0500 (CDT) Message-ID: <4E68D742.4010203@alcatel-lucent.com> Date: Thu, 08 Sep 2011 10:54:58 -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: Harald Alvestrand References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <4E68CB68.3020100@alcatel-lucent.com> <4E68D182.2090003@alvestrand.no> In-Reply-To: <4E68D182.2090003@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 14:53:12 -0000 Well, maybe we should take it off-line--I will be happy to explain a few things in October. Just some in-line answers: On 9/8/2011 10:30 AM, Harald Alvestrand wrote: >> I thought I had already proposed a subset: INVITE, SUBSCRIBE/NOTIFY, >> and REFER. > ... > > That's the commands. What are the parameters? My proposal is to populate the methods with parameters in the JavaScript application. > > As I've said before, unless I've misunderstood what SUBSCRIBE/NOTIFY > are for (I think they are just for presence), No, no, no! Not just for presence, although it can be used for presence. These precious methods came from PINT, how could you forget this! They allow the client to subscribe for an event at the server and then receive notifications asynchrously. This specific feature cannot be implemented using HTTP (just as INVITE cannot). We used them in PINT pretty much to enable the client to learn when PSTN call is disconnected, but the SIP group had found many other uses later. Again, my objective is to ensure that SIP (with all its bell and whistles) can be supported by a JS application. I am just starting to study the code kindly sent my way a few minuts ago, but when I am convinced that this can be done based on WebSocket alone, I will stop harping on this. Igor From igor.faynberg@alcatel-lucent.com Thu Sep 8 07:54: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 77CC621F84D7 for ; Thu, 8 Sep 2011 07:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.603 X-Spam-Level: X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 VDQ+y4pgkNt2 for ; Thu, 8 Sep 2011 07:54:21 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 94DEE21F84B4 for ; Thu, 8 Sep 2011 07:54:21 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p88EuAJc029478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 09:56:11 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p88EuAux011807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Sep 2011 09:56:10 -0500 Received: from [135.244.18.36] (faynberg.lra.lucent.com [135.244.18.36]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p88Eu959021380; Thu, 8 Sep 2011 09:56:09 -0500 (CDT) Message-ID: <4E68D789.90802@alcatel-lucent.com> Date: Thu, 08 Sep 2011 10:56:09 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Bernard Aboba References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net>, <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net>, <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com>, <4E67AD3D.9000005@alvestrand.no>, <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com>, <4E686663.1050900@alvestrand.no>, <4E68CB68.3020100@alcatel-lucent.com>, <4E68D182.2090003@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 14:54:22 -0000 Yes, I just got the link, and I am studying the code. > Harald said: > > "As I've said before, unless I've misunderstood what SUBSCRIBE/NOTIFY > are for (I think they are just for presence), I want them totally > outside the scope of RTCWEB; they are appropriate for implementation > in Javascript if someone needs them." > > [BA] I had thought that someone posted a link to a SIP Javascript > library that was designed to be used with jquery (similar to Strophe, > but for SIP). Has there been an argument demonstrating that this > *has* to be native? Overall, I'm not sure why we're having this > discussion. From pravindran@sonusnet.com Thu Sep 8 07:57: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 5D42621F84DA for ; Thu, 8 Sep 2011 07:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.089, 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 HD8EId9wypGd for ; Thu, 8 Sep 2011 07:57:19 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 01BB421F84D7 for ; Thu, 8 Sep 2011 07:57:18 -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 p88ExVFc009914; Thu, 8 Sep 2011 10:59:31 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 10:58:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6E37.C2DE6882" Date: Thu, 8 Sep 2011 20:28:20 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0988@sonusinmail02.sonusnet.com> In-Reply-To: <4E68D182.2090003@alvestrand.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] Thread-Index: AcxuM95mzOqoGZSMTjeF5HNSB5K8YwAA9IvQ References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <4E68CB68.3020100@alcatel-lucent.com> <4E68D182.2090003@alvestrand.no> From: "Ravindran Parthasarathi" To: "Harald Alvestrand" , X-OriginalArrivalTime: 08 Sep 2011 14:58:27.0770 (UTC) FILETIME=[C40329A0:01CC6E37] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 14:57:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6E37.C2DE6882 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Harald, =20 I'm talking about INVITE subset only. =20 Thanks Partha =20 From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Thursday, September 08, 2011 8:00 PM To: igor.faynberg@alcatel-lucent.com Cc: Ravindran Parthasarathi; Matthew Kaufman; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] =20 On 09/08/11 16:04, Igor Faynberg wrote:=20 On 9/8/2011 2:53 AM, Harald Alvestrand wrote:=20 =20 ... But sure - if you want us to implement some part of SIP, *please start stating what part* rather than making wooly statements. I thought I had already proposed a subset: INVITE, SUBSCRIBE/NOTIFY, and REFER. That's the commands. What are the parameters? As I've said before, unless I've misunderstood what SUBSCRIBE/NOTIFY are for (I think they are just for presence), I want them totally outside the scope of RTCWEB; they are appropriate for implementation in Javascript if someone needs them. I don't know what REFER is for well enough to have an opinion of whether it's relevant. Harald ------_=_NextPart_001_01CC6E37.C2DE6882 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Harald,

 

I’m talking about INVITE subset = only.

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Thursday, September 08, 2011 8:00 PM
To: igor.faynberg@alcatel-lucent.com
Cc: Ravindran Parthasarathi; Matthew Kaufman; rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remote recording - RTC-Web client acting as SIPREC session recording = client]

 

On 09/08/11 16:04, Igor Faynberg wrote: =



On 9/8/2011 2:53 AM, Harald Alvestrand wrote:

 

...

But sure - if you want us to implement some part of = SIP, *please start stating what part* rather than making wooly = statements.


I thought I had already proposed a subset: INVITE, SUBSCRIBE/NOTIFY, and = REFER.


That's the commands. What are the parameters?

As I've said before, unless I've misunderstood what SUBSCRIBE/NOTIFY are = for (I think they are just for presence), I want them totally outside the scope = of RTCWEB; they are appropriate for implementation in Javascript if someone = needs them.

I don't know what REFER is for well enough to have an opinion of whether = it's relevant.

             = Harald

------_=_NextPart_001_01CC6E37.C2DE6882-- From harald@alvestrand.no Thu Sep 8 07:59: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 ED1D621F87FA for ; Thu, 8 Sep 2011 07:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.058 X-Spam-Level: X-Spam-Status: No, score=-108.058 tagged_above=-999 required=5 tests=[AWL=2.541, 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 0gGP0Hn7GjNb for ; Thu, 8 Sep 2011 07:59:18 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 55DBF21F84DC for ; Thu, 8 Sep 2011 07:59:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4DF4039E0F3; Thu, 8 Sep 2011 17:01:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFbLpVqDXrRB; Thu, 8 Sep 2011 17:01:09 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 71E4639E074; Thu, 8 Sep 2011 17:01:09 +0200 (CEST) Message-ID: <4E68D8B5.7010602@alvestrand.no> Date: Thu, 08 Sep 2011 17:01:09 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <4E68CB68.3020100@alcatel-lucent.com> <4E68D182.2090003@alvestrand.no> <4E68D742.4010203@alcatel-lucent.com> In-Reply-To: <4E68D742.4010203@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 14:59:19 -0000 On 09/08/11 16:54, Igor Faynberg wrote: > Well, maybe we should take it off-line--I will be happy to explain a > few things in October. Just some in-line answers: > > On 9/8/2011 10:30 AM, Harald Alvestrand wrote: >>> I thought I had already proposed a subset: INVITE, SUBSCRIBE/NOTIFY, >>> and REFER. >> ... >> >> That's the commands. What are the parameters? > > My proposal is to populate the methods with parameters in the > JavaScript application. It seems that writing up your proposal in enough detail that we can tell which parts you intend to have done in Javascript and which parts in browser code is an useful exercise, because I just don't seem to get the picture. >> >> As I've said before, unless I've misunderstood what SUBSCRIBE/NOTIFY >> are for (I think they are just for presence), > > No, no, no! Not just for presence, although it can be used for > presence. These precious methods came from PINT, how could you forget > this! They allow the client to subscribe for an event at the server > and then receive notifications asynchrously. This specific feature > cannot be implemented using HTTP (just as INVITE cannot). We used > them in PINT pretty much to enable the client to learn when PSTN call > is disconnected, but the SIP group had found many other uses later. If the issue is getting a signal from a Web server to a client, there's approximately 100 ways to get notifications from the server to the client using HTTP (hanging GET being one of them). Now that WS is getting standardized, there will be 101. > > Again, my objective is to ensure that SIP (with all its bell and > whistles) can be supported by a JS application. I am just starting to > study the code kindly sent my way a few minuts ago, but when I am > convinced that this can be done based on WebSocket alone, I will stop > harping on this. > > Igor > From pravindran@sonusnet.com Thu Sep 8 08:12: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 EE30221F85EC for ; Thu, 8 Sep 2011 08:12:32 -0700 (PDT) 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.086, 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 3BpOiFdFw7SW for ; Thu, 8 Sep 2011 08:12:29 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id B993C21F85AE for ; Thu, 8 Sep 2011 08:12:28 -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 p88FEk8R019545; Thu, 8 Sep 2011 11:14:46 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 11:13:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6E39.E35B7242" Date: Thu, 8 Sep 2011 20:43:32 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0989@sonusinmail02.sonusnet.com> In-Reply-To: <4E686663.1050900@alvestrand.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] Thread-Index: Acxt9AbN3JhWXoAGQEWrQ9SN744t+wARGUtg References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> From: "Ravindran Parthasarathi" To: "Harald Alvestrand" X-OriginalArrivalTime: 08 Sep 2011 15:13:43.0904 (UTC) FILETIME=[E6121E00:01CC6E39] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 15:12:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6E39.E35B7242 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Harald, =20 I'm proposing for "SIP UA framework for RTCWeb browser", the framework provides Javascript API. In case you mean the same as "SIP lite". I'm fine with it. SIP UA framework helps to support two-party communication from RTCWeb browser and uses HTTP as presence or configuration interface.=20 =20 As I mentioned in the another mail, I'm talking about INVITE subset of RFC 3261 in browser. =20 =20 Thanks Partha =20 From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Thursday, September 08, 2011 12:23 PM To: Ravindran Parthasarathi Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] =20 On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote:=20 Harald, =20 For browser as a SIP UA application, browser has to no need to compliant with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also agree with you that browser-to-browser communication, I could not see the strong reason for supporting S/MIME. As part of the RTCWeb architecture & solution, we will able to explore the SIP UA requirement for making browser SIP compliant. So you're advocating for creating a "SIP lite" subset that RTCWEB browsers implement. I think we have been down this road before, and it's not a happy one. But sure - if you want us to implement some part of SIP, *please start stating what part* rather than making wooly statements. Subsets are Real Hard Work. Say for example, forking does not make sense in case of browser as SIP UA application, forked response will be rejected with CANCEL in browser without Javascript intervention. The main requirement is to build the right SIP UA framework in browser by which Javascript developer will be able to use to the maximum extent without impacting the basic 2 two party communication in the internet. =20 =20 As mailed in another thread, RTCWEB client + RTCWeb server makes to feel a modern exchange in web world (Plain Old Telephony System phone with exchange architecture). I think so because POTS phones are dumb which does not know its identity and every event like offhook, onhook has to passed to exchange (webserver) whereas RTCWeb client (browser) has to pass every event to webserver and webserver has whole intelligence to make it work. Don't forget that the RTCWEB client (the browser) contains an open, fully programmable application platform - the Javascript engine. That's a HUGE difference to the POTS phone. I got this feel more when someone is talking about MEGACO or MGCP between RTCWEB client & webserver. My understanding is that SIP does not fit well to legacy telephone-based paradigm by any means but MEGACO or MGCP are the better choice which maps to SS7 architecture well. I'm interested in seeing RTCWeb client perform the basic routing rather than webserver does the routing on behalf of RTCWEb client. =20 I agree with you that in case it is local exchange (same site like skype or Google hangout) communication, there will be no need of signaling but I'm interested in communication with one of the Google real-time user in internet without having any Google id. I believe that SIP will make it work. If by saying "the Google real time user in Internet", you mean a Google Talk user, you have that already. It's called Google Voice. It uses SIP, but not in the browser. Talking to someone who doesn't want to talk to you is an use case we don't intend to support. =20 Thanks Partha =20 From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Wednesday, September 07, 2011 11:13 PM To: Ravindran Parthasarathi Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] =20 On 09/07/11 19:29, Ravindran Parthasarathi wrote:=20 Matthew, =20 When I asked for SIP, I have meant RFC 3261 only. This is 269 pages, and has 26 normative dependencies including S/MIME. It's not a small dependency. The basic reason for asking SIP is to make the basic call works between browser to browser across web servers. Without SIP in browser, it is not going happen. Innovative application is going to be proprietary whether it is HTTP or SIP or any other protocol for that matter. =20 My reasoning are as follows: SIP makes browser more intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG.=20 Why does that "intelligence" need to be in the browser, rather than in the Javascript? The importance of basic call interop is that there is no need of many individual id like skype id, Google id and yahoo id by everyone in the world to communicate others. I wish to have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.=20 This only makes sense for applications that fit the "call an identified party" paradigm. SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provider. There is no need to build two different signaling logic in VoIP servers for each service. Your own example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible to avoided by having one signaling protocol. One protocol can be achieved by multiple applications choosing to implement one protocol. It doesn't have to be enforced by the prtoocol being embedded in the browser. =20 In RTCWEB does not standardize the signaling protocol interface between browsers, the interop across webservers is next to impossible and it will be restricted to single webserver (company) only. Please let me know in case I'm missing something here. I think the main thing you are missing is that there are many applications that people want to build on top of RTCWEB that are not telephones, and will not fit with telephone-based paradigms. =20 ------_=_NextPart_001_01CC6E39.E35B7242 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Harald,

 

I’m proposing for “SIP UA framework for = RTCWeb browser”, the framework provides Javascript API. In case you mean = the same as “SIP lite”. I’m fine with it. SIP UA framework = helps to support two-party communication from RTCWeb browser and uses HTTP as presence or configuration interface.

 

As I mentioned in the another mail, I’m talking = about INVITE subset of RFC 3261 in browser.  

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Thursday, September 08, 2011 12:23 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; = rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remote recording - RTC-Web client acting as SIPREC session recording = client]

 

On 09/08/2011 07:09 AM, Ravindran Parthasarathi = wrote:

Harald,

 

For browser as a SIP UA application, browser has to no need to compliant = with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also agree with = you that browser-to-browser communication, I could not see the strong reason for supporting S/MIME. As part of the RTCWeb architecture & solution, we = will able to explore the SIP UA requirement for making browser SIP = compliant.

So you're advocating for creating a "SIP = lite" subset that RTCWEB browsers implement.
I think we have been down this road before, and it's not a happy = one.
But sure - if you want us to implement some part of SIP, *please start = stating what part* rather than making wooly statements.

Subsets are Real Hard Work.

Say for example, forking does not make sense in case of browser as SIP UA application, forked response will be rejected with CANCEL in browser = without Javascript intervention. The main requirement is to build the right SIP = UA framework in browser by which Javascript developer will be able to use = to the maximum extent without impacting the basic 2 two party communication in = the internet. 

 

As mailed in another thread, RTCWEB client + RTCWeb server makes to feel a = modern exchange in web world (Plain Old Telephony System phone with exchange architecture). I think so because POTS phones are dumb which does not = know its identity and every event like offhook, onhook has to passed to exchange (webserver) whereas RTCWeb client (browser) has to pass every event to webserver and webserver has whole intelligence to make it = work.

Don't forget that the RTCWEB client (the browser) = contains an open, fully programmable application platform - the Javascript = engine. That's a HUGE difference to the POTS phone.

I got this feel more when someone is talking about MEGACO or MGCP between = RTCWEB client & webserver. My understanding is that SIP does not fit well = to legacy telephone-based paradigm by any means but MEGACO or MGCP are the = better choice which maps to SS7 architecture well. I’m interested in seeing = RTCWeb client perform the basic routing rather than webserver does the routing = on behalf of RTCWEb client.

 

I agree with you that in case it is local exchange (same site like skype = or Google hangout) communication, there will be no need of signaling but I’m interested in communication with one of the Google real-time user in = internet without having any Google id.  I believe that SIP will make it = work.

If by saying "the Google real time user in Internet", you mean a Google Talk user, you have that already. It's = called Google Voice. It uses SIP, but not in the browser.

Talking to someone who doesn't want to talk to you is an use case we = don't intend to support.

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:harald@alvestrand.no] =
Sent: Wednesday, September 07, 2011 11:13 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lu= cent.com; rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remote recording - RTC-Web client acting as SIPREC session recording = client]

 

On 09/07/11 19:29, Ravindran Parthasarathi wrote: =

Matthew,

 

When I asked for SIP, I have meant RFC 3261 only.

This is 269 pages, and has 26 normative = dependencies including S/MIME. It's not a small dependency.




The basic reason for asking SIP is to make the basic call works between = browser to browser across web servers. Without SIP in browser, it is not going happen. = Innovative application is going to be proprietary whether it is HTTP or SIP or any = other protocol for that matter.

 

My reasoning are as follows:

SIP makes browser more = intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG. =

Why does that "intelligence" need to be = in the browser, rather than in the Javascript?


The importance of basic call = interop is that there is no need of many individual id like skype id, Google = id  and yahoo id by everyone in the world to communicate others. I wish to = have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.

This only makes sense for applications that fit the "call an identified party" paradigm.


SIP helps to interop for = basic call with other existing realtime application in Enterprise & Telecom = provider.

There is no need to build two different signaling logic in VoIP servers for each service. Your own = example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible = to avoided by having one signaling protocol.

One protocol can be achieved by multiple = applications choosing to implement one protocol.
It doesn't have to be enforced by the prtoocol being embedded in the = browser.


 

In RTCWEB does not standardize the signaling protocol interface between = browsers, the interop across webservers is next to impossible and it will be = restricted to single webserver (company) only. Please let  me know in case = I’m missing something here.


I think the main thing you are missing is that there are many = applications that people want to build on top of RTCWEB that are not telephones, and will = not fit with telephone-based paradigms.

 

------_=_NextPart_001_01CC6E39.E35B7242-- From pkyzivat@alum.mit.edu Thu Sep 8 08: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 C98A121F8A6F for ; Thu, 8 Sep 2011 08:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 baApT1WsrDmD for ; Thu, 8 Sep 2011 08:20:18 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9E34621F891D for ; Thu, 8 Sep 2011 08:20:18 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta05.westchester.pa.mail.comcast.net with comcast id WEHF1h0051c6gX855FNBwB; Thu, 08 Sep 2011 15:22:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta23.westchester.pa.mail.comcast.net with comcast id WFN91h04Y0tdiYw3jFNAFw; Thu, 08 Sep 2011 15:22:11 +0000 Message-ID: <4E68DDC5.3050209@alum.mit.edu> Date: Thu, 08 Sep 2011 11:22:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Matthew Kaufman References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com> <4E666785.7040409@skype.net> <4E67513C.3030600@alvestrand.no> <4E677CB8.40203@skype.net> <4E678B44.9080208@alum.mit.edu> <4E67EBCF.5050206@skype.net> In-Reply-To: <4E67EBCF.5050206@skype.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 15:20:20 -0000 On 9/7/11 6:10 PM, Matthew Kaufman wrote: > On 9/7/11 8:18 AM, Paul Kyzivat wrote: >> Matthew, >> >> Good summary. >> >> I agree that webrtc provides flexibility in how to implement the UI >> portions of these features with generic webrtc clients. But it doesn't >> make these features trivial to implement. > > I didn't say that it did. But the flexibility does allow the feature to > be implemented in whatever combination of client-side Javascript and > server-side programming you wish. > >> In particular, the bridged line appearance still requires that a >> conference be established. With generic rtcweb clients, that probably >> means a central mixer. Setting that up is relatively easy if there is >> a central media termination point in rtcweb server, and it *has* mixer >> capabilities. > > Agree. > >> >> My point is not that rtcweb doesn't help with this case - just that >> these features that are so trivial in analog telephony just aren't so >> simple with voip, no matter how you do it. > > Also agree. > > The real difference comes with the programming model. With a SIP phone, > to add bridged line appearance support you need to write a new spec > (that doesn't exist), get consensus around that spec, and then upgrade > the phone firmware. With an SCCP (Skinny) phone, to add bridged line > appearance support you simply write some additional code that runs at > the server end that changes when the lights are commanded to turn on and > off, controls what happens when a lit line button is pushed, and > commands the phone to send the right kind of media to the right place. I think what you are saying is that with rtcweb you can build a replacement for Cisco Call Manager - with rtcweb replacking SCCP, and the call manager itself subsumed into a web server. This then allows any rtcweb enabled user device to be used instead of a Cisco proprietary phone. I agree with that, and its likely to be a good thing. (But maybe not for Cisco.) At a macro level that thing seems to have the same centralized architecture as the Call Manager. Call Manager never bought into the sip vision that the phones should be largely autonomous, and this approach using rtcweb doesn't either. The complexity of standardizing features like bridged line appearance arises if you try to follow that sip vision and allow autonomous sip devices to cooperate in that feature. I've been pondering this for a long time. I have realized its not practical to standardize all the features that span multiple devices attached to the same AOR - that having a server for the AOR coordinate the features across the multiple devices is more practical. And that rtcweb is a great way to do that without locking down the choice of devices. But I think the situation is different for coordinating features that span the multiple endpoints of a realtime communication session. Then it comes down to a case by case analysis of how important it is for a particular feature to be ubiquitous. For instance, maybe you want to use Facebook as your "call agent" for realtime communications. But does that mean you can't communicate with me because I'm not a Facebook user? Ideally you can still reach me while using Facebook as your call agent. Then there are *some* features that will ideally still work, while there might be other features that only work when both ends are facebook users. Those features that are to be more ubiquitous will require more standardization effort than those that aren't. (No free lunch.) Rtcweb ought to work with both sorts. > There is no reason why we should make a web browser, which has the added > advantage of a local execution environment for Javascript, *less* > capable than the aforementioned server-controlled phone. Note that Call Manager can use SIP phones as well as SCCP phones. And when those sip phones have the Cisco secret sauce (which deviates only mildly from *real* sip) they have all the functionality of the SCCP phones. I would expect that whatever way this debate ends (sip in the browser or not) the web browser should have the same level of functionality. Thanks, Paul From roman@telurix.com Thu Sep 8 08:33: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 B7DF121F8B92 for ; Thu, 8 Sep 2011 08:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kl5V-NktHaAl for ; Thu, 8 Sep 2011 08:33:53 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D954D21F8B91 for ; Thu, 8 Sep 2011 08:33:52 -0700 (PDT) Received: by yxj20 with SMTP id 20so848405yxj.31 for ; Thu, 08 Sep 2011 08:35:45 -0700 (PDT) Received: by 10.151.5.21 with SMTP id h21mr1038426ybi.438.1315496145117; Thu, 08 Sep 2011 08:35:45 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id u19sm414349ybm.4.2011.09.08.08.35.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Sep 2011 08:35:44 -0700 (PDT) Received: by yxj20 with SMTP id 20so848374yxj.31 for ; Thu, 08 Sep 2011 08:35:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.62.232 with SMTP id b8mr1300015pbs.523.1315496143245; Thu, 08 Sep 2011 08:35:43 -0700 (PDT) Received: by 10.68.43.136 with HTTP; Thu, 8 Sep 2011 08:35:43 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0989@sonusinmail02.sonusnet.com> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F0989@sonusinmail02.sonusnet.com> Date: Thu, 8 Sep 2011 11:35:43 -0400 Message-ID: From: Roman Shpount To: Ravindran Parthasarathi Content-Type: multipart/alternative; boundary=bcaec539618052505004ac6fd09b Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 15:33:54 -0000 --bcaec539618052505004ac6fd09b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Partha, What I am failing to understand is what you plan to use SIP for. SIP would be useful to call a SIP end point on the public IP or behind the same NAT. If you want to call another SIP end point behind NAT, especially if you nee= d to use TCP to send ICE offers or security with TLS, you will need an assistance of some type of server on the public IP. In order for this to work both server and the client will need to implement something like RFC 5626. This will require building something fairly tricky to essentially proxy all the SIP requests from the client to all the other SIP points. Building this is no easier then implementing the same thing using an HTTP server application which works with a client JavaScript library. If our primary goal were implementation of Intranet SIP phones, that would be an acceptable solution. For consumer oriented RTC service this is completely useless. On the other hand extending SIP based infrastructure to implement new functionality is a lot more complex. Adding new features will require standardization or navigating a large number of conflicting SIP related specifications which are currently in force. Also, keep in mind that compliance to a lot of more advanced SIP specifications does not necessaril= y imply easy interoperability with existing devices. Compliance to a lot of those standards require a custom SIP server or SBC which implements them using a much smaller subset supported by each different SIP device. Bottom line, adding new features in SIP based environment typically requires a lot of server development, which is pretty much what will be required for doing signaling via an HTTP connection. I will concur that using HTTP with JavaScript is a lot less efficient then using SIP for both the client and the server, since client will need to implement more functionality using JavaScript and the server will need to maintain large number of connections and proxy all the requests, but this i= s a drawback of any AJAX based solution. This is something that seems to be acceptable to the industry and should not be a decisive factor. _____________ Roman Shpount On Thu, Sep 8, 2011 at 11:13 AM, Ravindran Parthasarathi < pravindran@sonusnet.com> wrote: > Harald,**** > > ** ** > > I=92m proposing for =93SIP UA framework for RTCWeb browser=94, the framew= ork > provides Javascript API. In case you mean the same as =93SIP lite=94. I= =92m fine > with it. SIP UA framework helps to support two-party communication from > RTCWeb browser and uses HTTP as presence or configuration interface. **** > > ** ** > > As I mentioned in the another mail, I=92m talking about INVITE subset of = RFC > 3261 in browser. **** > > ** ** > > Thanks**** > > Partha**** > > ** ** > > *From:* Harald Alvestrand [mailto:harald@alvestrand.no] > *Sent:* Thursday, September 08, 2011 12:23 PM > > *To:* Ravindran Parthasarathi > *Cc:* Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org > *Subject:* Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote > recording - RTC-Web client acting as SIPREC session recording client]**** > > ** ** > > On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote: **** > > Harald,**** > > **** > > For browser as a SIP UA application, browser has to no need to compliant > with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also agre= e > with you that browser-to-browser communication, I could not see the stron= g > reason for supporting S/MIME. As part of the RTCWeb architecture & soluti= on, > we will able to explore the SIP UA requirement for making browser SIP > compliant.**** > > So you're advocating for creating a "SIP lite" subset that RTCWEB browser= s > implement. > I think we have been down this road before, and it's not a happy one. > But sure - if you want us to implement some part of SIP, *please start > stating what part* rather than making wooly statements. > > Subsets are Real Hard Work. > > **** > > Say for example, forking does not make sense in case of browser as SIP UA > application, forked response will be rejected with CANCEL in browser with= out > Javascript intervention. The main requirement is to build the right SIP U= A > framework in browser by which Javascript developer will be able to use to > the maximum extent without impacting the basic 2 two party communication = in > the internet. **** > > **** > > As mailed in another thread, RTCWEB client + RTCWeb server makes to feel = a > modern exchange in web world (Plain Old Telephony System phone with excha= nge > architecture). I think so because POTS phones are dumb which does not kno= w > its identity and every event like offhook, onhook has to passed to exchan= ge > (webserver) whereas RTCWeb client (browser) has to pass every event to > webserver and webserver has whole intelligence to make it work.**** > > Don't forget that the RTCWEB client (the browser) contains an open, fully > programmable application platform - the Javascript engine. That's a HUGE > difference to the POTS phone. > > **** > > I got this feel more when someone is talking about MEGACO or MGCP between > RTCWEB client & webserver. My understanding is that SIP does not fit well= to > legacy telephone-based paradigm by any means but MEGACO or MGCP are the > better choice which maps to SS7 architecture well. I=92m interested in se= eing > RTCWeb client perform the basic routing rather than webserver does the > routing on behalf of RTCWEb client.**** > > **** > > I agree with you that in case it is local exchange (same site like skype = or > Google hangout) communication, there will be no need of signaling but I= =92m > interested in communication with one of the Google real-time user in > internet without having any Google id. I believe that SIP will make it > work.**** > > If by saying "the Google real time user in Internet", you mean a Google > Talk user, you have that already. It's called Google Voice. It uses SIP, = but > not in the browser. > > Talking to someone who doesn't want to talk to you is an use case we don'= t > intend to support. > > **** > > **** > > Thanks**** > > Partha**** > > **** > > *From:* Harald Alvestrand [mailto:harald@alvestrand.no] > > *Sent:* Wednesday, September 07, 2011 11:13 PM > *To:* Ravindran Parthasarathi > *Cc:* Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org > *Subject:* Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote > recording - RTC-Web client acting as SIPREC session recording client]**** > > **** > > On 09/07/11 19:29, Ravindran Parthasarathi wrote: **** > > Matthew,**** > > **** > > When I asked for SIP, I have meant RFC 3261 only.**** > > This is 269 pages, and has 26 normative dependencies including S/MIME. It= 's > not a small dependency.**** > > > > > **** > > The basic reason for asking SIP is to make the basic call works between > browser to browser across web servers. Without SIP in browser, it is not > going happen. Innovative application is going to be proprietary whether i= t > is HTTP or SIP or any other protocol for that matter.**** > > **** > > My reasoning are as follows:**** > > SIP makes browser more intelligence compare to dump signaling mechanism > like MEGACO and browser acts as MG. **** > > Why does that "intelligence" need to be in the browser, rather than in th= e > Javascript? > > > **** > > The importance of basic call interop is that there is no need of many > individual id like skype id, Google id and yahoo id by everyone in the > world to communicate others. I wish to have single id like e-mail id to b= e > maintained by browser-to-browser users to communicate with others. **** > > This only makes sense for applications that fit the "call an identified > party" paradigm. > > > **** > > SIP helps to interop for basic call with other existing realtime > application in Enterprise & Telecom provider.**** > > There is no need to build two different signaling logic in VoIP servers f= or > each service. Your own example of Bridge line appearance will need two > implementation by the single vendor because desktop application or hardph= one > implementation based on SIP and browser based implementation is depend on > HTTP metadata. It is possible to avoided by having one signaling protocol= . > **** > > One protocol can be achieved by multiple applications choosing to impleme= nt > one protocol. > It doesn't have to be enforced by the prtoocol being embedded in the > browser. > > > **** > > **** > > In RTCWEB does not standardize the signaling protocol interface between > browsers, the interop across webservers is next to impossible and it will= be > restricted to single webserver (company) only. Please let me know in cas= e > I=92m missing something here.**** > > > I think the main thing you are missing is that there are many application= s > that people want to build on top of RTCWEB that are not telephones, and w= ill > not fit with telephone-based paradigms.**** > > ** ** > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --bcaec539618052505004ac6fd09b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Partha,

What I am failing to understand is what you plan to use SIP = for. SIP would be useful to call a SIP end point on the public IP or behind= the same NAT. If you want to call another SIP end point behind NAT, especi= ally if you need to use TCP to send ICE offers or security with TLS, you wi= ll need an assistance of some type of server on the public IP. In order for= this to work both server and the client will need to implement something l= ike RFC 5626. This will require building something fairly tricky to essenti= ally proxy all the SIP requests from the client to all the other SIP points= . Building this is no easier then implementing the same thing using an HTTP= server application which works with a client JavaScript library. If our pr= imary goal were implementation of Intranet SIP phones, that would be an acc= eptable solution. For consumer oriented RTC service this is completely usel= ess.

On the other hand extending SIP based infrastructure to implement new f= unctionality is a lot more complex. Adding new features will require standa= rdization or navigating a large number of conflicting SIP related specifica= tions which are currently in force. Also, keep in mind that compliance to a= lot of more advanced SIP specifications does not necessarily imply easy in= teroperability with existing devices. Compliance to a lot of those standard= s require a custom SIP server or SBC which implements them using a much sma= ller subset supported by each different SIP device. Bottom line, adding new= features in SIP based environment typically requires a lot of server devel= opment, which is pretty much what will be required for doing signaling via = an HTTP connection.
_____________
Roman Shpount


On Thu, Sep 8, 2011 at 11:13 AM, Ravindr= an Parthasarathi <pravindran@sonusnet.com> wrote:

Haral= d,

=A0

I=92m= proposing for =93SIP UA framework for RTCWeb browser=94, the framework provides Javascript API. In case you mean the same as =93SIP lite=94. I=92m fine with it. SIP UA framework helps to support two-party communication from RTCWeb browser and uses HTTP as presence or configuration interface.

=A0

As I = mentioned in the another mail, I=92m talking about INVITE subset of RFC 3261 in browser. =A0

=A0

Thank= s

Parth= a

=A0

From: Harald = Alvestrand [mailto:harald@al= vestrand.no]
Sent: Thursday, September 08, 2011 12:23 PM


To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remot= e recording - RTC-Web client acting as SIPREC session recording client]

=A0

On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrot= e:

Harald,

=A0

For browser as a SIP UA application, browser has to no need to compliant with 2= 69 pages of RFC 3261 as proxy core is irrelevant to it. I also agree with you = that browser-to-browser communication, I could not see the strong reason for supporting S/MIME. As part of the RTCWeb architecture & solution, we wi= ll able to explore the SIP UA requirement for making browser SIP compliant.

So you're advocating for creating a "SIP li= te" subset that RTCWEB browsers implement.
I think we have been down this road before, and it's not a happy one. But sure - if you want us to implement some part of SIP, *please start stat= ing what part* rather than making wooly statements.

Subsets are Real Hard Work.

Say for example, forking does not make sense in case of browser as SIP UA application, forked response will be rejected with CANCEL in browser withou= t Javascript intervention. The main requirement is to build the right SIP UA framework in browser by which Javascript developer will be able to use to t= he maximum extent without impacting the basic 2 two party communication in the internet.=A0

=A0

As mailed in another thread, RTCWEB client + RTCWeb server makes to feel a mod= ern exchange in web world (Plain Old Telephony System phone with exchange architecture). I think so because POTS phones are dumb which does not know = its identity and every event like offhook, onhook has to passed to exchange (webserver) whereas RTCWeb client (browser) has to pass every event to webserver and webserver has whole intelligence to make it work.

Don't forget that the RTCWEB client (the browser= ) contains an open, fully programmable application platform - the Javascript engine. That's a HUGE difference to the POTS phone.

I got this feel more when someone is talking about MEGACO or MGCP between RTC= WEB client & webserver. My understanding is that SIP does not fit well to legacy telephone-based paradigm by any means but MEGACO or MGCP are the bet= ter choice which maps to SS7 architecture well. I=92m interested in seeing RTCWeb client perform the basic routing rather than webserver does the routing on behalf of RTCWEb client.

=A0

I agree with you that in case it is local exchange (same site like skype or G= oogle hangout) communication, there will be no need of signaling but I=92m interested in communication with one of the Google real-time user in intern= et without having any Google id. =A0I believe that SIP will make it work.

If by saying "the Google real time user in Internet", you mean a Google Talk user, you have that already. It'= s called Google Voice. It uses SIP, but not in the browser.

Talking to someone who doesn't want to talk to you is an use case we do= n't intend to support.

=A0

Thanks

Partha

=A0

From: Harald = Alvestrand [mailt= o:harald@alvestrand.no]
Sent: Wednesday, September 07, 2011 11:13 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remot= e recording - RTC-Web client acting as SIPREC session recording client]

=A0

On 09/07/11 19:29, Ravindran Parthasarathi wrote:

Matthew,<= /u>

=A0

When I asked for SIP, I have meant RFC 3261 only.

This is 269 pages, and has 26 normative dependencies including S/MIME. It's not a small dependency.




The basic reason for asking SIP is to make the basic call works between browser= to browser across web servers. Without SIP in browser, it is not going happen. Innovat= ive application is going to be proprietary whether it is HTTP or SIP or any oth= er protocol for that matter.

=A0

My reasoning are as follows:

SIP makes browser more intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG.

Why does that "intelligence" need to be in= the browser, rather than in the Javascript?


The importance of basic call interop is that there is no need of many individual id like skype id, Google id=A0 and yahoo id by everyone in the world to communicate others. I wish to have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.

This only makes sense for applications that fit the "call an identified party" paradigm.


SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provid= er.

There is no need to build two different signaling logic in VoIP servers for each service. Your own exampl= e of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible to avoided by having one signaling protocol.

One protocol can be achieved by multiple application= s choosing to implement one protocol.
It doesn't have to be enforced by the prtoocol being embedded in the br= owser.


=A0<= /p>

In RTCWEB does not standardize the signaling protocol interface between browse= rs, the interop across webservers is next to impossible and it will be restrict= ed to single webserver (company) only. Please let=A0 me know in case I=92m missing something here.


I think the main thing you are missing is that there are many applications = that people want to build on top of RTCWEB that are not telephones, and will not= fit with telephone-based paradigms.

=A0


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


--bcaec539618052505004ac6fd09b-- From tasveren@sonusnet.com Thu Sep 8 08: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 D0D7921F8B1A for ; Thu, 8 Sep 2011 08:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeE4oyNaJhki for ; Thu, 8 Sep 2011 08:44:20 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 05DCB21F8ADE for ; Thu, 8 Sep 2011 08:44:19 -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 p88FkeRb008782; Thu, 8 Sep 2011 11:46:40 -0400 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: Thu, 8 Sep 2011 11:45:47 -0400 Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E703C28AF1@sonusmail04.sonusnet.com> In-Reply-To: <4E68DDC5.3050209@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver) Thread-Index: AcxuOxf78N8rOtbXRhy9k2of9l/DpgAAUhaw References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com><4E666785.7040409@skype.net> <4E67513C.3030600@alvestrand.no><4E677CB8.40203@skype.net> <4E678B44.9080208@alum.mit.edu><4E67EBCF.5050206@skype.net> <4E68DDC5.3050209@alum.mit.edu> From: "Asveren, Tolga" To: "Paul Kyzivat" , "Matthew Kaufman" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 15:44:20 -0000 Some questions/comments inline... Thanks, Tolga > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Thursday, September 08, 2011 11:23 AM > To: Matthew Kaufman > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & > architecture: Browser application with separate webserver & voipserver) >=20 > On 9/7/11 6:10 PM, Matthew Kaufman wrote: > > On 9/7/11 8:18 AM, Paul Kyzivat wrote: > >> Matthew, > >> > >> Good summary. > >> > >> I agree that webrtc provides flexibility in how to implement the UI > >> portions of these features with generic webrtc clients. But it doesn't > >> make these features trivial to implement. > > > > I didn't say that it did. But the flexibility does allow the feature to > > be implemented in whatever combination of client-side Javascript and > > server-side programming you wish. > > > >> In particular, the bridged line appearance still requires that a > >> conference be established. With generic rtcweb clients, that probably > >> means a central mixer. Setting that up is relatively easy if there is > >> a central media termination point in rtcweb server, and it *has* mixer > >> capabilities. > > > > Agree. > > > >> > >> My point is not that rtcweb doesn't help with this case - just that > >> these features that are so trivial in analog telephony just aren't so > >> simple with voip, no matter how you do it. > > > > Also agree. > > > > The real difference comes with the programming model. With a SIP phone, > > to add bridged line appearance support you need to write a new spec > > (that doesn't exist), get consensus around that spec, and then upgrade > > the phone firmware. With an SCCP (Skinny) phone, to add bridged line > > appearance support you simply write some additional code that runs at > > the server end that changes when the lights are commanded to turn on and > > off, controls what happens when a lit line button is pushed, and > > commands the phone to send the right kind of media to the right place. >=20 > I think what you are saying is that with rtcweb you can build a > replacement for Cisco Call Manager - with rtcweb replacking SCCP, and > the call manager itself subsumed into a web server. This then allows any > rtcweb enabled user device to be used instead of a Cisco proprietary > phone. I agree with that, and its likely to be a good thing. (But maybe > not for Cisco.) >=20 > At a macro level that thing seems to have the same centralized > architecture as the Call Manager. Call Manager never bought into the sip > vision that the phones should be largely autonomous, and this approach > using rtcweb doesn't either. >=20 > The complexity of standardizing features like bridged line appearance > arises if you try to follow that sip vision and allow autonomous sip > devices to cooperate in that feature. >=20 > I've been pondering this for a long time. I have realized its not > practical to standardize all the features that span multiple devices > attached to the same AOR - that having a server for the AOR coordinate > the features across the multiple devices is more practical. And that > rtcweb is a great way to do that without locking down the choice of > devices. >=20 > But I think the situation is different for coordinating features that > span the multiple endpoints of a realtime communication session. Then it > comes down to a case by case analysis of how important it is for a > particular feature to be ubiquitous. For instance, maybe you want to use > Facebook as your "call agent" for realtime communications. But does that > mean you can't communicate with me because I'm not a Facebook user? [TOLGA] Yes, I think so if the service provided by Facebook is "capability to establish a call to another Facebook user". If it is "capability to call any phone number", then one would be able to call any phone number, and if it the ability to call a Service-X identity, it will do so. I guess the notion of "capability to call anybody" is very vague. It all depends on the "identity context" + "identity to call" and that will be determined by the service AFAICS.=20 > Ideally you can still reach me while using Facebook as your call agent. > Then there are *some* features that will ideally still work, while there > might be other features that only work when both ends are facebook users. >=20 > Those features that are to be more ubiquitous will require more > standardization effort than those that aren't. (No free lunch.) >=20 > Rtcweb ought to work with both sorts. >=20 > > There is no reason why we should make a web browser, which has the added > > advantage of a local execution environment for Javascript, *less* > > capable than the aforementioned server-controlled phone. >=20 > Note that Call Manager can use SIP phones as well as SCCP phones. And > when those sip phones have the Cisco secret sauce (which deviates only > mildly from *real* sip) they have all the functionality of the SCCP phones. >=20 > I would expect that whatever way this debate ends (sip in the browser or > not) the web browser should have the same level of functionality. [TOLGA] Can I assume that you mean "webbrowser + JS" instead of "webbrowser as is"? I am not entirely sold on the idea that SIP endpoint is equivalent to a webbrowser from architectural point of view (even with JS). >=20 > Thanks, > Paul >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From roman@telurix.com Thu Sep 8 08:49: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 97E5121F8557 for ; Thu, 8 Sep 2011 08:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVTAiItol4HS for ; Thu, 8 Sep 2011 08:49:10 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id D1A3021F84DA for ; Thu, 8 Sep 2011 08:49:10 -0700 (PDT) Received: by pzk33 with SMTP id 33so4729011pzk.18 for ; Thu, 08 Sep 2011 08:50:59 -0700 (PDT) Received: by 10.68.33.228 with SMTP id u4mr1288426pbi.58.1315497059283; Thu, 08 Sep 2011 08:50:59 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx.google.com with ESMTPS id i4sm13830898pbr.4.2011.09.08.08.50.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Sep 2011 08:50:58 -0700 (PDT) Received: by pzk33 with SMTP id 33so4728896pzk.18 for ; Thu, 08 Sep 2011 08:50:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.43.8 with SMTP id s8mr1374937pbl.389.1315497057186; Thu, 08 Sep 2011 08:50:57 -0700 (PDT) Received: by 10.68.43.136 with HTTP; Thu, 8 Sep 2011 08:50:57 -0700 (PDT) In-Reply-To: References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 8 Sep 2011 11:50:57 -0400 Message-ID: From: Roman Shpount To: Jonathan Lennox Content-Type: multipart/alternative; boundary=bcaec5395f24cbf5a504ac700617 Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 15:49:11 -0000 --bcaec5395f24cbf5a504ac700617 Content-Type: text/plain; charset=ISO-8859-1 I think we should provide a way in JavaScript API to specify if encryption is required. We should be able to negotiate an open channel connection as well as encrypted one, if for not other reason then for debugging. It would be extremely hard to debug and troubleshoot any issues if all communications are encrypted. On the Offer/Answer side of the question, I don't think the question is to support or not support offer answer. I think what we should try to accomplish is a JavaScript API that allows to create solutions that will interop with offer answer. We can have API methods that provide additional media negotiation capabilities and it will be up to an application to decide if offer/answer interoperability is required for it or if other more feature complete or convenient API should be used. Not all the calls originated from the RTC client will need to be connected to old PSTN devices, but ability to be able to connect to old PSTN devices without using a media proxy is highly desired. _____________ Roman Shpount On Thu, Sep 8, 2011 at 8:21 AM, Jonathan Lennox wrote: > Indeed. > > More generally, the question is: should it be possible to send an offer > that by default does DTLS/SAVPF for RTCWeb, but also can fall back to other > RTP profiles to support legacy devices? > > If yes, then either browsers need to support CapNeg, or RTCWeb needs to use > something other than SDP Offer/Answer. > > If no, then supporting interop, without a media gateway, with other > non-RTCWeb modes (e.g., no ICE, no rtcp mux, no audio/video mux, etc.) > becomes IMO a lot less compelling. > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, September 08, 2011 2:35 AM > To: Randell Jesup; Jonathan Lennox > Cc: rtcweb@ietf.org > Subject: AVPF [was: [rtcweb] Encryption mandate (and offer/answer)] > > > Hi, > > >>>You could make forced-encryption the default, and allow the > >>>application control over whether to allow it is turned off for > >>>specific cases, like a PSTN call, or under the server's control. > >>>Signalling is secure, so it could even use a direct optional > >>>downgrade from SAVP* to AVP* (i.e. > >>>similar to the best-effort-strp draft) > >>This has implications for the parallel thread about the use of SDP > >>offer/answer. > >> > >>The solution MMUSIC has standardized for best-effort SRTP is SDP > >>CapNeg, RFC 5939. Do we want to require CapNeg support in browsers? > > > >Yeah, ok, I'm not going there. :-) It's probably not needed for this > >use-case anyways. > > The same question exists for AVPF, which has been suggested to be mandated. > > Regards, > > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec5395f24cbf5a504ac700617 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think we should provide a way in JavaScript API to specify if encryption = is required. We should be able to negotiate an open channel connection as w= ell as encrypted one, if for not other reason then for debugging. It would = be extremely hard to debug and troubleshoot any issues if all communication= s are encrypted.

On the Offer/Answer side of the question, I don't think the questio= n is to support or not support offer answer. I think what we should try to = accomplish is a JavaScript API that allows to create solutions that will in= terop with offer answer. We can have API methods that provide additional me= dia negotiation capabilities and it will be up to an application to decide = if offer/answer interoperability is required for it or if other more featur= e complete or convenient API should be used. Not all the calls originated f= rom the RTC client will need to be connected to old PSTN devices, but abili= ty to be able to connect to old PSTN devices without using a media proxy is= highly desired.
_____________
Roman Shpount


On Thu, Sep 8, 2011 at 8:21 AM, Jonathan= Lennox <jonatha= n@vidyo.com> wrote:
Indeed.

More generally, the question is: should it be possible to send an offer tha= t by default does DTLS/SAVPF for RTCWeb, but also can fall back to other RT= P profiles to support legacy devices?

If yes, then either browsers need to support CapNeg, or RTCWeb needs to use= something other than SDP Offer/Answer.

If no, then supporting interop, without a media gateway, with other non-RTC= Web modes (e.g., no ICE, no rtcp mux, no audio/video mux, etc.) becomes IMO= a lot less compelling.

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Thursday, September 08, 2011 2:35 AM
To: Randell Jesup; Jonathan Lennox
Cc: rtcweb@ietf.org
Subject: AVPF [was: [rtcweb] Encryption mandate (and offer/answer)]


Hi,

>>>You could make forced-encryption the default, and allow the
>>>application control over whether to allow it is turned off for<= br> >>>specific cases, like a PSTN call, or under the server's con= trol.
>>>Signalling is secure, so it could even use a direct optional >>>downgrade from SAVP* to AVP* (i.e.
>>>similar to the best-effort-strp draft)
>>This has implications for the parallel thread about the use of SDP<= br> >>offer/answer.
>>
>>The solution MMUSIC has standardized for best-effort SRTP is SDP >>CapNeg, RFC 5939. =A0Do we want to require CapNeg support in browse= rs?
>
>Yeah, ok, I'm not going there. =A0:-) =A0It's probably not need= ed for this
>use-case anyways.

The same question exists for AVPF, which has been suggested to be mandated.=

Regards,

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

--bcaec5395f24cbf5a504ac700617-- From pkyzivat@alum.mit.edu Thu Sep 8 08:50: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 08D6421F8557 for ; Thu, 8 Sep 2011 08:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 U3y+oRyEedpo for ; Thu, 8 Sep 2011 08:50:15 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3D121F84DA for ; Thu, 8 Sep 2011 08:50:15 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta10.westchester.pa.mail.comcast.net with comcast id WF8j1h0030mv7h05AFs8js; Thu, 08 Sep 2011 15:52:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta11.westchester.pa.mail.comcast.net with comcast id WFs71h0190tdiYw3XFs7bm; Thu, 08 Sep 2011 15:52:08 +0000 Message-ID: <4E68E4CA.8040400@alum.mit.edu> Date: Thu, 08 Sep 2011 11:52:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: , <4E6756C1.9060207@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 15:50:16 -0000 On 9/8/11 12:45 AM, Bernard Aboba wrote: > > > > 1) The media negotiations will be done using the same SDP > offer/answer semantics that are used in SIP. > > To be precise - you're suggesting that we use RFC 3264 offer/answer > > semantics. (That RFC is 25 pages long. RFC 3261, the core SIP document, > > is 269 pages, and is NOT a normative reference from 3264. I am anxious > > to avoid having a normative dependency on 3261.) > > > > I agree with this. > > [BA] I do *not* agree that RTCWEB should have to support every aspect of > SDP offer/answer. Basic offer/answer, sure. All potential corner cases? > Not necessarily. I'm not sure where you are going here? Are you suggesting that all the mandatory to implement O/A semantics of 3264 might not be supported? Or are you saying that O/A support may not work for all defined SDP extensions? I think that all mandatory O/A should be supported. If you have something specific in mind that is problematic, then maybe we should investigate why you think it needs to be excluded. My guess is that maybe it is something broken in the spec that ought to be fixed there. > > > 2) It will be possible to gateway between legacy SIP devices that > support ICE and appropriate RTP / SDP mechanisms and codecs without > using a media gateway. A signaling gateway to convert between the > signaling on the web side to the SIP signaling may be needed. > > > I agree with this - I think the "may be needed" will turn out to be > > "will be needed", but some portion of that gateway can be implemented by > > Javascript running in the browser, if desirable. > > [BA] This seems like a good principle, but I'm not clear that it will > work with all use cases. For example, what happens in the E911 use cases > when an RTCWEB implementation attempts to make a call to a PSAP > implementing NENA i3 Stage 3? If you don't have a media gateway, then > the browser will need to implement one of the mandated codecs on the > PSAP side. So in those use cases, eliminating the media gateway implies > making G.711 and H.264 mandatory-to-implement. AFAIK, not every rtcweb application will be obligated to support E911. (In particular, any application that doesn't identify callees by phone number is a good candidate to be exempt from E911. Certainly a server without a media gateway will be limited in what it can call based on codec compatibility. That may or may not be a limitation, depending on the application. Those that find it an unacceptable limitation will probably find a way to incorporate a transcoder when needed. Thanks, Paul From pkyzivat@alum.mit.edu Thu Sep 8 09:00: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 A544B21F87D9 for ; Thu, 8 Sep 2011 09:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 sblfvu7h8584 for ; Thu, 8 Sep 2011 09:00:26 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id C02C021F85BB for ; Thu, 8 Sep 2011 09:00:25 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta10.westchester.pa.mail.comcast.net with comcast id WFs01h0040SCNGk5AG2JfH; Thu, 08 Sep 2011 16:02:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta09.westchester.pa.mail.comcast.net with comcast id WG2H1h00D0tdiYw3VG2H5a; Thu, 08 Sep 2011 16:02:18 +0000 Message-ID: <4E68E72C.3080403@alum.mit.edu> Date: Thu, 08 Sep 2011 12:02:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <8233FBBB-26CE-4822-81A4-65F86A4E8666@edvina.net> <4E67F296.3020007@jesup.org> <4E685ED0.3010602@jesup.org> In-Reply-To: <4E685ED0.3010602@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 16:00:26 -0000 On 9/8/11 2:21 AM, Randell Jesup wrote: > On 9/8/2011 1:43 AM, Olle E. Johansson wrote: >> >>>> 7 sep 2011 kl. 21:20 skrev Randell Jesup: >>>> >>>>> Signalling is secure, so it could even use a direct optional >>>>> downgrade from SAVP* to AVP* (i.e. similar to the best-effort-strp >>>>> draft) >>>> How can you assert that signalling is secure? When, how? >>> I'm assuming the signalling is occurring as SIP over an HTTPS >>> connection to the server, or SIP-over-TLS - haven't really given it a >>> lot of thought other than this connection is securable is we start >>> with an HTTPS connection to the server. >> That only guarantees confidentiality the first hop of signalling, >> provided that the TLS certificates was properly verified. That's a >> long way from assuming that signalling is secure. >> > > Well, as this is rtcweb, the application knows it's talking to the > service associated with the app directly, so there should be no > intermediaries in the SIP fashion between the app and the service it > provides. I hadn't meant to have my statement apply to "federated" > connections between services, which is where your objection would > primarily come in. How would a user know whether the service he is using is federated or not? E.g. it may be possible for one user of a service to configure "call forwarding" using federation. Other users of the service will not necessarily know if they are talking to a user that has federation enabled. Thanks, Paul (There is the issue of "can someone spoof > https://foo.com/"; the answer *should* be no, and if so then that first > hop is secure). > > But this may be moot anyways given my response to Jonathan Lennox on > this topic about Cap-Neg (shudder). > From roman@telurix.com Thu Sep 8 09:03: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 2C32E21F889A for ; Thu, 8 Sep 2011 09:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmBl+Ky9kWeE for ; Thu, 8 Sep 2011 09:03:17 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD6221F87FA for ; Thu, 8 Sep 2011 09:03:17 -0700 (PDT) Received: by gxk9 with SMTP id 9so40735gxk.40 for ; Thu, 08 Sep 2011 09:05:09 -0700 (PDT) Received: by 10.68.1.34 with SMTP id 2mr1251430pbj.356.1315497909206; Thu, 08 Sep 2011 09:05:09 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx.google.com with ESMTPS id u10sm13849516pbr.12.2011.09.08.09.05.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Sep 2011 09:05:08 -0700 (PDT) Received: by pzk33 with SMTP id 33so4778338pzk.18 for ; Thu, 08 Sep 2011 09:05:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.132 with SMTP id k4mr1191639pbo.456.1315497907556; Thu, 08 Sep 2011 09:05:07 -0700 (PDT) Received: by 10.68.43.136 with HTTP; Thu, 8 Sep 2011 09:05:07 -0700 (PDT) In-Reply-To: <4E68E4CA.8040400@alum.mit.edu> References: <4E6756C1.9060207@alvestrand.no> <4E68E4CA.8040400@alum.mit.edu> Date: Thu, 8 Sep 2011 12:05:07 -0400 Message-ID: From: Roman Shpount To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=bcaec51a77007b8f6804ac70392c Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 16:03:18 -0000 --bcaec51a77007b8f6804ac70392c Content-Type: text/plain; charset=ISO-8859-1 If the goal is to create something that will interop with an existing SIP infrastructure using a signalling proxy only, we would need is to fully support RFC 3264. I think what we will need is an ability to generate an initial offer (as SDP), process the provisional SDP response, process final SDP response, process an offer and generate the response, and generate a new offer for the existing call (similar to the response to the SIP INVITE with no body) in accordance with rules in RFC 3264. We will need to decide which SDP related RFC would need to be supported, but I think RFC 4566, RFC 3551, RFC 5245, and RFC 3605 are the minimum. _____________ Roman Shpount On Thu, Sep 8, 2011 at 11:52 AM, Paul Kyzivat wrote: > On 9/8/11 12:45 AM, Bernard Aboba wrote: > >> >> > > 1) The media negotiations will be done using the same SDP >> offer/answer semantics that are used in SIP. >> > To be precise - you're suggesting that we use RFC 3264 offer/answer >> > semantics. (That RFC is 25 pages long. RFC 3261, the core SIP document, >> > is 269 pages, and is NOT a normative reference from 3264. I am anxious >> > to avoid having a normative dependency on 3261.) >> > >> > I agree with this. >> >> [BA] I do *not* agree that RTCWEB should have to support every aspect of >> SDP offer/answer. Basic offer/answer, sure. All potential corner cases? >> Not necessarily. >> > > I'm not sure where you are going here? > Are you suggesting that all the mandatory to implement O/A semantics of > 3264 might not be supported? Or are you saying that O/A support may not work > for all defined SDP extensions? > > I think that all mandatory O/A should be supported. If you have something > specific in mind that is problematic, then maybe we should investigate why > you think it needs to be excluded. My guess is that maybe it is something > broken in the spec that ought to be fixed there. > > > > > 2) It will be possible to gateway between legacy SIP devices that >> support ICE and appropriate RTP / SDP mechanisms and codecs without >> using a media gateway. A signaling gateway to convert between the >> signaling on the web side to the SIP signaling may be needed. >> >> > I agree with this - I think the "may be needed" will turn out to be >> > "will be needed", but some portion of that gateway can be implemented >> by >> > Javascript running in the browser, if desirable. >> >> [BA] This seems like a good principle, but I'm not clear that it will >> work with all use cases. For example, what happens in the E911 use cases >> when an RTCWEB implementation attempts to make a call to a PSAP >> implementing NENA i3 Stage 3? If you don't have a media gateway, then >> the browser will need to implement one of the mandated codecs on the >> PSAP side. So in those use cases, eliminating the media gateway implies >> making G.711 and H.264 mandatory-to-implement. >> > > AFAIK, not every rtcweb application will be obligated to support E911. > (In particular, any application that doesn't identify callees by phone > number is a good candidate to be exempt from E911. > > Certainly a server without a media gateway will be limited in what it can > call based on codec compatibility. That may or may not be a limitation, > depending on the application. Those that find it an unacceptable limitation > will probably find a way to incorporate a transcoder when needed. > > Thanks, > Paul > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --bcaec51a77007b8f6804ac70392c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If the goal is to create something that will interop with an existing SIP i= nfrastructure using a signalling proxy only, we would need is to fully supp= ort RFC 3264. I think what we will need is an ability to generate an initia= l offer (as SDP), process the provisional SDP response, process final SDP r= esponse, process an offer and generate the response, and generate a new off= er for the existing call (similar to the response to the SIP INVITE with no= body) in accordance with rules in RFC 3264. We will need to decide which S= DP related RFC would need to be supported, but I think RFC 4566, RFC 3551, = RFC 5245, and RFC 3605 are the minimum.
_____________
Roman Shpount


On Thu, Sep 8, 2011 at 11:52 AM, Paul Ky= zivat <pkyziv= at@alum.mit.edu> wrote:
On 9/8/11 12:45 AM, Bernard Aboba wrote:

=A0> > 1) The media negotiations will be done using the same SDP
offer/answer semantics that are used in SIP.
=A0> To be precise - you're suggesting that we use RFC 3264 offer/an= swer
=A0> semantics. (That RFC is 25 pages long. RFC 3261, the core SIP docum= ent,
=A0> is 269 pages, and is NOT a normative reference from 3264. I am anxi= ous
=A0> to avoid having a normative dependency on 3261.)
=A0>
=A0> I agree with this.

[BA] I do *not* agree that RTCWEB should have to support every aspect of SDP offer/answer. Basic offer/answer, sure. All potential corner cases?
Not necessarily.

I'm not sure where you are going here?
Are you suggesting that all the mandatory to implement O/A semantics of 326= 4 might not be supported? Or are you saying that O/A support may not work f= or all defined SDP extensions?

I think that all mandatory O/A should be supported. If you have something s= pecific in mind that is problematic, then maybe we should investigate why y= ou think it needs to be excluded. My guess is that maybe it is something br= oken in the spec that ought to be fixed there.


=A0> > 2) It will be possible to gateway between legacy SIP devices t= hat
support ICE and appropriate RTP / SDP mechanisms and codecs without
using a media gateway. A signaling gateway to convert between the
signaling on the web side to the SIP signaling may be needed.

=A0> I agree with this - I think the "may be needed" will turn= out to be
=A0> "will be needed", but some portion of that gateway can be= implemented by
=A0> Javascript running in the browser, if desirable.

[BA] This seems like a good principle, but I'm not clear that it will work with all use cases. For example, what happens in the E911 use cases when an RTCWEB implementation attempts to make a call to a PSAP
implementing NENA i3 Stage 3? If you don't have a media gateway, then the browser will need to implement one of the mandated codecs on the
PSAP side. So in those use cases, eliminating the media gateway implies
making G.711 and H.264 mandatory-to-implement.

AFAIK, not every rtcweb application will be obligated to support E911.
(In particular, any application that doesn't identify callees by phone = number is a good candidate to be exempt from E911.

Certainly a server without a media gateway will be limited in what it can c= all based on codec compatibility. That may or may not be a limitation, depe= nding on the application. Those that find it an unacceptable limitation wil= l probably find a way to incorporate a transcoder when needed.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

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

--bcaec51a77007b8f6804ac70392c-- From pkyzivat@alum.mit.edu Thu Sep 8 09:17: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 2C51421F889A for ; Thu, 8 Sep 2011 09:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 6wLTFgsatdWJ for ; Thu, 8 Sep 2011 09:17:15 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2CF21F87FA for ; Thu, 8 Sep 2011 09:17:15 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta07.westchester.pa.mail.comcast.net with comcast id WGJG1h00316LCl057GK8ts; Thu, 08 Sep 2011 16:19:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta06.westchester.pa.mail.comcast.net with comcast id WGK61h00t0tdiYw3SGK7ul; Thu, 08 Sep 2011 16:19:08 +0000 Message-ID: <4E68EB1D.7040501@alum.mit.edu> Date: Thu, 08 Sep 2011 12:19:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Michael Procter References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67D1F4.10002@mozilla.com> <4E6808D5.7090709@alum.mit.edu> <95877BC0-B0AA-4B20-9C2E-C16076BBE96E@edvina.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 16:17:16 -0000 On 9/8/11 5:33 AM, Michael Procter wrote: > Paul, Olle, > > Both of you correctly point out that determining when a session is > secure is a very hard problem - one that is nigh-on impossible except > for certain restricted scenarios. But I think we may have missed the > change of emphasis in Chris' proposed UI change. Instead of marking a > session as secure (which is hard to determine), he is suggesting > marking it as insecure (which is easier!). > > If the signalling and media entering and leaving the browser are not > secured by an appropriate mechanism, then the session should be marked > as 'insecure'. If they are secured, then Chris' proposal would have > no indication on the browser, which intuitively seems to match what we > know about the session - secure to the server but 'who knows' after > that. Whether that is good enough for you will depend on whether you > trust the service you are using. I agree that this might provide some utility that isn't otherwise achievable. However, trusting the service remains an issue. Big brother will probably ensure that most of them have back doors. Thanks, Paul > Michael > > On 8 September 2011 06:48, Olle E. Johansson wrote: >> >> 8 sep 2011 kl. 02:14 skrev Paul Kyzivat: >>> >>> Chris, >>> >>> I agree with you that the UI indication of security is important. >>> But its also *hard* for this application, for a variety of reasons: >>> >>> - While it may be easy for the browser to know if the media stream >>> is itself secured, its hard (impossible) to know that its secured >>> to its ultimate end point. That is the problem with intermediaries. >>> >>> - it may turn out that not all the streams in the "call" have the >>> same degree of security. >>> >>> Of course this can all be dealt with via proper definition of what the UI >>> indication means, and doesn't mean. But doing that will just render it >>> meaningless to many users. To be widely understood, the indication will need >>> to be simple, and closely aligned with what people "expect". >>> >>> Consider a stream that is secured to a PSTN gateway, and then travels over >>> the PSTN to somebody's phone. Should that be considered a "secure" call? Or >>> an "insecure" call? Or somewhere between those? >>> >>> Its going to be hard work to figure out what can both be reliably reported >>> to users and also be understandable and meaningful to users. >>> >> Agree. I see your way of thinking as an argument to make all sessions >> confidential, encrypted by default. We can't reliable define a "secure call" >> and separate insecure sessions from secure sessions. Which mean that a UI >> indication won't mean anything. We can just make sure that the first hop is >> protected, the rest is up to the application that operates the media >> session. >> /O > > >> On 9/7/11 4:20 PM, Christopher Blizzard wrote: >> >> I want secure-by-default, maybe even secure-only. >> Even if it's not secure-only there's also an important UI consideration >> depending how we end up doing that in browsers. In the past we've made >> the secure mode special (the lock icon in the early days, now the >> green/blue bar) but I think that we should be making the insecure mode >> special. That is, always mark a connection as very clearly unencrypted >> via UI affordances. Just like banks "wanting to know how to get the lock >> icon" we should be making call sites "wanting to know how to get rid of >> that huge ugly warning that makes us look bad." >> >> Once again, I would much prefer secure-only, but I'll take >> secure-by-default across browsers if I can get it. >> >> --Chris > From pkyzivat@alum.mit.edu Thu Sep 8 09:23: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 41F3921F886A for ; Thu, 8 Sep 2011 09:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 b48Y0GV5EAoz for ; Thu, 8 Sep 2011 09:23:51 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id D886721F84A7 for ; Thu, 8 Sep 2011 09:23:50 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id WGQg1h0031ZXKqc53GRkSb; Thu, 08 Sep 2011 16:25:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta21.westchester.pa.mail.comcast.net with comcast id WGRi1h01M0tdiYw3hGRjWT; Thu, 08 Sep 2011 16:25:43 +0000 Message-ID: <4E68ECA9.8030708@alum.mit.edu> Date: Thu, 08 Sep 2011 12:26:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <78E46957-F8C3-4607-B781-73CC824EB0E1@phonefromhere.com> In-Reply-To: <78E46957-F8C3-4607-B781-73CC824EB0E1@phonefromhere.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 16:23:52 -0000 On 9/8/11 5:38 AM, Tim Panton wrote: > Sites that don't wish to interop won't and it should not be forced on > them. I don't want my bank calling my second life avatar. While I agree with your general point, I can see why my SL avatar might want to call my bank. :-) Thanks, Paul From dzonatas@gmail.com Thu Sep 8 09:58: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 40A3921F86F6 for ; Thu, 8 Sep 2011 09:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.978 X-Spam-Level: X-Spam-Status: No, score=-3.978 tagged_above=-999 required=5 tests=[AWL=-0.379, 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 f4VnUXCZWFTD for ; Thu, 8 Sep 2011 09:58:12 -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 3115621F86A5 for ; Thu, 8 Sep 2011 09:58:12 -0700 (PDT) Received: by gyd12 with SMTP id 12so923600gyd.31 for ; Thu, 08 Sep 2011 10:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=8/awrJ2UvXID10ONcv227F6+McK4EvvQ+5kCzwqCF9k=; b=uuPURUSudr99wXVCiWO0XBvwwxJFB4znj8by3kP73RQn1Ejzqx3B8XYn/viJRw7+we S1BVrBd+wSOBO0a0qPZs8Sb6WiARxapafYryOoGcAm7MaRvvLP3Gnpmhun5Y2ACc24xN rLhTNP9/m5H5P9OlmaJ6Plnj2oHfWnXJCodPo= Received: by 10.236.73.195 with SMTP id v43mr6149896yhd.5.1315501204685; Thu, 08 Sep 2011 10:00:04 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id y79sm595204yhg.23.2011.09.08.10.00.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Sep 2011 10:00:03 -0700 (PDT) Message-ID: <4E68F507.8090102@gmail.com> Date: Thu, 08 Sep 2011 10:01:59 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E6756C1.9060207@alvestrand.no> <4E68E4CA.8040400@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 16:58:13 -0000 The main thing that concerns me with SIP is the stateful-ness, yet maybe that is not of any concern for mobile-phones. I look at this from evolution of RFC 2516 such that support of SIP in rtcweb allows return to stateless modes (in interop) where before we could assume stateless before specific sections on-the-wire and stateful after known points. Now people want that transition in the application layer and assume HTTPS is ok for stateful-ness. I can see why the multiplex route is desired, instead. Maybe NAT64 can be in-scope if it includes some more stateful PPPoE alternative. That would lead to "insider" and "outsider" modes for wi-fi (and on-the-wire for plug-ins), so I doubt current interest exist in this kind of change for standard. If, however, SIP and rtcweb work together on S/MIME and SSRC for stateful-ness than this could get easier (at least in half-duplex). On 09/08/2011 09:05 AM, Roman Shpount wrote: > If the goal is to create something that will interop with an existing > SIP infrastructure using a signalling proxy only, we would need is to > fully support RFC 3264. I think what we will need is an ability to > generate an initial offer (as SDP), process the provisional SDP > response, process final SDP response, process an offer and generate > the response, and generate a new offer for the existing call (similar > to the response to the SIP INVITE with no body) in accordance with > rules in RFC 3264. We will need to decide which SDP related RFC would > need to be supported, but I think RFC 4566, RFC 3551, RFC 5245, and > RFC 3605 are the minimum. > _____________ > Roman Shpount > > > On Thu, Sep 8, 2011 at 11:52 AM, Paul Kyzivat > wrote: > > On 9/8/11 12:45 AM, Bernard Aboba wrote: > > > �> > 1) The media negotiations will be done using the same SDP > offer/answer semantics that are used in SIP. > �> To be precise - you're suggesting that we use RFC 3264 > offer/answer > �> semantics. (That RFC is 25 pages long. RFC 3261, the core > SIP document, > �> is 269 pages, and is NOT a normative reference from 3264. I > am anxious > �> to avoid having a normative dependency on 3261.) > �> > �> I agree with this. > > [BA] I do *not* agree that RTCWEB should have to support every > aspect of > SDP offer/answer. Basic offer/answer, sure. All potential > corner cases? > Not necessarily. > > > I'm not sure where you are going here? > Are you suggesting that all the mandatory to implement O/A > semantics of 3264 might not be supported? Or are you saying that > O/A support may not work for all defined SDP extensions? > > I think that all mandatory O/A should be supported. If you have > something specific in mind that is problematic, then maybe we > should investigate why you think it needs to be excluded. My guess > is that maybe it is something broken in the spec that ought to be > fixed there. > > > �> > 2) It will be possible to gateway between legacy SIP > devices that > support ICE and appropriate RTP / SDP mechanisms and codecs > without > using a media gateway. A signaling gateway to convert between the > signaling on the web side to the SIP signaling may be needed. > > �> I agree with this - I think the "may be needed" will turn > out to be > �> "will be needed", but some portion of that gateway can be > implemented by > �> Javascript running in the browser, if desirable. > > [BA] This seems like a good principle, but I'm not clear that > it will > work with all use cases. For example, what happens in the E911 > use cases > when an RTCWEB implementation attempts to make a call to a PSAP > implementing NENA i3 Stage 3? If you don't have a media > gateway, then > the browser will need to implement one of the mandated codecs > on the > PSAP side. So in those use cases, eliminating the media > gateway implies > making G.711 and H.264 mandatory-to-implement. > > > AFAIK, not every rtcweb application will be obligated to support E911. > (In particular, any application that doesn't identify callees by > phone number is a good candidate to be exempt from E911. > > Certainly a server without a media gateway will be limited in what > it can call based on codec compatibility. That may or may not be a > limitation, depending on the application. Those that find it an > unacceptable limitation will probably find a way to incorporate a > transcoder when needed. > > � � � �Thanks, > � � � �Paul > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From pkyzivat@alum.mit.edu Thu Sep 8 10:06: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 4B59D21F85A4 for ; Thu, 8 Sep 2011 10:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 jtHmnt7w1zeR for ; Thu, 8 Sep 2011 10:06:50 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 441B421F8593 for ; Thu, 8 Sep 2011 10:06:50 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta12.westchester.pa.mail.comcast.net with comcast id WGXp1h00A1c6gX85CH8jRv; Thu, 08 Sep 2011 17:08:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta23.westchester.pa.mail.comcast.net with comcast id WH8h1h02N0tdiYw3jH8i8K; Thu, 08 Sep 2011 17:08:43 +0000 Message-ID: <4E68F6BC.3010300@alum.mit.edu> Date: Thu, 08 Sep 2011 13:09:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Asveren, Tolga" References: , <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com> <4E659576.1000301@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F0868@sonusinmail02.sonusnet.com><4E666785.7040409@skype.net> <4E67513C.3030600@alvestrand.no><4E677CB8.40203@skype.net> <4E678B44.9080208@alum.mit.edu><4E67EBCF.5050206@skype.net> <4E68DDC5.3050209@alum.mit.edu> <033458F56EC2A64E8D2D7B759FA3E7E703C28AF1@sonusmail04.sonusnet.com> In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E703C28AF1@sonusmail04.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase & architecture: Browser application with separate webserver & voipserver) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 17:06:51 -0000 On 9/8/11 11:45 AM, Asveren, Tolga wrote: > Some questions/comments inline... > > Thanks, > Tolga > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf >> Of Paul Kyzivat >> Sent: Thursday, September 08, 2011 11:23 AM >> To: Matthew Kaufman >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] Bridged line appearance? (Re: Usecase& >> architecture: Browser application with separate webserver& > voipserver) >> >> On 9/7/11 6:10 PM, Matthew Kaufman wrote: >>> On 9/7/11 8:18 AM, Paul Kyzivat wrote: >>>> Matthew, >>>> >>>> Good summary. >>>> >>>> I agree that webrtc provides flexibility in how to implement the UI >>>> portions of these features with generic webrtc clients. But it > doesn't >>>> make these features trivial to implement. >>> >>> I didn't say that it did. But the flexibility does allow the feature > to >>> be implemented in whatever combination of client-side Javascript and >>> server-side programming you wish. >>> >>>> In particular, the bridged line appearance still requires that a >>>> conference be established. With generic rtcweb clients, that > probably >>>> means a central mixer. Setting that up is relatively easy if there > is >>>> a central media termination point in rtcweb server, and it *has* > mixer >>>> capabilities. >>> >>> Agree. >>> >>>> >>>> My point is not that rtcweb doesn't help with this case - just that >>>> these features that are so trivial in analog telephony just aren't > so >>>> simple with voip, no matter how you do it. >>> >>> Also agree. >>> >>> The real difference comes with the programming model. With a SIP > phone, >>> to add bridged line appearance support you need to write a new spec >>> (that doesn't exist), get consensus around that spec, and then > upgrade >>> the phone firmware. With an SCCP (Skinny) phone, to add bridged line >>> appearance support you simply write some additional code that runs > at >>> the server end that changes when the lights are commanded to turn on > and >>> off, controls what happens when a lit line button is pushed, and >>> commands the phone to send the right kind of media to the right > place. >> >> I think what you are saying is that with rtcweb you can build a >> replacement for Cisco Call Manager - with rtcweb replacking SCCP, and >> the call manager itself subsumed into a web server. This then allows > any >> rtcweb enabled user device to be used instead of a Cisco proprietary >> phone. I agree with that, and its likely to be a good thing. (But > maybe >> not for Cisco.) >> >> At a macro level that thing seems to have the same centralized >> architecture as the Call Manager. Call Manager never bought into the > sip >> vision that the phones should be largely autonomous, and this approach >> using rtcweb doesn't either. >> >> The complexity of standardizing features like bridged line appearance >> arises if you try to follow that sip vision and allow autonomous sip >> devices to cooperate in that feature. >> >> I've been pondering this for a long time. I have realized its not >> practical to standardize all the features that span multiple devices >> attached to the same AOR - that having a server for the AOR coordinate >> the features across the multiple devices is more practical. And that >> rtcweb is a great way to do that without locking down the choice of >> devices. >> >> But I think the situation is different for coordinating features that >> span the multiple endpoints of a realtime communication session. Then > it >> comes down to a case by case analysis of how important it is for a >> particular feature to be ubiquitous. For instance, maybe you want to > use >> Facebook as your "call agent" for realtime communications. But does > that >> mean you can't communicate with me because I'm not a Facebook user? > [TOLGA] Yes, I think so if the service provided by Facebook is > "capability to establish a call to another Facebook user". If it is > "capability to call any phone number", then one would be able to call > any phone number, and if it the ability to call a Service-X identity, it > will do so. I guess the notion of "capability to call anybody" is very > vague. It all depends on the "identity context" + "identity to call" and > that will be determined by the service AFAICS. Agreed - clearly either sort of service could be provided. At the moment its a battle for dominance between a number of these services, so often they have negative motivation to federate. But this too shall pass, and it will be acknowledged that Facebook users can have friends on LinkedIn, and that LinkedIn users can have Contacts on Facebook. >> Ideally you can still reach me while using Facebook as your call > agent. >> Then there are *some* features that will ideally still work, while > there >> might be other features that only work when both ends are facebook > users. >> >> Those features that are to be more ubiquitous will require more >> standardization effort than those that aren't. (No free lunch.) >> >> Rtcweb ought to work with both sorts. >> >>> There is no reason why we should make a web browser, which has the > added >>> advantage of a local execution environment for Javascript, *less* >>> capable than the aforementioned server-controlled phone. >> >> Note that Call Manager can use SIP phones as well as SCCP phones. And >> when those sip phones have the Cisco secret sauce (which deviates only >> mildly from *real* sip) they have all the functionality of the SCCP > phones. >> >> I would expect that whatever way this debate ends (sip in the browser > or >> not) the web browser should have the same level of functionality. > [TOLGA] Can I assume that you mean "webbrowser + JS" instead of > "webbrowser as is"? Yes. What else could I mean? A web browser without an JS can't really do much interesting. Thanks, Paul > I am not entirely sold on the idea that SIP endpoint is equivalent to a > webbrowser from architectural point of view (even with JS). From pravindran@sonusnet.com Thu Sep 8 10:10: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 195EB21F8B10 for ; Thu, 8 Sep 2011 10:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 QjFqeKVipRlU for ; Thu, 8 Sep 2011 10:10:12 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 538D721F8593 for ; Thu, 8 Sep 2011 10:09:50 -0700 (PDT) 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 p88HCBgo032274; Thu, 8 Sep 2011 13:12:11 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Sep 2011 13:11:41 -0400 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: Thu, 8 Sep 2011 22:41:17 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0991@sonusinmail02.sonusnet.com> In-Reply-To: <4E67C3EE.50707@jesup.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] Thread-Index: Acxtk5lMXnIRWpfTSmyU6qdkKwIXdwAtiNrQ References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com><496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net><4E540FE2.7020605@alcatel-lucent.com><2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com><4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com><2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com><4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net><033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3EE.50707@jesup.org> From: "Ravindran Parthasarathi" To: "Randell Jesup" , X-OriginalArrivalTime: 08 Sep 2011 17:11:41.0200 (UTC) FILETIME=[6077C900:01CC6E4A] Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 17:10:15 -0000 In principle, I like your idea. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Randell Jesup >Sent: Thursday, September 08, 2011 12:50 AM >To: rtcweb@ietf.org >Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: >Remoterecording - RTC-Web client acting as SIPREC session >recordingclient] > >On 9/7/2011 3:07 AM, Olle E. Johansson wrote: >> 6 sep 2011 kl. 21:24 skrev Asveren, Tolga: >> >>> What about semantics (adding just a X-header won't help there) or how >much SIP would be left anyhow if all semantical control is exposed >through the API? >>> >>> I think bridged line appearance is a good test to run against >different models. >>> >> Well, I tried to stay neutral but examples likes this makes me not >want SIP in the browser. DTMF, Early Media, bridge line apperances and >other PSTN legacy will make the implementation too focused on classical >telephony and we'll spend too much time implementing features that are >application specific and we can implement in controlling applications, >client or server-side. >> >> Cullen tried to make a draft with "limited" SIP (maybe "SIP Lite") but >it will be hard to protect that from the myriad of extensions that add >PSTN functionality that's not really needed to set up multimedia calls >between two browser users. It may be needed for gatewaying to legacy >systems, but if we don't "stop Olle in the gate" - verbatim translation >of a Swedish saying that propably doesn't mean much to most people on >the list - I think we will never be done. >> >> Of course, being a SIP developer, I started off with thinking that SIP >in the browser was the default route. I am beginning to understand that >the browser is the user interface part we all need, the media handler. >We all have different requirements on how to control that media GUI and >to get anywhere I am beginning to think the logic for signalling to set >up rendevouz points and manage sessions has to move "somewhere else" >where we can implement SIP, XMPP or some other protocol that fulfills >the need of our respective application. > >I also started from the same point - assume SIP. SIP gives you all the >things that the zillions of hours and emails to define it and define >extensions and secure it provides, without having to reinvent all those >wheels (or ask app developers to reinvent them). Why go through the >horrible pain of choosing something else, or why throw the app >developers to the wolves to fend for themselves? > >However... > >Two things have swayed me. The primary one is the suggestion of >Offer/Answer in the browser. This breaks out the important negotiation >piece that almost any application would need, and while not perfect, SDP >O/A is a zillion times simpler than SIP with all the extensions one >could use. > >The other thing that swayed me was thinking about federation and the >apps that will be built with this. A webrtc app talks to its >(web)server, other webrtc clients running the app that talk to the >server, and to other webrtc applications/networks that federate with it >(and their clients). > >Federation is in the same hands as the person who provides/wrote the >app. If they have no interest in federation you can't force it, and >they may have no use for all the fancy SIP standards. > >On the other hand, if they *want* to either provide access to the wider >communication net that is the PSTN network, now or in the future, or >they want easy federation with other networks, it behooves them to use >SIP or something very close to it or equivalent/convertible (at a basic >level at least) to it. > >So what conclusions do I draw from this? > >1) O/A via SDP in the browser simplifies a lot of things (including >handling new codecs, etc). It doesn't extremely limit an application, >though we should think about how an application can interact with the >fmtp/etc parameters used. >=09 >2) SIP as a *separate* item that can be cleanly and easily *added* to a >webrtc app to handle the call setup/etc is a good idea. > >This means a webrtc app could use something else, or roll its own. Many >would use SIP. > >This would require (limited) SIP to be available as part of webrtc in >the browser - but as an option, not as a mandate. An application could >use an extended SIP client via JS or other mechanism. Basic SIP would >need to be in all webrtc implementations so the apps could rely on >having the option. > >This would make building apps & services that can (optionally) call PSTN >phones easy (very easy perhaps), while not limiting the ability of app >developers to innovate. It also makes it easier to build servers to >handle webrtc apps. > >-- >Randell Jesup >randell-ietf@jesup.org > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From pkyzivat@alum.mit.edu Thu Sep 8 10: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 16C8F21F8783 for ; Thu, 8 Sep 2011 10:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 JO4gswrteBOd for ; Thu, 8 Sep 2011 10:11:45 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id DE56B21F8770 for ; Thu, 8 Sep 2011 10:11:44 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta12.westchester.pa.mail.comcast.net with comcast id WH721h0010SCNGk5CHDei8; Thu, 08 Sep 2011 17:13:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta09.westchester.pa.mail.comcast.net with comcast id WHDd1h00E0tdiYw3VHDdhX; Thu, 08 Sep 2011 17:13:38 +0000 Message-ID: <4E68F7E4.20303@alum.mit.edu> Date: Thu, 08 Sep 2011 13:14:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E6756C1.9060207@alvestrand.no> <4E68E4CA.8040400@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 17:11:46 -0000 On 9/8/11 12:05 PM, Roman Shpount wrote: > If the goal is to create something that will interop with an existing > SIP infrastructure using a signalling proxy only, we would need is to > fully support RFC 3264. I think what we will need is an ability to > generate an initial offer (as SDP), process the provisional SDP > response, process final SDP response, process an offer and generate the > response, and generate a new offer for the existing call (similar to the > response to the SIP INVITE with no body) in accordance with rules in RFC > 3264. We will need to decide which SDP related RFC would need to be > supported, but I think RFC 4566, RFC 3551, RFC 5245, and RFC 3605 are > the minimum. If I understand you, then I think we are in agreement. Thanks, Paul > _____________ > Roman Shpount > > > On Thu, Sep 8, 2011 at 11:52 AM, Paul Kyzivat > wrote: > > On 9/8/11 12:45 AM, Bernard Aboba wrote: > > > > > 1) The media negotiations will be done using the same SDP > offer/answer semantics that are used in SIP. > > To be precise - you're suggesting that we use RFC 3264 > offer/answer > > semantics. (That RFC is 25 pages long. RFC 3261, the core SIP > document, > > is 269 pages, and is NOT a normative reference from 3264. I > am anxious > > to avoid having a normative dependency on 3261.) > > > > I agree with this. > > [BA] I do *not* agree that RTCWEB should have to support every > aspect of > SDP offer/answer. Basic offer/answer, sure. All potential corner > cases? > Not necessarily. > > > I'm not sure where you are going here? > Are you suggesting that all the mandatory to implement O/A semantics > of 3264 might not be supported? Or are you saying that O/A support > may not work for all defined SDP extensions? > > I think that all mandatory O/A should be supported. If you have > something specific in mind that is problematic, then maybe we should > investigate why you think it needs to be excluded. My guess is that > maybe it is something broken in the spec that ought to be fixed there. > > > > > 2) It will be possible to gateway between legacy SIP > devices that > support ICE and appropriate RTP / SDP mechanisms and codecs without > using a media gateway. A signaling gateway to convert between the > signaling on the web side to the SIP signaling may be needed. > > > I agree with this - I think the "may be needed" will turn out > to be > > "will be needed", but some portion of that gateway can be > implemented by > > Javascript running in the browser, if desirable. > > [BA] This seems like a good principle, but I'm not clear that it > will > work with all use cases. For example, what happens in the E911 > use cases > when an RTCWEB implementation attempts to make a call to a PSAP > implementing NENA i3 Stage 3? If you don't have a media gateway, > then > the browser will need to implement one of the mandated codecs on the > PSAP side. So in those use cases, eliminating the media gateway > implies > making G.711 and H.264 mandatory-to-implement. > > > AFAIK, not every rtcweb application will be obligated to support E911. > (In particular, any application that doesn't identify callees by > phone number is a good candidate to be exempt from E911. > > Certainly a server without a media gateway will be limited in what > it can call based on codec compatibility. That may or may not be a > limitation, depending on the application. Those that find it an > unacceptable limitation will probably find a way to incorporate a > transcoder when needed. > > Thanks, > Paul > > _________________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/__listinfo/rtcweb > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From blizzard@mozilla.com Thu Sep 8 11:38: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 6051721F8B04 for ; Thu, 8 Sep 2011 11:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87G7mf-z0pBk for ; Thu, 8 Sep 2011 11:38:56 -0700 (PDT) Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 034C221F899F for ; Thu, 8 Sep 2011 11:38:56 -0700 (PDT) Received: from [192.168.43.215] (unknown [206.29.182.149]) (Authenticated sender: blizzard@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id 5E1A64AED8D for ; Thu, 8 Sep 2011 11:40:48 -0700 (PDT) Message-ID: <4E6856A5.9080401@mozilla.com> Date: Wed, 07 Sep 2011 22:46:13 -0700 From: Christopher Blizzard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67D1F4.10002@mozilla.com> <4E6808D5.7090709@alum.mit.edu> <95877BC0-B0AA-4B20-9C2E-C16076BBE96E@edvina.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Encryption mandate X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 18:38:56 -0000 On 9/8/2011 2:33 AM, Michael Procter wrote: > Paul, Olle, > > Both of you correctly point out that determining when a session is > secure is a very hard problem - one that is nigh-on impossible except > for certain restricted scenarios. But I think we may have missed the > change of emphasis in Chris' proposed UI change. Instead of marking a > session as secure (which is hard to determine), he is suggesting > marking it as insecure (which is easier!). > > If the signalling and media entering and leaving the browser are not > secured by an appropriate mechanism, then the session should be marked > as 'insecure'. If they are secured, then Chris' proposal would have > no indication on the browser, which intuitively seems to match what we > know about the session - secure to the server but 'who knows' after > that. Whether that is good enough for you will depend on whether you > trust the service you are using. > Yes, this is a great way to put what I was saying. Thank you! --Chris From oej@edvina.net Thu Sep 8 11:46: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 2472E21F8B06 for ; Thu, 8 Sep 2011 11:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auEzbn-07k15 for ; Thu, 8 Sep 2011 11:46:51 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 67E8F21F858D for ; Thu, 8 Sep 2011 11:46:51 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id CC608754BCE5 for ; Thu, 8 Sep 2011 18:48:40 +0000 (UTC) From: "Olle E. Johansson" Content-Type: multipart/alternative; boundary="Apple-Mail=_C9957ED7-4099-420B-A6F4-9BE2CC0EB38E" Date: Thu, 8 Sep 2011 20:48:45 +0200 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [rtcweb] RTCweb signalling overview X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 18:46:52 -0000 --Apple-Mail=_C9957ED7-4099-420B-A6F4-9BE2CC0EB38E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii For those of you that did not participate in today's meeting, there was = an excellent overview presented by Martin Kaufman. It gives you an overview over the issues with signalling - to sip or not = to sip - and other issues. Do read it. Use the file rtcweb-3.pptx in http://www.ietf.org/proceedings/82/slides/ /O --Apple-Mail=_C9957ED7-4099-420B-A6F4-9BE2CC0EB38E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii For those of you that did not participate in today's meeting, there was an excellent overview presented by Martin Kaufman.

It gives you an overview over the issues with signalling - to sip or not to sip - and other issues. Do read it.


/O


--Apple-Mail=_C9957ED7-4099-420B-A6F4-9BE2CC0EB38E-- From igor.faynberg@alcatel-lucent.com Thu Sep 8 12:20: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 07FFF21F8B46 for ; Thu, 8 Sep 2011 12:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.602 X-Spam-Level: X-Spam-Status: No, score=-6.602 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZ05jvwTt21t for ; Thu, 8 Sep 2011 12:20:41 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7A53621F8B23 for ; Thu, 8 Sep 2011 12:20:41 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p88JMTxx019426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 14:22:30 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p88JMScf030858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Sep 2011 14:22:29 -0500 Received: from [135.244.18.36] (faynberg.lra.lucent.com [135.244.18.36]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p88JMQUq001196; Thu, 8 Sep 2011 14:22:27 -0500 (CDT) Message-ID: <4E6915F2.5000007@alcatel-lucent.com> Date: Thu, 08 Sep 2011 15:22:26 -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: Harald Alvestrand References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <4E68CB68.3020100@alcatel-lucent.com> <4E68D182.2090003@alvestrand.no> <4E68D742.4010203@alcatel-lucent.com> <4E68D8B5.7010602@alvestrand.no> In-Reply-To: <4E68D8B5.7010602@alvestrand.no> Content-Type: multipart/alternative; boundary="------------090203040201040906070206" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 19:20:42 -0000 This is a multi-part message in MIME format. --------------090203040201040906070206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > On 09/08/11 16:54, Igor Faynberg wrote: > ... > If the issue is getting a signal from a Web server to a client, > there's approximately 100 ways to get notifications from the server to > the client using HTTP (hanging GET being one of them). I thought that COMET-like polling is inefficient. Hanging GETs require server resources to hold a TCP session o open. Firewalls and IE7 time out a GET after 30-60 seconds. > Now that WS is getting standardized, there will be 101. > 101st, seems to be a solution, I agree. But it has not finished standardization, while SIP has. Igor --------------090203040201040906070206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/08/11 16:54, Igor Faynberg wrote:
...

If the issue is getting a signal from a Web server to a client, there's approximately 100 ways to get notifications from the server to the client using HTTP (hanging GET being one of them).

I thought  that COMET-like polling is inefficient. Hanging GETs require server resources to hold a TCP session o open. Firewalls and IE7 time out  a GET after 30-60 seconds.

Now that WS is getting standardized, there will be 101.


 101st, seems to be a solution, I agree.  But it has not finished standardization, while SIP has.

Igor
--------------090203040201040906070206-- From juberti@google.com Thu Sep 8 12: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 0B66D21F8B9E for ; Thu, 8 Sep 2011 12:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.657 X-Spam-Level: X-Spam-Status: No, score=-105.657 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-lNFFbeBuq8 for ; Thu, 8 Sep 2011 12:28:22 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6125021F8B80 for ; Thu, 8 Sep 2011 12:28:22 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p88JUE9u013884 for ; Thu, 8 Sep 2011 12:30:14 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315510215; bh=pHn668N//xYKqo5ZWyFY4LsXz3I=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=eMAk6m4EY2HJ3fA+Mfja4qtXEg1HNFCxZFw/bdMO4LfSAkXtUD+BM2rHxlTuqkfEu iqmzkUJ5TUlxkosfOGMhA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=vCPsp4XTMMN1Nu9URBdhWf+SvePNywOMaPF8+Ff3uIv9zvF4qCjPu0Zg1fGPC7Mjz wD4FrAQW9M7ORZpRNpFjg== Received: from ywa17 (ywa17.prod.google.com [10.192.1.17]) by wpaz24.hot.corp.google.com with ESMTP id p88JTjqt024162 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 8 Sep 2011 12:30:13 -0700 Received: by ywa17 with SMTP id 17so1105815ywa.41 for ; Thu, 08 Sep 2011 12:30:13 -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; bh=o/PoeiPjeXlnNuJdFG60VgEv1n2BufCvkdhfIvJAW7M=; b=v1yOIhPQc+7GQRmBYNvcQD5NJenJPZWaXnH+LXFQr44GR4vmaKHuSbwmk2x8AAvtPs 0E7WYMBxyFxlM7vTPtzg== Received: by 10.231.26.68 with SMTP id d4mr967632ibc.66.1315510213419; Thu, 08 Sep 2011 12:30:13 -0700 (PDT) Received: by 10.231.26.68 with SMTP id d4mr967623ibc.66.1315510213190; Thu, 08 Sep 2011 12:30:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.36.10 with HTTP; Thu, 8 Sep 2011 12:29:52 -0700 (PDT) In-Reply-To: <4E6915F2.5000007@alcatel-lucent.com> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <4E68CB68.3020100@alcatel-lucent.com> <4E68D182.2090003@alvestrand.no> <4E68D742.4010203@alcatel-lucent.com> <4E68D8B5.7010602@alvestrand.no> <4E6915F2.5000007@alcatel-lucent.com> From: Justin Uberti Date: Thu, 8 Sep 2011 15:29:52 -0400 Message-ID: To: igor.faynberg@alcatel-lucent.com Content-Type: multipart/alternative; boundary=001517740478f4a27e04ac731641 X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 19:28:23 -0000 --001517740478f4a27e04ac731641 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 8, 2011 at 3:22 PM, Igor Faynberg < igor.faynberg@alcatel-lucent.com> wrote: > ** > > On 09/08/11 16:54, Igor Faynberg wrote: > ... > > > If the issue is getting a signal from a Web server to a client, there's > approximately 100 ways to get notifications from the server to the client > using HTTP (hanging GET being one of them). > > > I thought that COMET-like polling is inefficient. Hanging GETs > require server resources to hold a TCP session o open. Firewalls and IE7 > time out a GET after 30-60 seconds. > In that case, you start a new hanging GET. If Gmail can work using this approach, telephony applications should be able to use it too. > > > Now that WS is getting standardized, there will be 101. > > > 101st, seems to be a solution, I agree. But it has not finished > standardization, while SIP has. > I would argue that WebSocket is considerably more mature than WebRTC. > > Igor > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001517740478f4a27e04ac731641 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 8, 2011 at 3:22 PM, Igor Fay= nberg <igor.faynberg@alcatel-lucent.com> wrote:
=20 =20 =20
On 09/08/11 16:54, Igor Faynberg wrote:
...

If the issue is getting a signal from a Web server to a client, there's approximately 100 ways to get notifications from the server to the client using HTTP (hanging GET being one of them).
I thought=C2=A0 that COMET-like polling is inefficient. Hanging GETs require=C2=A0serv= er resources to hold a TCP session o open. Firewalls and IE7 time out=C2=A0 a GET after 30-60 seconds.
In that case, you start a new hanging GET. If Gmail can work u= sing this approach, telephony applications should be able to use it too.
<= div class=3D"im">

Now that WS is getting standardized, there will be 101.


=C2=A0101st, seems to be a solution, I agree. =C2=A0But it has not fini= shed standardization, while SIP has.

<= div>I would argue that WebSocket is considerably more mature than WebRTC.

Igor

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


--001517740478f4a27e04ac731641-- From stpeter@stpeter.im Thu Sep 8 12: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 59B1E21F8B05 for ; Thu, 8 Sep 2011 12:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ePAnOthHCwZB for ; Thu, 8 Sep 2011 12:49:42 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AEB8021F8744 for ; Thu, 8 Sep 2011 12:49:42 -0700 (PDT) Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 53AF540E87; Thu, 8 Sep 2011 13:54:35 -0600 (MDT) Message-ID: <4E691CC6.9050905@stpeter.im> Date: Thu, 08 Sep 2011 13:51:34 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <4E68CB68.3020100@alcatel-lucent.com> <4E68D182.2090003@alvestrand.no> <4E68D742.4010203@alcatel-lucent.com> <4E68D8B5.7010602@alvestrand.no> <4E6915F2.5000007@alcatel-lucent.com> In-Reply-To: <4E6915F2.5000007@alcatel-lucent.com> X-Enigmail-Version: 1.3.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 08 Sep 2011 19:49:43 -0000 On 9/8/11 1:22 PM, Igor Faynberg wrote: >> On 09/08/11 16:54, Igor Faynberg wrote: >> ... > >> If the issue is getting a signal from a Web server to a client, >> there's approximately 100 ways to get notifications from the server to >> the client using HTTP (hanging GET being one of them). > > I thought that COMET-like polling is inefficient. Hanging GETs > require server resources to hold a TCP session o open. Firewalls and IE7 > time out a GET after 30-60 seconds. > >> Now that WS is getting standardized, there will be 101. >> > > 101st, seems to be a solution, I agree. But it has not finished > standardization, draft-ietf-hybi-thewebsocketprotocol is close to approve as a Proposed Standard (discussed on this morning's IESG telechat, still a few issues to clean up). Not that PS means finalization. > while SIP has. SIP is not a full Standard. rfc3261bis, anyone? ;-) Peter -- Peter Saint-Andre https://stpeter.im/ From igor.faynberg@alcatel-lucent.com Thu Sep 8 16:55: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 A58A021F89BA for ; Thu, 8 Sep 2011 16:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.603 X-Spam-Level: X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 CwCeIMrTuSSZ for ; Thu, 8 Sep 2011 16:55:09 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 153E021F86A0 for ; Thu, 8 Sep 2011 16:55:08 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p88NuwQ1018685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Sep 2011 18:56:59 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p88Nuv0X004769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Sep 2011 18:56:58 -0500 Received: from [135.244.18.36] (faynberg.lra.lucent.com [135.244.18.36]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p88Nuu1p012723; Thu, 8 Sep 2011 18:56:56 -0500 (CDT) Message-ID: <4E695648.2000001@alcatel-lucent.com> Date: Thu, 08 Sep 2011 19:56:56 -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: Peter Saint-Andre References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <4E68CB68.3020100@alcatel-lucent.com> <4E68D182.2090003@alvestrand.no> <4E68D742.4010203@alcatel-lucent.com> <4E68D8B5.7010602@alvestrand.no> <4E6915F2.5000007@alcatel-lucent.com> <4E691CC6.9050905@stpeter.im> In-Reply-To: <4E691CC6.9050905@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 23:55:09 -0000 According to Article 37 of Geneva Conventions, I am raising a white flag and requesting a 24-hour truce to collect dead and wounded. I will return to my trench at the expiration of the truce. Igor Peter Saint-Andre wrote: > ... > draft-ietf-hybi-thewebsocketprotocol is close to approve as a Proposed > Standard (discussed on this morning's IESG telechat, still a few issues > to clean up). Not that PS means finalization. > >> while SIP has. > SIP is not a full Standard. rfc3261bis, anyone? ;-) > > Peter > From oej@edvina.net Thu Sep 8 23:07: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 9174A21F8781 for ; Thu, 8 Sep 2011 23:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ZLWLbKiQ+6CJ for ; Thu, 8 Sep 2011 23:07:30 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id B230D21F86FF for ; Thu, 8 Sep 2011 23:07:30 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 424FE754BCE5 for ; Fri, 9 Sep 2011 06:09:21 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Sep 2011 08:09:20 +0200 Message-Id: To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [rtcweb] Yesterday's meeting : Security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 06:07:31 -0000 http://www.ietf.org/proceedings/82/slides/rtcweb-7.pdf In the webex meeting yesterday Eric Rescorla delivered a good = presentation of some of the security aspects involved in the = applications that will be built with webrtc/rtcweb technology. Some of the issues he raises are application specific, some goes into = w3c territory and some belongs in this group. The important question = here is the impact of the rtcweb framework. Can we create hooks that = help application developers? Is there a need to integrate security = mechanisms somehow?=20 Like: Does the media system need to be aware of the security properties = (certificate chain, ssl state) of the HTTP connection? Does the app need = to handle the media encryption keys at all or should we hide it from the = app developer and the web server?=20 Please read Eric's presentation and think. Maybe you can add a scenario = here too. /O= From stefan.lk.hakansson@ericsson.com Thu Sep 8 23:49: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 2AEBE21F8B82 for ; Thu, 8 Sep 2011 23:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.316 X-Spam-Level: X-Spam-Status: No, score=-6.316 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 kwyi3BXO6wte for ; Thu, 8 Sep 2011 23:49:54 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E661721F8A96 for ; Thu, 8 Sep 2011 23:49:53 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-30-4e69b782a269 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 09.66.20773.287B96E4; Fri, 9 Sep 2011 08:51:46 +0200 (CEST) Received: from [150.132.141.36] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 08:51:46 +0200 Message-ID: <4E69B77E.7090205@ericsson.com> Date: Fri, 9 Sep 2011 08:51:42 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Colin Perkins Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: [rtcweb] Convey "label" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 06:49:55 -0000 Colin, there was a discussion yesterday of how to convey the Id (aka "label") of a MediaStream object when it is sent over a PeerConnection. Presumable this info would be in the SDP offer (or whatever we end up using). There was a discussion on if CNAME could be used or if we need something new. You mentioned that it would be quite easy to add a new element or attribute if we would need that. Could you explain a bit more? Stefan From oej@edvina.net Thu Sep 8 23:51: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 BBB2A21F88B6 for ; Thu, 8 Sep 2011 23:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 B8apOH5C4TE8 for ; Thu, 8 Sep 2011 23:51:54 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id CDA3121F888A for ; Thu, 8 Sep 2011 23:51:50 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 9EAF4754BCE4; Fri, 9 Sep 2011 06:53:43 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <4E69B77E.7090205@ericsson.com> Date: Fri, 9 Sep 2011 08:53:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E69B77E.7090205@ericsson.com> To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= X-Mailer: Apple Mail (2.1244.3) Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] Convey "label" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 06:51:54 -0000 9 sep 2011 kl. 08:51 skrev Stefan H=E5kansson LK: > Colin, >=20 > there was a discussion yesterday of how to convey the Id (aka "label") = of a MediaStream object when it is sent over a PeerConnection. = Presumable this info would be in the SDP offer (or whatever we end up = using). There was a discussion on if CNAME could be used or if we need = something new. >=20 > You mentioned that it would be quite easy to add a new element or = attribute if we would need that. Could you explain a bit more? Just a kind reminder that there are application specific fields that we = can use in RTCP too... /O= From csp@csperkins.org Fri Sep 9 00:05: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 32A0321F8B82 for ; Fri, 9 Sep 2011 00:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Xg-hqc+0YUrb for ; Fri, 9 Sep 2011 00:05:50 -0700 (PDT) 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 3806821F8B7A for ; Fri, 9 Sep 2011 00:05:50 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.26]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R1vBf-0001x0-mC; Fri, 09 Sep 2011 07:07:43 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: Date: Fri, 9 Sep 2011 08:07:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <56C22F41-852F-4B20-A907-1181FE77E854@csperkins.org> References: <4E69B77E.7090205@ericsson.com> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Convey "label" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 07:05:51 -0000 On 9 Sep 2011, at 07:53, Olle E. Johansson wrote: > 9 sep 2011 kl. 08:51 skrev Stefan H=E5kansson LK: >> there was a discussion yesterday of how to convey the Id (aka = "label") of a MediaStream object when it is sent over a PeerConnection. = Presumable this info would be in the SDP offer (or whatever we end up = using). There was a discussion on if CNAME could be used or if we need = something new. >>=20 >> You mentioned that it would be quite easy to add a new element or = attribute if we would need that. Could you explain a bit more? >=20 > Just a kind reminder that there are application specific fields that = we can use in RTCP too... I was actually thinking of a new RTCP SDES item type to convey the = label. --=20 Colin Perkins http://csperkins.org/ From stefan.lk.hakansson@ericsson.com Fri Sep 9 00:07: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 5EB0F21F8AD3 for ; Fri, 9 Sep 2011 00:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.316 X-Spam-Level: X-Spam-Status: No, score=-6.316 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 13jXexn9hgl8 for ; Fri, 9 Sep 2011 00:07:27 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 954CF21F8A7D for ; Fri, 9 Sep 2011 00:07:27 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-9e-4e69bba09bb8 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5F.19.20773.0ABB96E4; Fri, 9 Sep 2011 09:09:20 +0200 (CEST) Received: from [150.132.141.36] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 09:09:20 +0200 Message-ID: <4E69BB9F.5050802@ericsson.com> Date: Fri, 9 Sep 2011 09:09:19 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Colin Perkins References: <4E69B77E.7090205@ericsson.com> <56C22F41-852F-4B20-A907-1181FE77E854@csperkins.org> In-Reply-To: <56C22F41-852F-4B20-A907-1181FE77E854@csperkins.org> 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] Convey "label" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 07:07:28 -0000 On 2011-09-09 09:07, Colin Perkins wrote: > On 9 Sep 2011, at 07:53, Olle E. Johansson wrote: >> 9 sep 2011 kl. 08:51 skrev Stefan Hkansson LK: >>> there was a discussion yesterday of how to convey the Id (aka "label") of a MediaStream object when it is sent over a PeerConnection. Presumable this info would be in the SDP offer (or whatever we end up using). There was a discussion on if CNAME could be used or if we need something new. >>> >>> You mentioned that it would be quite easy to add a new element or attribute if we would need that. Could you explain a bit more? >> >> Just a kind reminder that there are application specific fields that we can use in RTCP too... > > > I was actually thinking of a new RTCP SDES item type to convey the label. Does this mean it would be conveyed by RTCP (and not by e.g. SDP)? (Sorry to ask stupid questions). > From csp@csperkins.org Fri Sep 9 00:18: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 5B58921F8669 for ; Fri, 9 Sep 2011 00:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.403 X-Spam-Level: X-Spam-Status: No, score=-103.403 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuugMYDKL79w for ; Fri, 9 Sep 2011 00:18:24 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by ietfa.amsl.com (Postfix) with ESMTP id 991E921F8538 for ; Fri, 9 Sep 2011 00:18:23 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.26]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R1vNp-0006Em-Xb; Fri, 09 Sep 2011 07:20:17 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <4E69BB9F.5050802@ericsson.com> Date: Fri, 9 Sep 2011 08:20:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E69B77E.7090205@ericsson.com> <56C22F41-852F-4B20-A907-1181FE77E854@csperkins.org> <4E69BB9F.5050802@ericsson.com> To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Convey "label" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 07:18:25 -0000 On 9 Sep 2011, at 08:09, Stefan H=E5kansson LK wrote: > On 2011-09-09 09:07, Colin Perkins wrote: >> On 9 Sep 2011, at 07:53, Olle E. Johansson wrote: >>> 9 sep 2011 kl. 08:51 skrev Stefan H=E5kansson LK: >>>> there was a discussion yesterday of how to convey the Id (aka = "label") of a MediaStream object when it is sent over a PeerConnection. = Presumable this info would be in the SDP offer (or whatever we end up = using). There was a discussion on if CNAME could be used or if we need = something new. >>>>=20 >>>> You mentioned that it would be quite easy to add a new element or = attribute if we would need that. Could you explain a bit more? >>>=20 >>> Just a kind reminder that there are application specific fields that = we can use in RTCP too... >>=20 >>=20 >> I was actually thinking of a new RTCP SDES item type to convey the = label. >=20 > Does this mean it would be conveyed by RTCP (and not by e.g. SDP)? = (Sorry to ask stupid questions). I'd guess you'd need something in SDP too, although I haven't followed = the API closely enough to be sure. I suggested a new RTCP SDES item = because the CNAME didn't seem to have quite the right semantics, but = otherwise seemed to be conveyed in the way people wanted. --=20 Colin Perkins http://csperkins.org/ From harald@alvestrand.no Fri Sep 9 00:23: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 3A0E521F872A for ; Fri, 9 Sep 2011 00:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.109 X-Spam-Level: X-Spam-Status: No, score=-108.109 tagged_above=-999 required=5 tests=[AWL=2.489, 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 3jvO3OzQXDyM for ; Fri, 9 Sep 2011 00:23:46 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC6321F8677 for ; Fri, 9 Sep 2011 00:23:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8B05E39E129 for ; Fri, 9 Sep 2011 09:25:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RZousp6jpwp for ; Fri, 9 Sep 2011 09:25:39 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 149FE39E08B for ; Fri, 9 Sep 2011 09:25:39 +0200 (CEST) Message-ID: <4E69BF72.5060908@alvestrand.no> Date: Fri, 09 Sep 2011 09:25:38 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080703050509050609000704" Subject: Re: [rtcweb] RTCweb signalling overview X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 07:23:47 -0000 This is a multi-part message in MIME format. --------------080703050509050609000704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/08/11 20:48, Olle E. Johansson wrote: > For those of you that did not participate in today's meeting, there > was an excellent overview presented by Martin Kaufman. > > It gives you an overview over the issues with signalling - to sip or > not to sip - and other issues. Do read it. > > Use the file rtcweb-3.pptx > in > http://www.ietf.org/proceedings/82/slides/ Seconded. I liked the presentation even though I don't agree with the conclusions (I prefer Cullen's set). > > /O > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------080703050509050609000704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On 09/08/11 20:48, Olle E. Johansson wrote:
For those of you that did not participate in today's meeting, there was an excellent overview presented by Martin Kaufman.

It gives you an overview over the issues with signalling - to sip or not to sip - and other issues. Do read it.


Seconded.
I liked the presentation even though I don't agree with the conclusions (I prefer Cullen's set).


/O



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

--------------080703050509050609000704-- From oej@edvina.net Fri Sep 9 00:53: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 2E50E21F85EF for ; Fri, 9 Sep 2011 00:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_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 V9HfoazV5AxD for ; Fri, 9 Sep 2011 00:53:25 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 9970521F8464 for ; Fri, 9 Sep 2011 00:53:25 -0700 (PDT) Received: from [IPv6:2001:470:1f15:d79:1426:b5c4:b598:4131] (unknown [IPv6:2001:470:1f15:d79:1426:b5c4:b598:4131]) by smtp7.webway.se (Postfix) with ESMTPA id 1DF0C754BCE4; Fri, 9 Sep 2011 07:55:17 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <56C22F41-852F-4B20-A907-1181FE77E854@csperkins.org> Date: Fri, 9 Sep 2011 09:55:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <58801C7D-AAD4-4C27-A2C2-6378AF18DBFE@edvina.net> References: <4E69B77E.7090205@ericsson.com> <56C22F41-852F-4B20-A907-1181FE77E854@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.1244.3) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Convey "label" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 07:53:26 -0000 9 sep 2011 kl. 09:07 skrev Colin Perkins: > On 9 Sep 2011, at 07:53, Olle E. Johansson wrote: >> 9 sep 2011 kl. 08:51 skrev Stefan H=E5kansson LK: >>> there was a discussion yesterday of how to convey the Id (aka = "label") of a MediaStream object when it is sent over a PeerConnection. = Presumable this info would be in the SDP offer (or whatever we end up = using). There was a discussion on if CNAME could be used or if we need = something new. >>>=20 >>> You mentioned that it would be quite easy to add a new element or = attribute if we would need that. Could you explain a bit more? >>=20 >> Just a kind reminder that there are application specific fields that = we can use in RTCP too... >=20 >=20 > I was actually thinking of a new RTCP SDES item type to convey the = label. >=20 Side note: I know we're not talking SIP, but it actually touches = Hadriel's Session ID proposal too...=20 /O= From juberti@google.com Fri Sep 9 05:57: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 B0F1321F862F for ; Fri, 9 Sep 2011 05:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.693 X-Spam-Level: X-Spam-Status: No, score=-105.693 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kdfaGi4uYvy for ; Fri, 9 Sep 2011 05:57:08 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACE621F85F6 for ; Fri, 9 Sep 2011 05:57:07 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p89Cws8c013479 for ; Fri, 9 Sep 2011 05:58:54 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315573134; bh=gTWJ0QMlCu1HMlUudet8gDRBTFA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=bkS9BWxE9S8XepMwS09K0QA3/TFcRP0VxnphJyDUgD2/Ima6nD7jYFFCCYtT0hidg ozi1WMH+kV9jAHQWV6koQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=v/HERyTMB50oMTJGo3lTIhIStUM8HsjKzQMS/wsDaWHLCDyT0wCNWwrl0K+GEJ/uU SPkhPxgemS0Ng1+0W1IxA== Received: from gwb17 (gwb17.prod.google.com [10.200.2.17]) by wpaz13.hot.corp.google.com with ESMTP id p89CwrRQ009186 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 9 Sep 2011 05:58:53 -0700 Received: by gwb17 with SMTP id 17so1604879gwb.15 for ; Fri, 09 Sep 2011 05:58:53 -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; bh=SNnUA85THEyLKp/a/VLCqChkUfOsGm5C29ZXXF8TsPU=; b=n6NJBX63DZd5aiKGPyWqVUno902813Z/IjWwt6GTFONGufcf9D5q/nSmlY8evpf1rU kEC1dca4Eg0kJktAjxbw== Received: by 10.231.74.76 with SMTP id t12mr2208435ibj.79.1315573133335; Fri, 09 Sep 2011 05:58:53 -0700 (PDT) Received: by 10.231.74.76 with SMTP id t12mr2208424ibj.79.1315573133157; Fri, 09 Sep 2011 05:58:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.36.10 with HTTP; Fri, 9 Sep 2011 05:58:32 -0700 (PDT) In-Reply-To: <58801C7D-AAD4-4C27-A2C2-6378AF18DBFE@edvina.net> References: <4E69B77E.7090205@ericsson.com> <56C22F41-852F-4B20-A907-1181FE77E854@csperkins.org> <58801C7D-AAD4-4C27-A2C2-6378AF18DBFE@edvina.net> From: Justin Uberti Date: Fri, 9 Sep 2011 08:58:32 -0400 Message-ID: To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=000e0cd4a5ec4724ec04ac81bddc X-System-Of-Record: true Cc: "rtcweb@ietf.org" , Colin Perkins Subject: Re: [rtcweb] Convey "label" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 12:57:08 -0000 --000e0cd4a5ec4724ec04ac81bddc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 9, 2011 at 3:55 AM, Olle E. Johansson wrote: > > 9 sep 2011 kl. 09:07 skrev Colin Perkins: > > > On 9 Sep 2011, at 07:53, Olle E. Johansson wrote: > >> 9 sep 2011 kl. 08:51 skrev Stefan H=C3=A5kansson LK: > >>> there was a discussion yesterday of how to convey the Id (aka "label"= ) > of a MediaStream object when it is sent over a PeerConnection. Presumable > this info would be in the SDP offer (or whatever we end up using). There = was > a discussion on if CNAME could be used or if we need something new. > >>> > >>> You mentioned that it would be quite easy to add a new element or > attribute if we would need that. Could you explain a bit more? > >> > >> Just a kind reminder that there are application specific fields that w= e > can use in RTCP too... > > > > > > I was actually thinking of a new RTCP SDES item type to convey the labe= l. > > > Side note: I know we're not talking SIP, but it actually touches Hadriel'= s > Session ID proposal too... > > It's not clear to me that we need a MediaStream to have a label, or any identifier other than CNAME, unless it's meant to be some sort of "display name" for that particular stream. If there are other expected usages of the label, I'd be interested to know what they are. --000e0cd4a5ec4724ec04ac81bddc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 9, 2011 at 3:55 AM, Olle E. = Johansson <oej@edvin= a.net> wrote:

9 sep 2011 kl. 09:07 skrev Colin Perkins:

> On 9 Sep 2011, at 07:53, Olle E. Johansson wrote:
>> 9 sep 2011 kl. 08:51 skrev Stefan H=C3=A5kansson LK:
>>> there was a discussion yesterday of how to convey the Id (aka = "label") of a MediaStream object when it is sent over a PeerConne= ction. Presumable this info would be in the SDP offer (or whatever we end u= p using). There was a discussion on if CNAME could be used or if we need so= mething new.
>>>
>>> You mentioned that it would be quite easy to add a new element= or attribute if we would need that. Could you explain a bit more?
>>
>> Just a kind reminder that there are application specific fields th= at we can use in RTCP too...
>
>
> I was actually thinking of a new RTCP SDES item type to convey the lab= el.
>
Side note: I know we're not talking SIP, but it actually touches = Hadriel's Session ID proposal too...


It's no= t clear to me that we need a MediaStream to have a label, or any identifier= other than CNAME, unless it's meant to be some sort of "display n= ame" for that particular stream. If there are other expected usages of= the label, I'd be interested to know what they are.
--000e0cd4a5ec4724ec04ac81bddc-- From keith.drage@alcatel-lucent.com Fri Sep 9 06:07: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 83EE921F8591 for ; Fri, 9 Sep 2011 06:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.834 X-Spam-Level: X-Spam-Status: No, score=-105.834 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqtcfZcDFucr for ; Fri, 9 Sep 2011 06:07:01 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 98A9021F858D for ; Fri, 9 Sep 2011 06:07:00 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p89D8fCA002356 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 9 Sep 2011 15:08:52 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 9 Sep 2011 15:08:48 +0200 From: "DRAGE, Keith (Keith)" To: Harald Alvestrand , "rtcweb@ietf.org" Date: Fri, 9 Sep 2011 15:08:46 +0200 Thread-Topic: [rtcweb] RTCweb signalling overview Thread-Index: AcxuwbOFVUfX7jiRRHeJtJuTZ9HjpQALqydQ Message-ID: References: <4E69BF72.5060908@alvestrand.no> In-Reply-To: <4E69BF72.5060908@alvestrand.no> 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_EDC0A1AE77C57744B664A310A0B23AE220BA3C91FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [rtcweb] RTCweb signalling overview X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 13:07:02 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE220BA3C91FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable With respect to question 3 in this set. As I said on the call, the requirements for what needs to be standardised b= etween the two web servers depends on whether web server A needs to know an= ything about user B, and whether web server B needs to know anything about = user A. I believe this goes beyond SDP, because it may need to be informati= on beyond the media contents, e.g. it may need to include information about= each user's capabilities and preferences. I actually have two slightly inconsistent views about this interface. Yes it does need to be standardised. I don't like the idea of fragmentation= being forced on the market because an appropriate standardised solution ha= s not been identified. No RTCWEB should not standardise it because it is out of scope of RTCWEB. Surely this is also the interface by which support of interworking with leg= acy systems has to be attained? Perhaps the easiest way out is to identify that full blow SIP is a solution= for this specific interface, and RTCWEB identifies to SIPCORE as to whethe= r there are any additional requirements that SIP cannot meet. Regards Keith ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Harald Alvestrand Sent: 09 September 2011 08:26 To: rtcweb@ietf.org Subject: Re: [rtcweb] RTCweb signalling overview On 09/08/11 20:48, Olle E. Johansson wrote: For those of you that did not participate in today's meeting, there was an = excellent overview presented by Martin Kaufman. It gives you an overview over the issues with signalling - to sip or not to= sip - and other issues. Do read it. Use the file rtcweb-3.pptx in http://www.ietf.org/proceedings/82/slides/ Seconded. I liked the presentation even though I don't agree with the conclusions (I = prefer Cullen's set). /O _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_EDC0A1AE77C57744B664A310A0B23AE220BA3C91FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

With respect to question 3 in this set= .

 

As I said on the call, the requirement= s for what needs to be standardised between the two web servers depends on whether web server A needs to know anything about user B, and whether web server B needs to know anything about user A. I believe this goes beyond SD= P, because it may need to be information beyond the media contents, e.g. it ma= y need to include information about each user’s capabilities and preferences.

 

I actually have two slightly inconsist= ent views about this interface.

 

Yes it does need to be standardised. I= don’t like the idea of fragmentation being forced on the market because an appropriate standardised solution has not been identified.

 

No RTCWEB should not standardise it because it is out of scope of RTCWEB.

 

Surely this is also the interface by w= hich support of interworking with legacy systems has to be attained?<= /span>

 

Perhaps the easiest way out is to iden= tify that full blow SIP is a solution for this specific interface, and RTCWEB identifies to SIPCORE as to whether there are any additional requirements t= hat SIP cannot meet.

 

Regards

 

Keith

 

 

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Beh= alf Of Harald Alvestrand
Sent: 09 September 2011 08:2= 6
To: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCweb signalling overview

=  

= On 09/08/11 20:48, Olle E. Johansson wrote:

= For those of you that did not participate in tod= ay's meeting, there was an excellent overview presented by Martin Kaufman. =

=  

= It gives you an overview over the issues with signalling - to sip or not to sip - and other issues. Do read it.

=  

=
Seconded.
I liked the presentation even though I don't agree with the conclusions (I prefer Cullen's set).


=  

= /O

=  

=  

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



=
 
--_000_EDC0A1AE77C57744B664A310A0B23AE220BA3C91FRMRSSXCHMBSC3d_-- From stefan.lk.hakansson@ericsson.com Fri Sep 9 06:11: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 DE29021F867E for ; Fri, 9 Sep 2011 06:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.315 X-Spam-Level: X-Spam-Status: No, score=-6.315 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 bnYPqgIuA6Ib for ; Fri, 9 Sep 2011 06:11:50 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0B46721F8660 for ; Fri, 9 Sep 2011 06:11:49 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-17-4e6a110770f5 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 71.F3.20773.7011A6E4; Fri, 9 Sep 2011 15:13:44 +0200 (CEST) Received: from [150.132.141.36] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Fri, 9 Sep 2011 15:13:43 +0200 Message-ID: <4E6A1107.8090302@ericsson.com> Date: Fri, 9 Sep 2011 15:13:43 +0200 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E69B77E.7090205@ericsson.com> <56C22F41-852F-4B20-A907-1181FE77E854@csperkins.org> <58801C7D-AAD4-4C27-A2C2-6378AF18DBFE@edvina.net> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Convey "label" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 13:11:51 -0000 On 2011-09-09 14:58, Justin Uberti wrote: > > > On Fri, Sep 9, 2011 at 3:55 AM, Olle E. Johansson > wrote: > > > 9 sep 2011 kl. 09:07 skrev Colin Perkins: > > > On 9 Sep 2011, at 07:53, Olle E. Johansson wrote: > >> 9 sep 2011 kl. 08:51 skrev Stefan Håkansson LK: > >>> there was a discussion yesterday of how to convey the Id (aka > "label") of a MediaStream object when it is sent over a > PeerConnection. Presumable this info would be in the SDP offer (or > whatever we end up using). There was a discussion on if CNAME could > be used or if we need something new. > >>> > >>> You mentioned that it would be quite easy to add a new element > or attribute if we would need that. Could you explain a bit more? > >> > >> Just a kind reminder that there are application specific fields > that we can use in RTCP too... > > > > > > I was actually thinking of a new RTCP SDES item type to convey > the label. > > > Side note: I know we're not talking SIP, but it actually touches > Hadriel's Session ID proposal too... > > > It's not clear to me that we need a MediaStream to have a label, or any > identifier other than CNAME, unless it's meant to be some sort of > "display name" for that particular stream. If there are other expected > usages of the label, I'd be interested to know what they are. The main purpose of an identifier of MediaStream's I see is to be able to reference them after transport over a PeerConnection. If several MediaStreams are sent over a PC, you need to be able to reference them - all the receiving app gets is "addstream" events. Of course you could add them one by one in a determined order, but that would mean that set up takes longer than required. I'm not sure CNAME can fulfill this purpose in all cases or not. From oej@edvina.net Fri Sep 9 06:22: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 00E9021F8997 for ; Fri, 9 Sep 2011 06:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_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 lh1outllXta7 for ; Fri, 9 Sep 2011 06:22:30 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF4D21F8591 for ; Fri, 9 Sep 2011 06:22:30 -0700 (PDT) Received: from [IPv6:2001:470:1f15:d79:1426:b5c4:b598:4131] (unknown [IPv6:2001:470:1f15:d79:1426:b5c4:b598:4131]) by smtp7.webway.se (Postfix) with ESMTPA id C59F0754BCE4; Fri, 9 Sep 2011 13:24:21 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: "Olle E. Johansson" In-Reply-To: Date: Fri, 9 Sep 2011 15:24:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <59F2188C-109B-4FDF-AAF0-6F90849F2F7F@edvina.net> References: <4E69BF72.5060908@alvestrand.no> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1244.3) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCweb signalling overview X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 13:22:31 -0000 9 sep 2011 kl. 15:08 skrev DRAGE, Keith (Keith): > With respect to question 3 in this set. > =20 > As I said on the call, the requirements for what needs to be = standardised between the two web servers depends on whether web server A = needs to know anything about user B, and whether web server B needs to = know anything about user A. I believe this goes beyond SDP, because it = may need to be information beyond the media contents, e.g. it may need = to include information about each user=92s capabilities and preferences. > =20 > I actually have two slightly inconsistent views about this interface. How good it feels to not be alone and confused :-) > =20 > Yes it does need to be standardised. I don=92t like the idea of = fragmentation being forced on the market because an appropriate = standardised solution has not been identified. Exactly. > =20 > No RTCWEB should not standardise it because it is out of scope of = RTCWEB. Yes, agree. > =20 > Surely this is also the interface by which support of interworking = with legacy systems has to be attained? Well, if the app developer wants to interface legacy systems. The = important thing for rtcweb is to understand whether access to legacy = systems affects the rtcweb architecture if the signalling is removed = from scope. > =20 > Perhaps the easiest way out is to identify that full blow SIP is a = solution for this specific interface, and RTCWEB identifies to SIPCORE = as to whether there are any additional requirements that SIP cannot = meet. In addition, I see XMPP to be a solution for that specific interface = too...=20 /O > =20 > Regards > =20 > Keith > =20 > =20 > =20 > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Harald Alvestrand > Sent: 09 September 2011 08:26 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] RTCweb signalling overview > =20 > On 09/08/11 20:48, Olle E. Johansson wrote: > For those of you that did not participate in today's meeting, there = was an excellent overview presented by Martin Kaufman. > =20 > It gives you an overview over the issues with signalling - to sip or = not to sip - and other issues. Do read it. > =20 > Use the file rtcweb-3.pptx in = http://www.ietf.org/proceedings/82/slides/ >=20 > Seconded. > I liked the presentation even though I don't agree with the = conclusions (I prefer Cullen's set). >=20 >=20 > =20 > /O > =20 > =20 > =20 > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From mperumal@cisco.com Fri Sep 9 06:23: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 CE08921F8A7B for ; Fri, 9 Sep 2011 06:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.373 X-Spam-Level: X-Spam-Status: No, score=-10.373 tagged_above=-999 required=5 tests=[AWL=0.225, 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 txpECTy6Gqu6 for ; Fri, 9 Sep 2011 06:23:34 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5C821F8997 for ; Fri, 9 Sep 2011 06:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=39225; q=dns/txt; s=iport; t=1315574727; x=1316784327; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=wzZetMKpiyv5ayFcczEphJMVTJr520xUuJRL4D1AFSM=; b=jb7ImY56cBxVmRQTTojMhLWLcEZQd2rppLUKHNPrhsWLwVsdM1HLS0s2 mtN7JwRwYymmBdvQIs2yAz2MuQrVxmd4giRRt54PZjqsHyXVQpiZmL5fY 78anaQPELQDzvplGMmtP6gYnWq4mdx4ZXNj/TwfBYN0RIzWkPaIleaeEJ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0AALESak5Io8UT/2dsb2JhbAA3CoJNliqPGHiBUgEBAQEDAQEBDwEJEQM+GwIBCBEEAQELBhABBgEGASUBHwkIAQEEAQoHAQgBEgeHWJkvAZ5Tg0eCR2AEh2uQa4wE X-IronPort-AV: E=Sophos;i="4.68,356,1312156800"; d="scan'208,217";a="114720018" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 09 Sep 2011 13:25:25 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p89DPOKr027096; Fri, 9 Sep 2011 13:25:24 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); Fri, 9 Sep 2011 18:55:24 +0530 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6EF3.EE25D19E" Date: Fri, 9 Sep 2011 18:55:19 +0530 Message-ID: <1D062974A4845E4D8A343C653804920206557F48@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] RTCweb signalling overview Thread-Index: AcxuwbOFVUfX7jiRRHeJtJuTZ9HjpQALqydQAACotHA= References: <4E69BF72.5060908@alvestrand.no> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "DRAGE, Keith (Keith)" , "Harald Alvestrand" , X-OriginalArrivalTime: 09 Sep 2011 13:25:24.0416 (UTC) FILETIME=[EE7CB400:01CC6EF3] Subject: Re: [rtcweb] RTCweb signalling overview X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 13:23:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC6EF3.EE25D19E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable |Perhaps the easiest way out is to identify that full=20 |blow SIP is a solution for this specific interface,=20 |and RTCWEB identifies to SIPCORE as to whether there=20 |are any additional requirements that SIP cannot meet. =20 Doesn't this federated SIP suffer from the same problems VIPR is trying to solve? Of course, the alternative is to choose SIP trunk providers and go through SBCs and PSTN -:) =20 Muthu =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Friday, September 09, 2011 6:39 PM To: Harald Alvestrand; rtcweb@ietf.org Subject: Re: [rtcweb] RTCweb signalling overview =20 With respect to question 3 in this set. =20 As I said on the call, the requirements for what needs to be standardised between the two web servers depends on whether web server A needs to know anything about user B, and whether web server B needs to know anything about user A. I believe this goes beyond SDP, because it may need to be information beyond the media contents, e.g. it may need to include information about each user's capabilities and preferences. =20 I actually have two slightly inconsistent views about this interface. =20 Yes it does need to be standardised. I don't like the idea of fragmentation being forced on the market because an appropriate standardised solution has not been identified.=20 =20 No RTCWEB should not standardise it because it is out of scope of RTCWEB. =20 Surely this is also the interface by which support of interworking with legacy systems has to be attained? =20 Perhaps the easiest way out is to identify that full blow SIP is a solution for this specific interface, and RTCWEB identifies to SIPCORE as to whether there are any additional requirements that SIP cannot meet. =20 Regards =20 Keith =20 =20 =20 ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: 09 September 2011 08:26 To: rtcweb@ietf.org Subject: Re: [rtcweb] RTCweb signalling overview =20 On 09/08/11 20:48, Olle E. Johansson wrote:=20 For those of you that did not participate in today's meeting, there was an excellent overview presented by Martin Kaufman.=20 =20 It gives you an overview over the issues with signalling - to sip or not to sip - and other issues. Do read it. =20 Use the file rtcweb-3.pptx in http://www.ietf.org/proceedings/82/slides/ Seconded. I liked the presentation even though I don't agree with the conclusions (I prefer Cullen's set). =20 /O =20 =20 =20 =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------_=_NextPart_001_01CC6EF3.EE25D19E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

|Perhaps the easiest way out is to identify that full

|blow SIP is a solution for this specific interface,

|and RTCWEB identifies to SIPCORE as to whether there

|are any additional requirements that SIP cannot meet.

 

Doesn't this federated SIP suffer from the same problems VIPR is trying to solve? Of course, the alternative is to choose SIP trunk = providers and go through SBCs and PSTN -:)

 

Muthu

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of DRAGE, Keith = (Keith)
Sent: Friday, September 09, 2011 6:39 PM
To: Harald Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] RTCweb signalling = overview

 

With respect to question 3 in this = set.

 

As I said on the call, the = requirements for what needs to be standardised between the two web servers depends on = whether web server A needs to know anything about user B, and whether web server = B needs to know anything about user A. I believe this goes beyond SDP, = because it may need to be information beyond the media contents, e.g. it may need = to include information about each user’s capabilities and = preferences.

 

I actually have two slightly = inconsistent views about this interface.

 

Yes it does need to be standardised. = I don’t like the idea of fragmentation being forced on the market = because an appropriate standardised solution has not been identified. =

 

No RTCWEB should not standardise it = because it is out of scope of RTCWEB.

 

Surely this is also the interface by = which support of interworking with legacy systems has to be = attained?

 

Perhaps the easiest way out is to = identify that full blow SIP is a solution for this specific interface, and RTCWEB identifies to SIPCORE as to whether there are any additional = requirements that SIP cannot meet.

 

Regards

 

Keith

 

 

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald = Alvestrand
Sent: 09 September 2011 08:26
To: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCweb signalling overview

 

On 09/08/11 20:48, Olle E. Johansson wrote:

For those of you that did not participate in today's meeting, there was an = excellent overview presented by Martin Kaufman.

 

It gives you an overview over the issues with signalling - to sip or not to sip - = and other issues. Do read it.

 


Seconded.
I liked the presentation even though I don't agree with the conclusions = (I prefer Cullen's set).

 

/O

 

 

 
 
_______________________________________=
________
rtcweb mailing =
list
rtcweb@ietf.org
https://www.ietf.or=
g/mailman/listinfo/rtcweb



 
------_=_NextPart_001_01CC6EF3.EE25D19E-- From SRS0=7mxL/o=32=sipsorcery.com=aaron@eigbox.net Fri Sep 9 06:54: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 5A10321F8B3E for ; Fri, 9 Sep 2011 06:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxwquSeyNaYn for ; Fri, 9 Sep 2011 06:54:06 -0700 (PDT) Received: from bosmailout03.eigbox.net (bosmailout03.eigbox.net [66.96.190.3]) by ietfa.amsl.com (Postfix) with ESMTP id 745AD21F8AFA for ; Fri, 9 Sep 2011 06:54:06 -0700 (PDT) Received: from bosmailscan17.eigbox.net ([10.20.15.17]) by bosmailout03.eigbox.net with esmtp (Exim) id 1R21Ym-0004Cl-MR for rtcweb@ietf.org; Fri, 09 Sep 2011 09:56:00 -0400 Received: from bosimpout01.eigbox.net ([10.20.55.1]) by bosmailscan17.eigbox.net with esmtp (Exim) id 1R21Yl-0000Bs-FA for rtcweb@ietf.org; Fri, 09 Sep 2011 09:55:59 -0400 Received: from bosauthsmtp09.eigbox.net ([10.20.18.9]) by bosimpout01.eigbox.net with NO UCE id Wdvz1h00B0BkY8i01dvzsg; Fri, 09 Sep 2011 09:55:59 -0400 X-EN-OrigOutIP: 10.20.18.9 X-EN-IMPSID: Wdvz1h00B0BkY8i01dvzsg Received: from cpe-124-179-251-248.lns3.dav.bigpond.net.au ([124.179.251.248] helo=AaronPC) by bosauthsmtp09.eigbox.net with esmtpa (Exim) id 1R21Yk-0003Ki-8S for rtcweb@ietf.org; Fri, 09 Sep 2011 09:55:59 -0400 From: "Aaron Clauson" To: References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <4E68CB68.3020100@alcatel-lucent.com> <4E68D182.2090003@alvestrand.no> <4E68D742.4010203@alcatel-lucent.com> <4E68D8B5.7010602@alvestrand.no> <4E6915F2.5000007@alcatel-lucent.com> <4E691CC6.9050905@stpeter.im> <4E695648.2000001@alcatel-lucent.com> In-Reply-To: <4E695648.2000001@alcatel-lucent.com> Date: Fri, 9 Sep 2011 23:55:49 +1000 Message-ID: <017201cc6ef8$33f571d0$9be05570$@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: AcxugwPGZZwx2t5GRiO1eoON13qQJAAcqVZQ Content-Language: en-au X-EN-UserInfo: 915df896000ea0661f52ada7de781755:376581c79ab009618cc3d679a775619e X-EN-AuthUser: aaron@sipsorcery.com Sender: "Aaron Clauson" X-EN-OrigIP: 124.179.251.248 X-EN-OrigHost: cpe-124-179-251-248.lns3.dav.bigpond.net.au Subject: Re: [rtcweb] SIP MUST NOT be used 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: Fri, 09 Sep 2011 13:57:13 -0000 Another 2 cents from a SIP person. I think attempting to incorporate SIP (or Jingle et al) into RTCWeb would be a bad idea for the reason that it would significantly slow down and complicate the standard. If SIP is included in RTCWeb then there will need to be a discussion, already emerging here, about which parts of SIP to include and all the other intricacies of SIP; transports, sips vs sip, request routing etc etc. Writing a javascript SIP stack is a small task compared to getting the RTCWeb media capabilities built into browsers. As soon as the first browser appears that supports RTP then javascript SIP stacks will start popping up all over the place. I for one would love to be able to process calls in my browser and to be able to do it yesterday. Slowing the RTCWeb process down for something that will take care of itself anyway, namely readily available javascript signalling libraries, would be a shame. Aaron From mary.ietf.barnes@gmail.com Fri Sep 9 08:50: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 7874321F8A67 for ; Fri, 9 Sep 2011 08:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.461 X-Spam-Level: X-Spam-Status: No, score=-103.461 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blf9DDA1EMlx for ; Fri, 9 Sep 2011 08:50:28 -0700 (PDT) Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id 256A521F85D1 for ; Fri, 9 Sep 2011 08:50:28 -0700 (PDT) Received: by vws10 with SMTP id 10so1026393vws.16 for ; Fri, 09 Sep 2011 08:52:23 -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=ywB0V/3KOkzANjgVXd2ww9MK1RjntW54ZFh693dU/FQ=; b=dzc3whA7flWhiwcETxUl2jdcG2TwZVoeb3hI2OdaGDwwqg1CD/FpxU9wZFjjEM8jko XGleRnvLHWUUaZTlWsK7n8HfXOhLrn9ZN1pX9/RXUuskYsL25KmZjEUsT4WSWr2MFmHH WWtDuQpaNpKPXfPBQivUfLkZsJVV7Qct6+PKg= MIME-Version: 1.0 Received: by 10.52.70.100 with SMTP id l4mr771480vdu.23.1315583543128; Fri, 09 Sep 2011 08:52:23 -0700 (PDT) Received: by 10.52.35.2 with HTTP; Fri, 9 Sep 2011 08:52:23 -0700 (PDT) In-Reply-To: <1D062974A4845E4D8A343C653804920206557F48@XMB-BGL-414.cisco.com> References: <4E69BF72.5060908@alvestrand.no> <1D062974A4845E4D8A343C653804920206557F48@XMB-BGL-414.cisco.com> Date: Fri, 9 Sep 2011 10:52:23 -0500 Message-ID: From: Mary Barnes To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: multipart/alternative; boundary=20cf307ac75fc2b0d504ac8429a8 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCweb signalling overview X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 15:50:29 -0000 --20cf307ac75fc2b0d504ac8429a8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, federated SIP certainly has the problems that VIPR is intended to solve. And, of course, without VIPR or without SPs supporting Federations and/or ENUM, the only choice is to interwork via the PSTN. However, given that there are multiple solutions for SIP based federation, it makes sense to not reinvent the wheel and trying to suggest that you only need a subset of SIP for this interface is a slipperly slope as has already been suggested. And, of course, using SIP as is on this interface facilitates interworking in cases where the Web Server is interfacing to a "legacy" SIP Server. As an aside, I think it's silly to refer to the SIP protocol developed by the IETF as "legacy". I don't think the intent of RTCWEB is to marginalize SIP. As Keith suggests, it may be that some additional information needs to be passed over that interface to support RTCWEB, but I would hope that would not require core SIP changes. Mary. On Fri, Sep 9, 2011 at 8:25 AM, Muthu Arul Mozhi Perumal (mperumal) < mperumal@cisco.com> wrote: > |Perhaps the easiest way out is to identify that full **** > > |blow SIP is a solution for this specific interface, **** > > |and RTCWEB identifies to SIPCORE as to whether there **** > > |are any additional requirements that SIP cannot meet.**** > > ** ** > > Doesn't this federated SIP suffer from the same problems VIPR is trying t= o > solve? Of course, the alternative is to choose SIP trunk providers and go > through SBCs and PSTN -:)**** > > ** ** > > Muthu**** > > ** ** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *DRAGE, Keith (Keith) > *Sent:* Friday, September 09, 2011 6:39 PM > *To:* Harald Alvestrand; rtcweb@ietf.org > > *Subject:* Re: [rtcweb] RTCweb signalling overview**** > > ** ** > > With respect to question 3 in this set.**** > > ** ** > > As I said on the call, the requirements for what needs to be standardised > between the two web servers depends on whether web server A needs to know > anything about user B, and whether web server B needs to know anything ab= out > user A. I believe this goes beyond SDP, because it may need to be > information beyond the media contents, e.g. it may need to include > information about each user=92s capabilities and preferences.**** > > ** ** > > I actually have two slightly inconsistent views about this interface.**** > > ** ** > > Yes it does need to be standardised. I don=92t like the idea of fragmenta= tion > being forced on the market because an appropriate standardised solution h= as > not been identified. **** > > ** ** > > No RTCWEB should not standardise it because it is out of scope of RTCWEB.= * > *** > > ** ** > > Surely this is also the interface by which support of interworking with > legacy systems has to be attained?**** > > ** ** > > Perhaps the easiest way out is to identify that full blow SIP is a soluti= on > for this specific interface, and RTCWEB identifies to SIPCORE as to wheth= er > there are any additional requirements that SIP cannot meet.**** > > ** ** > > Regards**** > > ** ** > > Keith**** > > ** ** > > ** ** > > ** ** > ------------------------------ > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Harald Alvestrand > *Sent:* 09 September 2011 08:26 > *To:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] RTCweb signalling overview**** > > ** ** > > On 09/08/11 20:48, Olle E. Johansson wrote: **** > > For those of you that did not participate in today's meeting, there was a= n > excellent overview presented by Martin Kaufman. **** > > ** ** > > It gives you an overview over the issues with signalling - to sip or not = to > sip - and other issues. Do read it.**** > > ** ** > > Use the file rtcweb-3.pptx > in http://www.ietf.org/proceedings/82/slides/**** > > > Seconded. > I liked the presentation even though I don't agree with the conclusions (= I > prefer Cullen's set). > ** > ****** > > ** ** > > /O**** > > ** ** > > ** ** > > ** ** > > ** ** > > _______________________________________________**** > > 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 > > --20cf307ac75fc2b0d504ac8429a8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, federated SIP certainly has the problems that VIPR is intended to solv= e. =A0And, of course, without VIPR or without SPs supporting Federations an= d/or ENUM, the only choice is to interwork via the PSTN. =A0However, given = that there are multiple solutions for SIP based federation, it makes sense = to not reinvent the wheel and trying to suggest that you only need a subset= of SIP for this interface is a slipperly slope as has already been suggest= ed. And, of course, using SIP as is on this interface facilitates interwork= ing in cases where the Web Server is interfacing to a "legacy" SI= P Server. =A0As an aside, I think it's silly to refer to the SIP protoc= ol developed by the IETF as "legacy". =A0 I don't think the i= ntent of RTCWEB is to marginalize SIP. =A0 As Keith suggests, it may be tha= t some additional information needs to be passed over that interface to sup= port RTCWEB, but I would hope that would not require core SIP changes.=A0
Mary.=A0

On Fri, Sep 9, 20= 11 at 8:25 AM, Muthu Arul Mozhi Perumal (mperumal) <mperumal@cisco.com> wrote= :

|Perhaps the easiest way out is to identify that full

|blow SIP is a solution for this specific interface,

|and RTCWEB identifies to SIPCORE as to whether there

|are any additional requirements that SIP cannot meet.

=A0

Doesn't this federated SIP suffer from the same problems VIPR is trying to solve? Of course, the alternative is to choose SIP trunk provi= ders and go through SBCs and PSTN -:)

=A0

Muthu

=A0

From: rtcweb-bounces@ietf.o= rg [mailto:rtcweb= -bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: Friday, September 09, 2011 6:39 PM
To: Harald Alvestrand; rtcweb@ietf.org


Subject: Re: [rtcweb] RTCweb signalling overview
=

=A0

With respect to question 3 in this set.

=A0

As I said on the call, the requirements for what needs to be standardised between the two web servers depends on whethe= r web server A needs to know anything about user B, and whether web server B needs to know anything about user A. I believe this goes beyond SDP, becaus= e it may need to be information beyond the media contents, e.g. it may need to include information about each user=92s capabilities and preferences.

=A0

I actually have two slightly inconsistent views about this interface.

=A0

Yes it does need to be standardised. I don=92t like the idea of fragmentation being forced on the market because an appropriate standardised solution has not been identified.

=A0

No RTCWEB should not standardise it because it is out of scope of RTCWEB.

=A0

Surely this is also the interface by which support of interworking with legacy systems has to be attained?

=A0

Perhaps the easiest way out is to identify that full blow SIP is a solution for this specific interface, and RTCWEB identifies to SIPCORE as to whether there are any additional requirements t= hat SIP cannot meet.

=A0

Regards

=A0

Keith

=A0

=A0

=A0

From: rtcweb-bounces@ietf.o= rg [mailto:rtcweb= -bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: 09 September 2011 08:26
To: rtcweb@ietf= .org
Subject: Re: [rtcweb] RTCweb signalling overview

=A0

On 09/08/11 20:48, Olle E. Johansson wrote:

For those of you that did not participate in today's meeting, there was an excell= ent overview presented by Martin Kaufman.

=A0

It gives you an overview over the issues with signalling - to sip or not to sip - an= d other issues. Do read it.

=A0

=
Seconded.
I liked the presentation even though I don't agree with the conclusions= (I prefer Cullen's set).

=A0

/O

=A0

=A0

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



=A0

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


--20cf307ac75fc2b0d504ac8429a8-- From juberti@google.com Fri Sep 9 09:13: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 5396D21F8B9F for ; Fri, 9 Sep 2011 09:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.738 X-Spam-Level: X-Spam-Status: No, score=-104.738 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WfU5rhAgK0x for ; Fri, 9 Sep 2011 09:13:24 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2E121F8B9C for ; Fri, 9 Sep 2011 09:13:23 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p89GFITX007385 for ; Fri, 9 Sep 2011 09:15:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315584918; bh=zEpiMyZi598NFN6fNWripUqd7AI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=s0o/IRsLt/RQr+eCvQONvEiNZjQQdolbCpKPgJMBBiOcV3Bqkvgw84NHqZc+dKwAR n6a4/m8Q+jTTpAzPqTeWA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=O6RP6OdvrSMfb2npZFgeiXEnrPAUv6JCWch/FOflahiPY7KhhVlMrkKK2TPR6sRUR uR7VMRLDsUIHpVXhEdnbw== Received: from gyf2 (gyf2.prod.google.com [10.243.50.66]) by hpaq12.eem.corp.google.com with ESMTP id p89GE79l018798 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 9 Sep 2011 09:15:16 -0700 Received: by gyf2 with SMTP id 2so2073350gyf.13 for ; Fri, 09 Sep 2011 09:15:16 -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; bh=G5L3oZcFAmI5P3AKdN3ye6IrRKY6uNaqseAQ8WHc37A=; b=o5aFPLPGk02LoxULZjU8Wuonb+3ON6q+6pQSgCVnrYIA6VM5TXhRsd7hqHx5vVgyQ/ XYavruNwARsEQNRgWM2Q== Received: by 10.42.134.2 with SMTP id j2mr1212791ict.149.1315584916496; Fri, 09 Sep 2011 09:15:16 -0700 (PDT) Received: by 10.42.134.2 with SMTP id j2mr1212786ict.149.1315584916265; Fri, 09 Sep 2011 09:15:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.36.10 with HTTP; Fri, 9 Sep 2011 09:14:56 -0700 (PDT) In-Reply-To: <4E6A1107.8090302@ericsson.com> References: <4E69B77E.7090205@ericsson.com> <56C22F41-852F-4B20-A907-1181FE77E854@csperkins.org> <58801C7D-AAD4-4C27-A2C2-6378AF18DBFE@edvina.net> <4E6A1107.8090302@ericsson.com> From: Justin Uberti Date: Fri, 9 Sep 2011 12:14:56 -0400 Message-ID: To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= Content-Type: multipart/alternative; boundary=90e6ba6e8dba9b1b2d04ac847bd8 X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Convey "label" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 16:13:25 -0000 --90e6ba6e8dba9b1b2d04ac847bd8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 9, 2011 at 9:13 AM, Stefan H=C3=A5kansson LK < stefan.lk.hakansson@ericsson.com> wrote: > On 2011-09-09 14:58, Justin Uberti wrote: > >> >> >> On Fri, Sep 9, 2011 at 3:55 AM, Olle E. Johansson > > wrote: >> >> >> 9 sep 2011 kl. 09:07 skrev Colin Perkins: >> >> > On 9 Sep 2011, at 07:53, Olle E. Johansson wrote: >> >> 9 sep 2011 kl. 08:51 skrev Stefan H=C3=A5kansson LK: >> >>> there was a discussion yesterday of how to convey the Id (aka >> "label") of a MediaStream object when it is sent over a >> PeerConnection. Presumable this info would be in the SDP offer (or >> whatever we end up using). There was a discussion on if CNAME could >> be used or if we need something new. >> >>> >> >>> You mentioned that it would be quite easy to add a new element >> or attribute if we would need that. Could you explain a bit more? >> >> >> >> Just a kind reminder that there are application specific fields >> that we can use in RTCP too... >> > >> > >> > I was actually thinking of a new RTCP SDES item type to convey >> the label. >> > >> Side note: I know we're not talking SIP, but it actually touches >> Hadriel's Session ID proposal too... >> >> >> It's not clear to me that we need a MediaStream to have a label, or any >> identifier other than CNAME, unless it's meant to be some sort of >> "display name" for that particular stream. If there are other expected >> usages of the label, I'd be interested to know what they are. >> > The main purpose of an identifier of MediaStream's I see is to be able to > reference them after transport over a PeerConnection. If several > MediaStreams are sent over a PC, you need to be able to reference them - = all > the receiving app gets is "addstream" events. > > Of course you could add them one by one in a determined order, but that > would mean that set up takes longer than required. > > I'm not sure CNAME can fulfill this purpose in all cases or not. Right, I agree the app needs to be able to say "this video feed is for user A" and "this video feed is for user B", if for no other reason than to be able to display a user identifier underneath the appropriate video feed. However as mentioned previously I think that this implies that each feed (i.e. track) requires an identifier, not necessarily the stream. So I propose we add a unique label attribute for tracks, which is essentially a handle; this handle allows clear identification of a track, and can be passed around in application messaging if needed. We may also want to allow a non-unique display name to be provided as well. I see no harm in having MediaStream's label be the CNAME, as a portable handle for MediaStreams, but I haven't yet heard a use case where one would use this handle instead of the track handle. > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --90e6ba6e8dba9b1b2d04ac847bd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 9, 2011 at 9:13 AM, Stefan H= =C3=A5kansson LK <stefan.lk.hakansson@ericsson.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;">
On 2011-09-09 14:58, Justin Uberti wrote:


On Fri, Sep 9, 2011 at 3:55 AM, Olle E. Johansson <oej@edvina.net
=
<mailto:oej@edvina.n= et>> wrote:


=C2=A0 =C2=A09 sep 2011 kl. 09:07 skrev Colin Perkins:

=C2=A0 =C2=A0 > On 9 Sep 2011, at 07:53, Olle E. Johansson wrote:
=C2=A0 =C2=A0 >> 9 sep 2011 kl. 08:51 skrev Stefan H=C3=A5kansson LK= :
=C2=A0 =C2=A0 >>> there was a discussion yesterday of how to conv= ey the Id (aka
=C2=A0 =C2=A0"label") of a MediaStream object when it is sent ov= er a
=C2=A0 =C2=A0PeerConnection. Presumable this info would be in the SDP offe= r (or
=C2=A0 =C2=A0whatever we end up using). There was a discussion on if CNAME= could
=C2=A0 =C2=A0be used or if we need something new.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> You mentioned that it would be quite easy to ad= d a new element
=C2=A0 =C2=A0or attribute if we would need that. Could you explain a bit m= ore?
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Just a kind reminder that there are application spe= cific fields
=C2=A0 =C2=A0that we can use in RTCP too...
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I was actually thinking of a new RTCP SDES item type to= convey
=C2=A0 =C2=A0the label.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0Side note: I know we're not talking SIP, but it actually = touches
=C2=A0 =C2=A0Hadriel's Session ID proposal too...


It's not clear to me that we need a MediaStream to have a label, or any=
identifier other than CNAME, unless it's meant to be some sort of
"display name" for that particular stream. If there are other exp= ected
usages of the label, I'd be interested to know what they are.
The main purpose of an identifier of MediaStream's I see is to be able = to reference them after transport over a PeerConnection. If several MediaSt= reams are sent over a PC, you need to be able to reference them - all the r= eceiving app gets is "addstream" events.

Of course you could add them one by one in a determined order, but that wou= ld mean that set up takes longer than required.

I'm not sure CNAME can fulfill this purpose in all cases or not.

Right, I agree the app needs to be able to say &q= uot;this video feed is for user A" and "this video feed is for us= er B", if for no other reason than to be able to display a user identi= fier underneath the appropriate video feed. However as mentioned previously= I think that this implies that each feed (i.e. track) requires an identifi= er, not necessarily the stream. So I propose we add a=C2=A0unique label att= ribute for tracks, which is essentially a handle; this handle allows clear = identification of a track, and can be passed around in application messagin= g if needed. We may also want to allow a non-unique display name to be prov= ided as well.

I see no harm in having MediaStream's label be the = CNAME, as a portable handle for MediaStreams, but I haven't yet heard a= use case where one would use this handle instead of the track handle.

<= /div>


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

--90e6ba6e8dba9b1b2d04ac847bd8-- From juberti@google.com Fri Sep 9 09:29: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 C4A3021F84BC for ; Fri, 9 Sep 2011 09:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.477 X-Spam-Level: X-Spam-Status: No, score=-105.477 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vWzwq9gw1Td for ; Fri, 9 Sep 2011 09:29:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2625E21F84A5 for ; Fri, 9 Sep 2011 09:29:42 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p89GVb7Z014676 for ; Fri, 9 Sep 2011 09:31:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315585897; bh=1DkJppDrM5V6Wv2xPkH2ifwsyxY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=mGJjZSPqogYj6fVIQlAkVSaOIU1g3XzBOtqGBi6l+sxnlNsoJ3oSieGZrYLV1tG85 ESx7+2CCSGcRrimD6z7mg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=suGvJVctMUYatnC6TDhauZZx88NIqELrRFhrEb1NvbrJDtJOLWC/fWOLt3NAsPgrp 6l3zG9Tx3OuCHUU8UbkoA== Received: from gyb11 (gyb11.prod.google.com [10.243.49.75]) by wpaz21.hot.corp.google.com with ESMTP id p89GVZHs011208 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 9 Sep 2011 09:31:35 -0700 Received: by gyb11 with SMTP id 11so277535gyb.29 for ; Fri, 09 Sep 2011 09:31:35 -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; bh=1NQKjkx5IXybV00BIGxlaOFHZnAogd8Uq0QUjhK3nQA=; b=p9iF6Oww2LTfbRqWDIky0yGDrloEhl/bLBeO7xdC/rw/kLdMVPNcdeXiNOjgRsa2Ct b56m9JrVPfVUu+zV/INw== Received: by 10.42.134.2 with SMTP id j2mr1224459ict.149.1315585895666; Fri, 09 Sep 2011 09:31:35 -0700 (PDT) Received: by 10.42.134.2 with SMTP id j2mr1224431ict.149.1315585894134; Fri, 09 Sep 2011 09:31:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.36.10 with HTTP; Fri, 9 Sep 2011 09:31:14 -0700 (PDT) In-Reply-To: References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> From: Justin Uberti Date: Fri, 9 Sep 2011 12:31:14 -0400 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=90e6ba6e8dbae4344804ac84b55f X-System-Of-Record: true Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 16:29:44 -0000 --90e6ba6e8dbae4344804ac84b55f Content-Type: text/plain; charset=UTF-8 This feels like a pretty fundamental question. I thought we were getting pretty close to a consensus for the signaling mechanism with Cullen's presentation, but this seems to complicate that significantly. On Thu, Sep 8, 2011 at 8:21 AM, Jonathan Lennox wrote: > Indeed. > > More generally, the question is: should it be possible to send an offer > that by default does DTLS/SAVPF for RTCWeb, but also can fall back to other > RTP profiles to support legacy devices? > > If yes, then either browsers need to support CapNeg, or RTCWeb needs to use > something other than SDP Offer/Answer. > > If no, then supporting interop, without a media gateway, with other > non-RTCWeb modes (e.g., no ICE, no rtcp mux, no audio/video mux, etc.) > becomes IMO a lot less compelling. > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, September 08, 2011 2:35 AM > To: Randell Jesup; Jonathan Lennox > Cc: rtcweb@ietf.org > Subject: AVPF [was: [rtcweb] Encryption mandate (and offer/answer)] > > > Hi, > > >>>You could make forced-encryption the default, and allow the > >>>application control over whether to allow it is turned off for > >>>specific cases, like a PSTN call, or under the server's control. > >>>Signalling is secure, so it could even use a direct optional > >>>downgrade from SAVP* to AVP* (i.e. > >>>similar to the best-effort-strp draft) > >>This has implications for the parallel thread about the use of SDP > >>offer/answer. > >> > >>The solution MMUSIC has standardized for best-effort SRTP is SDP > >>CapNeg, RFC 5939. Do we want to require CapNeg support in browsers? > > > >Yeah, ok, I'm not going there. :-) It's probably not needed for this > >use-case anyways. > > The same question exists for AVPF, which has been suggested to be mandated. > > Regards, > > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --90e6ba6e8dbae4344804ac84b55f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This feels like a pretty fundamental question. I thought we were getting pr= etty close to a consensus for the signaling mechanism with Cullen's pre= sentation, but this seems to complicate that significantly.

On Thu, Sep 8, 2011 at 8:21 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:
Indeed.

More generally, the question is: should it be possible to send an offer tha= t by default does DTLS/SAVPF for RTCWeb, but also can fall back to other RT= P profiles to support legacy devices?

If yes, then either browsers need to support CapNeg, or RTCWeb needs to use= something other than SDP Offer/Answer.

If no, then supporting interop, without a media gateway, with other non-RTC= Web modes (e.g., no ICE, no rtcp mux, no audio/video mux, etc.) becomes IMO= a lot less compelling.

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Thursday, September 08, 2011 2:35 AM
To: Randell Jesup; Jonathan Lennox
Cc: rtcweb@ietf.org
Subject: AVPF [was: [rtcweb] Encryption mandate (and offer/answer)]


Hi,

>>>You could make forced-encryption the default, and allow the
>>>application control over whether to allow it is turned off for<= br> >>>specific cases, like a PSTN call, or under the server's con= trol.
>>>Signalling is secure, so it could even use a direct optional >>>downgrade from SAVP* to AVP* (i.e.
>>>similar to the best-effort-strp draft)
>>This has implications for the parallel thread about the use of SDP<= br> >>offer/answer.
>>
>>The solution MMUSIC has standardized for best-effort SRTP is SDP >>CapNeg, RFC 5939. =C2=A0Do we want to require CapNeg support in bro= wsers?
>
>Yeah, ok, I'm not going there. =C2=A0:-) =C2=A0It's probably no= t needed for this
>use-case anyways.

The same question exists for AVPF, which has been suggested to be mandated.=

Regards,

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

--90e6ba6e8dbae4344804ac84b55f-- From john.elwell@siemens-enterprise.com Fri Sep 9 09:40: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 CD54B21F8802 for ; Fri, 9 Sep 2011 09:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.05 X-Spam-Level: X-Spam-Status: No, score=-103.05 tagged_above=-999 required=5 tests=[AWL=-0.451, 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 STZ+IIF3SHKz for ; Fri, 9 Sep 2011 09:40:00 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id ACD1F21F86DE for ; Fri, 9 Sep 2011 09:39:59 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id B909A1EB8474 for ; Fri, 9 Sep 2011 18:41:52 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 9 Sep 2011 18:41:52 +0200 From: "Elwell, John" To: "rtcweb@ietf.org" Date: Fri, 9 Sep 2011 18:41:51 +0200 Thread-Topic: Proposed text - remote recording use case Thread-Index: AcxvD2BDwyObig+rTKql0YP/877l3Q== Message-ID: 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: [rtcweb] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 16:40:01 -0000 On yesterday's call it was agreed to work on text to cover the remote recor= ding use case. Below is text, based on an earlier proposal and subsequent i= nput. I have focused on the main requirement derived from this use case, re= lating to copying to a different peer connection, and skipped any more deta= iled requirements concerning possible mixing of the two directions of audio= or injecting any tones / announcements. 4.2.yy Remote Session Recording In this use case, the web application user wishes to record a real-time com= munication at a remote third party (e.g., a recording device), such that tr= ansmitted and received audio, video or other real-time media are transmitte= d in real-time to the third party. The third party can perform recording, a= rchiving, retrieval, playback, etc., but can also perform real-time analyti= cs on the media. A typical deployment might be in a contact centre. The web= application also sends metadata that gives context to the stored media. Th= e web application will ensure that appropriate indications are given to par= ticipants so that they are aware of recording. New requirements: Fyy1: The browser MUST be able to send in real-time to a third party media = that are being transmitted to and received from remote participants. Ayy1: The web application MUST be able to ask the browser to transmit in re= al-time to a third party media that are being transmitted to and received f= rom remote participants. Comments? John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. From dzonatas@gmail.com Fri Sep 9 10:19: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 71C6521F86AA for ; Fri, 9 Sep 2011 10:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.971 X-Spam-Level: X-Spam-Status: No, score=-3.971 tagged_above=-999 required=5 tests=[AWL=-0.372, 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 xMJ7QZnYEnka for ; Fri, 9 Sep 2011 10:19:13 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B76A121F86A1 for ; Fri, 9 Sep 2011 10:19:13 -0700 (PDT) Received: by yxt33 with SMTP id 33so379515yxt.31 for ; Fri, 09 Sep 2011 10:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=jcjB+cxwSLGVRrVopYRdKUcGoyO/GJDxRi64SCFNdiE=; b=pv0wlwJwcrypouzDJzpVkmSEUwHtp06cYCxw49rLh3f3eSVeOyPra3TJwtC1/4pN5H KQcz14ZE2xJNI03w16Z2Vi6af7ZB1CuccHFQ1S2+ug5zScCW/DE9dwgrwQsdqNwv+Res Q7tjSV96B4aTdi7AFH69MlsbywxnrAkdA4PeM= Received: by 10.68.199.67 with SMTP id ji3mr577726pbc.38.1315588868684; Fri, 09 Sep 2011 10:21:08 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id u2sm21284921pbq.9.2011.09.09.10.21.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Sep 2011 10:21:07 -0700 (PDT) Message-ID: <4E6A4B78.2010802@gmail.com> Date: Fri, 09 Sep 2011 10:23:04 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 17:19:14 -0000 On 09/09/2011 09:41 AM, Elwell, John wrote: > On yesterday's call it was agreed to work on text to cover the remote recording use case. Below is text, based on an earlier proposal and subsequent input. I have focused on the main requirement derived from this use case, relating to copying to a different peer connection, and skipped any more detailed requirements concerning possible mixing of the two directions of audio or injecting any tones / announcements. > > 4.2.yy Remote Session Recording > In this use case, the web application user wishes to record a real-time communication at a remote third party (e.g., a recording device), such that transmitted and received audio, video or other real-time media are transmitted in real-time to the third party. The third party can perform recording, archiving, retrieval, playback, etc., but can also perform real-time analytics on the media. A typical deployment might be in a contact centre. The web application also sends metadata that gives context to the stored media. The web application will ensure that appropriate indications are given to participants so that they are aware of recording. > > New requirements: > Fyy1: The browser MUST be able to send in real-time to a third party media that are being transmitted to and received from remote participants. > > Ayy1: The web application MUST be able to ask the browser to transmit in real-time to a third party media that are being transmitted to and received from remote participants. > > Comments? > Is there some specific need for the use of the words "third party"? I think that should be "modem", yet I know that word doesn't work in replace as-is. Maybe extend RFC 2198 to indicate the presence of an "audio-out" capable of modulation of SSRC media that MAY record. Does that hint on something more fair and reusable? > John > > > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ > > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. > Registered No: 5903714, England. > > Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From alan.b.johnston@gmail.com Fri Sep 9 10:46: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 E57AB21F86EC for ; Fri, 9 Sep 2011 10:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 oR4n38J6G4KN for ; Fri, 9 Sep 2011 10:46:01 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3BA21F86EA for ; Fri, 9 Sep 2011 10:46:01 -0700 (PDT) Received: by yie12 with SMTP id 12so502927yie.31 for ; Fri, 09 Sep 2011 10:47:56 -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:content-transfer-encoding; bh=N3j9QSuyYUUEhc32N/yW7IWQnGyPBtM7Rn+HRYBkEOo=; b=VT+YO8dEmsCkRpOBsaKsOkW9Rr2iX0wJPjtDXyFqFSyJ6kCJWt31qaeMYzU/y5RZeX MPfJt87/WTBHJoD+MjoJuxpgfzrNTZLSq6B938/swwKZFaP2NfgiaJs+blhV3JbDELUE nIJBkyB378LraXeTo2JrRevIdDyKsu2xSKu60= MIME-Version: 1.0 Received: by 10.150.74.9 with SMTP id w9mr2252609yba.108.1315590475235; Fri, 09 Sep 2011 10:47:55 -0700 (PDT) Received: by 10.151.7.5 with HTTP; Fri, 9 Sep 2011 10:47:55 -0700 (PDT) In-Reply-To: References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 9 Sep 2011 12:47:55 -0500 Message-ID: From: Alan Johnston To: Justin Uberti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 17:46:02 -0000 Here's my thinking on this. We have CapNeg because the default profile for VoIP and video is unfortunately insecure RTP. We also need to have a single pass offer/answer negotiation since this is what we are used to having. While I am not in favor of allowing insecure RTP in browsers, I know some feel this is a requirement. I do like Chris's suggestion that SRTP be the default, with no chrome messages trying to indicate the security of the call, but that if RTP is used, we are universally agreed that is is very insecure and the browser chrome should make it very, very clear to the user that their privacy is being disregarded by the service. If we make SRTP the default, and allow RTP, we could do the same in our signaling negotiation. The default will be SRTP - this can be expressed in SDP without CapNeg. Should the RTCWEB clients choose to instead negotiate RTP, then this could be done with a second SDP Offer/Answer exchange. This would provide yet another incentive for services to use the secure mode. A signaling gateway could support CapNeg and handle using 3PCC the AVP/SAVP negotiation outside of RTCWEB. Otherwise, if we require CapNeg in the browser, this is a large leap in complexity, and without proven interoperability and deployment of CapNeg today, a very risky proposition. - Alan - On Fri, Sep 9, 2011 at 11:31 AM, Justin Uberti wrote: > This feels like a pretty fundamental question. I thought we were getting > pretty close to a consensus for the signaling mechanism with Cullen's > presentation, but this seems to complicate that significantly. > > On Thu, Sep 8, 2011 at 8:21 AM, Jonathan Lennox wrot= e: >> >> Indeed. >> >> More generally, the question is: should it be possible to send an offer >> that by default does DTLS/SAVPF for RTCWeb, but also can fall back to ot= her >> RTP profiles to support legacy devices? >> >> If yes, then either browsers need to support CapNeg, or RTCWeb needs to >> use something other than SDP Offer/Answer. >> >> If no, then supporting interop, without a media gateway, with other >> non-RTCWeb modes (e.g., no ICE, no rtcp mux, no audio/video mux, etc.) >> becomes IMO a lot less compelling. >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Thursday, September 08, 2011 2:35 AM >> To: Randell Jesup; Jonathan Lennox >> Cc: rtcweb@ietf.org >> Subject: AVPF [was: [rtcweb] Encryption mandate (and offer/answer)] >> >> >> Hi, >> >> >>>You could make forced-encryption the default, and allow the >> >>>application control over whether to allow it is turned off for >> >>>specific cases, like a PSTN call, or under the server's control. >> >>>Signalling is secure, so it could even use a direct optional >> >>>downgrade from SAVP* to AVP* (i.e. >> >>>similar to the best-effort-strp draft) >> >>This has implications for the parallel thread about the use of SDP >> >>offer/answer. >> >> >> >>The solution MMUSIC has standardized for best-effort SRTP is SDP >> >>CapNeg, RFC 5939. =A0Do we want to require CapNeg support in browsers? >> > >> >Yeah, ok, I'm not going there. =A0:-) =A0It's probably not needed for t= his >> >use-case anyways. >> >> The same question exists for AVPF, which has been suggested to be >> mandated. >> >> Regards, >> >> Christer >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > From juberti@google.com Fri Sep 9 11:00: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 908AE21F85F7 for ; Fri, 9 Sep 2011 11:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.51 X-Spam-Level: X-Spam-Status: No, score=-105.51 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFiLwqdpN3sv for ; Fri, 9 Sep 2011 11:00:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 23AB021F85F5 for ; Fri, 9 Sep 2011 11:00:17 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p89I2ASE021892 for ; Fri, 9 Sep 2011 11:02:10 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315591331; bh=oj4Gb4HBk5bysEtTZYgHiXpUu/A=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=P01A7pPnJIdp0iKWNjbRd1eyE3HWF/2qFndW5MlX+c1zWbx71vq3HrA1GWd6LHMXX FlzDUwwoxVvjZLVSIhRAw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=qKDhKku57E2NgLHHKX+vqxYPRbNJOfk/KaET3OT/qbfs3d6RLXdARA1ttoEssieuN yL22aWTqFfrq0RFAabTNw== Received: from ywa17 (ywa17.prod.google.com [10.192.1.17]) by hpaq13.eem.corp.google.com with ESMTP id p89I287k009174 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 9 Sep 2011 11:02:09 -0700 Received: by ywa17 with SMTP id 17so2169405ywa.13 for ; Fri, 09 Sep 2011 11:02:08 -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; bh=ocgxv1OnHSq4jZDqwEpNgIJ0XGEAnp0Z9reNwSq1fIE=; b=pL494s8KtuJBHH/Uh5wMJE2d7PbQdlxQ4HgxkByipV7WyR4kBOHP7p3S8bW851DeFH HLvu8Hb2ToqYSY2wmfZg== Received: by 10.43.133.133 with SMTP id hy5mr174827icc.82.1315591328491; Fri, 09 Sep 2011 11:02:08 -0700 (PDT) Received: by 10.43.133.133 with SMTP id hy5mr174816icc.82.1315591328123; Fri, 09 Sep 2011 11:02:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.36.10 with HTTP; Fri, 9 Sep 2011 11:01:48 -0700 (PDT) In-Reply-To: References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> From: Justin Uberti Date: Fri, 9 Sep 2011 14:01:48 -0400 Message-ID: To: Alan Johnston Content-Type: multipart/alternative; boundary=20cf307f385ec84d2404ac85f917 X-System-Of-Record: true Cc: Randell Jesup , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 18:00:19 -0000 --20cf307f385ec84d2404ac85f917 Content-Type: text/plain; charset=UTF-8 On Fri, Sep 9, 2011 at 1:47 PM, Alan Johnston wrote: > Here's my thinking on this. We have CapNeg because the default > profile for VoIP and video is unfortunately insecure RTP. We also > need to have a single pass offer/answer negotiation since this is what > we are used to having. > > While I am not in favor of allowing insecure RTP in browsers, I know > some feel this is a requirement. I do like Chris's suggestion that > SRTP be the default, with no chrome messages trying to indicate the > security of the call, but that if RTP is used, we are universally > agreed that is is very insecure and the browser chrome should make it > very, very clear to the user that their privacy is being disregarded > by the service. > > If we make SRTP the default, and allow RTP, we could do the same in > our signaling negotiation. The default will be SRTP - this can be > expressed in SDP without CapNeg. Should the RTCWEB clients choose to > instead negotiate RTP, then this could be done with a second SDP > Offer/Answer exchange. This would provide yet another incentive for > services to use the secure mode. > So would it work like this? Assume participants A (prefers secure) and B (only supports insecure) A -> B (offer with DTLS/SRTP) B -> A (answer with 488 or other error) A -> B (offer with plain old RTP) B -> A (answer with 200) I prefer Jingle's way of allowing crypto to be agreed upon in a single o/a exchange, but this seems OK too. > A signaling gateway could support CapNeg and handle using 3PCC the > AVP/SAVP negotiation outside of RTCWEB. > > Otherwise, if we require CapNeg in the browser, this is a large leap > in complexity, and without proven interoperability and deployment of > CapNeg today, a very risky proposition. > > - Alan - > > On Fri, Sep 9, 2011 at 11:31 AM, Justin Uberti wrote: > > This feels like a pretty fundamental question. I thought we were getting > > pretty close to a consensus for the signaling mechanism with Cullen's > > presentation, but this seems to complicate that significantly. > > > > On Thu, Sep 8, 2011 at 8:21 AM, Jonathan Lennox > wrote: > >> > >> Indeed. > >> > >> More generally, the question is: should it be possible to send an offer > >> that by default does DTLS/SAVPF for RTCWeb, but also can fall back to > other > >> RTP profiles to support legacy devices? > >> > >> If yes, then either browsers need to support CapNeg, or RTCWeb needs to > >> use something other than SDP Offer/Answer. > >> > >> If no, then supporting interop, without a media gateway, with other > >> non-RTCWeb modes (e.g., no ICE, no rtcp mux, no audio/video mux, etc.) > >> becomes IMO a lot less compelling. > >> > >> -----Original Message----- > >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >> Sent: Thursday, September 08, 2011 2:35 AM > >> To: Randell Jesup; Jonathan Lennox > >> Cc: rtcweb@ietf.org > >> Subject: AVPF [was: [rtcweb] Encryption mandate (and offer/answer)] > >> > >> > >> Hi, > >> > >> >>>You could make forced-encryption the default, and allow the > >> >>>application control over whether to allow it is turned off for > >> >>>specific cases, like a PSTN call, or under the server's control. > >> >>>Signalling is secure, so it could even use a direct optional > >> >>>downgrade from SAVP* to AVP* (i.e. > >> >>>similar to the best-effort-strp draft) > >> >>This has implications for the parallel thread about the use of SDP > >> >>offer/answer. > >> >> > >> >>The solution MMUSIC has standardized for best-effort SRTP is SDP > >> >>CapNeg, RFC 5939. Do we want to require CapNeg support in browsers? > >> > > >> >Yeah, ok, I'm not going there. :-) It's probably not needed for this > >> >use-case anyways. > >> > >> The same question exists for AVPF, which has been suggested to be > >> mandated. > >> > >> Regards, > >> > >> Christer > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > --20cf307f385ec84d2404ac85f917 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 9, 2011 at 1:47 PM, Alan Joh= nston <al= an.b.johnston@gmail.com> wrote:
Here's my thinking on this. =C2=A0We have CapNeg because the default profile for VoIP and video is unfortunately insecure RTP. =C2=A0We also
need to have a single pass offer/answer negotiation since this is what
we are used to having.

While I am not in favor of allowing insecure RTP in browsers, I know
some feel this is a requirement. =C2=A0I do like Chris's suggestion tha= t
SRTP be the default, with no chrome messages trying to indicate the
security of the call, but that if RTP is used, we are universally
agreed that is is very insecure and the browser chrome should make it
very, very clear to the user that their privacy is being disregarded
by the service.

If we make SRTP the default, and allow RTP, we could do the same in
our signaling negotiation. =C2=A0The default will be SRTP - this can be
expressed in SDP without CapNeg. =C2=A0Should the RTCWEB clients choose to<= br> instead negotiate RTP, then this could be done with a second SDP
Offer/Answer exchange. =C2=A0This would provide yet another incentive for services to use the secure mode.

So wou= ld it work like this?
Assume participants A (prefers secure) and= =C2=A0B (only supports insecure)=C2=A0
A -> B (offer with DTLS= /SRTP)
B -> A (answer with 488 or other error)
A -> B (offer = with plain old RTP)
B -> A (answer with 200)

I prefer Jingle's way of allowing crypto to be agreed upon in a= single o/a exchange, but this seems OK too.


A signaling gateway could support CapNeg and handle using 3PCC the
AVP/SAVP negotiation outside of RTCWEB.

Otherwise, if we require CapNeg in the browser, this is a large leap
in complexity, and without proven interoperability and deployment of
CapNeg today, a very risky proposition.

- Alan -

On Fri, Sep 9, 2011 at 11:31 AM, Justin Uberti <juberti@google.com> wrote:
> This feels like a pretty fundamental question. I thought we were getti= ng
> pretty close to a consensus for the signaling mechanism with Cullen= 9;s
> presentation, but this seems to complicate that significantly.
>
> On Thu, Sep 8, 2011 at 8:21 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:
>>
>> Indeed.
>>
>> More generally, the question is: should it be possible to send an = offer
>> that by default does DTLS/SAVPF for RTCWeb, but also can fall back= to other
>> RTP profiles to support legacy devices?
>>
>> If yes, then either browsers need to support CapNeg, or RTCWeb nee= ds to
>> use something other than SDP Offer/Answer.
>>
>> If no, then supporting interop, without a media gateway, with othe= r
>> non-RTCWeb modes (e.g., no ICE, no rtcp mux, no audio/video mux, e= tc.)
>> becomes IMO a lot less compelling.
>>
>> -----Original Message-----
>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
>> Sent: Thursday, September 08, 2011 2:35 AM
>> To: Randell Jesup; Jonathan Lennox
>> Cc: rtcweb@ietf.org
>> Subject: AVPF [was: [rtcweb] Encryption mandate (and offer/answer)= ]
>>
>>
>> Hi,
>>
>> >>>You could make forced-encryption the default, and allo= w the
>> >>>application control over whether to allow it is turned= off for
>> >>>specific cases, like a PSTN call, or under the server&= #39;s control.
>> >>>Signalling is secure, so it could even use a direct op= tional
>> >>>downgrade from SAVP* to AVP* (i.e.
>> >>>similar to the best-effort-strp draft)
>> >>This has implications for the parallel thread about the us= e of SDP
>> >>offer/answer.
>> >>
>> >>The solution MMUSIC has standardized for best-effort SRTP = is SDP
>> >>CapNeg, RFC 5939. =C2=A0Do we want to require CapNeg suppo= rt in browsers?
>> >
>> >Yeah, ok, I'm not going there. =C2=A0:-) =C2=A0It's pr= obably not needed for this
>> >use-case anyways.
>>
>> The same question exists for AVPF, which has been suggested to be<= br> >> mandated.
>>
>> Regards,
>>
>> Christer
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--20cf307f385ec84d2404ac85f917-- From matthew.kaufman@skype.net Fri Sep 9 11:10: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 CD9D721F8804 for ; Fri, 9 Sep 2011 11:10:12 -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 6JqPSyJGMn8x for ; Fri, 9 Sep 2011 11:10:12 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 01F2221F86A4 for ; Fri, 9 Sep 2011 11:10:12 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id B12D3170B; Fri, 9 Sep 2011 20:11:36 +0200 (CEST) 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=qzo2V/Z9q5F4L5 h7HNxZzbMepHA=; b=UYM8dDt9M1Rb3Hcei5Ht+vAT6Hx62ND4PF1yBmGivUuxSs yOZFZms28s2Pmws0VzCtvYM4GhC9MlXCSNUx2/yskBVKpgaEoA0p2yZpEJAMKBN7 V+lH4X52lm941wRLli4PfzgRHF6c9MYTgMv2YYLSlSCkmJ2zeT+rfBKEiRSHk= 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=jjO0HmZDQONzbIIkqp0CO9 IowwwCNyo4LUqwSI++oWr156ml9IkfNVFYHtoJcck8ElOd7MISSOVK72ra0BPKjd mowJMkSLOJCEH+C+VtmiJTNJPv1rXNBiD9mevKETfcqqpSDvY0NqKcgrjl8mKyor 8dtjy30UeMyTTOd5h9lOo= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id AF8817F6; Fri, 9 Sep 2011 20:11:36 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 7BB721672682; Fri, 9 Sep 2011 20:11:36 +0200 (CEST) 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 GudvrDxvbc1J; Fri, 9 Sep 2011 20:11:35 +0200 (CEST) Received: from Matthew-Kaufman-Air.local (unknown [131.107.200.34]) by zimbra.skype.net (Postfix) with ESMTPSA id 4AF0C1672681; Fri, 9 Sep 2011 20:11:34 +0200 (CEST) Message-ID: <4E6A56D4.2030602@skype.net> Date: Fri, 09 Sep 2011 11:11:32 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Alan Johnston References: <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randell Jesup , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 18:10:12 -0000 On 9/9/11 10:47 AM, Alan Johnston wrote: > The default will be SRTP - this can be > expressed in SDP without CapNeg. Should the RTCWEB clients choose to > instead negotiate RTP, then this could be done with a second SDP > Offer/Answer exchange. I believe you've just designed a downgrade vulnerability. Matthew Kaufman From dzonatas@gmail.com Fri Sep 9 11:28: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 55C3721F86A4 for ; Fri, 9 Sep 2011 11:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.964 X-Spam-Level: X-Spam-Status: No, score=-3.964 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMuwEn9MtTWA for ; Fri, 9 Sep 2011 11:28:47 -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 5CAEB21F8610 for ; Fri, 9 Sep 2011 11:28:47 -0700 (PDT) Received: by ywa6 with SMTP id 6so216119ywa.31 for ; Fri, 09 Sep 2011 11:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=U6JSXFPemTrSJmAC65Wj3/BEKUgtSM6RR0y9f74jorI=; b=j78hPnMHTsJvUtZf16OkERtN6lBeiZ28ZYGIcz0b09IEGjjawefTKlN65qWAXlBSL3 GrJ+mVAfReSN+OrSxIRNzqSrLzKtZlcgvZtCCL0yiLuEuqcida2+AD4r1viGp+1A/1Ur NB68j+1w1k31iqe8eqBxNEBZZbEb5WPaQ8XgE= Received: by 10.68.64.193 with SMTP id q1mr928447pbs.237.1315593042528; Fri, 09 Sep 2011 11:30:42 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id i1sm21874539pbe.1.2011.09.09.11.30.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Sep 2011 11:30:41 -0700 (PDT) Message-ID: <4E6A5BC7.40507@gmail.com> Date: Fri, 09 Sep 2011 11:32:39 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype .net> In-Reply-To: <4E6A56D4.2030602@skype.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 18:28:48 -0000 On 09/09/2011 11:11 AM, Matthew Kaufman wrote: > On 9/9/11 10:47 AM, Alan Johnston wrote: >> The default will be SRTP - this can be >> expressed in SDP without CapNeg. Should the RTCWEB clients choose to >> instead negotiate RTP, then this could be done with a second SDP >> Offer/Answer exchange. > > I believe you've just designed a downgrade vulnerability. From the CPU perspective, any analogue signal is "insecure" (no matter how useful), and the words are interchangeable until something is purposely made further insecure or further processed unto digital-only. Downgrade is recoverable, yet something that leads to collapse of state from the VM is not. -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From ekr@rtfm.com Fri Sep 9 11: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 8B7EF21F8715 for ; Fri, 9 Sep 2011 11:33:42 -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 HVDqmC30sR3m for ; Fri, 9 Sep 2011 11:33:42 -0700 (PDT) Received: from mail-ey0-f174.google.com (mail-ey0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id C4CCA21F86EC for ; Fri, 9 Sep 2011 11:33:41 -0700 (PDT) Received: by eyx24 with SMTP id 24so1515415eyx.19 for ; Fri, 09 Sep 2011 11:35:36 -0700 (PDT) Received: by 10.213.3.201 with SMTP id 9mr522542ebo.107.1315593336407; Fri, 09 Sep 2011 11:35:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.4.11 with HTTP; Fri, 9 Sep 2011 11:35:16 -0700 (PDT) In-Reply-To: <4E6A56D4.2030602@skype.net> References: <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> From: Eric Rescorla Date: Fri, 9 Sep 2011 11:35:16 -0700 Message-ID: To: Matthew Kaufman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 18:33:42 -0000 On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman wrote: > On 9/9/11 10:47 AM, Alan Johnston wrote: >> >> =A0 The default will be SRTP - this can be >> expressed in SDP without CapNeg. =A0Should the RTCWEB clients choose to >> instead negotiate RTP, then this could be done with a second SDP >> Offer/Answer exchange. > > I believe you've just designed a downgrade vulnerability. Unless I'm missing something, if you (a) support an insecure mode and (b) a= llow negotiation of insecure vs. secure, there's not really any way to avoid a downgrade issue; the attacker can always pretend not to support security and how do y= ou know better? Obviously, it helps if you can negotiate the use or non-use of media security over a secure-ish signaling channel, but that doesn't reduce the threat from the signaling service. Best, -Ekr From juberti@google.com Fri Sep 9 11:52: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 9FD1C21F86C1 for ; Fri, 9 Sep 2011 11:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.655 X-Spam-Level: X-Spam-Status: No, score=-105.655 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 VeFqFeFvSi4V for ; Fri, 9 Sep 2011 11:52:26 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id EF87521F86A4 for ; Fri, 9 Sep 2011 11:52:25 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p89IsGDu011958 for ; Fri, 9 Sep 2011 11:54:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315594456; bh=6MOIlJi/HtQIhX+/Is0ja677s0U=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ga2KLLxDVvyFWP5WaBWLIWz3KnCgW0TsvAJKoL80WuJktwuSpe/9c30Z9cTnhbSt8 NTyA8ZwbBHF9lADxEK6EA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=vGxDvN1UCT0aKS0Ni/ltT94SiSCY6iYSkVSevxTMR4v2ihDiBW57BJy8jTO4dstDe UZJhGTs5tkANfwsgmNMxg== Received: from yxm34 (yxm34.prod.google.com [10.190.4.34]) by wpaz33.hot.corp.google.com with ESMTP id p89IrYuI016393 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 9 Sep 2011 11:54:15 -0700 Received: by yxm34 with SMTP id 34so3334381yxm.25 for ; Fri, 09 Sep 2011 11:54:10 -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; bh=czYvCWdoGZIgShRPO11Ac1Gl1mTWYXSfij2ZY8uh7q4=; b=ZqPuPBjLv+fQ/OzzpGHu+cbFnm8+BtFI9XqI6t/W+bJFduIFdE7bwG7Vnb6g1wi1J3 HLvKIQ9Egh3/9/N8y0Cw== Received: by 10.42.134.2 with SMTP id j2mr1326154ict.149.1315594450308; Fri, 09 Sep 2011 11:54:10 -0700 (PDT) Received: by 10.42.134.2 with SMTP id j2mr1326144ict.149.1315594450204; Fri, 09 Sep 2011 11:54:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.36.10 with HTTP; Fri, 9 Sep 2011 11:53:50 -0700 (PDT) In-Reply-To: References: <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> From: Justin Uberti Date: Fri, 9 Sep 2011 14:53:50 -0400 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=90e6ba6e8dbadf76c704ac86b379 X-System-Of-Record: true Cc: Randell Jesup , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 18:52:26 -0000 --90e6ba6e8dbadf76c704ac86b379 Content-Type: text/plain; charset=UTF-8 On Fri, Sep 9, 2011 at 2:35 PM, Eric Rescorla wrote: > On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman > wrote: > > On 9/9/11 10:47 AM, Alan Johnston wrote: > >> > >> The default will be SRTP - this can be > >> expressed in SDP without CapNeg. Should the RTCWEB clients choose to > >> instead negotiate RTP, then this could be done with a second SDP > >> Offer/Answer exchange. > > > > I believe you've just designed a downgrade vulnerability. > > Unless I'm missing something, if you (a) support an insecure mode and (b) > allow > negotiation of insecure vs. secure, there's not really any way to > avoid a downgrade > issue; the attacker can always pretend not to support security and how do > you > know better? Obviously, it helps if you can negotiate the use or non-use of > media security over a secure-ish signaling channel, but that doesn't reduce > the threat from the signaling service. > We can of course expose the encryption state to the application so that it can decide if it wants to proceed with/warn about the downgrade to plain old RTP. --90e6ba6e8dbadf76c704ac86b379 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 9, 2011 at 2:35 PM, Eric Res= corla <ekr@rtfm.com> wrote:
On Fri, Sep 9, 2011 at 1= 1:11 AM, Matthew Kaufman
<matthew.kaufman@skype.net<= /a>> wrote:
> On 9/9/11 10:47 AM, Alan Johnston wrote:
>>
>> =C2=A0 The default will be SRTP - this can be
>> expressed in SDP without CapNeg. =C2=A0Should the RTCWEB clients c= hoose to
>> instead negotiate RTP, then this could be done with a second SDP >> Offer/Answer exchange.
>
> I believe you've just designed a downgrade vulnerability.

Unless I'm missing something, if you (a) support an insecur= e mode and (b) allow
negotiation of insecure vs. secure, there's not really any way to
avoid a downgrade
issue; the attacker can always pretend not to support security and how do y= ou
know better? Obviously, it helps if you can negotiate the use or non-use of=
media security over a secure-ish signaling channel, but that doesn't re= duce
the threat from the signaling service.

--90e6ba6e8dbadf76c704ac86b379-- From dzonatas@gmail.com Fri Sep 9 12:01: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 B337D21F8804 for ; Fri, 9 Sep 2011 12:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.957 X-Spam-Level: X-Spam-Status: No, score=-3.957 tagged_above=-999 required=5 tests=[AWL=-0.358, 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 M+uEjZ7POixl for ; Fri, 9 Sep 2011 12:01:15 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 07E5E21F8486 for ; Fri, 9 Sep 2011 12:01:14 -0700 (PDT) Received: by gwb17 with SMTP id 17so2146470gwb.15 for ; Fri, 09 Sep 2011 12:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xaw6kQRPNCKPEsdDApO3hmZ8mwTbhVeuZoo4cgJHg8Y=; b=xaED2MFSZFT37/cq/lYRP68D4/LXNrehruZRVvnwJCWvqC7RxupXLMzc29gQRhNiQf 1hPg3TCCmeiSSYROCzjgSlXzB5IwPxE1yRd/12cZM/83PJCVt0HuLhTqQyTQcK2K8u3w haTpuYGXV2av3cQ+fEyUHa5NRrKFh9vsfloIQ= Received: by 10.42.117.196 with SMTP id u4mr744128icq.371.1315594990143; Fri, 09 Sep 2011 12:03:10 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id o5sm9217693ibu.12.2011.09.09.12.03.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Sep 2011 12:03:08 -0700 (PDT) Message-ID: <4E6A6362.5000402@gmail.com> Date: Fri, 09 Sep 2011 12:05:06 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 19:01:15 -0000 On 09/09/2011 11:53 AM, Justin Uberti wrote: > > > On Fri, Sep 9, 2011 at 2:35 PM, Eric Rescorla > wrote: > > On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman > > wrote: > > On 9/9/11 10:47 AM, Alan Johnston wrote: > >> > >> The default will be SRTP - this can be > >> expressed in SDP without CapNeg. Should the RTCWEB clients > choose to > >> instead negotiate RTP, then this could be done with a second SDP > >> Offer/Answer exchange. > > > > I believe you've just designed a downgrade vulnerability. > > Unless I'm missing something, if you (a) support an insecure mode > and (b) allow > negotiation of insecure vs. secure, there's not really any way to > avoid a downgrade > issue; the attacker can always pretend not to support security and > how do you > know better? Obviously, it helps if you can negotiate the use or > non-use of > media security over a secure-ish signaling channel, but that > doesn't reduce > the threat from the signaling service. > > > We can of course expose the encryption state to the application so > that it can decide if it wants to proceed with/warn about the > downgrade to plain old RTP. > That would be federalization then, not downgrade. -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From alan.b.johnston@gmail.com Fri Sep 9 12:22: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 0382521F84E1 for ; Fri, 9 Sep 2011 12:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.553 X-Spam-Level: X-Spam-Status: No, score=-103.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 0vH6fnNOzWVy for ; Fri, 9 Sep 2011 12:22:07 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 10CC321F84BC for ; Fri, 9 Sep 2011 12:21:38 -0700 (PDT) Received: by yie12 with SMTP id 12so586445yie.31 for ; Fri, 09 Sep 2011 12:23:31 -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:content-transfer-encoding; bh=G0+isCFKAAFRb46jM216qsK4DMsw3os7NWbqMUnByVU=; b=ameR9AUg170yn+lRvL6eIBdb7zQi1AZKJMRL8OFahDRgKYeRF3RvcAiadKID/yEJ3g HedztRi3YgH2vzQWs63waRbo+rtPNZiMesGopLcjRUKLX09wqb7Upox4f4AR/ifC9eMb vUqB+RS8wSmMluJg+0Nwyde1TROV4n5AcFNK8= MIME-Version: 1.0 Received: by 10.150.113.18 with SMTP id l18mr989763ybc.222.1315596211609; Fri, 09 Sep 2011 12:23:31 -0700 (PDT) Received: by 10.151.7.5 with HTTP; Fri, 9 Sep 2011 12:23:31 -0700 (PDT) In-Reply-To: References: <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> Date: Fri, 9 Sep 2011 14:23:31 -0500 Message-ID: From: Alan Johnston To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 19:22:20 -0000 Ekr is correct. If we allow RTP, which I think is a mistake, then there is always a downgrade attack. My point was that if we must support insecure media, we could avoid the complexity of CapNeg by not requiring a single pass non-secure media negotiation. - Alan - On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla wrote: > On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman > wrote: >> On 9/9/11 10:47 AM, Alan Johnston wrote: >>> >>> =A0 The default will be SRTP - this can be >>> expressed in SDP without CapNeg. =A0Should the RTCWEB clients choose to >>> instead negotiate RTP, then this could be done with a second SDP >>> Offer/Answer exchange. >> >> I believe you've just designed a downgrade vulnerability. > > Unless I'm missing something, if you (a) support an insecure mode and (b)= allow > negotiation of insecure vs. secure, there's not really any way to > avoid a downgrade > issue; the attacker can always pretend not to support security and how do= you > know better? Obviously, it helps if you can negotiate the use or non-use = of > media security over a secure-ish signaling channel, but that doesn't redu= ce > the threat from the signaling service. > > Best, > -Ekr > From roman@telurix.com Fri Sep 9 12: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 200FE21F86C1 for ; Fri, 9 Sep 2011 12:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.768 X-Spam-Level: X-Spam-Status: No, score=-2.768 tagged_above=-999 required=5 tests=[AWL=0.208, 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 Nhc6eMexccTL for ; Fri, 9 Sep 2011 12:37:55 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC0321F86A6 for ; Fri, 9 Sep 2011 12:37:55 -0700 (PDT) Received: by yie12 with SMTP id 12so600159yie.31 for ; Fri, 09 Sep 2011 12:39:51 -0700 (PDT) Received: by 10.90.232.12 with SMTP id e12mr2125976agh.114.1315597190824; Fri, 09 Sep 2011 12:39:50 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by mx.google.com with ESMTPS id b4sm2603054ank.3.2011.09.09.12.39.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Sep 2011 12:39:50 -0700 (PDT) Received: by gxk9 with SMTP id 9so1570908gxk.40 for ; Fri, 09 Sep 2011 12:39:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.8.36 with SMTP id o4mr404878pba.255.1315597186211; Fri, 09 Sep 2011 12:39:46 -0700 (PDT) Received: by 10.68.43.136 with HTTP; Fri, 9 Sep 2011 12:39:46 -0700 (PDT) In-Reply-To: References: <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> Date: Fri, 9 Sep 2011 15:39:46 -0400 Message-ID: From: Roman Shpount To: Alan Johnston Content-Type: multipart/alternative; boundary=bcaec52157b3f3a14604ac875661 Cc: Randell Jesup , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 19:37:56 -0000 --bcaec52157b3f3a14604ac875661 Content-Type: text/plain; charset=ISO-8859-1 I think RTP vs SRTP should be handled similarly to HTTP vs HTTPS. If the current session is secure (started by HTTPS) only secure media should be allowed, or unsecure connections should only be allowed after the user consent. If the session is started by HTTP, unsecure media should be allowed since all the signaling is insecure in the first place. Please keep in mind that secure media is not limited to SRTP. RTP over DTLS is as or more secure then SRTP. _____________ Roman Shpount On Fri, Sep 9, 2011 at 3:23 PM, Alan Johnston wrote: > Ekr is correct. If we allow RTP, which I think is a mistake, then > there is always a downgrade attack. > > My point was that if we must support insecure media, we could avoid > the complexity of CapNeg by not requiring a single pass non-secure > media negotiation. > > - Alan - > > On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla wrote: > > On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman > > wrote: > >> On 9/9/11 10:47 AM, Alan Johnston wrote: > >>> > >>> The default will be SRTP - this can be > >>> expressed in SDP without CapNeg. Should the RTCWEB clients choose to > >>> instead negotiate RTP, then this could be done with a second SDP > >>> Offer/Answer exchange. > >> > >> I believe you've just designed a downgrade vulnerability. > > > > Unless I'm missing something, if you (a) support an insecure mode and (b) > allow > > negotiation of insecure vs. secure, there's not really any way to > > avoid a downgrade > > issue; the attacker can always pretend not to support security and how do > you > > know better? Obviously, it helps if you can negotiate the use or non-use > of > > media security over a secure-ish signaling channel, but that doesn't > reduce > > the threat from the signaling service. > > > > Best, > > -Ekr > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec52157b3f3a14604ac875661 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think RTP vs SRTP should be handled similarly to HTTP vs HTTPS. If the cu= rrent session is secure (started by HTTPS) only secure media should be allo= wed, or unsecure connections should only be allowed after the user consent.= If the session is started by HTTP, unsecure media should be allowed since = all the signaling is insecure in the first place. Please keep in mind that = secure media is not limited to SRTP. RTP over DTLS is as or more secure the= n SRTP.
_____________
Roman Shpount


On Fri, Sep 9, 2011 at 3:23 PM, Alan Joh= nston <al= an.b.johnston@gmail.com> wrote:
Ekr is correct. =A0If we allow RTP, which I think is a mistake, then
there is always a downgrade attack.

My point was that if we must support insecure media, we could avoid
the complexity of CapNeg by not requiring a single pass non-secure
media negotiation.

- Alan -

On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman
> <matthew.kaufman@skype= .net> wrote:
>> On 9/9/11 10:47 AM, Alan Johnston wrote:
>>>
>>> =A0 The default will be SRTP - this can be
>>> expressed in SDP without CapNeg. =A0Should the RTCWEB clients = choose to
>>> instead negotiate RTP, then this could be done with a second S= DP
>>> Offer/Answer exchange.
>>
>> I believe you've just designed a downgrade vulnerability.
>
> Unless I'm missing something, if you (a) support an insecure mode = and (b) allow
> negotiation of insecure vs. secure, there's not really any way to<= br> > avoid a downgrade
> issue; the attacker can always pretend not to support security and how= do you
> know better? Obviously, it helps if you can negotiate the use or non-u= se of
> media security over a secure-ish signaling channel, but that doesn'= ;t reduce
> the threat from the signaling service.
>
> Best,
> -Ekr
>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--bcaec52157b3f3a14604ac875661-- From dzonatas@gmail.com Fri Sep 9 12:42: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 B7E9621F86F6 for ; Fri, 9 Sep 2011 12:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[AWL=-0.351, 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 0eVcAHkcDHiR for ; Fri, 9 Sep 2011 12:42:22 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE08521F86C1 for ; Fri, 9 Sep 2011 12:42:21 -0700 (PDT) Received: by yxt33 with SMTP id 33so503350yxt.31 for ; Fri, 09 Sep 2011 12:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VJZcyEn0numwAqsqxcA+c3YVhVb2sWvpWBBkWtCREkw=; b=gl8gGywzItn3vaG9KZhj7jA/KglxlnDjizfhP0yjjHh1OhxYwyUU/JSkR2MhtwtzoN VWxz5KaEmW1U15ju3fGN019sA5kXvcPcMy63MutxDz1ropjmO0wxzlwjPQLftSopCutv a/WMBAR9r63loB3OHsxNX6pkB6WNZykfRJlnM= Received: by 10.42.97.73 with SMTP id m9mr1349663icn.126.1315597454515; Fri, 09 Sep 2011 12:44:14 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id 37sm9639597iba.5.2011.09.09.12.44.13 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Sep 2011 12:44:13 -0700 (PDT) Message-ID: <4E6A6D04.9030806@gmail.com> Date: Fri, 09 Sep 2011 12:46:12 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 19:42:22 -0000 On 09/09/2011 12:23 PM, Alan Johnston wrote: > Ekr is correct. If we allow RTP, which I think is a mistake, then > there is always a downgrade attack > Two encrypted states that negotiate with each other is not an attack. There is just no obvious equality between the two "when introduced." Let the federated servers introduce them; otherwise, it's browser to browser with the bigger unknown. Maybe QoS can include syllabic gain performance measurements to test that continuously, yet that is forward-thinking for many despite known proof. > My point was that if we must support insecure media, we could avoid > the complexity of CapNeg by not requiring a single pass non-secure > media negotiation. > > - Alan - > > On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla wrote: > >> On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman >> wrote: >> >>> On 9/9/11 10:47 AM, Alan Johnston wrote: >>> >>>> � The default will be SRTP - this can be >>>> expressed in SDP without CapNeg. �Should the RTCWEB clients choose to >>>> instead negotiate RTP, then this could be done with a second SDP >>>> Offer/Answer exchange. >>>> >>> I believe you've just designed a downgrade vulnerability. >>> >> Unless I'm missing something, if you (a) support an insecure mode and (b) allow >> negotiation of insecure vs. secure, there's not really any way to >> avoid a downgrade >> issue; the attacker can always pretend not to support security and how do you >> know better? Obviously, it helps if you can negotiate the use or non-use of >> media security over a secure-ish signaling channel, but that doesn't reduce >> the threat from the signaling service. >> >> Best, >> -Ekr >> >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From dzonatas@gmail.com Fri Sep 9 12:50: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 0C34E21F87FC for ; Fri, 9 Sep 2011 12:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.944 X-Spam-Level: X-Spam-Status: No, score=-3.944 tagged_above=-999 required=5 tests=[AWL=-0.345, 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 1+2KAlQPqJrJ for ; Fri, 9 Sep 2011 12:50:10 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 22C8B21F873A for ; Fri, 9 Sep 2011 12:50:10 -0700 (PDT) Received: by yie12 with SMTP id 12so610398yie.31 for ; Fri, 09 Sep 2011 12:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Z2HQYqHxtJmdtXlQQXNw7wElsI0Zcb/ecCHrtewTUM0=; b=jLZ6T5tgrTDRO6Gxx1iOaJ8bsbHktmmILLg9+ddXP/InYucm6GE6BLjrqII0c/KKoe y9a1j5Nvhgq8gWMAPUKEczvMnuFz5DeQwq5nHfHUrwkuQyOD1ZK7CaBv6sgNE3flSirM njMSluR0pronJtXIeF8R0l8Ch2tQfidMKngkU= Received: by 10.42.152.199 with SMTP id j7mr1323308icw.417.1315597923328; Fri, 09 Sep 2011 12:52:03 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id df21sm9362752ibb.9.2011.09.09.12.52.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Sep 2011 12:52:02 -0700 (PDT) Message-ID: <4E6A6ED9.4010306@gmail.com> Date: Fri, 09 Sep 2011 12:54:01 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 19:50:11 -0000 On 09/09/2011 12:39 PM, Roman Shpount wrote: > I think RTP vs SRTP should be handled similarly to HTTP vs HTTPS. Then that would be the same footsteps as HTTPS, and many of us silently do not want that standardized again. We want the stateful layer, and all routes HTTPS ends that state ("this part is done" despite bis). > If the current session is secure (started by HTTPS) only secure media > should be allowed, or unsecure connections should only be allowed > after the user consent. That's like one-way street that wouldn't support "third-party" (use-cases). > If the session is started by HTTP, unsecure media should be allowed > since all the signaling is insecure in the first place. We can just use OPTIONS here, so this path is not an "attack". > Please keep in mind that secure media is not limited to SRTP. RTP over > DTLS is as or more secure then SRTP. > _____________ > Roman Shpount > > > On Fri, Sep 9, 2011 at 3:23 PM, Alan Johnston > > wrote: > > Ekr is correct. �If we allow RTP, which I think is a mistake, then > there is always a downgrade attack. > > My point was that if we must support insecure media, we could avoid > the complexity of CapNeg by not requiring a single pass non-secure > media negotiation. > > - Alan - > > On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla > wrote: > > On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman > > > > wrote: > >> On 9/9/11 10:47 AM, Alan Johnston wrote: > >>> > >>> � The default will be SRTP - this can be > >>> expressed in SDP without CapNeg. �Should the RTCWEB clients > choose to > >>> instead negotiate RTP, then this could be done with a second SDP > >>> Offer/Answer exchange. > >> > >> I believe you've just designed a downgrade vulnerability. > > > > Unless I'm missing something, if you (a) support an insecure > mode and (b) allow > > negotiation of insecure vs. secure, there's not really any way to > > avoid a downgrade > > issue; the attacker can always pretend not to support security > and how do you > > know better? Obviously, it helps if you can negotiate the use or > non-use of > > media security over a secure-ish signaling channel, but that > doesn't reduce > > the threat from the signaling service. > > > > Best, > > -Ekr > > > _______________________________________________ > 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 > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From christer.holmberg@ericsson.com Fri Sep 9 13:20: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 93A2D21F85D1 for ; Fri, 9 Sep 2011 13:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 icduZ+9A0BgJ for ; Fri, 9 Sep 2011 13:20: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 F151821F85CE for ; Fri, 9 Sep 2011 13:20:13 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-c9-4e6a757057f0 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D7.47.20773.0757A6E4; Fri, 9 Sep 2011 22:22:08 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 9 Sep 2011 22:22:08 +0200 From: Christer Holmberg To: 'Alan Johnston' , Eric Rescorla Date: Fri, 9 Sep 2011 22:22:07 +0200 Thread-Topic: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] Thread-Index: AcxvJhZdVKRLLlJ2Tymnryzk+6+mBwAB4Fmw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45F96@ESESSCMS0356.eemea.ericsson.se> References: <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> 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: Randell Jesup , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 20:20:23 -0000 Hi, In general I agree with Alan that we should try to avoid CapNeg. Regarding AVPF vs AVP, we also first need to decide whether AVP will be sup= ported in the first place. Then, if we decide to support AVP, we have to ma= ke a similar decision whether to use CapNeg or to rely on a "fallback" offe= r/answer. Regards, Christer =20 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Alan Johnston Sent: 9. syyskuuta 2011 22:24 To: Eric Rescorla Cc: Randell Jesup; Jonathan Lennox; rtcweb@ietf.org Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] Ekr is correct. If we allow RTP, which I think is a mistake, then there is= always a downgrade attack. My point was that if we must support insecure media, we could avoid the com= plexity of CapNeg by not requiring a single pass non-secure media negotiati= on. - Alan - On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla wrote: > On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman=20 > wrote: >> On 9/9/11 10:47 AM, Alan Johnston wrote: >>> >>> =A0 The default will be SRTP - this can be expressed in SDP without=20 >>> CapNeg. =A0Should the RTCWEB clients choose to instead negotiate RTP,=20 >>> then this could be done with a second SDP Offer/Answer exchange. >> >> I believe you've just designed a downgrade vulnerability. > > Unless I'm missing something, if you (a) support an insecure mode and=20 > (b) allow negotiation of insecure vs. secure, there's not really any=20 > way to avoid a downgrade issue; the attacker can always pretend not to=20 > support security and how do you know better? Obviously, it helps if=20 > you can negotiate the use or non-use of media security over a=20 > secure-ish signaling channel, but that doesn't reduce the threat from=20 > the signaling service. > > Best, > -Ekr > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From dzonatas@gmail.com Fri Sep 9 13:51: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 A359621F86A2 for ; Fri, 9 Sep 2011 13:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.938 X-Spam-Level: X-Spam-Status: No, score=-3.938 tagged_above=-999 required=5 tests=[AWL=-0.339, 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 n1jBAoPykA8F for ; Fri, 9 Sep 2011 13:51:48 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1CA21F8559 for ; Fri, 9 Sep 2011 13:51:42 -0700 (PDT) Received: by yxt33 with SMTP id 33so559848yxt.31 for ; Fri, 09 Sep 2011 13:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=JqCCeT55stODZmt4a9ZVDrYQG7ZQDmkvr9SJBs6SPB8=; b=QO1KrrLU8fYTVClCWibPQ+Hf6kejJw5rSf+13xlWcrRr0nroRMMOJfgqFjxtKJRN0R /lbWH7eeeDpeREv+cam9Y1uXboOF9qOhj7+44dDduTNH4jxyPQepH7bYDLFFLrXFwjwZ +jULnAdnp1oP+Q8uTttKHDEzT2SVtNmfVGjgE= Received: by 10.42.96.68 with SMTP id i4mr1316188icn.354.1315601618012; Fri, 09 Sep 2011 13:53:38 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id d8sm9858365ibl.1.2011.09.09.13.53.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Sep 2011 13:53:37 -0700 (PDT) Message-ID: <4E6A7D47.5020201@gmail.com> Date: Fri, 09 Sep 2011 13:55:35 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <7F2072F1E0DE894DA4B517B93C6A05852233D45F96@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233D45F96@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 20:51:48 -0000 On 09/09/2011 01:22 PM, Christer Holmberg wrote: > Hi, > > In general I agree with Alan that we should try to avoid CapNeg. > The only security needed "to avoid" that is the guarantee/certificate of the pure software VM process (i.e. OSI); otherwise, CapNeg is hardware hacking. The stateless API is the default capabilities, so there is no carrier for some secure state otherwise. Discovery of further capabilities is ideal in duration of the carrier. I find it helpful to munge client and server APIs into one API set instead of separate definitions as proof. Capabilities then are just driver issues, not application issues. > Regarding AVPF vs AVP, we also first need to decide whether AVP will be supported in the first place. Then, if we decide to support AVP, we have to make a similar decision whether to use CapNeg or to rely on a "fallback" offer/answer. > > Regards, > > Christer > > > > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Alan Johnston > Sent: 9. syyskuuta 2011 22:24 > To: Eric Rescorla > Cc: Randell Jesup; Jonathan Lennox; rtcweb@ietf.org > Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] > > Ekr is correct. If we allow RTP, which I think is a mistake, then there is always a downgrade attack. > > My point was that if we must support insecure media, we could avoid the complexity of CapNeg by not requiring a single pass non-secure media negotiation. > > - Alan - > > On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla wrote: > >> On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman >> wrote: >> >>> On 9/9/11 10:47 AM, Alan Johnston wrote: >>> >>>> � The default will be SRTP - this can be expressed in SDP without >>>> CapNeg. �Should the RTCWEB clients choose to instead negotiate RTP, >>>> then this could be done with a second SDP Offer/Answer exchange. >>>> >>> I believe you've just designed a downgrade vulnerability. >>> >> Unless I'm missing something, if you (a) support an insecure mode and >> (b) allow negotiation of insecure vs. secure, there's not really any >> way to avoid a downgrade issue; the attacker can always pretend not to >> support security and how do you know better? Obviously, it helps if >> you can negotiate the use or non-use of media security over a >> secure-ish signaling channel, but that doesn't reduce the threat from >> the signaling service. >> >> Best, >> -Ekr >> >> > _______________________________________________ > 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 > > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From christer.holmberg@ericsson.com Fri Sep 9 14:12: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 B897D21F869E for ; Fri, 9 Sep 2011 14:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 Xbed4GOhbSUn for ; Fri, 9 Sep 2011 14:12:09 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9D82C21F869C for ; Fri, 9 Sep 2011 14:12:08 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ce-4e6a819b7b27 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E7.B9.20773.B918A6E4; Fri, 9 Sep 2011 23:14:04 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 9 Sep 2011 23:14:04 +0200 From: Christer Holmberg To: 'Dzonatas Sol' , "rtcweb@ietf.org" Date: Fri, 9 Sep 2011 23:14:03 +0200 Thread-Topic: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] Thread-Index: AcxvMpLjgFQ/kh6FS+O488IfjuKOsAAAsE9g Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45F98@ESESSCMS0356.eemea.ericsson.se> References: <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <7F2072F1E0DE894DA4B517B93C6A05852233D45F96@ESESSCMS0356.eemea.ericsson.se> <4E6A7D47.5020201@gmail.com> In-Reply-To: <4E6A7D47.5020201@gmail.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: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 21:12:09 -0000 What security do we avoid by avoiding CapNeg? Regards, Christer=20 -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Dzonatas Sol Sent: 9. syyskuuta 2011 23:56 To: rtcweb@ietf.org Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] On 09/09/2011 01:22 PM, Christer Holmberg wrote: > Hi, > > In general I agree with Alan that we should try to avoid CapNeg. > =20 The only security needed "to avoid" that is the guarantee/certificate of th= e pure software VM process (i.e. OSI); otherwise, CapNeg is hardware hackin= g. The stateless API is the default capabilities, so there is no carrier for s= ome secure state otherwise. Discovery of further capabilities is ideal in d= uration of the carrier. I find it helpful to munge client and server APIs into one API set instead = of separate definitions as proof. Capabilities then are just driver issues,= not application issues. > Regarding AVPF vs AVP, we also first need to decide whether AVP will be s= upported in the first place. Then, if we decide to support AVP, we have to = make a similar decision whether to use CapNeg or to rely on a "fallback" of= fer/answer. > > Regards, > > Christer > > > > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 > Behalf Of Alan Johnston > Sent: 9. syyskuuta 2011 22:24 > To: Eric Rescorla > Cc: Randell Jesup; Jonathan Lennox; rtcweb@ietf.org > Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and=20 > offer/answer)] > > Ekr is correct. If we allow RTP, which I think is a mistake, then there = is always a downgrade attack. > > My point was that if we must support insecure media, we could avoid the c= omplexity of CapNeg by not requiring a single pass non-secure media negotia= tion. > > - Alan - > > On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla wrote: > =20 >> On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman=20 >> wrote: >> =20 >>> On 9/9/11 10:47 AM, Alan Johnston wrote: >>> =20 >>>> The default will be SRTP - this can be expressed in SDP without=20 >>>> CapNeg. Should the RTCWEB clients choose to instead negotiate RTP,=20 >>>> then this could be done with a second SDP Offer/Answer exchange. >>>> =20 >>> I believe you've just designed a downgrade vulnerability. >>> =20 >> Unless I'm missing something, if you (a) support an insecure mode and >> (b) allow negotiation of insecure vs. secure, there's not really any=20 >> way to avoid a downgrade issue; the attacker can always pretend not=20 >> to support security and how do you know better? Obviously, it helps=20 >> if you can negotiate the use or non-use of media security over a=20 >> secure-ish signaling channel, but that doesn't reduce the threat from=20 >> the signaling service. >> >> Best, >> -Ekr >> >> =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > =20 -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Fri Sep 9 14:16: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 609FC21F86A1 for ; Fri, 9 Sep 2011 14:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 J55aOCgCAsk9 for ; Fri, 9 Sep 2011 14:16:44 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 68DF121F8569 for ; Fri, 9 Sep 2011 14:16:28 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R28Su-0002gZ-HJ for rtcweb@ietf.org; Fri, 09 Sep 2011 16:18:24 -0500 Message-ID: <4E6A81EC.3080002@jesup.org> Date: Fri, 09 Sep 2011 17:15:24 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> 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] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 21:16:45 -0000 On 9/9/2011 3:23 PM, Alan Johnston wrote: > Ekr is correct. If we allow RTP, which I think is a mistake, then > there is always a downgrade attack. Yes, that's true. The same issue was involved in the best-effort-srtp draft, which unfortunately was dropped because CapNeg would "solve" it. (For historical note, it's still not "solved" because CapNeg support is >>>> more complex than best-effort-srtp and not generally deployed, and I doubt ever will be ala SDPng (though I'm not close to status on CapNeg.) Hmmm. A real downgrade attack requires that the signalling be compromised. I wonder if there are characteristics of a webrtc transaction that could help avoid this sort of attack (for example, a secondary way out-of-scope here for the app to know ahead of time if the target will need to be downgraded). Or some way for the service to vouch for the downgrade (i.e. wasn't a MITM). You have to trust the service, but in this case you're doing so to this degree anyways. > My point was that if we must support insecure media, we could avoid > the complexity of CapNeg by not requiring a single pass non-secure > media negotiation. There is another option. I talked about services that wanted to support PSTN could decide if they were willing to support a downgrade. The application could know it's calling a PSTN gateway and if it does know that, avoid a media gateway by not offering encrypted media. I see a significant use-case for some services will be calling PSTN numbers and services, much as it is now for VoIP. Yes, a bunch of new non-legacy services wouldn't use/want it. But the app for a PSTN-using service could specifically allow it. So the question comes down to what's the advantage to using unencrypted RTP? 1) No media gateway needed. This is the big one. Saves on $$$, saves on delay (sometimes a lot), may save on complexity in a PBX type of situation. But is there an issue due to ICE requirements? If those can't be turned off safely too, that kills this whole discussion I think. 2) Debug/etc tools work better with RTP. Not important. 3) May simplify/improve some E911 cases. Might be important; likely not. So, effectively it comes down to "is advantage 1 worth the complexity/risk?" Anyone want to defend that case? > - Alan - > > On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla wrote: >> Unless I'm missing something, if you (a) support an insecure mode and (b) allow >> negotiation of insecure vs. secure, there's not really any way to >> avoid a downgrade >> issue; the attacker can always pretend not to support security and how do you >> know better? Obviously, it helps if you can negotiate the use or non-use of >> media security over a secure-ish signaling channel, but that doesn't reduce >> the threat from the signaling service. >> >> Best, >> -Ekr >> -- Randell Jesup randell-ietf@jesup.org From juberti@google.com Fri Sep 9 14:27: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 D03C721F88B7 for ; Fri, 9 Sep 2011 14:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.849 X-Spam-Level: X-Spam-Status: No, score=-104.849 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMCBesaFMHj9 for ; Fri, 9 Sep 2011 14:27:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id E6BAD21F8715 for ; Fri, 9 Sep 2011 14:27:51 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p89LTh76019217 for ; Fri, 9 Sep 2011 14:29:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315603783; bh=amXv2hUe/7IGFVqK1otEf6hSCbQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Q/UZN4WI5V3ZOIbwfhtVXZC/00jSt39Y85Pm1W4QLpHBOjjFZF0C3WDyaE5frfBG9 9rQny13bBGXeltJnB9e6g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=sJOVTSiHd+v8DVba/tQu9zHHptXekhSt4Gn4BPBkdNdwGd2KjdXGYRn6shWsBq3uL yeEaTlPU7z51eJs5tcMfw== Received: from gya6 (gya6.prod.google.com [10.243.49.6]) by wpaz33.hot.corp.google.com with ESMTP id p89LTeKB020716 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 9 Sep 2011 14:29:42 -0700 Received: by gya6 with SMTP id 6so1535727gya.0 for ; Fri, 09 Sep 2011 14:29:42 -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; bh=AbEss+Bd7EiinDX6ByvXjnIOro1YE+2LwNikSDTxbxA=; b=frXkjkvPkAG6FqzKqO0o6TKCIyNLqF5hn3/4Exqj1UJlMAraP2KCsxFs4rMxLOz1o4 SFOOZwC8v7Qc7AfyWmdQ== Received: by 10.231.41.69 with SMTP id n5mr2954586ibe.92.1315603782336; Fri, 09 Sep 2011 14:29:42 -0700 (PDT) Received: by 10.231.41.69 with SMTP id n5mr2954578ibe.92.1315603782187; Fri, 09 Sep 2011 14:29:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.36.10 with HTTP; Fri, 9 Sep 2011 14:29:22 -0700 (PDT) In-Reply-To: <4E6A81EC.3080002@jesup.org> References: <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org> From: Justin Uberti Date: Fri, 9 Sep 2011 17:29:22 -0400 Message-ID: To: Randell Jesup Content-Type: multipart/alternative; boundary=0015177407d41a3b4e04ac88e052 X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 21:27:52 -0000 --0015177407d41a3b4e04ac88e052 Content-Type: text/plain; charset=UTF-8 On Fri, Sep 9, 2011 at 5:15 PM, Randell Jesup wrote: > On 9/9/2011 3:23 PM, Alan Johnston wrote: > >> Ekr is correct. If we allow RTP, which I think is a mistake, then >> there is always a downgrade attack. >> > > Yes, that's true. The same issue was involved in the best-effort-srtp > draft, which unfortunately > was dropped because CapNeg would "solve" it. (For historical note, it's > still not "solved" > because CapNeg support is >>>> more complex than best-effort-srtp and not > generally deployed, > and I doubt ever will be ala SDPng (though I'm not close to status on > CapNeg.) > > Hmmm. A real downgrade attack requires that the signalling be compromised. > I wonder if there > are characteristics of a webrtc transaction that could help avoid this sort > of attack (for example, > a secondary way out-of-scope here for the app to know ahead of time if the > target will need to > be downgraded). Or some way for the service to vouch for the downgrade > (i.e. wasn't a MITM). > You have to trust the service, but in this case you're doing so to this > degree anyways. > > > My point was that if we must support insecure media, we could avoid >> the complexity of CapNeg by not requiring a single pass non-secure >> media negotiation. >> > > There is another option. I talked about services that wanted to support > PSTN could decide if they > were willing to support a downgrade. The application could know it's > calling a PSTN gateway and > if it does know that, avoid a media gateway by not offering encrypted > media. > > I see a significant use-case for some services will be calling PSTN numbers > and services, much > as it is now for VoIP. > Yes, a bunch of new non-legacy services wouldn't use/want it. But the app > for a PSTN-using service > could specifically allow it. > > So the question comes down to what's the advantage to using unencrypted > RTP? > 1) No media gateway needed. This is the big one. Saves on $$$, saves on > delay (sometimes a lot), > may save on complexity in a PBX type of situation. > But is there an issue due to ICE requirements? If those can't be turned > off safely too, that kills this > whole discussion I think. > 2) Debug/etc tools work better with RTP. Not important. > 3) May simplify/improve some E911 cases. Might be important; likely not. In Quebec City, the mic discussion also noted a use case for enterprises that want to log communications. Regarding #1, the ability to avoid media gateways for "contemporary devices" has been a design requirement from the start. I think we need to have a clear understanding that this requirement creates serious, unavoidable problems before jettisoning it. > So, effectively it comes down to "is advantage 1 worth the > complexity/risk?" Anyone want to defend that > case? > > - Alan - >> >> On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla wrote: >> >>> Unless I'm missing something, if you (a) support an insecure mode and (b) >>> allow >>> >>> negotiation of insecure vs. secure, there's not really any way to >>> avoid a downgrade >>> issue; the attacker can always pretend not to support security and how do >>> you >>> know better? Obviously, it helps if you can negotiate the use or non-use >>> of >>> media security over a secure-ish signaling channel, but that doesn't >>> reduce >>> the threat from the signaling service. >>> >>> Best, >>> -Ekr >>> >>> > -- > Randell Jesup > randell-ietf@jesup.org > > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --0015177407d41a3b4e04ac88e052 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 9, 2011 at 5:15 PM, Randell = Jesup <rande= ll-ietf@jesup.org> wrote:
On 9/9/2011 3:23 PM, Alan Johnston wrote:
Ekr is correct. =C2=A0If we allow RTP, which I think is a mistake, then
there is always a downgrade attack.

Yes, that's true. =C2=A0The same issue was involved in the best-effort-= srtp draft, which unfortunately
was dropped because CapNeg would "solve" it. =C2=A0(For historica= l note, it's still not "solved"
because CapNeg support is >>>> more complex than best-effort-sr= tp and not generally deployed,
and I doubt ever will be ala SDPng (though I'm not close to status on C= apNeg.)

Hmmm. =C2=A0A real downgrade attack requires that the signalling be comprom= ised. =C2=A0I wonder if there
are characteristics of a webrtc transaction that could help avoid this sort= of attack (for example,
a secondary way out-of-scope here for the app to know ahead of time if the = target will need to
be downgraded). =C2=A0Or some way for the service to vouch for the downgrad= e (i.e. wasn't a MITM).
You have to trust the service, but in this case you're doing so to this= degree anyways.


My point was that if we must support insecure media, we could avoid
the complexity of CapNeg by not requiring a single pass non-secure
media negotiation.

There is another option. =C2=A0I talked about services that wanted to suppo= rt PSTN =C2=A0could decide if they
were willing to support a downgrade. =C2=A0The application could know it= 9;s calling a PSTN gateway and
if it does know that, avoid a media gateway by not offering encrypted media= .

I see a significant use-case for some services will be calling PSTN numbers= and services, much
as it is now for VoIP.
Yes, a bunch of new non-legacy services wouldn't use/want it. =C2=A0But= the app for a PSTN-using service
could specifically allow it.

So the question comes down to what's the advantage to using unencrypted= RTP?
1) No media gateway needed. =C2=A0This is the big one. =C2=A0Saves on $$$, = saves on delay (sometimes a lot),
=C2=A0 =C2=A0may save on complexity in a PBX type of situation.
=C2=A0 =C2=A0But is there an issue due to ICE requirements? =C2=A0If those= can't be turned off safely too, that kills this
=C2=A0 =C2=A0whole discussion I think.
2) Debug/etc tools work better with RTP. =C2=A0Not important.
3) May simplify/improve some E911 cases. =C2=A0Might be important; likely n= ot.

In Quebec City, the mic discussion also= noted a use case for enterprises that want to log communications.

Regarding #1, the ability to avoid media gateways for "= contemporary devices" has been a design requirement from the start. I = think we need to have a clear understanding that this requirement creates s= erious, unavoidable problems before jettisoning it.

=C2=A0

So, effectively it comes down to "is advantage 1 worth the complexity/= risk?" =C2=A0Anyone want to defend that
case?

- Alan -

On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla<ekr@rtfm.com> =C2=A0wrote:
Unless I'm missing something, if you (a) support an insecure mode and (= b) allow

negotiation of insecure vs. secure, there's not really any way to
avoid a downgrade
issue; the attacker can always pretend not to support security and how do y= ou
know better? Obviously, it helps if you can negotiate the use or non-use of=
media security over a secure-ish signaling channel, but that doesn't re= duce
the threat from the signaling service.

Best,
-Ekr


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


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

--0015177407d41a3b4e04ac88e052-- From dzonatas@gmail.com Fri Sep 9 14:30: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 61D3921F88B7 for ; Fri, 9 Sep 2011 14:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 P3cojelprZC2 for ; Fri, 9 Sep 2011 14:30:53 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7569821F8715 for ; Fri, 9 Sep 2011 14:30:53 -0700 (PDT) Received: by yie12 with SMTP id 12so690799yie.31 for ; Fri, 09 Sep 2011 14:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tVvCm5Ip3F6bfuhTM2TRc7HsceoqoX5th5ddMc8PL90=; b=BXojn0UuMkGMDWvWU8+sVegHxV2HeJhQhTmt+2meNClfuXk9Df71h2c3sSSU7C7vRV YzMmFjE9GtskZwqJ3Z+M5LZDze1LA9twa3nFaFloledBWM6aHEn6WtFWUQR0cOUZgJVp Pi1YBoE1z0c3ivOMwjTVpOuE/adgxyQRf2JDo= Received: by 10.42.29.133 with SMTP id r5mr404947icc.233.1315603969136; Fri, 09 Sep 2011 14:32:49 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id el2sm9642445ibb.10.2011.09.09.14.32.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Sep 2011 14:32:48 -0700 (PDT) Message-ID: <4E6A8676.6060708@gmail.com> Date: Fri, 09 Sep 2011 14:34:46 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: Christer Holmberg References: <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <7F2072F1E0DE894DA4B517B93C6A05852233D45F96@ESESSCMS0356.eemea.ericsson.se> <4E6A7D47.5020201@gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45F98@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233D45F98@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 21:30:54 -0000 Real-time is your default security; "to avoid" that in this WG.... edited: The only security needed for an API is the guarantee/certificate of the pure software VM process (i.e. OSI) ("to avoid CapNeg"); otherwise, CapNeg is hardware hacking. [Not everybody complies with the strictness of nuclear licenses, and clarity only goes so far.] On 09/09/2011 02:14 PM, Christer Holmberg wrote: > What security do we avoid by avoiding CapNeg? > > Regards, > > Christer > > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Dzonatas Sol > Sent: 9. syyskuuta 2011 23:56 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] > > On 09/09/2011 01:22 PM, Christer Holmberg wrote: > >> Hi, >> >> In general I agree with Alan that we should try to avoid CapNeg. >> >> > The only security needed "to avoid" that is the guarantee/certificate of the pure software VM process (i.e. OSI); otherwise, CapNeg is hardware hacking. > > The stateless API is the default capabilities, so there is no carrier for some secure state otherwise. Discovery of further capabilities is ideal in duration of the carrier. > > I find it helpful to munge client and server APIs into one API set instead of separate definitions as proof. Capabilities then are just driver issues, not application issues. > > > >> Regarding AVPF vs AVP, we also first need to decide whether AVP will be supported in the first place. Then, if we decide to support AVP, we have to make a similar decision whether to use CapNeg or to rely on a "fallback" offer/answer. >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Alan Johnston >> Sent: 9. syyskuuta 2011 22:24 >> To: Eric Rescorla >> Cc: Randell Jesup; Jonathan Lennox; rtcweb@ietf.org >> Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and >> offer/answer)] >> >> Ekr is correct. If we allow RTP, which I think is a mistake, then there is always a downgrade attack. >> >> My point was that if we must support insecure media, we could avoid the complexity of CapNeg by not requiring a single pass non-secure media negotiation. >> >> - Alan - >> >> On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla wrote: >> >> >>> On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman >>> wrote: >>> >>> >>>> On 9/9/11 10:47 AM, Alan Johnston wrote: >>>> >>>> >>>>> The default will be SRTP - this can be expressed in SDP without >>>>> CapNeg. Should the RTCWEB clients choose to instead negotiate RTP, >>>>> then this could be done with a second SDP Offer/Answer exchange. >>>>> >>>>> >>>> I believe you've just designed a downgrade vulnerability. >>>> >>>> >>> Unless I'm missing something, if you (a) support an insecure mode and >>> (b) allow negotiation of insecure vs. secure, there's not really any >>> way to avoid a downgrade issue; the attacker can always pretend not >>> to support security and how do you know better? Obviously, it helps >>> if you can negotiate the use or non-use of media security over a >>> secure-ish signaling channel, but that doesn't reduce the threat from >>> the signaling service. >>> >>> Best, >>> -Ekr >>> >>> >>> >> _______________________________________________ >> 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 >> >> >> > > -- > --- http://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering > Ag-Biotech, Virtual Reality, Consultant > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From dzonatas@gmail.com Fri Sep 9 14:58: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 AB83221F889A for ; Fri, 9 Sep 2011 14:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.926 X-Spam-Level: X-Spam-Status: No, score=-3.926 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IRyKBKW57ET for ; Fri, 9 Sep 2011 14:58:35 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id C528021F891D for ; Fri, 9 Sep 2011 14:58:35 -0700 (PDT) Received: by pzk33 with SMTP id 33so10730667pzk.18 for ; Fri, 09 Sep 2011 15:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=LUX7D27ibbDbag+j8SvwYjyAsXxJafF9BULK9yevePk=; b=J1kvWXpjLKcTf0+t6zm9tQo/4TrTi6w/3z2vEN5DogzyT0QLkh8lUCJCGsQskvsqye gLFxp5tntnMhmtA2/+aVQZhCQpbcNkRiOAGn6ZfE7aYQBRjhMLCrmU00mvXpg7kyw0vC X7mDXmMDoFmU4JQYv9S4cuZLisk9N66qy0f/g= Received: by 10.68.55.100 with SMTP id r4mr1811527pbp.124.1315605631645; Fri, 09 Sep 2011 15:00:31 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id e8sm22665810pbc.8.2011.09.09.15.00.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Sep 2011 15:00:31 -0700 (PDT) Message-ID: <4E6A8CF5.2030801@gmail.com> Date: Fri, 09 Sep 2011 15:02:29 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org> In-Reply-To: <4E6A81EC.3080002@jesup.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 09 Sep 2011 21:58:36 -0000 On 09/09/2011 02:15 PM, Randell Jesup wrote: > On 9/9/2011 3:23 PM, Alan Johnston wrote: >> Ekr is correct. If we allow RTP, which I think is a mistake, then >> there is always a downgrade attack. > > Yes, that's true. The same issue was involved in the best-effort-srtp > draft, which unfortunately > was dropped because CapNeg would "solve" it. (For historical note, > it's still not "solved" > because CapNeg support is >>>> more complex than best-effort-srtp and > not generally deployed, > and I doubt ever will be ala SDPng (though I'm not close to status on > CapNeg.) > > Hmmm. A real downgrade attack requires that the signalling be > compromised. I wonder if there > are characteristics of a webrtc transaction that could help avoid this > sort of attack (for example, > a secondary way out-of-scope here for the app to know ahead of time if > the target will need to > be downgraded). Or some way for the service to vouch for the > downgrade (i.e. wasn't a MITM). > You have to trust the service, but in this case you're doing so to > this degree anyways. > >> My point was that if we must support insecure media, we could avoid >> the complexity of CapNeg by not requiring a single pass non-secure >> media negotiation. > > There is another option. I talked about services that wanted to > support PSTN could decide if they > were willing to support a downgrade. The application could know it's > calling a PSTN gateway and > if it does know that, avoid a media gateway by not offering encrypted > media. > > I see a significant use-case for some services will be calling PSTN > numbers and services, much > as it is now for VoIP. > Yes, a bunch of new non-legacy services wouldn't use/want it. But the > app for a PSTN-using service > could specifically allow it. > > So the question comes down to what's the advantage to using > unencrypted RTP? > 1) No media gateway needed. This is the big one. Saves on $$$, saves > on delay (sometimes a lot), > may save on complexity in a PBX type of situation. > But is there an issue due to ICE requirements? If those can't be > turned off safely too, that kills this > whole discussion I think. The ICE toggle already exists. Perhaps you meant non-media in the insecure audio-only state? Also known as high-fidelity. > 2) Debug/etc tools work better with RTP. Not important. > 3) May simplify/improve some E911 cases. Might be important; likely not. > > So, effectively it comes down to "is advantage 1 worth the > complexity/risk?" Anyone want to defend that > case? The virtual "stateless" driver supposedly doesn't exist unless you want to pass DAE only for CapNeg and rely on object recognition and painful convex optimizations. Again, shape is reliable, not a risk. Do you let the federated-servers know these traffic-shapes? > >> - Alan - >> >> On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla wrote: >>> Unless I'm missing something, if you (a) support an insecure mode >>> and (b) allow >>> negotiation of insecure vs. secure, there's not really any way to >>> avoid a downgrade >>> issue; the attacker can always pretend not to support security and >>> how do you >>> know better? Obviously, it helps if you can negotiate the use or >>> non-use of >>> media security over a secure-ish signaling channel, but that doesn't >>> reduce >>> the threat from the signaling service. >>> >>> Best, >>> -Ekr >>> > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From pkyzivat@alum.mit.edu Fri Sep 9 21:04: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 7173821F8565 for ; Fri, 9 Sep 2011 21:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 BpMwP8rHGbUi for ; Fri, 9 Sep 2011 21:04:10 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 84BE421F855D for ; Fri, 9 Sep 2011 21:04:09 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta07.westchester.pa.mail.comcast.net with comcast id Wo8n1h0031c6gX857s66Sp; Sat, 10 Sep 2011 04:06:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta23.westchester.pa.mail.comcast.net with comcast id Ws641h00n0tdiYw3js64Y1; Sat, 10 Sep 2011 04:06:06 +0000 Message-ID: <4E6AE22A.2070106@alum.mit.edu> Date: Sat, 10 Sep 2011 00:06:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org> In-Reply-To: <4E6A81EC.3080002@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Sep 2011 04:04:11 -0000 This isn't really an rtcweb issue - its a secure media O/A issue. The exact same thing could arise if we had somebody with an urgent desire to do secure media with fallback to insecure media in SIP. All the arguments against capneg would be exactly the same. The problem is that people aren't finding capneg a usable solution to this problem, just the way that people didn't find SDPng a solution to the inadequacies of SDP. While it is possible for rtcweb to adopt its own solution to the problem, that only solves half the problem. And it then creates an interop problem with SIP. The "right" solution is to go back to mmusic for an O/A mechanism for secure/insecure media that is more usable than capneg. If its deemed that doing this would take too long, and its necessary to do something special for rtcweb, then a parallel effort ought to be started to sort out how it can interoperate with SIP or anything else that uses O/A. (The "good" news is that I doubt there are many (any?) deployed uses of capneg in SIP for negotiation of secure/insecure media.) Thanks, Paul On 9/9/11 5:15 PM, Randell Jesup wrote: > On 9/9/2011 3:23 PM, Alan Johnston wrote: >> Ekr is correct. If we allow RTP, which I think is a mistake, then >> there is always a downgrade attack. > > Yes, that's true. The same issue was involved in the best-effort-srtp > draft, which unfortunately > was dropped because CapNeg would "solve" it. (For historical note, it's > still not "solved" > because CapNeg support is >>>> more complex than best-effort-srtp and > not generally deployed, > and I doubt ever will be ala SDPng (though I'm not close to status on > CapNeg.) > > Hmmm. A real downgrade attack requires that the signalling be > compromised. I wonder if there > are characteristics of a webrtc transaction that could help avoid this > sort of attack (for example, > a secondary way out-of-scope here for the app to know ahead of time if > the target will need to > be downgraded). Or some way for the service to vouch for the downgrade > (i.e. wasn't a MITM). > You have to trust the service, but in this case you're doing so to this > degree anyways. > >> My point was that if we must support insecure media, we could avoid >> the complexity of CapNeg by not requiring a single pass non-secure >> media negotiation. > > There is another option. I talked about services that wanted to support > PSTN could decide if they > were willing to support a downgrade. The application could know it's > calling a PSTN gateway and > if it does know that, avoid a media gateway by not offering encrypted > media. > > I see a significant use-case for some services will be calling PSTN > numbers and services, much > as it is now for VoIP. > Yes, a bunch of new non-legacy services wouldn't use/want it. But the > app for a PSTN-using service > could specifically allow it. > > So the question comes down to what's the advantage to using unencrypted > RTP? > 1) No media gateway needed. This is the big one. Saves on $$$, saves on > delay (sometimes a lot), > may save on complexity in a PBX type of situation. > But is there an issue due to ICE requirements? If those can't be turned > off safely too, that kills this > whole discussion I think. > 2) Debug/etc tools work better with RTP. Not important. > 3) May simplify/improve some E911 cases. Might be important; likely not. > > So, effectively it comes down to "is advantage 1 worth the > complexity/risk?" Anyone want to defend that > case? > >> - Alan - >> >> On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla wrote: >>> Unless I'm missing something, if you (a) support an insecure mode and >>> (b) allow >>> negotiation of insecure vs. secure, there's not really any way to >>> avoid a downgrade >>> issue; the attacker can always pretend not to support security and >>> how do you >>> know better? Obviously, it helps if you can negotiate the use or >>> non-use of >>> media security over a secure-ish signaling channel, but that doesn't >>> reduce >>> the threat from the signaling service. >>> >>> Best, >>> -Ekr >>> > From oej@edvina.net Sat Sep 10 00:15: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 0421A21F8A35 for ; Sat, 10 Sep 2011 00:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLELT8M46V8D for ; Sat, 10 Sep 2011 00:15:17 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3297821F89BA for ; Sat, 10 Sep 2011 00:15:17 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 0C3D9754BCE4 for ; Sat, 10 Sep 2011 07:17:10 +0000 (UTC) From: "Olle E. Johansson" Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_85107E4B-22E4-49AB-9F99-26F9C76932B0" Date: Sat, 10 Sep 2011 09:17:16 +0200 In-Reply-To: <4E6A81EC.3080002@jesup.org> To: rtcweb@ietf.org References: <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org> Message-Id: <78CC1B42-392D-4311-9417-33CC702A2FD1@edvina.net> X-Mailer: Apple Mail (2.1244.3) Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Sep 2011 07:15:18 -0000 --Apple-Mail=_85107E4B-22E4-49AB-9F99-26F9C76932B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 9 sep 2011 kl. 23:15 skrev Randell Jesup: > 3) May simplify/improve some E911 cases. Might be important; likely = not. 911/112 cases might be typical phone calls that *require* = confidentiality. In Sweden 112 is used for a lot more than accidents - = call the priest, report child abuse and others that really are calls = that in now way should be listened-in to by other users on the LAN or = the IP network. /O= --Apple-Mail=_85107E4B-22E4-49AB-9F99-26F9C76932B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
3) May = simplify/improve some E911 cases.  Might be important; likely = not.

911/112 cases might be = typical phone calls that *require* confidentiality. In Sweden 112 is = used for a lot more than accidents - call the priest, report child abuse = and others that really are calls that in now way should be listened-in = to by other users on the LAN or the IP = network.

/O
= --Apple-Mail=_85107E4B-22E4-49AB-9F99-26F9C76932B0-- From oej@edvina.net Sat Sep 10 00:50: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 A3ADF21F8772 for ; Sat, 10 Sep 2011 00:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.038, 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 JD4uE1t5lKVe for ; Sat, 10 Sep 2011 00:50:05 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 536DD21F8715 for ; Sat, 10 Sep 2011 00:50:02 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 835E5754BCE4; Sat, 10 Sep 2011 07:51:55 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Sat, 10 Sep 2011 09:52:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <16BE1F12-0AB7-45D5-BA4A-3E0A59BE1E62@edvina.net> References: <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype .net> To: Eric Rescorla X-Mailer: Apple Mail (2.1244.3) Cc: Randell Jesup , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Sep 2011 07:50:05 -0000 9 sep 2011 kl. 20:35 skrev Eric Rescorla: > On Fri, Sep 9, 2011 at 11:11 AM, Matthew Kaufman > wrote: >> On 9/9/11 10:47 AM, Alan Johnston wrote: >>>=20 >>> The default will be SRTP - this can be >>> expressed in SDP without CapNeg. Should the RTCWEB clients choose = to >>> instead negotiate RTP, then this could be done with a second SDP >>> Offer/Answer exchange. >>=20 >> I believe you've just designed a downgrade vulnerability. >=20 > Unless I'm missing something, if you (a) support an insecure mode and = (b) allow > negotiation of insecure vs. secure, there's not really any way to > avoid a downgrade > issue; the attacker can always pretend not to support security and how = do you > know better? Obviously, it helps if you can negotiate the use or = non-use of > media security over a secure-ish signaling channel, but that doesn't = reduce > the threat from the signaling service. >=20 Have we solved the issues with a "secure-ish signaling channel" = anywhere? I don't think we can assume that they exist in the = architecture and build solutions based on that assumption.=20 SIP/TLS end2end is still very hard to handle. Single hop is definitely = protected assuming that we have a CA trust path that we trust, but = mutli-hop is still very hard to assure as being "secure-ish" after all = these years with SIP. HTTPS is not an answer here either, especially not with the deployment = of enterprise SSL proxys that fake a site certificate in order to be = able to listen-in to the traffic. /O From oej@edvina.net Sat Sep 10 00:52: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 5FB3A21F84FC for ; Sat, 10 Sep 2011 00:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6OpqLxM8xOE for ; Sat, 10 Sep 2011 00:52:57 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id B934321F8563 for ; Sat, 10 Sep 2011 00:52:57 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 65541754BCE4; Sat, 10 Sep 2011 07:54:53 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_685975E1-1A7B-4FA5-9074-38A99E6513FB" From: "Olle E. Johansson" In-Reply-To: Date: Sat, 10 Sep 2011 09:54:59 +0200 Message-Id: <1541FDA8-C3F6-4D24-BEC4-60EDACB6B582@edvina.net> References: <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype .net> To: Roman Shpount X-Mailer: Apple Mail (2.1244.3) Cc: Randell Jesup , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Sep 2011 07:52:58 -0000 --Apple-Mail=_685975E1-1A7B-4FA5-9074-38A99E6513FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 9 sep 2011 kl. 21:39 skrev Roman Shpount: > Please keep in mind that secure media is not limited to SRTP. RTP = over DTLS is as or more secure then SRTP Interesting. Can you please elaborate? I haven't heard that being stated = before and it made me curious. Thanks, /O= --Apple-Mail=_685975E1-1A7B-4FA5-9074-38A99E6513FB Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
9 sep 2011 kl. 21:39 skrev Roman Shpount:

 Please keep in mind that secure media is not limited to SRTP. RTP over DTLS is as or more secure then SRTP

Interesting. Can you please elaborate? I haven't heard that being stated before and it made me curious.

Thanks,
/O
--Apple-Mail=_685975E1-1A7B-4FA5-9074-38A99E6513FB-- From roman@telurix.com Sat Sep 10 04:45: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 D7E2D21F851A for ; Sat, 10 Sep 2011 04:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[AWL=0.167, 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 afVD+3SdicnF for ; Sat, 10 Sep 2011 04:45:52 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0F00321F8515 for ; Sat, 10 Sep 2011 04:45:51 -0700 (PDT) Received: by yie12 with SMTP id 12so1032741yie.31 for ; Sat, 10 Sep 2011 04:47:49 -0700 (PDT) Received: by 10.68.0.104 with SMTP id 8mr1009524pbd.381.1315655269021; Sat, 10 Sep 2011 04:47:49 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx.google.com with ESMTPS id i3sm19223196pbg.10.2011.09.10.04.47.46 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Sep 2011 04:47:47 -0700 (PDT) Received: by pzk33 with SMTP id 33so13680014pzk.18 for ; Sat, 10 Sep 2011 04:47:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.43.8 with SMTP id s8mr2297224pbl.389.1315655266516; Sat, 10 Sep 2011 04:47:46 -0700 (PDT) Received: by 10.68.43.136 with HTTP; Sat, 10 Sep 2011 04:47:46 -0700 (PDT) In-Reply-To: <1541FDA8-C3F6-4D24-BEC4-60EDACB6B582@edvina.net> References: <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <1541FDA8-C3F6-4D24-BEC4-60EDACB6B582@edvina.net> Date: Sat, 10 Sep 2011 07:47:46 -0400 Message-ID: From: Roman Shpount To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=bcaec5395f24cebec204ac94dc27 Cc: Randell Jesup , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Sep 2011 11:45:53 -0000 --bcaec5395f24cebec204ac94dc27 Content-Type: text/plain; charset=ISO-8859-1 SRTP is a simple media encryption using signaling channel exchanged keys and salt to do simple counter mode AES with content signing using HMAC-SHA1. It also implements a dictionary based replay protection. DTLS offers wider encryption and content signing algorithm selection, end-point handshake based on certificates, certificate validation using certificate authority. In general, DTLS offers same protection that TLS does, while SRTP is simplified and optimized for media. In regard to the overall discussion, if we want interop with existing VoIP infrastructure, we need to support RTP with AVP. 99% of all SIP deployments do not support and cannot support SRTP. None of the wholesale VoIP telephony carriers support SRTP (some offer VPN or direct interconnects if you care about privacy). Consumer VoIP companies (like Vonage or Comcast) do not support or use SRTP for any calls from their customer equipment. In places were encryption is supported (like Skype) it is often either something different from SRTP. In order to connect to all those environments without media proxy we need plain RTP. Otherwise we will need to put a media proxy (SBC) to connect to them. Finally, there is a reasonably low expectation of privacy as far as voice calls are concerned. Most of the PSTN phone calls go over the wire connected to an unlocked box outside your house. Anybody (and by this I mean anybody walking down the street) can listen to your calls including emergency ones. People like to raise security as concern but for 99% of the calls, as well as for 99% of the web traffic which goes over HTTP vs HTTPS, nobody cares. _____________ Roman Shpount On Sat, Sep 10, 2011 at 3:54 AM, Olle E. Johansson wrote: > > 9 sep 2011 kl. 21:39 skrev Roman Shpount: > > Please keep in mind that secure media is not limited to SRTP. RTP over > DTLS is as or more secure then SRTP > > > Interesting. Can you please elaborate? I haven't heard that being stated > before and it made me curious. > > Thanks, > /O > --bcaec5395f24cebec204ac94dc27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable SRTP is a simple media encryption using signaling channel exchanged keys an= d salt to do simple counter mode AES with content signing using HMAC-SHA1. = It also implements a dictionary based replay protection. DTLS offers wider = encryption and content signing algorithm selection, end-point handshake bas= ed on certificates, certificate validation using certificate authority. In = general, DTLS offers same protection that TLS does, while SRTP is simplifie= d and optimized for media.

In regard to the overall discussion, if we want interop with existing V= oIP infrastructure, we need to support RTP with AVP. 99% of all SIP deploym= ents do not support and cannot support SRTP. None of the wholesale VoIP tel= ephony carriers support SRTP (some offer VPN or direct interconnects if you= care about privacy). Consumer VoIP companies (like Vonage or Comcast) do n= ot support or use SRTP for any calls from their customer equipment. In plac= es were encryption is supported (like Skype) it is often either something d= ifferent from SRTP. In order to connect to all those environments without m= edia proxy we need plain RTP. Otherwise we will need to put a media proxy (= SBC) to connect to them.

Finally, there is a reasonably low expectation of privacy as far as voi= ce calls are concerned. Most of the PSTN phone calls go over the wire conne= cted to an unlocked box outside your house. Anybody (and by this I mean any= body walking down the street) can listen to your calls including emergency = ones. People like to raise security as concern but for 99% of the calls, as= well as for 99% of the web traffic which goes over HTTP vs HTTPS, nobody c= ares.
_____________
Roman Shpount


On Sat, Sep 10, 2011 at 3:54 AM, Olle E.= Johansson <oej@edvi= na.net> wrote:

9 sep 2011 kl. 21:39 skre= v Roman Shpount:

=A0Please keep in = mind that secure media is not limited to SRTP. RTP over DTLS is as or more = secure then SRTP

Interesting. Can you please elaborate? I haven't heard that being state= d before and it made me curious.

Than= ks,
/O

--bcaec5395f24cebec204ac94dc27-- From matthew.kaufman@skype.net Sat Sep 10 09: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 9EFAF21F84D9 for ; Sat, 10 Sep 2011 09:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.235 X-Spam-Level: X-Spam-Status: No, score=-5.235 tagged_above=-999 required=5 tests=[AWL=1.364, 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 Z5-v4FNNEFwU for ; Sat, 10 Sep 2011 09:21:43 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id D4A9521F84D7 for ; Sat, 10 Sep 2011 09:21:42 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 8C2B97FE; Sat, 10 Sep 2011 18:23:38 +0200 (CEST) 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=5/PooXDDkLIgLz 0m+7wjib1+BiU=; b=gKlX8DYeH7tWCYTTcbTjzD6KGYrIF4n3TwTFCa3f0+p1Nj rwHeK0sotxIoEsGhbCF5dfEWkjeetkYaAWs73gbQLPvXHTf+ccvoUxtyjsCAtf4d ccTz5iW9u7veQU+Y1UZGbwkRwdAC3PRj7RirEBT7D+omNowefQE419TpTLgXI= 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=SY9H+n56dGOjDP94tdzV02 5ZgS8Ckx7DwdvLsGXXAF62tdEyYunIhE9kmpFbgBE887vBFu4qrShYCkrkdOYhP1 UP/B6IJkwPATo8YLhAs9xufCWozWnmde0zG6b9wpO7DqaxY4/V4HrZz4NVOCl6XF Nt+9ECNQfYxweycKcsKo8= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 89B937F8; Sat, 10 Sep 2011 18:23:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 5F69135075D0; Sat, 10 Sep 2011 18:23:38 +0200 (CEST) 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 CiuEsxWPS780; Sat, 10 Sep 2011 18:23:37 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 4BB7135075CE; Sat, 10 Sep 2011 18:23:36 +0200 (CEST) Message-ID: <4E6B8ED1.6040601@skype.net> Date: Sat, 10 Sep 2011 09:22:41 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Roman Shpount References: <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <1541FDA8-C3F6-4D24-BEC4-60EDACB6B582@edvina.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randell Jesup , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Sep 2011 16:21:44 -0000 On 9/10/2011 4:47 AM, Roman Shpount wrote: > SRTP is a simple media encryption using signaling channel exchanged > keys and salt to do simple counter mode AES with content signing using > HMAC-SHA1. It also implements a dictionary based replay protection. > DTLS offers wider encryption and content signing algorithm selection, > end-point handshake based on certificates, certificate validation > using certificate authority. In general, DTLS offers same protection > that TLS does, while SRTP is simplified and optimized for media. I think you left out a description of DTLS-SRTP and made other simplifications. > > In regard to the overall discussion, if we want interop with existing > VoIP infrastructure, we need to support RTP with AVP. 99% of all SIP > deployments do not support and cannot support SRTP. They also cannot complete the ICE STUN handshake that is required to prove to the browser that they are willing to accept media. > None of the wholesale VoIP telephony carriers support SRTP (some offer > VPN or direct interconnects if you care about privacy). Likewise regarding ICE. > Consumer VoIP companies (like Vonage or Comcast) do not support or use > SRTP for any calls from their customer equipment. And again regarding ICE. > In places were encryption is supported (like Skype) it is often either > something different from SRTP. In order to connect to all those > environments without media proxy we need plain RTP. Even if we need plain RTP, that isn't an argument for SDES-keyed SRTP. Matthew Kaufman From dzonatas@gmail.com Sat Sep 10 09:29: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 15E0E21F8744 for ; Sat, 10 Sep 2011 09:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.92 X-Spam-Level: X-Spam-Status: No, score=-3.92 tagged_above=-999 required=5 tests=[AWL=-0.321, 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 u5HQXD1FQa50 for ; Sat, 10 Sep 2011 09:29:58 -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 6C22521F872A for ; Sat, 10 Sep 2011 09:29:58 -0700 (PDT) Received: by ywa6 with SMTP id 6so830577ywa.31 for ; Sat, 10 Sep 2011 09:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=HK3q6MdCRcDNrwP7HWeNJdYinzWJKDmVIJHKbBqALYU=; b=YGDhG8RWiPagSUMEtz+//2uRykpqjk+n9KSJ1CsHtLpvfV2zYCG9LAsvQatG4DQmyb Jak6e2nUzGLk0EJPZ3mt1t06epJJQPiTnl2/rfzDYfTbJfyqRBkG7oveg1ytv7G4FTS6 HVWQyXbWbU3oSw7vHWIayDeyrmVsccEbQaywQ= Received: by 10.68.0.162 with SMTP id 2mr56052pbf.191.1315672315914; Sat, 10 Sep 2011 09:31:55 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id i4sm28549738pbr.4.2011.09.10.09.31.52 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Sep 2011 09:31:55 -0700 (PDT) Message-ID: <4E6B9171.1010308@gmail.com> Date: Sat, 10 Sep 2011 09:33:53 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <1541FDA8-C3F6-4D24-BEC4-60EDACB6B582@edvina.net> <4E6B8ED1.6040601@skype.net> In-Reply-To: <4E6B8ED1.6040601@skype.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Sep 2011 16:29:59 -0000 On 09/10/2011 09:22 AM, Matthew Kaufman wrote: > > Even if we need plain RTP, that isn't an argument for SDES-keyed SRTP. > SRTP appears useful for subscriptions. -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From dzonatas@gmail.com Sat Sep 10 11: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 2AF2821F84C9 for ; Sat, 10 Sep 2011 11:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.915 X-Spam-Level: X-Spam-Status: No, score=-3.915 tagged_above=-999 required=5 tests=[AWL=-0.316, 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 IVY38SdR8ubg for ; Sat, 10 Sep 2011 11:16:29 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8A14F21F84B8 for ; Sat, 10 Sep 2011 11:16:29 -0700 (PDT) Received: by pzk33 with SMTP id 33so15046701pzk.18 for ; Sat, 10 Sep 2011 11:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EEc1BVXAAZ508CUUhtsRG9RPuP/ItJYQVRLPeQ04UoU=; b=aGY2sOEdhzozid6vtgEaxeaqoJq5inKkHP/RkyaTSKJyCrnELNBSPxaUBDHC/ny2LF L+nB/21Jp4UUOCkvarxx839ZbKAgD4itRBHDIXTJBla/3WaYijYterEAviw37sN6tDa0 g7mKwmqk4cLMoHCMw75A9NYcC/kVOwpu0d1Lo= Received: by 10.68.1.104 with SMTP id 8mr1765214pbl.91.1315678707533; Sat, 10 Sep 2011 11:18:27 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id i4sm29145382pbr.4.2011.09.10.11.18.24 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Sep 2011 11:18:26 -0700 (PDT) Message-ID: <4E6BAA68.7020001@gmail.com> Date: Sat, 10 Sep 2011 11:20:24 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <1541FDA8-C3F6-4D24-BEC4-60EDACB6B582@edvina.net> <4E6B8ED1.6040601@skype.net> <4E6B9171.1010308@gmail.com> In-Reply-To: <4E6B9171.1010308@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Sep 2011 18:16:30 -0000 On 09/10/2011 09:33 AM, Dzonatas Sol wrote: > On 09/10/2011 09:22 AM, Matthew Kaufman wrote: >> >> Even if we need plain RTP, that isn't an argument for SDES-keyed SRTP. >> > > SRTP appears useful for subscriptions. > Yes, I'm thinking that this WG can say JS *needs* subscriptions to virtual dirvers (or at least ABI drivers), and that JS works on RFC. Is that a bend? -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From dzonatas@gmail.com Sat Sep 10 11:33: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 1DF1F21F87F0 for ; Sat, 10 Sep 2011 11:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[AWL=-0.311, 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 lKSbw3FL9GwB for ; Sat, 10 Sep 2011 11:33:31 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD5221F87E2 for ; Sat, 10 Sep 2011 11:33:31 -0700 (PDT) Received: by gwb17 with SMTP id 17so3304217gwb.15 for ; Sat, 10 Sep 2011 11:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=9nObvKIzvdc1/ndBWWi/X60Ee3+D3Kloxakg66Ecxy4=; b=mUJvElyrhqeAUpYgMHCSIW+NnBeSyzkDB9doFW1Ypw4aauVgWux6ShvGY/f9Vxj8jl 5c20+zXUUhErs6GWWBV+FJEf8PgKfi9hGuejjh/+A8fvcF0i75LSej8ELJ0TJMJZ9i7E BvpH8HhuHnzVy0T3+SIZ7bDqY/q7l0TVA429k= Received: by 10.68.42.137 with SMTP id o9mr2593308pbl.272.1315679727483; Sat, 10 Sep 2011 11:35:27 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id p7sm29455151pbe.0.2011.09.10.11.35.26 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Sep 2011 11:35:26 -0700 (PDT) Message-ID: <4E6BAE67.9030009@gmail.com> Date: Sat, 10 Sep 2011 11:37:27 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <1541FDA8-C3F6-4D24-BEC4-60EDACB6B582@edvina.net> <4E6B8ED1.6040601@skype.net> <4E6B9171.1010308@gmail.com> <4E6BAA68.7020001@gmail.com > In-Reply-To: <4E6BAA68.7020001@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Sep 2011 18:33:32 -0000 On 09/10/2011 11:20 AM, Dzonatas Sol wrote: > On 09/10/2011 09:33 AM, Dzonatas Sol wrote: >> On 09/10/2011 09:22 AM, Matthew Kaufman wrote: >>> >>> Even if we need plain RTP, that isn't an argument for SDES-keyed SRTP. >>> >> >> SRTP appears useful for subscriptions. >> > > Yes, I'm thinking that this WG can say JS *needs* subscriptions to > virtual dirvers (or at least ABI drivers), and that JS works on RFC. > > Is that a bend? > If 16-bit, use ICE, otherwise use 64-bit ABI. Simple? -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From dzonatas@gmail.com Sat Sep 10 11:41: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 E206421F84B9 for ; Sat, 10 Sep 2011 11:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.905 X-Spam-Level: X-Spam-Status: No, score=-3.905 tagged_above=-999 required=5 tests=[AWL=-0.306, 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 GUABnXgpBQF2 for ; Sat, 10 Sep 2011 11:41:28 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4117D21F84B4 for ; Sat, 10 Sep 2011 11:41:28 -0700 (PDT) Received: by pzk33 with SMTP id 33so15131260pzk.18 for ; Sat, 10 Sep 2011 11:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4890Uc85WdnY8/hJA8jSswoFOr80PxVZipLEWJsw4r0=; b=I/xYA5iiPZgG06IUPfduI5P48T51JNRWiB/bOeU3+pdW0UpA+QKY1AqEQ4Gs/VTzOt eTsugskWni/2z+YRRb29NAsOfn0+5C9XRyD2LRa347/8GgM1cDcg5wnfUHCibBlhMzj6 nKTdgvwnCi6Z9iTRRdNk3EsbCSUOREWapppoI= Received: by 10.68.30.229 with SMTP id v5mr463962pbh.86.1315680206741; Sat, 10 Sep 2011 11:43:26 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id z1sm29269679pbz.6.2011.09.10.11.43.25 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Sep 2011 11:43:26 -0700 (PDT) Message-ID: <4E6BB046.7060002@gmail.com> Date: Sat, 10 Sep 2011 11:45:26 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <1541FDA8-C3F6-4D24-BEC4-60EDACB6B582@edvina.net> <4E6B8ED1.6040601@skype.net> <4E6B9171.1010308@gmail.com> <4E6BAA68.7020001@gmail.com> <4E6BAE67.9030009@gmail.com> In-Reply-To: <4E6BAE67.9030009@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Sep 2011 18:41:29 -0000 On 09/10/2011 11:37 AM, Dzonatas Sol wrote: > On 09/10/2011 11:20 AM, Dzonatas Sol wrote: >> On 09/10/2011 09:33 AM, Dzonatas Sol wrote: >>> On 09/10/2011 09:22 AM, Matthew Kaufman wrote: >>>> >>>> Even if we need plain RTP, that isn't an argument for SDES-keyed SRTP. >>>> >>> >>> SRTP appears useful for subscriptions. >>> >> >> Yes, I'm thinking that this WG can say JS *needs* subscriptions to >> virtual dirvers (or at least ABI drivers), and that JS works on RFC. >> >> Is that a bend? >> > > If 16-bit, use ICE, otherwise use 64-bit ABI. Simple? > > If 16-bit environment, use ICE; otherwise, use 64-bit NAT. That was me "talking". -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From roman@telurix.com Sat Sep 10 11:50: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 7193521F8505 for ; Sat, 10 Sep 2011 11:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.837 X-Spam-Level: X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=0.139, 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 vKicp9MG+p1L for ; Sat, 10 Sep 2011 11:50:27 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9788E21F84F7 for ; Sat, 10 Sep 2011 11:50:26 -0700 (PDT) Received: by pzk33 with SMTP id 33so15161646pzk.18 for ; Sat, 10 Sep 2011 11:52:25 -0700 (PDT) Received: by 10.68.38.166 with SMTP id h6mr1866871pbk.466.1315680744902; Sat, 10 Sep 2011 11:52:24 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx.google.com with ESMTPS id f6sm29526415pbp.2.2011.09.10.11.52.20 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Sep 2011 11:52:20 -0700 (PDT) Received: by pzk33 with SMTP id 33so15161386pzk.18 for ; Sat, 10 Sep 2011 11:52:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.12.103 with SMTP id x7mr2097843pbb.188.1315680739808; Sat, 10 Sep 2011 11:52:19 -0700 (PDT) Received: by 10.68.43.136 with HTTP; Sat, 10 Sep 2011 11:52:19 -0700 (PDT) In-Reply-To: <4E6B8ED1.6040601@skype.net> References: <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <1541FDA8-C3F6-4D24-BEC4-60EDACB6B582@edvina.net> <4E6B8ED1.6040601@skype.net> Date: Sat, 10 Sep 2011 14:52:19 -0400 Message-ID: From: Roman Shpount To: Matthew Kaufman Content-Type: multipart/alternative; boundary=bcaec5215f832256c604ac9acb14 Cc: Randell Jesup , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Sep 2011 18:50:29 -0000 --bcaec5215f832256c604ac9acb14 Content-Type: text/plain; charset=ISO-8859-1 Yes, I did simplify things quite a bit in regard to *RTP-over-DTLS*, but the main point was that SRTP is not the only or the most secure media transport out there. As far as ICE is concerned, it is backwards compatible with non-ICE end points. The worst you can end up with (and this is not mandated, but just the recommended procedure for selecting the default flow in the standard) is going through a TURN server (if one is available) every time you are talking to a non-ICE end point. If in the API we provide a way to specify STUN/TURN servers used for media, we can effectively turn ICE off for some calls. On the related note, I do think that specifying and providing STUN and TURN servers should be responsibility of the RTC application developer and not the browser configuration. TURN server can consume quite a bit of bandwidth and one can see that they will be provided as a paid service in combination with RTC application itself. _____________ Roman Shpount On Sat, Sep 10, 2011 at 12:22 PM, Matthew Kaufman wrote: > On 9/10/2011 4:47 AM, Roman Shpount wrote: > >> SRTP is a simple media encryption using signaling channel exchanged keys >> and salt to do simple counter mode AES with content signing using HMAC-SHA1. >> It also implements a dictionary based replay protection. DTLS offers wider >> encryption and content signing algorithm selection, end-point handshake >> based on certificates, certificate validation using certificate authority. >> In general, DTLS offers same protection that TLS does, while SRTP is >> simplified and optimized for media. >> > > I think you left out a description of DTLS-SRTP and made other > simplifications. > > > >> In regard to the overall discussion, if we want interop with existing VoIP >> infrastructure, we need to support RTP with AVP. 99% of all SIP deployments >> do not support and cannot support SRTP. >> > > They also cannot complete the ICE STUN handshake that is required to prove > to the browser that they are willing to accept media. > > > None of the wholesale VoIP telephony carriers support SRTP (some offer VPN >> or direct interconnects if you care about privacy). >> > > Likewise regarding ICE. > > > Consumer VoIP companies (like Vonage or Comcast) do not support or use >> SRTP for any calls from their customer equipment. >> > > And again regarding ICE. > > > In places were encryption is supported (like Skype) it is often either >> something different from SRTP. In order to connect to all those environments >> without media proxy we need plain RTP. >> > > Even if we need plain RTP, that isn't an argument for SDES-keyed SRTP. > > Matthew Kaufman > > --bcaec5215f832256c604ac9acb14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, I did simplify things quite a bit in regard to RTP-over-DTLS, b= ut the main point was that SRTP is not the only or the most secure media tr= ansport out there.

As far as ICE is concerned, it is backwards compa= tible with non-ICE end points. The worst you can end up with (and this is n= ot mandated, but just the recommended procedure for selecting the default f= low in the standard) is going through a TURN server (if one is available) e= very time you are talking to a non-ICE end point. If in the API we provide = a way to specify STUN/TURN servers used for media, we can effectively turn = ICE off for some calls.

On the related note, I do think that specifying and providing STUN and = TURN servers should be responsibility of the RTC application developer and = not the browser configuration. TURN server can consume quite a bit of bandw= idth and one can see that they will be provided as a paid service in combin= ation with RTC application itself.
_____________
Roman Shpount


On Sat, Sep 10, 2011 at 12:22 PM, Matthe= w Kaufman <matthew.kaufman@skype.net> wrote:
On 9/10/2011 4:47 AM, Roman Shpount wrote:
SRTP is a simple media encryption using signaling channel exchanged keys an= d salt to do simple counter mode AES with content signing using HMAC-SHA1. = It also implements a dictionary based replay protection. DTLS offers wider = encryption and content signing algorithm selection, end-point handshake bas= ed on certificates, certificate validation using certificate authority. In = general, DTLS offers same protection that TLS does, while SRTP is simplifie= d and optimized for media.

I think you left out a description of DTLS-SRTP and made other simplificati= ons.



In regard to the overall discussion, if we want interop with existing VoIP = infrastructure, we need to support RTP with AVP. 99% of all SIP deployments= do not support and cannot support SRTP.

They also cannot complete the ICE STUN handshake that is required to prove = to the browser that they are willing to accept media.


None of the wholesale VoIP telephony carriers support SRTP (some offer VPN = or direct interconnects if you care about privacy).

Likewise regarding ICE.


Consumer VoIP companies (like Vonage or Comcast) do not support or use SRTP= for any calls from their customer equipment.

And again regarding ICE.


In places were encryption is supported (like Skype) it is often either some= thing different from SRTP. In order to connect to all those environments wi= thout media proxy we need plain RTP.

Even if we need plain RTP, that isn't an argument for SDES-keyed SRTP.<= br>
Matthew Kaufman


--bcaec5215f832256c604ac9acb14-- From matthew.kaufman@skype.net Sat Sep 10 13:39: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 C688E21F8726 for ; Sat, 10 Sep 2011 13:39:45 -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 VQmjrJO22x1Z for ; Sat, 10 Sep 2011 13:39:45 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id CDBB121F8715 for ; Sat, 10 Sep 2011 13:39:44 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id DC1747FE; Sat, 10 Sep 2011 22:41:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=subject :references:content-transfer-encoding:from:content-type :in-reply-to:message-id:date:to:cc:mime-version; s=mx; bh=HZwWhr xZKAArlwsyKQwqnlsDhug=; b=iTh4ZwA8pZvgTbvHrlQQUCCVrbikXxXMPAdbo2 nZWENp3zLiA0tRIneB8N6uW7BHIIcH4sbdSmOQxS3UfsHYnZg30IfF5nm5F88hSR 8oRw1O8InhqNzLVDowaPvCa5f74uyRuWRdb9Ez0eRUGjyKkZBOQvD6uvM/q2/S9w KlWJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=subject:references :content-transfer-encoding:from:content-type:in-reply-to :message-id:date:to:cc:mime-version; q=dns; s=mx; b=JjcSDIhXHDEb jAoJjmf5A9FctaSmIGxxnvqGddNZbd7WJNYjajQsejyOAwsRnxmHYjeKQcr7FLkt Wp8dSOuCgAwSdD4GrKc7TwOUSWZGAQiNUa487Ymw57qKDTMF1xadn2fTjagrRaMi h8GS5eMa1N/sLDpkPvkPnu5Vo6I2xno= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id D6EDB7F6; Sat, 10 Sep 2011 22:41:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id AEE8F3506F8A; Sat, 10 Sep 2011 22:41:41 +0200 (CEST) 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 DyvbcQ3vVnpx; Sat, 10 Sep 2011 22:41:40 +0200 (CEST) Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id CF07A350709F; Sat, 10 Sep 2011 22:41:40 +0200 (CEST) References: <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <1541FDA8-C3F6-4D24-BEC4-60EDACB6B582@edvina.net> <4E6B8 ED1.6040601@skype.net> Content-Transfer-Encoding: quoted-printable From: Matthew Kaufman Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: <903DEDB7-CA26-4354-90B2-BE97B78B0A34@skype.net> Date: Sat, 10 Sep 2011 22:41:40 +0200 (CEST) To: Roman Shpount Mime-Version: 1.0 X-Mailer: Zimbra 6.0.9_GA_2686 (MobileSync - Apple-iPad2C2/812.1) Cc: Randell Jesup , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Sep 2011 20:39:45 -0000 On Sep 10, 2011, at 11:52 AM, Roman Shpount wrote: >=20 >=20 > On the related note, I do think that specifying and providing STUN and TU= RN servers should be responsibility of the RTC application developer and no= t the browser configuration. TURN server can consume quite a bit of bandwid= th and one can see that they will be provided as a paid service in combinat= ion with RTC application itself. >=20 I think we need both... In a corporate environment, there might be the desi= re or need to send everything to a a TURN service operated by the organizat= ion, independently of whether or not the service provider operates such ser= vices. Matthew Kaufman Sent from my iPad From bernard_aboba@hotmail.com Sat Sep 10 16:01: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 C06E621F84C5 for ; Sat, 10 Sep 2011 16:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.192 X-Spam-Level: X-Spam-Status: No, score=-102.192 tagged_above=-999 required=5 tests=[AWL=0.406, 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 9ARfGl7HgtWc for ; Sat, 10 Sep 2011 16:01:34 -0700 (PDT) Received: from blu0-omc4-s34.blu0.hotmail.com (blu0-omc4-s34.blu0.hotmail.com [65.55.111.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDB921F84A3 for ; Sat, 10 Sep 2011 16:01:34 -0700 (PDT) Received: from BLU152-W1 ([65.55.111.135]) by blu0-omc4-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 10 Sep 2011 16:03:33 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_9efe667d-3654-4db9-a5b4-611264a1da81_" X-Originating-IP: [64.134.103.181] From: Bernard Aboba To: , Date: Sat, 10 Sep 2011 16:03:32 -0700 Importance: Normal In-Reply-To: <78CC1B42-392D-4311-9417-33CC702A2FD1@edvina.net> References: , <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com>, <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com>, <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net>, <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com>, <4E67C3F7.7020304@jesup.org>, <4E67F003.6000108@jesup.org>, <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se>, , , , <4E6A56D4.2030602@skype.net>, , , <4E6A81EC.3080002@jesup.org>, <78CC1B42-392D-4311-9417-33CC702A2FD1@edvina.net> MIME-Version: 1.0 X-OriginalArrivalTime: 10 Sep 2011 23:03:33.0113 (UTC) FILETIME=[DCF98E90:01CC700D] Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 10 Sep 2011 23:01:34 -0000 --_9efe667d-3654-4db9-a5b4-611264a1da81_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BA] Can you provide a citation for the assertion that confidentiality coul= d be *required* for an emergency services call? I am not aware of any such a regulatory requirement in the US.=20 From: oej@edvina.net Date: Sat=2C 10 Sep 2011 09:17:16 +0200 To: rtcweb@ietf.org Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] 9 sep 2011 kl. 23:15 skrev Randell Jesup:3) May simplify/improve some E911 = cases. Might be important=3B likely not. 911/112 cases might be typical phone calls that *require* confidentiality. = In Sweden 112 is used for a lot more than accidents - call the priest=2C re= port child abuse and others that really are calls that in now way should be= listened-in to by other users on the LAN or the IP network. /O _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb = --_9efe667d-3654-4db9-a5b4-611264a1da81_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[BA] Can you provide a citation for the assertion that confidentiality coul= d be *required* for an emergency services call?

I am not aware of an= y such a regulatory requirement in the US.


From: oej@edvina.net
Date: Sat=2C 10 Sep 2011 09:17:16 +0200To: rtcweb@ietf.org
Subject: Re: [rtcweb] AVPF [was: Encryption mandate= (and offer/answer)]


9 sep= 2011 kl. 23:15 skrev Randell Jesup:

= 3) May = simplify/improve some E911 cases.  =3BMight be important=3B likely not.=

911/112 cases might be typica= l phone calls that *require* confidentiality. In Sweden 112 is used for a l= ot more than accidents - call the priest=2C report child abuse and others t= hat really are calls that in now way should be listened-in to by other user= s on the LAN or the IP network.

/O

______= _________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
= --_9efe667d-3654-4db9-a5b4-611264a1da81_-- From christer.holmberg@ericsson.com Sat Sep 10 17:14: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 3EFA221F87C5 for ; Sat, 10 Sep 2011 17:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 CUg8+YcOARfk for ; Sat, 10 Sep 2011 17:14:58 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 210C121F84DB for ; Sat, 10 Sep 2011 17:14:57 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-06-4e6bfdf76b18 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C6.51.20773.7FDFB6E4; Sun, 11 Sep 2011 02:16:56 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Sun, 11 Sep 2011 02:16:56 +0200 From: Christer Holmberg To: Paul Kyzivat , "rtcweb@ietf.org" Date: Sun, 11 Sep 2011 02:16:54 +0200 Thread-Topic: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] Thread-Index: AcxvbvtKZZpHJLxnSpGvEJzdd3SangAp4MGv Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se> References: <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org>,<4E6AE22A.2070106@alum.mit.edu> In-Reply-To: <4E6AE22A.2070106@alum.mit.edu> 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: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Sep 2011 00:14:59 -0000 Hi, >This isn't really an rtcweb issue - its a secure media O/A issue. Well, it depends. If you are supposed to be able to provide different alter= natives (SRTP vs RTP and AVPF vs AVP) simultanously, it might have impact o= n the browser requirement, and the browser/app API. >The exact same thing could arise if we had somebody with an urgent >desire to do secure media with fallback to insecure media in SIP. >All the arguments against capneg would be exactly the same. > >The problem is that people aren't finding capneg a usable solution to >this problem, just the way that people didn't find SDPng a solution to >the inadequacies of SDP. > >While it is possible for rtcweb to adopt its own solution to the >problem, that only solves half the problem. And it then creates an >interop problem with SIP. A send-a-new-offer-if-the-first-offers-fails mechanism would be backward co= mpatible - assuming the offerer can guess why the first offer failed. Also, using the AVP and RTP profiles, together with attributes that specifi= es the AVPF and SRTP stuff would also work. Of course, it goes against the = current AVPF and SRTP specifications, and since current legacy deployments = would not understand such attributes, they would always end up using AVP an= d RTP. Regards, Christer On 9/9/11 5:15 PM, Randell Jesup wrote: > On 9/9/2011 3:23 PM, Alan Johnston wrote: >> Ekr is correct. If we allow RTP, which I think is a mistake, then >> there is always a downgrade attack. > > Yes, that's true. The same issue was involved in the best-effort-srtp > draft, which unfortunately > was dropped because CapNeg would "solve" it. (For historical note, it's > still not "solved" > because CapNeg support is >>>> more complex than best-effort-srtp and > not generally deployed, > and I doubt ever will be ala SDPng (though I'm not close to status on > CapNeg.) > > Hmmm. A real downgrade attack requires that the signalling be > compromised. I wonder if there > are characteristics of a webrtc transaction that could help avoid this > sort of attack (for example, > a secondary way out-of-scope here for the app to know ahead of time if > the target will need to > be downgraded). Or some way for the service to vouch for the downgrade > (i.e. wasn't a MITM). > You have to trust the service, but in this case you're doing so to this > degree anyways. > >> My point was that if we must support insecure media, we could avoid >> the complexity of CapNeg by not requiring a single pass non-secure >> media negotiation. > > There is another option. I talked about services that wanted to support > PSTN could decide if they > were willing to support a downgrade. The application could know it's > calling a PSTN gateway and > if it does know that, avoid a media gateway by not offering encrypted > media. > > I see a significant use-case for some services will be calling PSTN > numbers and services, much > as it is now for VoIP. > Yes, a bunch of new non-legacy services wouldn't use/want it. But the > app for a PSTN-using service > could specifically allow it. > > So the question comes down to what's the advantage to using unencrypted > RTP? > 1) No media gateway needed. This is the big one. Saves on $$$, saves on > delay (sometimes a lot), > may save on complexity in a PBX type of situation. > But is there an issue due to ICE requirements? If those can't be turned > off safely too, that kills this > whole discussion I think. > 2) Debug/etc tools work better with RTP. Not important. > 3) May simplify/improve some E911 cases. Might be important; likely not. > > So, effectively it comes down to "is advantage 1 worth the > complexity/risk?" Anyone want to defend that > case? > >> - Alan - >> >> On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla wrote: >>> Unless I'm missing something, if you (a) support an insecure mode and >>> (b) allow >>> negotiation of insecure vs. secure, there's not really any way to >>> avoid a downgrade >>> issue; the attacker can always pretend not to support security and >>> how do you >>> know better? Obviously, it helps if you can negotiate the use or >>> non-use of >>> media security over a secure-ish signaling channel, but that doesn't >>> reduce >>> the threat from the signaling service. >>> >>> Best, >>> -Ekr >>> > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb= From pkyzivat@alum.mit.edu Sat Sep 10 18:42: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 6E2A821F8476 for ; Sat, 10 Sep 2011 18:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-BVsjwZmXNl for ; Sat, 10 Sep 2011 18:42:11 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 73D7A21F8472 for ; Sat, 10 Sep 2011 18:42:11 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta06.westchester.pa.mail.comcast.net with comcast id XDex1h0011HzFnQ56DkBk9; Sun, 11 Sep 2011 01:44:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta14.westchester.pa.mail.comcast.net with comcast id XDk91h01j0tdiYw3aDkAee; Sun, 11 Sep 2011 01:44:11 +0000 Message-ID: <4E6C1267.3030100@alum.mit.edu> Date: Sat, 10 Sep 2011 21:44:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Christer Holmberg References: <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org>, <4E6AE22A.2070106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Sep 2011 01:42:12 -0000 On 9/10/11 8:16 PM, Christer Holmberg wrote: > Hi, > >> This isn't really an rtcweb issue - its a secure media O/A issue. > > Well, it depends. If you are supposed to be able to provide different alternatives (SRTP vs RTP and AVPF vs AVP) simultanously, it might have impact on the browser requirement, and the browser/app API. I didn't mean it had no impact on rtcweb. Only that the O/A issues are not unique to rtcweb. >> The exact same thing could arise if we had somebody with an urgent >> desire to do secure media with fallback to insecure media in SIP. >> All the arguments against capneg would be exactly the same. >> >> The problem is that people aren't finding capneg a usable solution to >> this problem, just the way that people didn't find SDPng a solution to >> the inadequacies of SDP. >> >> While it is possible for rtcweb to adopt its own solution to the >> problem, that only solves half the problem. And it then creates an >> interop problem with SIP. > > A send-a-new-offer-if-the-first-offers-fails mechanism would be backward compatible - assuming the offerer can guess why the first offer failed. It *might* work in some cases, but it would be iffy. If the connection is being federated via SIP, I don't know if the intent is that both O/As be done in the same INVITE or int separate INVITEs. Each has its own limitations: If done in a single INVITE, its quite possible that the INVITE with the first offer will be rejected entirely, without giving chance for a 2nd INVITE. If done as separate INVITEs, there is chance that they might not go to the same destination. At the least, that could lead to extended setup times. And, IIRC, that approach was discussed before going with the capneg, and was rejected. So that approach *may* violate some RFC, though I don't know which one. Thanks, Paul > Also, using the AVP and RTP profiles, together with attributes that specifies the AVPF and SRTP stuff would also work. Of course, it goes against the current AVPF and SRTP specifications, and since current legacy deployments would not understand such attributes, they would always end up using AVP and RTP. > > Regards, > > Christer > > > On 9/9/11 5:15 PM, Randell Jesup wrote: >> On 9/9/2011 3:23 PM, Alan Johnston wrote: >>> Ekr is correct. If we allow RTP, which I think is a mistake, then >>> there is always a downgrade attack. >> >> Yes, that's true. The same issue was involved in the best-effort-srtp >> draft, which unfortunately >> was dropped because CapNeg would "solve" it. (For historical note, it's >> still not "solved" >> because CapNeg support is>>>> more complex than best-effort-srtp and >> not generally deployed, >> and I doubt ever will be ala SDPng (though I'm not close to status on >> CapNeg.) >> >> Hmmm. A real downgrade attack requires that the signalling be >> compromised. I wonder if there >> are characteristics of a webrtc transaction that could help avoid this >> sort of attack (for example, >> a secondary way out-of-scope here for the app to know ahead of time if >> the target will need to >> be downgraded). Or some way for the service to vouch for the downgrade >> (i.e. wasn't a MITM). >> You have to trust the service, but in this case you're doing so to this >> degree anyways. >> >>> My point was that if we must support insecure media, we could avoid >>> the complexity of CapNeg by not requiring a single pass non-secure >>> media negotiation. >> >> There is another option. I talked about services that wanted to support >> PSTN could decide if they >> were willing to support a downgrade. The application could know it's >> calling a PSTN gateway and >> if it does know that, avoid a media gateway by not offering encrypted >> media. >> >> I see a significant use-case for some services will be calling PSTN >> numbers and services, much >> as it is now for VoIP. >> Yes, a bunch of new non-legacy services wouldn't use/want it. But the >> app for a PSTN-using service >> could specifically allow it. >> >> So the question comes down to what's the advantage to using unencrypted >> RTP? >> 1) No media gateway needed. This is the big one. Saves on $$$, saves on >> delay (sometimes a lot), >> may save on complexity in a PBX type of situation. >> But is there an issue due to ICE requirements? If those can't be turned >> off safely too, that kills this >> whole discussion I think. >> 2) Debug/etc tools work better with RTP. Not important. >> 3) May simplify/improve some E911 cases. Might be important; likely not. >> >> So, effectively it comes down to "is advantage 1 worth the >> complexity/risk?" Anyone want to defend that >> case? >> >>> - Alan - >>> >>> On Fri, Sep 9, 2011 at 1:35 PM, Eric Rescorla wrote: >>>> Unless I'm missing something, if you (a) support an insecure mode and >>>> (b) allow >>>> negotiation of insecure vs. secure, there's not really any way to >>>> avoid a downgrade >>>> issue; the attacker can always pretend not to support security and >>>> how do you >>>> know better? Obviously, it helps if you can negotiate the use or >>>> non-use of >>>> media security over a secure-ish signaling channel, but that doesn't >>>> reduce >>>> the threat from the signaling service. >>>> >>>> Best, >>>> -Ekr >>>> >> > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Sat Sep 10 19:04: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 DA7FB21F87FC for ; Sat, 10 Sep 2011 19:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 b7i35Vltm9Et for ; Sat, 10 Sep 2011 19:04: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 4B27921F87F0 for ; Sat, 10 Sep 2011 19:04:45 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R2ZRU-0007Ox-M4 for rtcweb@ietf.org; Sat, 10 Sep 2011 21:06:44 -0500 Message-ID: <4E6C16FF.1000706@jesup.org> Date: Sat, 10 Sep 2011 22:03:43 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org>, <4E6AE22A.2070106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se> 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] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Sep 2011 02:04:47 -0000 On 9/10/2011 8:16 PM, Christer Holmberg wrote: > >> The exact same thing could arise if we had somebody with an urgent >> desire to do secure media with fallback to insecure media in SIP. >> All the arguments against capneg would be exactly the same. >> >> The problem is that people aren't finding capneg a usable solution to >> this problem, just the way that people didn't find SDPng a solution to >> the inadequacies of SDP. >> >> While it is possible for rtcweb to adopt its own solution to the >> problem, that only solves half the problem. And it then creates an >> interop problem with SIP. > A send-a-new-offer-if-the-first-offers-fails mechanism would be backward compatible - assuming the offerer can guess why the first offer failed. > > Also, using the AVP and RTP profiles, together with attributes that specifies the AVPF and SRTP stuff would also work. Of course, it goes against the current AVPF and SRTP specifications, and since current legacy deployments would not understand such attributes, they would always end up using AVP and RTP. I think what you've speced here is basically similar to the draft-best-effort-srtp proposal. -- Randell Jesup randell-ietf@jesup.org From stefan.lk.hakansson@ericsson.com Sun Sep 11 01:48: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 7A42221F84D8 for ; Sun, 11 Sep 2011 01:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.315 X-Spam-Level: X-Spam-Status: No, score=-6.315 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 1OAsH1bV0Whe for ; Sun, 11 Sep 2011 01:48:47 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 977E621F84D7 for ; Sun, 11 Sep 2011 01:48:46 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-c0-4e6c76667b8a Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 75.04.20773.6667C6E4; Sun, 11 Sep 2011 10:50:46 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.112]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Sun, 11 Sep 2011 10:50:46 +0200 From: =?Windows-1252?Q?Stefan_H=E5kansson_LK?= To: Randell Jesup , "rtcweb@ietf.org" Date: Sun, 11 Sep 2011 10:49:16 +0200 Thread-Topic: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] Thread-Index: AcxwJ3hLpGVDydVTR3u4B0FWN8AJqgAODe0T Message-ID: References: <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org>, <4E6AE22A.2070106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se>, <4E6C16FF.1000706@jesup.org> In-Reply-To: <4E6C16FF.1000706@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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Sep 2011 08:48:48 -0000 In my mind I had built a slightly different model of how this would work. I= n essence, the SDP o/a would not be allowed to negotiate encryption or not,= that should be set when creating the PeerConnection object: * The level of media protection to use (NONE, SDES-SRTP or DTLS-SRTP) shoul= d be set by the web app when a PeerConnection object is created (possibly p= art of the configuration string) * One pre-requisite for the PeerConnection to enter the =93open=94 state (a= nd for streams to be set up) must be that the same level of protection is s= elected by both peer apps * We should never allow any SDP o/a to negotiate away from the selected lev= el of protection. This would work just fine in the most common use cases as it is the same ap= p, served by the same server, running in both browsers, and since support o= f NONE, SDES-SRTP and DTLS-SRTP in browsers should be mandated. The service= provider/app developer decides. The tricky part would be interop. But if we take the =91browser to browser,= but the app coming from different sources=92 case, the two teams developin= g the apps must communicate any way to make them interop. Agreeing on wheth= er to use NONE, SDES-SRTP or DTLS-SRTP is just one detail to agree on. Developers of apps to interop with legacy must acquire enough info about th= e system to interop with to make the right setting of PeerConnection for th= e specific case. Remember, the primary target for this activity is browser-to-browser. This = should be simple and straightforward for the app developer. That the app de= veloper would have to think a bit more for interop cases is quite OK IMO. Stefan ________________________________________ From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Randel= l Jesup [randell-ietf@jesup.org] Sent: Sunday, September 11, 2011 4:03 AM To: rtcweb@ietf.org Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] On 9/10/2011 8:16 PM, Christer Holmberg wrote: > >> The exact same thing could arise if we had somebody with an urgent >> desire to do secure media with fallback to insecure media in SIP. >> All the arguments against capneg would be exactly the same. >> >> The problem is that people aren't finding capneg a usable solution to >> this problem, just the way that people didn't find SDPng a solution to >> the inadequacies of SDP. >> >> While it is possible for rtcweb to adopt its own solution to the >> problem, that only solves half the problem. And it then creates an >> interop problem with SIP. > A send-a-new-offer-if-the-first-offers-fails mechanism would be backward = compatible - assuming the offerer can guess why the first offer failed. > > Also, using the AVP and RTP profiles, together with attributes that speci= fies the AVPF and SRTP stuff would also work. Of course, it goes against th= e current AVPF and SRTP specifications, and since current legacy deployment= s would not understand such attributes, they would always end up using AVP = and RTP. I think what you've speced here is basically similar to the draft-best-effort-srtp proposal. -- Randell Jesup randell-ietf@jesup.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From HKaplan@acmepacket.com Sun Sep 11 05:58: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 3970421F8669 for ; Sun, 11 Sep 2011 05:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 fPnEweZHSxaa for ; Sun, 11 Sep 2011 05:58:06 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id A003321F863E for ; Sun, 11 Sep 2011 05:58:06 -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; Sun, 11 Sep 2011 08:59:53 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sun, 11 Sep 2011 08:59:52 -0400 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] Thread-Index: AQHMcIKwV9u+0Arv+EmqYITZjPuIBw== Date: Sun, 11 Sep 2011 12:59:50 +0000 Message-ID: <1C177DD3-C9AC-49D3-BDD6-0FC43CB9F26F@acmepacket.com> References: <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org> <4E6AE22A.2070106@alum.mit.edu> In-Reply-To: <4E6AE22A.2070106@alum.mit.edu> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Sep 2011 12:58:07 -0000 I doubt you'd get MMUSIC to change their tune. (pun intended) They don't seem to accept lack of adoption as an indication that we need an= alternative for things. For example, mandating ICE for IPv4/v6 dual-stack= offers. -hadriel On Sep 10, 2011, at 12:06 AM, Paul Kyzivat wrote: > The "right" solution is to go back to mmusic for an O/A mechanism for sec= ure/insecure media that is more usable than capneg. If its deemed that doin= g this would take too long, and its necessary to do something special for r= tcweb, then a parallel effort ought to be started to sort out how it can in= teroperate with SIP or anything else that uses O/A. >=20 > (The "good" news is that I doubt there are many (any?) deployed uses of c= apneg in SIP for negotiation of secure/insecure media.) >=20 > Thanks, > Paul >=20 From prvs=228ffc744=tterriberry@mozilla.com Sun Sep 11 06:37: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 C890B21F85E3 for ; Sun, 11 Sep 2011 06:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWymamlITp6j for ; Sun, 11 Sep 2011 06:37:07 -0700 (PDT) Received: from mxip2i.isis.unc.edu (mxip2i.isis.unc.edu [152.2.2.193]) by ietfa.amsl.com (Postfix) with ESMTP id 3C89121F85C4 for ; Sun, 11 Sep 2011 06:37:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAGu5bE6sGgRS/2dsb2JhbABBpx2BdIFSAQEFOEABEAshFg8JAwIBAgFFEwEHAr0khm4Eh22QVRCMJw X-IronPort-AV: E=Sophos;i="4.67,504,1309752000"; d="scan'208";a="183571524" Received: from mr1a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.82]) by mxip2o.isis.unc.edu with ESMTP; 11 Sep 2011 09:39:06 -0400 X-UNC-Auth-As: tterribe X-UNC-Auth-IP: 24.103.99.21 Received: from [172.26.0.112] (rrcs-24-103-99-21.nyc.biz.rr.com [24.103.99.21]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id p8BDd3Uk017451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 11 Sep 2011 09:39:06 -0400 (EDT) Message-ID: <4E6CB9F7.2060208@mozilla.com> Date: Sun, 11 Sep 2011 06:39:03 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101120 Gentoo/2.0.10 SeaMonkey/2.0.10 MIME-Version: 1.0 CC: "rtcweb@ietf.org" References: <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org>, <4E6AE22A.2070106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se>, <4E6C16FF.1000706@jesup.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Sep 2011 13:37:07 -0000 > * The level of media protection to use (NONE, SDES-SRTP or DTLS-SRTP) should be set by the web app Why wouldn't this devolve to, "Don't communicate anything. Instead, try to create a PeerConnection with DTLS-SRTP, and when that fails, try to create a second one with NONE," in the actual webapp. Or, more likely, since NONE will have a better chance of working with legacy devices, "Try to create a PeerConnection with NONE, and when that fails, try to create a second one with DTLS-SRTP." Assuming anyone bothers with the second step. Having the choice of SDES-SRTP or DTLS-SRTP will also make it more likely people won't bother with either, as they won't know which one to use. We can try to create incentives with browser chrome, but there's only so much that can do. From HKaplan@acmepacket.com Sun Sep 11 06:49: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 0104021F85EF for ; Sun, 11 Sep 2011 06:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 5Fr38rZ7cJpn for ; Sun, 11 Sep 2011 06:49:23 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4936921F85E3 for ; Sun, 11 Sep 2011 06:49:23 -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; Sun, 11 Sep 2011 09:51:23 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sun, 11 Sep 2011 09:51:22 -0400 From: Hadriel Kaplan To: Cullen Jennings Thread-Topic: Supporting legacy PSTN interop (was: Use of offer / answer semantics) Thread-Index: AQHMcIniZ46zQg8sI0u9j63r6cyTzw== Date: Sun, 11 Sep 2011 13:51:20 +0000 Message-ID: <8314E027-1250-495C-ABE9-F2C3FE581F48@acmepacket.com> References: <4E663A35.7000507@skype.net> <2E243EBA-3A4C-420F-A1CF-B62374FFEF66@cisco.com> In-Reply-To: <2E243EBA-3A4C-420F-A1CF-B62374FFEF66@cisco.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="us-ascii" Content-ID: <25CAF8C5AE30464E90128B2022C51B02@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: [rtcweb] Supporting legacy PSTN interop (was: Use of offer / answer semantics) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Sep 2011 13:49:24 -0000 On Sep 6, 2011, at 9:45 PM, Cullen Jennings wrote: >=20 > On Sep 6, 2011, at 9:20 AM, Matthew Kaufman wrote: >=20 >>> The primary issues identified with this was concerns over mapping this = to legacy SDP. >>=20 >> This makes the assumption that the primary use case will have things tha= t speak only SDP offer/answer on the far side. I think that's a very IETF += SIP + legacy point of view, which is an unfortunate way to approach the fu= ture of communications as enabled by web applications. >=20 > I'm not assuming anything about this being the primary use case. I'm assu= ming it is an important use case. If it were not, we would do this totally = differently probably starting with not using RTP, certainly not using SDP o= r offer/answer, and I'd argue for a p2p (in the overlay network sense of th= e term) form rendezvous - there would be people on the list point out if we= use used HIP, everything would be done. We are not doing that because it i= s an import use case. The reason it is important is because that is the wa= y we connect this to the existing voice and video communication infrastruct= ure that currently supports well over 4 billion users and probably over 5 b= illion. We already have a boat load of solutions to this problem if we don'= t care about legacy. That Flash stuff seems to be in lots of browsers and w= ork fine to other browsers - but I want more than that. For the same reason= IPV6 device that can't connect to anything V4 are much less interesting th= an devices that c > an connect to both, I want interoperability with the past (meaning all th= e existing deployments) and path for an interesting future. Either one by i= tself is not enough.=20 >=20 I don't see how the current rtcweb direction could really do that. If you = really want to interop with the 5 billion PSTN/IMS users without a gateway = "interworking" rtcweb media to legacy SIP-based media, the rtcweb browser w= ould have to mandate support for G.711, AVP rather than AVPF, support NOT u= sing ICE, support not using SRTP, and not multiplexing RTP/RTCP. If ICE re= mains mandatory to use, then there'll have to be some media-layer ICE termi= nator (or TURN server) to interop with the PSTN no matter what. =20 The odds are there'll be some form of SBC at the border of the SIP-PSTN pro= vider anyway (e.g., an IBCF), but the question is whether it'll be the PSTN= providers that have to pay the additional cost to interop with rtcweb medi= a, or whether it'll be the rtcweb service provider who also have to deploy = gateways. At the end of the day it costs money to interwork this stuff - i= .e., more hardware/blades/CPUs/whatever. So even if the PSTN providers alr= eady use SBCs and they're the ones doing the interop work, it'll cost more = either in the form of more SBCs, or higher-scale hardware in them. Generally the most expensive thing would be to make the gateway/SBC have to= transcode, so if we could at least mandate rtcweb clients support G.711 an= d AVP, that would be good. It would really suck if every call to/from the = PSTN had to be transcoded from opus/AVPF to G.711/AVP, when G.711/AVP is ro= yalty free (and trivial relative to opus/avpf). -hadriel From HKaplan@acmepacket.com Sun Sep 11 08:59: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 B0F8021F854D for ; Sun, 11 Sep 2011 08:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 bHnIbQhp4A9P for ; Sun, 11 Sep 2011 08:59:57 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id BB68521F853B for ; Sun, 11 Sep 2011 08:59:57 -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; Sun, 11 Sep 2011 12:01:57 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sun, 11 Sep 2011 12:01:57 -0400 From: Hadriel Kaplan To: "Olle E. Johansson" Thread-Topic: [rtcweb] RTCweb signalling overview Thread-Index: AQHMcJwgDojMpyHS5E2yEootaFdjdg== Date: Sun, 11 Sep 2011 16:01:55 +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: text/plain; charset="us-ascii" Content-ID: <1E5BB3942B6B1846AF9EA7168084EC16@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] RTCweb signalling overview X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Sep 2011 15:59:58 -0000 Was the meeting audio recorded? It would be nice to listen to the discussi= on. :) -hadriel On Sep 8, 2011, at 2:48 PM, Olle E. Johansson wrote: > For those of you that did not participate in today's meeting, there was a= n excellent overview presented by Martin Kaufman. >=20 > It gives you an overview over the issues with signalling - to sip or not = to sip - and other issues. Do read it. >=20 > Use the file rtcweb-3.pptx in http://www.ietf.org/proceedings/82/slides/ >=20 > /O >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From dzonatas@gmail.com Sun Sep 11 09:34: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 7746D21F87F0 for ; Sun, 11 Sep 2011 09:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[AWL=-0.301, 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 CJM1-EW6Rr1r for ; Sun, 11 Sep 2011 09:34:14 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id BA20621F87D9 for ; Sun, 11 Sep 2011 09:34:14 -0700 (PDT) Received: by pzk33 with SMTP id 33so19503437pzk.18 for ; Sun, 11 Sep 2011 09:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=UlLFh3KE781/J+VSTYkfQTHiDFinQWdVMoRCmX2BOVU=; b=kjlDdI+18gL+Q83l9f2WQmLcsA3SJ5ymofYKcQ8baRax+mMZai7ZJVvrE4dM0k7KQq TwXnQDiUcqsHvGN9xrK8umq9C68pbaec0u/A77a1Vqodka/Rhn7/TS+Cwqqg5dCbeiO3 X0bjsaJZxwSzgUvgrWdn92MkA/AwaSc8iC6rk= Received: by 10.68.34.169 with SMTP id a9mr1866965pbj.134.1315758970753; Sun, 11 Sep 2011 09:36:10 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id f6sm1720793pbp.2.2011.09.11.09.36.09 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Sep 2011 09:36:09 -0700 (PDT) Message-ID: <4E6CE3F3.4040009@gmail.com> Date: Sun, 11 Sep 2011 09:38:11 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: , <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net>, <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com>, <4E67C3F7.7020304@jesup.org>, <4E67F003.6000108@jesup.org>, <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se>, , , , <4E6A56D4.2030602@skype.net>, , , <4E6A81EC.3080002@jesup.org>, <78CC1B42-392D-4311-9417-33CC702A2FD1@edvina.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Sep 2011 16:34:15 -0000 I think the real question is more simple: if 32-bit audio "could be *required* for emergency services". It doesn't seem standard beyond 24-bit, yet I can imagine the filter attempt for DSL-to-DTLS. On 09/10/2011 04:03 PM, Bernard Aboba wrote: > [BA] Can you provide a citation for the assertion that confidentiality > could be *required* for an emergency services call? > > I am not aware of any such a regulatory requirement in the US. > > > ------------------------------------------------------------------------ > From: oej@edvina.net > Date: Sat, 10 Sep 2011 09:17:16 +0200 > To: rtcweb@ietf.org > Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] > > > 9 sep 2011 kl. 23:15 skrev Randell Jesup: > > 3) May simplify/improve some E911 cases. Might be important; > likely not. > > > 911/112 cases might be typical phone calls that *require* > confidentiality. In Sweden 112 is used for a lot more than accidents - > call the priest, report child abuse and others that really are calls > that in now way should be listened-in to by other users on the LAN or > the IP network. > > /O > > _______________________________________________ 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 > -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From pravindran@sonusnet.com Sun Sep 11 12:22: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 107C021F86F6 for ; Sun, 11 Sep 2011 12:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, J_BACKHAIR_53=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 C5C2-qCR3vL3 for ; Sun, 11 Sep 2011 12:21:59 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 05EE321F86EE for ; Sun, 11 Sep 2011 12:21:58 -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 p8BJOQQL030925; Sun, 11 Sep 2011 15:24:26 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Sep 2011 15:23:56 -0400 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: Mon, 12 Sep 2011 00:53:52 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F09EA@sonusinmail02.sonusnet.com> In-Reply-To: <4E691CC6.9050905@stpeter.im> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] Thread-Index: AcxuYLv74sRbRYyWTw6p8sklFnpfFwCTmtUA References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net><4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net><2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com><4E67AD3D.9000005@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com><4E686663.1050900@alvestrand.no><4E68CB68.3020100@alcatel-lucent.com><4E68D182.2090003@alvestrand.no><4E68D742.4010203@alcatel-lucent.com><4E68D8B5.7010602@alvestrand.no><4E6915F2.5000007@alcatel-lucent.com> <4E691CC6.9050905@stpeter.im> From: "Ravindran Parthasarathi" To: "Peter Saint-Andre" , X-OriginalArrivalTime: 11 Sep 2011 19:23:56.0290 (UTC) FILETIME=[5963AE20:01CC70B8] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Sep 2011 19:22:00 -0000 Peter, Thanks for forwarding info about draft-ietf-hybi-thewebsocketprotocol. I started this mail thread to know whether RTCWeb1.0 is a unofficial RFC3261bis for the line side (endpoint to access server) :-) [I really don't know the better term for the line side]. Endpoint may be desktop, smart phone (android), laptop, tablet, CPE, etc., Till reading this draft, I assumed websocket as a socket layer for HTTP and it is bad assumption :-(. In short, browser is able to create two way communication with webserver (which has globally routable address). Two browser creating websocket with web servers will be able to communicate with each other. This architecture exactly fits in SIP world as =20 SIP UA <---->B2BUA<----->SIP UA And resultant as browser<---> webserver <----> browser. I tend to agree with you that Websocket looks as a better choice for this simple web architecture as there is no need of identity exchange here because webserver knows and authenticated both browsers with the corresponding identity. In fact, B2BUA with globally routable address will interop better with any endpoint for that matter. The difference comes into picture for federation (interop between servers). I'm not very clear whether websocket is intended for federation as well or not. Most of the discussion RTCWeb points to use SIP as a federation protocol which may change later. I'm interested knowing your view here. For this mail, I assume that SIP as a federation protocol of RTCWeb1.0 and I'm ready to change if it is the right thing to do :-) I'm asking for the single protocol based on my gateway implementation experience in signaling protocol like SIP, H.323, and basic of MEGACO, Q.931 (ISDN) etc., My understanding is that mapping of between tow protocols leads to get the common set in both protocol and under utilization of specific protocol functionality. The mapping is not perfect lot of times and one of the example which I know in IETF product is RFC 3398. It is not possible in RFC 3398 to proper reverse mapping of cause code for ISUP in case conversion in first gateway converts ISUP to SIP, second gateway converts is SIP to ISUP, ISUP cause code value in second gateway is not same what is received in first gateway and this leads to lot of interop issue which includes passing of reason SIP header with Q.931 IE recently as per IETF-80 decision (workaround bug fix). This is not the only mapping failure which I have seen during the gateway implementation. So, I prefer to look for the strong reason for putting multiple protocol (SIP, websocket) as a RTCWeb architecture.=20 Apart from this, my understanding is that websocket + REST XML is the best choice in web world but SIP + REST XML is an overkill. My understanding is based on SIPREC metadata XML design where I explored to make REST XML which is generic for SIP and other protocols, but I realized that REST XML is overkill for SIP as it has dialog context in both server & client. Please let me know your comments on this. Also, Endpoint shall be single IETF protocol for real-time communication rather than having two protocols (SIP, websocket) for any application. It looks inconsistent for Endpoint application to use SIP and Endpoint browser application to use websocket. IMO, IETF should give some clarity for better real-time network design here. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Peter Saint-Andre >Sent: Friday, September 09, 2011 1:22 AM >To: igor.faynberg@alcatel-lucent.com >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote >recording - RTC-Web client acting as SIPREC session recording client] > >On 9/8/11 1:22 PM, Igor Faynberg wrote: >>> On 09/08/11 16:54, Igor Faynberg wrote: >>> ... >> >>> If the issue is getting a signal from a Web server to a client, >>> there's approximately 100 ways to get notifications from the server >to >>> the client using HTTP (hanging GET being one of them). >> >> I thought that COMET-like polling is inefficient. Hanging GETs >> require server resources to hold a TCP session o open. Firewalls and >IE7 >> time out a GET after 30-60 seconds. >> >>> Now that WS is getting standardized, there will be 101. >>> >> >> 101st, seems to be a solution, I agree. But it has not finished >> standardization, > >draft-ietf-hybi-thewebsocketprotocol is close to approve as a Proposed >Standard (discussed on this morning's IESG telechat, still a few issues >to clean up). Not that PS means finalization. > >> while SIP has. > >SIP is not a full Standard. rfc3261bis, anyone? ;-) > >Peter > >-- >Peter Saint-Andre >https://stpeter.im/ > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Sun Sep 11 12:34: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 5908021F8A58 for ; Sun, 11 Sep 2011 12:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 JvomghqXivz2 for ; Sun, 11 Sep 2011 12:34:21 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7502021F8A57 for ; Sun, 11 Sep 2011 12:34:21 -0700 (PDT) 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 p8BJahhT006798; Sun, 11 Sep 2011 15:36:43 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Sep 2011 15:36:13 -0400 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: Mon, 12 Sep 2011 01:06:09 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F09EB@sonusinmail02.sonusnet.com> In-Reply-To: <8314E027-1250-495C-ABE9-F2C3FE581F48@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Supporting legacy PSTN interop (was: Use of offer / answer semantics) Thread-Index: AQHMcIniZ46zQg8sI0u9j63r6cyTz5VIkV5A References: <4E663A35.7000507@skype.net><2E243EBA-3A4C-420F-A1CF-B62374FFEF66@cisco.com> <8314E027-1250-495C-ABE9-F2C3FE581F48@acmepacket.com> From: "Ravindran Parthasarathi" To: "Hadriel Kaplan" , "Cullen Jennings" X-OriginalArrivalTime: 11 Sep 2011 19:36:13.0530 (UTC) FILETIME=[10D193A0:01CC70BA] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Supporting legacy PSTN interop (was: Use of offer / answer semantics) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Sep 2011 19:34:22 -0000 I agree with Hadriel for PSTN interop. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Hadriel Kaplan >Sent: Sunday, September 11, 2011 7:21 PM >To: Cullen Jennings >Cc: >Subject: [rtcweb] Supporting legacy PSTN interop (was: Use of offer / >answer semantics) > > >On Sep 6, 2011, at 9:45 PM, Cullen Jennings wrote: > >> >> On Sep 6, 2011, at 9:20 AM, Matthew Kaufman wrote: >> >>>> The primary issues identified with this was concerns over mapping >this to legacy SDP. >>> >>> This makes the assumption that the primary use case will have things >that speak only SDP offer/answer on the far side. I think that's a very >IETF + SIP + legacy point of view, which is an unfortunate way to >approach the future of communications as enabled by web applications. >> >> I'm not assuming anything about this being the primary use case. I'm >assuming it is an important use case. If it were not, we would do this >totally differently probably starting with not using RTP, certainly not >using SDP or offer/answer, and I'd argue for a p2p (in the overlay >network sense of the term) form rendezvous - there would be people on >the list point out if we use used HIP, everything would be done. We are >not doing that because it is an import use case. The reason it is >important is because that is the way we connect this to the existing >voice and video communication infrastructure that currently supports >well over 4 billion users and probably over 5 billion. We already have a >boat load of solutions to this problem if we don't care about legacy. >That Flash stuff seems to be in lots of browsers and work fine to other >browsers - but I want more than that. For the same reason IPV6 device >that can't connect to anything V4 are much less interesting than devices >that > c >> an connect to both, I want interoperability with the past (meaning all >the existing deployments) and path for an interesting future. Either one >by itself is not enough. >> > >I don't see how the current rtcweb direction could really do that. If >you really want to interop with the 5 billion PSTN/IMS users without a >gateway "interworking" rtcweb media to legacy SIP-based media, the >rtcweb browser would have to mandate support for G.711, AVP rather than >AVPF, support NOT using ICE, support not using SRTP, and not >multiplexing RTP/RTCP. If ICE remains mandatory to use, then there'll >have to be some media-layer ICE terminator (or TURN server) to interop >with the PSTN no matter what. > >The odds are there'll be some form of SBC at the border of the SIP-PSTN >provider anyway (e.g., an IBCF), but the question is whether it'll be >the PSTN providers that have to pay the additional cost to interop with >rtcweb media, or whether it'll be the rtcweb service provider who also >have to deploy gateways. At the end of the day it costs money to >interwork this stuff - i.e., more hardware/blades/CPUs/whatever. So >even if the PSTN providers already use SBCs and they're the ones doing >the interop work, it'll cost more either in the form of more SBCs, or >higher-scale hardware in them. > >Generally the most expensive thing would be to make the gateway/SBC have >to transcode, so if we could at least mandate rtcweb clients support >G.711 and AVP, that would be good. It would really suck if every call >to/from the PSTN had to be transcoded from opus/AVPF to G.711/AVP, when >G.711/AVP is royalty free (and trivial relative to opus/avpf). > >-hadriel > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Sun Sep 11 13:12: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 AFC3A21F8AB0 for ; Sun, 11 Sep 2011 13:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 yCgOWJPxLwKY for ; Sun, 11 Sep 2011 13:12:02 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id A2A1521F8AAC for ; Sun, 11 Sep 2011 13:12:02 -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 p8BKEWrW030712; Sun, 11 Sep 2011 16:14:32 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Sep 2011 16:14:02 -0400 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: Mon, 12 Sep 2011 01:43:59 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F09EC@sonusinmail02.sonusnet.com> In-Reply-To: <017201cc6ef8$33f571d0$9be05570$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SIP MUST NOT be used in browser? Thread-Index: AcxugwPGZZwx2t5GRiO1eoON13qQJAAcqVZQAHIio4A= References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <4E68CB68.3020100@alcatel-lucent.com> <4E68D182.2090003@alvestrand.no> <4E68D742.4010203@alcatel-lucent.com> <4E68D8B5.7010602@alvestrand.no> <4E6915F2.5000007@alcatel-lucent.com><4E691CC6.9050905@stpeter.im> <4E695648.2000001@alcatel-lucent.com> <017201cc6ef8$33f571d0$9be 05570$@c om> From: "Ravindran Parthasarathi" To: "Aaron Clauson" , X-OriginalArrivalTime: 11 Sep 2011 20:14:02.0458 (UTC) FILETIME=[593483A0:01CC70BF] Subject: Re: [rtcweb] SIP MUST NOT be used 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: Sun, 11 Sep 2011 20:12:03 -0000 Hi Aaron, Javascript SIP stacks (Ex: phono.com) exists already and RTCWeb1.0 is not a gating factor for those development. My worry is that RTCWeb1.0 is standardized and then identify the gap in signaling which is not a good protocol design. It is better to discuss with signaling rather than just solving media protocol requirement alone. In case any implementation deployed, the backward compatibility has to be provided till the end of the product and RTCWeb1.0 is a not an exception. For the time factor concern, let us work for the quick closer and I have no disagreement there. But I have problem in case it is mentioned as the issues will not be solved to meet the WG deadline. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Aaron Clauson >Sent: Friday, September 09, 2011 7:26 PM >To: rtcweb@ietf.org >Subject: Re: [rtcweb] SIP MUST NOT be used in browser? > >Another 2 cents from a SIP person. > >I think attempting to incorporate SIP (or Jingle et al) into RTCWeb >would be >a bad idea for the reason that it would significantly slow down and >complicate the standard. If SIP is included in RTCWeb then there will >need >to be a discussion, already emerging here, about which parts of SIP to >include and all the other intricacies of SIP; transports, sips vs sip, >request routing etc etc. > >Writing a javascript SIP stack is a small task compared to getting the >RTCWeb media capabilities built into browsers. As soon as the first >browser >appears that supports RTP then javascript SIP stacks will start popping >up >all over the place. > >I for one would love to be able to process calls in my browser and to be >able to do it yesterday. Slowing the RTCWeb process down for something >that >will take care of itself anyway, namely readily available javascript >signalling libraries, would be a shame. > >Aaron > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Sun Sep 11 13:27: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 C191221F84FB for ; Sun, 11 Sep 2011 13:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 Lj+B-B3yrNmD for ; Sun, 11 Sep 2011 13:27:16 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id DEEA621F84E1 for ; Sun, 11 Sep 2011 13:27:15 -0700 (PDT) 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 p8BKTkJ5008102; Sun, 11 Sep 2011 16:29:46 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Sep 2011 16:29:16 -0400 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: Mon, 12 Sep 2011 01:59:13 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F09ED@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Proposed text - remote recording use case Thread-Index: AcxvD2BDwyObig+rTKql0YP/877l3QBsKwJg References: From: "Ravindran Parthasarathi" To: "Elwell, John" , X-OriginalArrivalTime: 11 Sep 2011 20:29:16.0500 (UTC) FILETIME=[7A044140:01CC70C1] Subject: Re: [rtcweb] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Sep 2011 20:27:16 -0000 John, Please let me know whether the updated text works for you: New requirements: Fyy1: The browser MUST be able to send in real-time to an another browser/session recording server(SRS) that are being transmitted to and received from remote browser. Ayy1: The web application MUST be able to ask the browser to transmit in real-time to another browser/session recording server(SRS) that are being transmitted to and received from remote browser. Basically I changed "a third party media" to "an another browser/session recording server (SRS)" because SRS is not required to be third party. Also, there is a discussion wherein the actual participant is not known to the browser, so I prefer "browser" rather than "participants". As I asked in the meeting (but couldn't discuss due to time constraint), it is possible for browser to do the signaling directly to the SRS without going through original webserver. The signaling towards recording is not required to be SIP but it shall be websocket (let discuss separately). Here, the advantageous in this model is that the recording signaling hop is reduced to 1 hop (browser to SRS) from 2 hops (browser to webserver, webserver to SRS). Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Elwell, John >Sent: Friday, September 09, 2011 10:12 PM >To: rtcweb@ietf.org >Subject: [rtcweb] Proposed text - remote recording use case > >On yesterday's call it was agreed to work on text to cover the remote >recording use case. Below is text, based on an earlier proposal and >subsequent input. I have focused on the main requirement derived from >this use case, relating to copying to a different peer connection, and >skipped any more detailed requirements concerning possible mixing of the >two directions of audio or injecting any tones / announcements. > >4.2.yy Remote Session Recording >In this use case, the web application user wishes to record a real-time >communication at a remote third party (e.g., a recording device), such >that transmitted and received audio, video or other real-time media are >transmitted in real-time to the third party. The third party can perform >recording, archiving, retrieval, playback, etc., but can also perform >real-time analytics on the media. A typical deployment might be in a >contact centre. The web application also sends metadata that gives >context to the stored media. The web application will ensure that >appropriate indications are given to participants so that they are aware >of recording. > >New requirements: >Fyy1: The browser MUST be able to send in real-time to a third party >media that are being transmitted to and received from remote >participants. > >Ayy1: The web application MUST be able to ask the browser to transmit in >real-time to a third party media that are being transmitted to and >received from remote participants. > >Comments? > >John > > >John Elwell >Tel: +44 1908 817801 (office and mobile) >Email: john.elwell@siemens-enterprise.com >http://www.siemens-enterprise.com/uk/ > >Siemens Enterprise Communications Limited. >Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 >0DJ. >Registered No: 5903714, England. > >Siemens Enterprise Communications Limited is a Trademark Licensee of >Siemens AG. > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Sun Sep 11 14:04: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 A4D3F21F8A57 for ; Sun, 11 Sep 2011 14:04:35 -0700 (PDT) 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.086, 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 7T6qm7qFv442 for ; Sun, 11 Sep 2011 14:04:29 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id F1C0021F8997 for ; Sun, 11 Sep 2011 14:04:28 -0700 (PDT) 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 p8BL6uOv031961; Sun, 11 Sep 2011 17:06:56 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Sep 2011 17:06:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC70C6.A8F72A26" Date: Mon, 12 Sep 2011 02:36:22 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F09EE@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] Thread-Index: AcxuPP0feYPgx86jT+OVoz6XWaUpWwChUwlQ References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com><496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net><4E540FE2.7020605@alcatel-lucent.com><2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com><4E6595E7.7060503@skype.net><4E661C83.5000103@alcatel-lucent.com><4E668FB3.9020601@skype.net><2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com><4E67AD3D.9000005@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com><4E686663.1050900@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F0989@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: "Roman Shpount" X-OriginalArrivalTime: 11 Sep 2011 21:06:26.0010 (UTC) FILETIME=[AAE87BA0:01CC70C6] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 11 Sep 2011 21:04:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC70C6.A8F72A26 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roman, =20 IIUC, SIP 2.0 (RFC 3261) and its extensions are not flexible for public internet two-party communication and HTTP (websocket) + Javascript is a better known solution for this communication but less efficient. I tend to agree with you in case my understanding about your mail is correct.=20 =20 My way of looking at this problem solving using websocket with no other its extension is that the time of market delivery of RTCWeb1.0 without looking for the future. I'm worried because these sort of deliverables creates chaos during RTCWeb2.0 wherein RTCweb2.0 will be restricted to RTCWeb 1.0 to meet backward compatibility. Very good example is not that folks are not interested in SIP 2.0 with its extensions or SIP 3.0 as you mentioned below J =20 Please read inline. =20 Thanks Partha =20 =20 From: Roman Shpount [mailto:roman@telurix.com]=20 Sent: Thursday, September 08, 2011 9:06 PM To: Ravindran Parthasarathi Cc: Harald Alvestrand; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] =20 Partha, What I am failing to understand is what you plan to use SIP for.=20 [Partha] SIP for real-time communication using IETF standard. SIP would be useful to call a SIP end point on the public IP or behind the same NAT. If you want to call another SIP end point behind NAT, especially if you need to use TCP to send ICE offers or security with TLS, you will need an assistance of some type of server on the public IP. In order for this to work both server and the client will need to implement something like RFC 5626. This will require building something fairly tricky to essentially proxy all the SIP requests from the client to all the other SIP points. Building this is no easier then implementing the same thing using an HTTP server application which works with a client JavaScript library. If our primary goal were implementation of Intranet SIP phones, that would be an acceptable solution. For consumer oriented RTC service this is completely useless. [Partha]. You are comparing RFC 5626 with websocket(draft-ietf-hybi-thewebsocketprotocol ). Please correct me here On the other hand extending SIP based infrastructure to implement new functionality is a lot more complex. Adding new features will require standardization or navigating a large number of conflicting SIP related specifications which are currently in force.=20 [Partha] I hope that you are talking about backward-compatibility issue which I mentioned earlier. Any new protocol looks green for the basic call and the mentioned supplementary services. While keep adding more service, HTTP will land in the same place. So, I'm not fully convinced here. I really don't know why do you think SIP based infrastructure is complex but I agree with you that SIP API design matters. Also, keep in mind that compliance to a lot of more advanced SIP specifications does not necessarily imply easy interoperability with existing devices. Compliance to a lot of those standards require a custom SIP server or SBC which implements them using a much smaller subset supported by each different SIP device. Bottom line, adding new features in SIP based environment typically requires a lot of server development, which is pretty much what will be required for doing signaling via an HTTP connection. [Partha] I agree with you that SIP interop is not straight forward because legacy implementation issues but HTTP connection calls new gateway with new mapping of the protocol. Please note that SIP normalization in SBC is well established compare to creating new HTTP + XML metadata to SIP gateways. I will concur that using HTTP with JavaScript is a lot less efficient then using SIP for both the client and the server, since client will need to implement more functionality using JavaScript and the server will need to maintain large number of connections and proxy all the requests, but this is a drawback of any AJAX based solution. This is something that seems to be acceptable to the industry and should not be a decisive factor. [Partha] The industry tries to re-use existing infrastructure for easy interop but does not mean that it is the best solution and IETF has to be adopt the same. IETF shall provide the better protocol. The industry adopts if the right protocol is designed or selected. _____________ Roman Shpount On Thu, Sep 8, 2011 at 11:13 AM, Ravindran Parthasarathi wrote: Harald, =20 I'm proposing for "SIP UA framework for RTCWeb browser", the framework provides Javascript API. In case you mean the same as "SIP lite". I'm fine with it. SIP UA framework helps to support two-party communication from RTCWeb browser and uses HTTP as presence or configuration interface.=20 =20 As I mentioned in the another mail, I'm talking about INVITE subset of RFC 3261 in browser. =20 =20 Thanks Partha =20 From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Thursday, September 08, 2011 12:23 PM To: Ravindran Parthasarathi Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] =20 On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote:=20 Harald, =20 For browser as a SIP UA application, browser has to no need to compliant with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also agree with you that browser-to-browser communication, I could not see the strong reason for supporting S/MIME. As part of the RTCWeb architecture & solution, we will able to explore the SIP UA requirement for making browser SIP compliant. So you're advocating for creating a "SIP lite" subset that RTCWEB browsers implement. I think we have been down this road before, and it's not a happy one. But sure - if you want us to implement some part of SIP, *please start stating what part* rather than making wooly statements. Subsets are Real Hard Work. Say for example, forking does not make sense in case of browser as SIP UA application, forked response will be rejected with CANCEL in browser without Javascript intervention. The main requirement is to build the right SIP UA framework in browser by which Javascript developer will be able to use to the maximum extent without impacting the basic 2 two party communication in the internet. =20 =20 As mailed in another thread, RTCWEB client + RTCWeb server makes to feel a modern exchange in web world (Plain Old Telephony System phone with exchange architecture). I think so because POTS phones are dumb which does not know its identity and every event like offhook, onhook has to passed to exchange (webserver) whereas RTCWeb client (browser) has to pass every event to webserver and webserver has whole intelligence to make it work. Don't forget that the RTCWEB client (the browser) contains an open, fully programmable application platform - the Javascript engine. That's a HUGE difference to the POTS phone. I got this feel more when someone is talking about MEGACO or MGCP between RTCWEB client & webserver. My understanding is that SIP does not fit well to legacy telephone-based paradigm by any means but MEGACO or MGCP are the better choice which maps to SS7 architecture well. I'm interested in seeing RTCWeb client perform the basic routing rather than webserver does the routing on behalf of RTCWEb client. =20 I agree with you that in case it is local exchange (same site like skype or Google hangout) communication, there will be no need of signaling but I'm interested in communication with one of the Google real-time user in internet without having any Google id. I believe that SIP will make it work. If by saying "the Google real time user in Internet", you mean a Google Talk user, you have that already. It's called Google Voice. It uses SIP, but not in the browser. Talking to someone who doesn't want to talk to you is an use case we don't intend to support. =20 Thanks Partha =20 From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Wednesday, September 07, 2011 11:13 PM To: Ravindran Parthasarathi Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] =20 On 09/07/11 19:29, Ravindran Parthasarathi wrote:=20 Matthew, =20 When I asked for SIP, I have meant RFC 3261 only. This is 269 pages, and has 26 normative dependencies including S/MIME. It's not a small dependency. The basic reason for asking SIP is to make the basic call works between browser to browser across web servers. Without SIP in browser, it is not going happen. Innovative application is going to be proprietary whether it is HTTP or SIP or any other protocol for that matter. =20 My reasoning are as follows: SIP makes browser more intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG.=20 Why does that "intelligence" need to be in the browser, rather than in the Javascript? The importance of basic call interop is that there is no need of many individual id like skype id, Google id and yahoo id by everyone in the world to communicate others. I wish to have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.=20 This only makes sense for applications that fit the "call an identified party" paradigm. SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provider. There is no need to build two different signaling logic in VoIP servers for each service. Your own example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible to avoided by having one signaling protocol. One protocol can be achieved by multiple applications choosing to implement one protocol. It doesn't have to be enforced by the prtoocol being embedded in the browser. =20 In RTCWEB does not standardize the signaling protocol interface between browsers, the interop across webservers is next to impossible and it will be restricted to single webserver (company) only. Please let me know in case I'm missing something here. I think the main thing you are missing is that there are many applications that people want to build on top of RTCWEB that are not telephones, and will not fit with telephone-based paradigms. =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------_=_NextPart_001_01CC70C6.A8F72A26 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roman,

 

IIUC, SIP 2.0 (RFC 3261) and its extensions are not = flexible for public internet two-party communication and HTTP (websocket) + = Javascript is a better known solution for this communication but less efficient. I tend = to agree with you in case my understanding about your mail is correct. =

 

My way of looking at this problem solving using websocket = with no other its extension is that the time of market delivery of RTCWeb1.0 = without looking for the future. I’m worried because these sort of = deliverables creates chaos during RTCWeb2.0 wherein RTCweb2.0 will be restricted to = RTCWeb 1.0 to meet backward compatibility. Very good example is not that folks = are not interested in SIP 2.0 with its extensions or SIP 3.0 as you mentioned = below J

 

Please read inline.

 

Thanks

Partha

 

 

From:= Roman = Shpount [mailto:roman@telurix.com]
Sent: Thursday, September 08, 2011 9:06 PM
To: Ravindran Parthasarathi
Cc: Harald Alvestrand; rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remote recording - RTC-Web client acting as SIPREC session recording = client]

 

Partha,

What I am failing to understand is what you plan to use SIP for.

[Partha] SIP = for real-time communication using IETF = standard.

SIP would be useful = to call a SIP end point on the public IP or behind the same NAT. If you want to = call another SIP end point behind NAT, especially if you need to use TCP to = send ICE offers or security with TLS, you will need an assistance of some type of = server on the public IP. In order for this to work both server and the client = will need to implement something like RFC 5626. This will require building = something fairly tricky to essentially proxy all the SIP requests from the client = to all the other SIP points. Building this is no easier then implementing the = same thing using an HTTP server application which works with a client = JavaScript library. If our primary goal were implementation of Intranet SIP phones, = that would be an acceptable solution. For consumer oriented RTC service this = is completely useless.

[Partha]. You = are comparing RFC 5626 with websocket(draft-ietf-hybi-thewebsocketprotocol = ). Please correct me here

On the other hand extending SIP based infrastructure to implement new functionality is a lot more complex. Adding new features will require standardization or navigating a large number of conflicting SIP related specifications which are currently in force.

[Partha] I hope = that you are talking about backward-compatibility issue which I mentioned = earlier. Any new protocol looks green for the basic call and the mentioned = supplementary services. While keep adding more service, HTTP will land in the same = place. So, I’m not fully convinced here. I really don’t know why do you = think SIP based infrastructure is complex but I agree with you that SIP API = design matters.

Also, keep in mind = that compliance to a lot of more advanced SIP specifications does not = necessarily imply easy interoperability with existing devices. Compliance to a lot = of those standards require a custom SIP server or SBC which implements them using = a much smaller subset supported by each different SIP device. Bottom line, = adding new features in SIP based environment typically requires a lot of server development, which is pretty much what will be required for doing = signaling via an HTTP connection.

[Partha] I = agree with you that SIP interop is not straight forward because legacy = implementation issues but HTTP connection calls new gateway with new mapping of the = protocol. Please note that SIP normalization in SBC is well established compare to = creating new HTTP + XML metadata to SIP gateways.



I will concur that using HTTP with JavaScript is a lot less efficient = then using SIP for both the client and the server, since client will need to implement more functionality using JavaScript and the server will need = to maintain large number of connections and proxy all the requests, but = this is a drawback of any AJAX based solution. This is something that seems to be acceptable to the industry and should not be a decisive factor.

[Partha] The = industry tries to re-use  existing infrastructure for easy interop but does = not mean that it is the best solution and IETF has to be adopt the same. = IETF shall provide the better protocol. The industry adopts if the right protocol = is designed or selected.


_____________
Roman Shpount

On Thu, Sep 8, 2011 at 11:13 AM, Ravindran = Parthasarathi <pravindran@sonusnet.com> wrote:

Harald,

 

I’m proposing for = “SIP UA framework for RTCWeb browser”, the framework provides Javascript = API. In case you mean the same as “SIP lite”. I’m fine with = it. SIP UA framework helps to support two-party communication from RTCWeb = browser and uses HTTP as presence or configuration interface.

 

As I mentioned in the another = mail, I’m talking about INVITE subset of RFC 3261 in browser. =  

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Thursday, September 08, 2011 12:23 PM


To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remote recording - RTC-Web client acting as SIPREC session recording = client]

 <= /o:p>

On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote:

Harald,

 

For browser as a SIP UA application, browser = has to no need to compliant with 269 pages of RFC 3261 as proxy core is irrelevant = to it. I also agree with you that browser-to-browser communication, I could not = see the strong reason for supporting S/MIME. As part of the RTCWeb = architecture & solution, we will able to explore the SIP UA requirement for = making browser SIP compliant.

So you're advocating for creating a "SIP lite" subset that RTCWEB browsers implement.
I think we have been down this road before, and it's not a happy = one.
But sure - if you want us to implement some part of SIP, *please start = stating what part* rather than making wooly statements.

Subsets are Real Hard Work.

Say for example, forking does not make sense = in case of browser as SIP UA application, forked response will be rejected with = CANCEL in browser without Javascript intervention. The main requirement is to = build the right SIP UA framework in browser by which Javascript developer will = be able to use to the maximum extent without impacting the basic 2 two = party communication in the internet. 

 

As mailed in another thread, RTCWEB client + = RTCWeb server makes to feel a modern exchange in web world (Plain Old Telephony = System phone with exchange architecture). I think so because POTS phones are = dumb which does not know its identity and every event like offhook, onhook = has to passed to exchange (webserver) whereas RTCWeb client (browser) has to = pass every event to webserver and webserver has whole intelligence to make it = work.

Don't forget that the RTCWEB client (the browser) contains an open, fully programmable application platform - the Javascript engine. That's a HUGE difference to the POTS phone.

I got this feel more when someone is talking = about MEGACO or MGCP between RTCWEB client & webserver. My understanding = is that SIP does not fit well to legacy telephone-based paradigm by any means = but MEGACO or MGCP are the better choice which maps to SS7 architecture = well. I’m interested in seeing RTCWeb client perform the basic routing = rather than webserver does the routing on behalf of RTCWEb = client.

 

I agree with you that in case it is local = exchange (same site like skype or Google hangout) communication, there will be no = need of signaling but I’m interested in communication with one of the = Google real-time user in internet without having any Google id.  I believe = that SIP will make it work.

If by saying "the Google real time user in Internet", you mean a = Google Talk user, you have that already. It's called Google Voice. It uses SIP, = but not in the browser.

Talking to someone who doesn't want to talk to you is an use case we = don't intend to support.

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Wednesday, September 07, 2011 11:13 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remote recording - RTC-Web client acting as SIPREC session recording = client]

 <= /o:p>

On 09/07/11 19:29, Ravindran Parthasarathi wrote:

Matthew,

 

When I asked for SIP, I have meant RFC 3261 = only.

This is 269 pages, and has 26 normative dependencies including S/MIME. It's = not a small dependency.



The basic reason for asking SIP is to make = the basic call works between browser to browser across web servers. Without SIP in browser, it is not going happen. Innovative application is going to be proprietary whether it is HTTP or SIP or any other protocol for that = matter.

 

My reasoning are as = follows:

SIP makes browser more intelligence = compare to dump signaling mechanism like MEGACO and browser acts as MG. =

Why does that "intelligence" need to be in the browser, rather = than in the Javascript?

The importance of basic call interop = is that there is no need of many individual id like skype id, Google id  = and yahoo id by everyone in the world to communicate others. I wish to have single = id like e-mail id to be maintained by browser-to-browser users to = communicate with others.

This only makes sense for applications that fit the "call an identified party" paradigm.

SIP helps to interop for basic call = with other existing realtime application in Enterprise & Telecom = provider.

There is no need to build two = different signaling logic in VoIP servers for each service. Your own example of = Bridge line appearance will need two implementation by the single vendor = because desktop application or hardphone implementation based on SIP and browser = based implementation is depend on HTTP metadata. It is possible to avoided by = having one signaling protocol.

One protocol can be achieved by multiple applications choosing to implement = one protocol.
It doesn't have to be enforced by the prtoocol being embedded in the = browser.

 

In RTCWEB does not standardize the signaling = protocol interface between browsers, the interop across webservers is next to = impossible and it will be restricted to single webserver (company) only. Please = let  me know in case I’m missing something here.


I think the main thing you are missing is that there are many = applications that people want to build on top of RTCWEB that are not telephones, and will = not fit with telephone-based paradigms.

 <= /o:p>


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

 

------_=_NextPart_001_01CC70C6.A8F72A26-- From roman@telurix.com Sun Sep 11 19:43: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 D770121F8A7E for ; Sun, 11 Sep 2011 19:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.857 X-Spam-Level: X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=0.119, 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 NL-jRZWOWJ1l for ; Sun, 11 Sep 2011 19:43:04 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC8721F8A95 for ; Sun, 11 Sep 2011 19:43:03 -0700 (PDT) Received: by pzk33 with SMTP id 33so21360685pzk.18 for ; Sun, 11 Sep 2011 19:45:05 -0700 (PDT) Received: by 10.68.44.130 with SMTP id e2mr3658352pbm.173.1315795505253; Sun, 11 Sep 2011 19:45:05 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx.google.com with ESMTPS id i1sm39991213pbe.1.2011.09.11.19.45.03 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Sep 2011 19:45:03 -0700 (PDT) Received: by pzk33 with SMTP id 33so21360532pzk.18 for ; Sun, 11 Sep 2011 19:45:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.43.8 with SMTP id s8mr3000196pbl.389.1315795502235; Sun, 11 Sep 2011 19:45:02 -0700 (PDT) Received: by 10.68.43.136 with HTTP; Sun, 11 Sep 2011 19:45:01 -0700 (PDT) In-Reply-To: <903DEDB7-CA26-4354-90B2-BE97B78B0A34@skype.net> References: <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <1541FDA8-C3F6-4D24-BEC4-60EDACB6B582@edvina.net> <903DEDB7-CA26-4354-90B2-BE97B78B0A34@skype.net> Date: Sun, 11 Sep 2011 22:45:01 -0400 Message-ID: From: Roman Shpount To: Matthew Kaufman Content-Type: multipart/alternative; boundary=bcaec5395f2481ff7804acb583c7 Cc: Randell Jesup , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 02:43:05 -0000 --bcaec5395f2481ff7804acb583c7 Content-Type: text/plain; charset=ISO-8859-1 Not sure if you want to configure TURN servers per organization. It is not guaranteed that the TURN server will be used for the call. Additionally you do want TURN server on the public internet, out side of the corporate network. I think what you are trying to accomplish should be implemented via proxy. SOCKS5 proxy can be used for media and can be used to enforce corporate policies. When connecting to an external TURN server, a regular HTTP proxy can be used, but in this case you normally end up with two different media relay agents (proxy and a TURN server). _____________ Roman Shpount On Sat, Sep 10, 2011 at 4:41 PM, Matthew Kaufman wrote: > > > > On Sep 10, 2011, at 11:52 AM, Roman Shpount wrote: > > > > > > > On the related note, I do think that specifying and providing STUN and > TURN servers should be responsibility of the RTC application developer and > not the browser configuration. TURN server can consume quite a bit of > bandwidth and one can see that they will be provided as a paid service in > combination with RTC application itself. > > > > I think we need both... In a corporate environment, there might be the > desire or need to send everything to a a TURN service operated by the > organization, independently of whether or not the service provider operates > such services. > > Matthew Kaufman > > Sent from my iPad > --bcaec5395f2481ff7804acb583c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not sure if you want to configure TURN servers per organization. It is not = guaranteed that the TURN server will be used for the call. Additionally you= do want TURN server on the public internet, out side of the corporate netw= ork. I think what you are trying to accomplish should be implemented via pr= oxy. SOCKS5 proxy can be used for media and can be used to enforce corporat= e policies. When connecting to an external TURN server, a regular HTTP prox= y can be used, but in this case you normally end up with two different medi= a relay agents (proxy and a TURN server).
_____________
Roman Shpount


On Sat, Sep 10, 2011 at 4:41 PM, Matthew= Kaufman <matthew.kaufman@skype.net> wrote:



On Sep 10, 2011, at 11:52 AM, Roman Shpount <roman@telurix.com> wrote:

>
>
> On the related note, I do think that specifying and providing STUN and= TURN servers should be responsibility of the RTC application developer and= not the browser configuration. TURN server can consume quite a bit of band= width and one can see that they will be provided as a paid service in combi= nation with RTC application itself.
>

I think we need both... In a corporate environment, there might be th= e desire or need to send everything to a a TURN service operated by the org= anization, independently of whether or not the service provider operates su= ch services.

Matthew Kaufman

Sent from my iPad

--bcaec5395f2481ff7804acb583c7-- From roman@telurix.com Sun Sep 11 19:56: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 DCE9C21F8546 for ; Sun, 11 Sep 2011 19:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HayGFrSezbp3 for ; Sun, 11 Sep 2011 19:56:13 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3E02B21F854F for ; Sun, 11 Sep 2011 19:56:13 -0700 (PDT) Received: by pzk33 with SMTP id 33so21401865pzk.18 for ; Sun, 11 Sep 2011 19:58:15 -0700 (PDT) Received: by 10.68.52.136 with SMTP id t8mr1461792pbo.244.1315796290984; Sun, 11 Sep 2011 19:58:10 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx.google.com with ESMTPS id i1sm40055932pbe.1.2011.09.11.19.58.09 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Sep 2011 19:58:09 -0700 (PDT) Received: by pzk33 with SMTP id 33so21401546pzk.18 for ; Sun, 11 Sep 2011 19:58:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.31.71 with SMTP id y7mr1810434pbh.121.1315796288982; Sun, 11 Sep 2011 19:58:08 -0700 (PDT) Received: by 10.68.43.136 with HTTP; Sun, 11 Sep 2011 19:58:08 -0700 (PDT) In-Reply-To: <4E6CB9F7.2060208@mozilla.com> References: <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org> <4E6AE22A.2070106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se> <4E6C16FF.1000706@jesup.org> <4E6CB9F7.2060208@mozilla.com> Date: Sun, 11 Sep 2011 22:58:08 -0400 Message-ID: From: Roman Shpount To: "Timothy B. Terriberry" Content-Type: multipart/alternative; boundary=bcaec520f2eb66d0eb04acb5b247 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 02:56:14 -0000 --bcaec520f2eb66d0eb04acb5b247 Content-Type: text/plain; charset=ISO-8859-1 I guess what I do not understand in this discussion is why do we need to negotiate all of this in the offer/answer. We need something that can interop with offer answer, but no more then that. The client JavaScript application should have control and ability to specify what kind of offer is generated. We can use the exisitng HTTP connection to get all the additional restrictions and options for the call. It is normally known to the application if the security is needed and supported. The functionality of figuring out device capabilities and user intent of this call (secure call to the bank or public video chat) should be left to the application and should not be part of this specification. What's currently is missing is ability to transmit and receive media. The rest of the features, such as getting events including new call event from the server, sending events to the server, maintaining a persistent connection from behind firewall and NAT is already present in the current web infrastructure. We do not need a new signaling protocol or standard. We do not need to add an existing signaling protocol not implemented by the browser such as SIP. It adds no new functionality and makes standard bigger and more difficult to comply. All that is needed is media. _____________ Roman Shpount On Sun, Sep 11, 2011 at 9:39 AM, Timothy B. Terriberry < tterriberry@mozilla.com> wrote: > * The level of media protection to use (NONE, SDES-SRTP or DTLS-SRTP) >> should be set by the web app >> > > Why wouldn't this devolve to, "Don't communicate anything. Instead, try to > create a PeerConnection with DTLS-SRTP, and when that fails, try to create a > second one with NONE," in the actual webapp. > > Or, more likely, since NONE will have a better chance of working with > legacy devices, "Try to create a PeerConnection with NONE, and when that > fails, try to create a second one with DTLS-SRTP." Assuming anyone bothers > with the second step. Having the choice of SDES-SRTP or DTLS-SRTP will also > make it more likely people won't bother with either, as they won't know > which one to use. We can try to create incentives with browser chrome, but > there's only so much that can do. > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --bcaec520f2eb66d0eb04acb5b247 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I guess what I do not understand in this discussion is why do we need to ne= gotiate all of this in the offer/answer. We need something that can interop= with offer answer, but no more then that. The client JavaScript applicatio= n should have control and ability to specify what kind of offer is generate= d. We can use the exisitng HTTP connection to get all the additional restri= ctions and options for the call. It is normally known to the application if= the security is needed and supported. The functionality of figuring out de= vice capabilities and user intent of this call (secure call to the bank or = public video chat) should be left to the application and should not be part= of this specification. What's currently is missing is ability to trans= mit and receive media. The rest of the features, such as getting events inc= luding new call event from the server, sending events to the server, mainta= ining a persistent connection from behind firewall and NAT is already prese= nt in the current web infrastructure. We do not need a new signaling protoc= ol or standard. We do not need to add an existing signaling protocol not im= plemented by the browser such as SIP. It adds no new functionality and make= s standard bigger and more difficult to comply. All that is needed is media= .
_____________
Roman Shpount


On Sun, Sep 11, 2011 at 9:39 AM, Timothy= B. Terriberry <tterriberry@mozilla.com> wrote:
* The level of media protection to use (NONE, SDES-SRTP or DTLS-SRTP) shoul= d be set by the web app

Why wouldn't this devolve to, "Don't communicate anything. Ins= tead, try to create a PeerConnection with DTLS-SRTP, and when that fails, t= ry to create a second one with NONE," in the actual webapp.

Or, more likely, since NONE will have a better chance of working with legac= y devices, "Try to create a PeerConnection with NONE, and when that fa= ils, try to create a second one with DTLS-SRTP." Assuming anyone bothe= rs with the second step. Having the choice of SDES-SRTP or DTLS-SRTP will a= lso make it more likely people won't bother with either, as they won= 9;t know which one to use. We can try to create incentives with browser chr= ome, but there's only so much that can do.

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

--bcaec520f2eb66d0eb04acb5b247-- From roman@telurix.com Sun Sep 11 20: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 812CE21F8A57 for ; Sun, 11 Sep 2011 20:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.791 X-Spam-Level: X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[AWL=0.185, 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 bgbQ3B7WUTIv for ; Sun, 11 Sep 2011 20:25:36 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 40D4521F889A for ; Sun, 11 Sep 2011 20:25:36 -0700 (PDT) Received: by pzk33 with SMTP id 33so21498980pzk.18 for ; Sun, 11 Sep 2011 20:27:38 -0700 (PDT) Received: by 10.68.5.138 with SMTP id s10mr2950112pbs.238.1315798057214; Sun, 11 Sep 2011 20:27:37 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx.google.com with ESMTPS id i1sm40202091pbe.1.2011.09.11.20.27.34 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Sep 2011 20:27:35 -0700 (PDT) Received: by pzk33 with SMTP id 33so21498717pzk.18 for ; Sun, 11 Sep 2011 20:27:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.12.40 with SMTP id v8mr3557983pbb.322.1315798054329; Sun, 11 Sep 2011 20:27:34 -0700 (PDT) Received: by 10.68.43.136 with HTTP; Sun, 11 Sep 2011 20:27:33 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F09EE@sonusinmail02.sonusnet.com> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F0989@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F09EE@sonusinmail02.sonusnet.com> Date: Sun, 11 Sep 2011 23:27:33 -0400 Message-ID: From: Roman Shpount To: Ravindran Parthasarathi Content-Type: multipart/alternative; boundary=bcaec51f90199fdeba04acb61b42 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 03:25:38 -0000 --bcaec51f90199fdeba04acb61b42 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Partha, What I was saying that even with the current web client infrastructure you can implement everything you need to create a signaling channel. You can us= e a hanging HTTP request technique to send notifications to the client. This is less efficient then websocket, but this is available and is used by a lo= t of applications that implement IM and other real time event notifications. My main point is that communications using RFC 3261 SIP would be limited to communications between two clients on the public internet or on the same natted network. This is useless to a consumer oriented RTC application, where each end point would be behind its own NAT. To communicate using SIP from behind NAT you need some types of SIP extensions. The standard that intends (and somewhat fails) to provide a generic solution for communications between SIP end points behind NAT is RFC 5626. This is the only solution that allows support for SIP over TCP and SIP over TLS (security) from behind NAT. It essentially makes clients proxy all its SIP requests through a persistent connection to a proxy located on the public IP. The main downsides of this solution is that I do not know of the single one actually implemented and available (to be honest we just built one) and that it still has problems with things like connection reset in the middle of a SIP transaction. As far as efficiency of this solution is concerned it is no more network, CPU, or implementation efficient then building an HTTP to SIP proxy doing the same thing. If web RTC becomes a reality I would see that someone can take a month or two and implement such HTTP to SIP proxy using SIP servlets or a custom module to opensips. This is no more complicated then that. Once again, this does not even need websockets, but would certainly benefit from them. If we go this route we do not need to add anything to HTTP. We do not need to standardize this. This all falls within an already existing capabilities of JavaScript and things like XMLHttpRequest. There is nothing for the standard committee to do in regard to signaling. We will not add any value by creating new standards here. We can try to adapt SIP for RTC, but in som= e sense existing browser environment provides a signaling channel that is better, more flexible, more robust, secure, and most importantly already implemented. As far as working with telephone companies, our best course of action is to provide something that, with some application knowledge, can be mapped to SIP. If we want to terminate to the existing telephone network this is the only course of action. Everything else will result into something were medi= a would need to be proxied. It does not matter how good or robust protocol we create here, it will take telephone companies 5-10 years to adopt and implement it. This is not the time-frame that we can afford. _____________ Roman Shpount On Sun, Sep 11, 2011 at 5:06 PM, Ravindran Parthasarathi < pravindran@sonusnet.com> wrote: > Hi Roman,**** > > ** ** > > IIUC, SIP 2.0 (RFC 3261) and its extensions are not flexible for public > internet two-party communication and HTTP (websocket) + Javascript is a > better known solution for this communication but less efficient. I tend t= o > agree with you in case my understanding about your mail is correct. **** > > ** ** > > My way of looking at this problem solving using websocket with no other i= ts > extension is that the time of market delivery of RTCWeb1.0 without lookin= g > for the future. I=92m worried because these sort of deliverables creates = chaos > during RTCWeb2.0 wherein RTCweb2.0 will be restricted to RTCWeb 1.0 to me= et > backward compatibility. Very good example is not that folks are not > interested in SIP 2.0 with its extensions or SIP 3.0 as you mentioned bel= ow > J**** > > ** ** > > Please read inline.**** > > ** ** > > Thanks**** > > Partha**** > > ** ** > > ** ** > > *From:* Roman Shpount [mailto:roman@telurix.com] > *Sent:* Thursday, September 08, 2011 9:06 PM > *To:* Ravindran Parthasarathi > *Cc:* Harald Alvestrand; rtcweb@ietf.org > > *Subject:* Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote > recording - RTC-Web client acting as SIPREC session recording client]**** > > ** ** > > Partha, > > What I am failing to understand is what you plan to use SIP for. **** > > *[Partha] SIP for real-time communication using IETF standard.* > > SIP would be useful to call a SIP end point on the public IP or behind th= e > same NAT. If you want to call another SIP end point behind NAT, especiall= y > if you need to use TCP to send ICE offers or security with TLS, you will > need an assistance of some type of server on the public IP. In order for > this to work both server and the client will need to implement something > like RFC 5626. This will require building something fairly tricky to > essentially proxy all the SIP requests from the client to all the other S= IP > points. Building this is no easier then implementing the same thing using= an > HTTP server application which works with a client JavaScript library. If = our > primary goal were implementation of Intranet SIP phones, that would be an > acceptable solution. For consumer oriented RTC service this is completely > useless.**** > > *[Partha]. You are comparing RFC 5626 with > websocket(draft-ietf-hybi-thewebsocketprotocol ). Please correct me here* > > On the other hand extending SIP based infrastructure to implement new > functionality is a lot more complex. Adding new features will require > standardization or navigating a large number of conflicting SIP related > specifications which are currently in force. **** > > *[Partha] I hope that you are talking about backward-compatibility issue > which I mentioned earlier. Any new protocol looks green for the basic cal= l > and the mentioned supplementary services. While keep adding more service, > HTTP will land in the same place. So, I=92m not fully convinced here. I r= eally > don=92t know why do you think SIP based infrastructure is complex but I a= gree > with you that SIP API design matters.* > > Also, keep in mind that compliance to a lot of more advanced SIP > specifications does not necessarily imply easy interoperability with > existing devices. Compliance to a lot of those standards require a custom > SIP server or SBC which implements them using a much smaller subset > supported by each different SIP device. Bottom line, adding new features = in > SIP based environment typically requires a lot of server development, whi= ch > is pretty much what will be required for doing signaling via an HTTP > connection.**** > > *[Partha] I agree with you that SIP interop is not straight forward > because legacy implementation issues but HTTP connection calls new gatewa= y > with new mapping of the protocol. Please note that SIP normalization in S= BC > is well established compare to creating new HTTP + XML metadata to SIP > gateways.* > > > > I will concur that using HTTP with JavaScript is a lot less efficient the= n > using SIP for both the client and the server, since client will need to > implement more functionality using JavaScript and the server will need to > maintain large number of connections and proxy all the requests, but this= is > a drawback of any AJAX based solution. This is something that seems to be > acceptable to the industry and should not be a decisive factor.**** > > *[Partha] The industry tries to re-use existing infrastructure for easy > interop but does not mean that it is the best solution and IETF has to be > adopt the same. IETF shall provide the better protocol. The industry adop= ts > if the right protocol is designed or selected.* > > > _____________ > Roman Shpount > > ** > > On Thu, Sep 8, 2011 at 11:13 AM, Ravindran Parthasarathi < > pravindran@sonusnet.com> wrote:**** > > Harald,**** > > **** > > I=92m proposing for =93SIP UA framework for RTCWeb browser=94, the framew= ork > provides Javascript API. In case you mean the same as =93SIP lite=94. I= =92m fine > with it. SIP UA framework helps to support two-party communication from > RTCWeb browser and uses HTTP as presence or configuration interface. **** > > **** > > As I mentioned in the another mail, I=92m talking about INVITE subset of = RFC > 3261 in browser. **** > > **** > > Thanks**** > > Partha**** > > **** > > *From:* Harald Alvestrand [mailto:harald@alvestrand.no] > *Sent:* Thursday, September 08, 2011 12:23 PM**** > > > *To:* Ravindran Parthasarathi > *Cc:* Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org > > *Subject:* Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote > recording - RTC-Web client acting as SIPREC session recording client]**** > > **** > > On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote: **** > > Harald,**** > > **** > > For browser as a SIP UA application, browser has to no need to compliant > with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also agre= e > with you that browser-to-browser communication, I could not see the stron= g > reason for supporting S/MIME. As part of the RTCWeb architecture & soluti= on, > we will able to explore the SIP UA requirement for making browser SIP > compliant.**** > > So you're advocating for creating a "SIP lite" subset that RTCWEB browser= s > implement. > I think we have been down this road before, and it's not a happy one. > But sure - if you want us to implement some part of SIP, *please start > stating what part* rather than making wooly statements. > > Subsets are Real Hard Work.**** > > Say for example, forking does not make sense in case of browser as SIP UA > application, forked response will be rejected with CANCEL in browser with= out > Javascript intervention. The main requirement is to build the right SIP U= A > framework in browser by which Javascript developer will be able to use to > the maximum extent without impacting the basic 2 two party communication = in > the internet. **** > > **** > > As mailed in another thread, RTCWEB client + RTCWeb server makes to feel = a > modern exchange in web world (Plain Old Telephony System phone with excha= nge > architecture). I think so because POTS phones are dumb which does not kno= w > its identity and every event like offhook, onhook has to passed to exchan= ge > (webserver) whereas RTCWeb client (browser) has to pass every event to > webserver and webserver has whole intelligence to make it work.**** > > Don't forget that the RTCWEB client (the browser) contains an open, fully > programmable application platform - the Javascript engine. That's a HUGE > difference to the POTS phone.**** > > I got this feel more when someone is talking about MEGACO or MGCP between > RTCWEB client & webserver. My understanding is that SIP does not fit well= to > legacy telephone-based paradigm by any means but MEGACO or MGCP are the > better choice which maps to SS7 architecture well. I=92m interested in se= eing > RTCWeb client perform the basic routing rather than webserver does the > routing on behalf of RTCWEb client.**** > > **** > > I agree with you that in case it is local exchange (same site like skype = or > Google hangout) communication, there will be no need of signaling but I= =92m > interested in communication with one of the Google real-time user in > internet without having any Google id. I believe that SIP will make it > work.**** > > If by saying "the Google real time user in Internet", you mean a Google > Talk user, you have that already. It's called Google Voice. It uses SIP, = but > not in the browser. > > Talking to someone who doesn't want to talk to you is an use case we don'= t > intend to support.**** > > **** > > Thanks**** > > Partha**** > > **** > > *From:* Harald Alvestrand [mailto:harald@alvestrand.no] > > *Sent:* Wednesday, September 07, 2011 11:13 PM > *To:* Ravindran Parthasarathi > *Cc:* Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org > > *Subject:* Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote > recording - RTC-Web client acting as SIPREC session recording client] > **** > > **** > > On 09/07/11 19:29, Ravindran Parthasarathi wrote: **** > > Matthew,**** > > **** > > When I asked for SIP, I have meant RFC 3261 only.**** > > This is 269 pages, and has 26 normative dependencies including S/MIME. It= 's > not a small dependency.**** > > > > **** > > The basic reason for asking SIP is to make the basic call works between > browser to browser across web servers. Without SIP in browser, it is not > going happen. Innovative application is going to be proprietary whether i= t > is HTTP or SIP or any other protocol for that matter.**** > > **** > > My reasoning are as follows:**** > > SIP makes browser more intelligence compare to dump signaling mechanism > like MEGACO and browser acts as MG. **** > > Why does that "intelligence" need to be in the browser, rather than in th= e > Javascript? > > **** > > The importance of basic call interop is that there is no need of many > individual id like skype id, Google id and yahoo id by everyone in the > world to communicate others. I wish to have single id like e-mail id to b= e > maintained by browser-to-browser users to communicate with others. **** > > This only makes sense for applications that fit the "call an identified > party" paradigm. > > **** > > SIP helps to interop for basic call with other existing realtime > application in Enterprise & Telecom provider.**** > > There is no need to build two different signaling logic in VoIP servers f= or > each service. Your own example of Bridge line appearance will need two > implementation by the single vendor because desktop application or hardph= one > implementation based on SIP and browser based implementation is depend on > HTTP metadata. It is possible to avoided by having one signaling protocol= . > **** > > One protocol can be achieved by multiple applications choosing to impleme= nt > one protocol. > It doesn't have to be enforced by the prtoocol being embedded in the > browser. > > **** > > **** > > In RTCWEB does not standardize the signaling protocol interface between > browsers, the interop across webservers is next to impossible and it will= be > restricted to single webserver (company) only. Please let me know in cas= e > I=92m missing something here.**** > > > I think the main thing you are missing is that there are many application= s > that people want to build on top of RTCWEB that are not telephones, and w= ill > not fit with telephone-based paradigms.**** > > **** > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb**** > > ** ** > --bcaec51f90199fdeba04acb61b42 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Partha,

What I was saying that even with the current web client infr= astructure you can implement everything you need to create a signaling chan= nel. You can use a hanging HTTP request technique to send notifications to = the client. This is less efficient then websocket, but this is available an= d is used by a lot of applications that implement IM and other real time ev= ent notifications.

My main point is that communications using RFC 3261 SIP would be limite= d to communications between two clients on the public internet or on the sa= me natted network. This is useless to a consumer oriented RTC application, = where each end point would be behind its own NAT. To communicate using SIP = from behind NAT you need some types of SIP extensions. The standard that in= tends (and somewhat fails) to provide a generic solution for communications= between SIP end points behind NAT is RFC 5626. This is the only solution t= hat allows support for SIP over TCP and SIP over TLS (security) from behind= NAT. It essentially makes clients proxy all its SIP requests through a per= sistent connection to a proxy located on the public IP. The main downsides = of this solution is that I do not know of the single one actually implement= ed and available (to be honest we just built one) and that it still has pro= blems with things like connection reset in the middle of a SIP transaction.= As far as efficiency of this solution is concerned it is no more network, = CPU, or implementation efficient then building an HTTP to SIP proxy doing t= he same thing. If web RTC becomes a reality I would see that someone can ta= ke a month or two and implement=A0 such HTTP to SIP proxy using SIP servlet= s or a custom module to opensips. This is no more complicated then that. On= ce again, this does not even need websockets, but would certainly benefit f= rom them.

If we go this route we do not need to add anything to HTTP. We do not n= eed to standardize this. This all falls within an already existing capabili= ties of JavaScript and things like XMLHttpRequest. There is nothing for the= standard committee to do in regard to signaling. We will not add any value= by creating new standards here. We can try to adapt SIP for RTC, but in so= me sense existing browser environment provides a signaling channel that is = better, more flexible, more robust, secure, and most importantly already im= plemented.

As far as working with telephone companies, our best course of action i= s to provide something that, with some application knowledge, can be mapped= to SIP. If we want to terminate to the existing telephone network this is = the only course of action. Everything else will result into something were = media would need to be proxied. It does not matter how good or robust proto= col we create here, it will take telephone companies 5-10 years to adopt an= d implement it. This is not the time-frame that we can afford.
_____________
Roman Shpount


On Sun, Sep 11, 2011 at 5:06 PM, Ravindr= an Parthasarathi <pravindran@sonusnet.com> wrote:

Hi Ro= man,

=A0

IIUC,= SIP 2.0 (RFC 3261) and its extensions are not flexible for public internet two-party communication and HTTP (websocket) + Javascript i= s a better known solution for this communication but less efficient. I tend to agree with you in case my understanding about your mail is correct. =

=A0

My wa= y of looking at this problem solving using websocket with no other its extension is that the time of market delivery of RTCWeb1.0 wit= hout looking for the future. I=92m worried because these sort of deliverables creates chaos during RTCWeb2.0 wherein RTCweb2.0 will be restricted to RTCW= eb 1.0 to meet backward compatibility. Very good example is not that folks are= not interested in SIP 2.0 with its extensions or SIP 3.0 as you mentioned below= J

=A0

Pleas= e read inline.

=A0

Thank= s

Parth= a

=A0

=A0

From:= Roman Shpount [mailto:roman@teluri= x.com]
Sent: Thursday, September 08, 2011 9:06 PM
To: Ravindran Parthasarathi
Cc: Harald Alvestrand; rtcweb@ietf.org


Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remot= e recording - RTC-Web client acting as SIPREC session recording client]

=A0

Partha,

What I am failing to understand is what you plan to use SIP for.

[Partha] SIP for real-time communication using IETF standard.

SIP would be useful t= o call a SIP end point on the public IP or behind the same NAT. If you want to call another SIP end point behind NAT, especially if you need to use TCP to send= ICE offers or security with TLS, you will need an assistance of some type of se= rver on the public IP. In order for this to work both server and the client will need to implement something like RFC 5626. This will require building somet= hing fairly tricky to essentially proxy all the SIP requests from the client to = all the other SIP points. Building this is no easier then implementing the same thing using an HTTP server application which works with a client JavaScript library. If our primary goal were implementation of Intranet SIP phones, th= at would be an acceptable solution. For consumer oriented RTC service this is completely useless.

[Partha]. You are comparing RFC 5626 with websocket(draft-ietf-hybi-thewebsocketprotocol ). P= lease correct me here

On the other hand extending SIP based infrastructure to implement new functionality is a lot more complex. Adding new features will require standardization or navigating a large number of conflicting SIP related specifications which are currently in force. =

[Partha] I hope that you are talking about backward-compatibility issue which I mentioned earlie= r. Any new protocol looks green for the basic call and the mentioned supplementary services. While keep adding more service, HTTP will land in the same place.= So, I=92m not fully convinced here. I really don=92t know why do you think SIP based infrastructure is complex but I agree with you that SIP API desig= n matters.

Also, keep in mind th= at compliance to a lot of more advanced SIP specifications does not necessaril= y imply easy interoperability with existing devices. Compliance to a lot of t= hose standards require a custom SIP server or SBC which implements them using a = much smaller subset supported by each different SIP device. Bottom line, adding = new features in SIP based environment typically requires a lot of server development, which is pretty much what will be required for doing signaling= via an HTTP connection.

[Partha] I agree with you that SIP interop is not straight forward because legacy implementation issues but HTTP connection calls new gateway with new mapping of the protoc= ol. Please note that SIP normalization in SBC is well established compare to cr= eating new HTTP + XML metadata to SIP gateways.



I will concur that using HTTP with JavaScript is a lot less efficient then using SIP for both the client and the server, since client will need to implement more functionality using JavaScript and the server will need to maintain large number of connections and proxy all the requests, but this i= s a drawback of any AJAX based solution. This is something that seems to be acceptable to the industry and should not be a decisive factor.

[Partha] The industry tries to re-use =A0existing infrastructure for easy interop but does not mean that it is the best solution and IETF has to be adopt the same. IETF s= hall provide the better protocol. The industry adopts if the right protocol is designed or selected.


_____________
Roman Shpount

<= /i>

On Thu, Sep 8, 2011 at 11:13 AM, Ravindran Parthasar= athi <pravindran= @sonusnet.com> wrote:

Haral= d,

=A0

I=92m= proposing for =93SIP UA framework for RTCWeb browser=94, the framework provides Javascript API. In case you mean the same as =93SIP lite=94. I=92m fine with it. SIP UA framework helps to support two-party communication from RTCWeb browser a= nd uses HTTP as presence or configuration interface.

=A0

As I = mentioned in the another mail, I=92m talking about INVITE subset of RFC 3261 in browser. =A0=

=A0

Thank= s

Parth= a

=A0

From:= Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Thursday, September 08, 2011 12:23 PM


To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org


Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remot= e recording - RTC-Web client acting as SIPREC session recording client]

=A0

On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote:

Harald,

=A0

For browser as a SI= P UA application, browser has to no need to compliant with 269 pages of RFC 3261 as proxy core is irrelevant to= it. I also agree with you that browser-to-browser communication, I could not se= e the strong reason for supporting S/MIME. As part of the RTCWeb architecture & solution, we will able to explore the SIP UA requirement for making browser SIP compliant.

So you're advocating for creating a "SIP lite" subset that RTCWE= B browsers implement.
I think we have been down this road before, and it's not a happy one. But sure - if you want us to implement some part of SIP, *please start stat= ing what part* rather than making wooly statements.

Subsets are Real Hard Work.

Say for example, fo= rking does not make sense in case of browser as SIP UA application, forked response will be rejected with CAN= CEL in browser without Javascript intervention. The main requirement is to buil= d the right SIP UA framework in browser by which Javascript developer will be able to use to the maximum extent without impacting the basic 2 two party communication in the internet.=A0

=A0

As mailed in anothe= r thread, RTCWEB client + RTCWeb server makes to feel a modern exchange in web world (Plain Old Telephony Sy= stem phone with exchange architecture). I think so because POTS phones are dumb which does not know its identity and every event like offhook, onhook has t= o passed to exchange (webserver) whereas RTCWeb client (browser) has to pass every event to webserver and webserver has whole intelligence to make it wo= rk.

Don't forget that the RTCWEB client (the browser) contains an open, fully programmable application platform - the Javascript engine. That's a HUG= E difference to the POTS phone.

I got this feel mor= e when someone is talking about MEGACO or MGCP between RTCWEB client & webserver. My understanding is t= hat SIP does not fit well to legacy telephone-based paradigm by any means but MEGACO or MGCP are the better choice which maps to SS7 architecture well. I=92m interested in seeing RTCWeb client perform the basic routing rather t= han webserver does the routing on behalf of RTCWEb client.=

=A0

I agree with you th= at in case it is local exchange (same site like skype or Google hangout) communication, there will be no ne= ed of signaling but I=92m interested in communication with one of the Google real-time user in internet without having any Google id. =A0I believe that SIP will make it work.

If by saying "the Google real time user in Internet", you mean a Google Talk user, you have that already. It's called Google Voice. It uses SIP= , but not in the browser.

Talking to someone who doesn't want to talk to you is an use case we do= n't intend to support.

=A0

Thanks

Partha

=A0

From:= Harald Alvestrand [mailt= o:harald@alvestrand.no]
Sent: Wednesday, September 07, 2011 11:13 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org


Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remot= e recording - RTC-Web client acting as SIPREC session recording client]
=

=A0

On 09/07/11 19:29, Ravindran Parthasarathi wrote:

Matthew,<= /u>

=A0

When I asked for SI= P, I have meant RFC 3261 only.

This is 269 pages, and has 26 normative dependencies including S/MIME. It's = not a small dependency.



The basic reason fo= r asking SIP is to make the basic call works between browser to browser across web servers. Without SIP in browser, it is not going happen. Innovative application is going to be proprietary whether it is HTTP or SIP or any other protocol for that matter= .

=A0

My reasoning are as= follows:

SIP makes browser more intelligence com= pare to dump signaling mechanism like MEGACO and browser acts as MG. <= /u>

Why does that "intelligence" need to be in the browser, rather than i= n the Javascript?

The importance of basic call interop is= that there is no need of many individual id like skype id, Google id=A0 and yaho= o id by everyone in the world to communicate others. I wish to have single id like e-mail id to be maintained by browser-to-browser users to communicate = with others.

This only makes sense for applications that fit the "call an identified party" paradigm.

SIP helps to interop for basic call wit= h other existing realtime application in Enterprise & Telecom provider.

There is no need to build two different signaling logic in VoIP servers for each service. Your own example of Bridg= e line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser ba= sed implementation is depend on HTTP metadata. It is possible to avoided by hav= ing one signaling protocol.

One protocol can be achieved by multiple applications choosing to implement one protocol.
It doesn't have to be enforced by the prtoocol being embedded in the br= owser.

=A0<= /p>

In RTCWEB does not = standardize the signaling protocol interface between browsers, the interop across webservers is next to imposs= ible and it will be restricted to single webserver (company) only. Please let=A0 me know in case I=92m missing something here.


I think the main thing you are missing is that there are many applications = that people want to build on top of RTCWEB that are not telephones, and will not= fit with telephone-based paradigms.

=A0


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

=A0


--bcaec51f90199fdeba04acb61b42-- From stefan.lk.hakansson@ericsson.com Sun Sep 11 23:31: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 725F621F849B for ; Sun, 11 Sep 2011 23:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.314 X-Spam-Level: X-Spam-Status: No, score=-6.314 tagged_above=-999 required=5 tests=[AWL=-0.015, 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 J0aI+XDBTfGN for ; Sun, 11 Sep 2011 23:31:25 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5C221F8487 for ; Sun, 11 Sep 2011 23:31:24 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-b8-4e6da7b6b2ab Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FF.ED.20773.6B7AD6E4; Mon, 12 Sep 2011 08:33:27 +0200 (CEST) Received: from [150.132.141.36] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 12 Sep 2011 08:33:26 +0200 Message-ID: <4E6DA7B6.8020204@ericsson.com> Date: Mon, 12 Sep 2011 08:33:26 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org>, <4E6AE22A.2070106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se>, <4E6C16FF.1000706@jesup.org> <4E6CB9F7.2060208@mozilla.com> In-Reply-To: <4E6CB9F7.2060208@mozilla.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 06:31:26 -0000 I think there is no protection against badly written apps. If the signaling messages ("SDPs") are not properly protected as an example, there is another security hole. People not bothering with protecting media may not bother to protect the signaling either. I also think the default in my model protection (if the app makes no input) should be DTLS-SRTP. Stefan On 2011-09-11 15:39, Timothy B. Terriberry wrote: >> * The level of media protection to use (NONE, SDES-SRTP or DTLS-SRTP) should be set by the web app > > Why wouldn't this devolve to, "Don't communicate anything. Instead, try > to create a PeerConnection with DTLS-SRTP, and when that fails, try to > create a second one with NONE," in the actual webapp. > > Or, more likely, since NONE will have a better chance of working with > legacy devices, "Try to create a PeerConnection with NONE, and when that > fails, try to create a second one with DTLS-SRTP." Assuming anyone > bothers with the second step. Having the choice of SDES-SRTP or > DTLS-SRTP will also make it more likely people won't bother with either, > as they won't know which one to use. We can try to create incentives > with browser chrome, but there's only so much that can do. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Sun Sep 11 23:34: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 16B5221F8509 for ; Sun, 11 Sep 2011 23:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.314 X-Spam-Level: X-Spam-Status: No, score=-6.314 tagged_above=-999 required=5 tests=[AWL=-0.015, 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 0AcVcYaQZxSf for ; Sun, 11 Sep 2011 23:34:56 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5DB21F84FC for ; Sun, 11 Sep 2011 23:34:56 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-3e-4e6da88aa84b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5B.50.02839.A88AD6E4; Mon, 12 Sep 2011 08:36:58 +0200 (CEST) Received: from [150.132.141.36] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Mon, 12 Sep 2011 08:36:57 +0200 Message-ID: <4E6DA889.8030306@ericsson.com> Date: Mon, 12 Sep 2011 08:36:57 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org> <4E6AE22A.2070106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se> <4E6C16FF.1000706@jesup.org> <4E6CB9F7.2060208@mozilla.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 06:34:57 -0000 Agree fully. The SDP o/a is IMO there to set up media streams already agreed on (including level of protection) using other means. On 2011-09-12 04:58, Roman Shpount wrote: > I guess what I do not understand in this discussion is why do we need to > negotiate all of this in the offer/answer. We need something that can > interop with offer answer, but no more then that. The client JavaScript > application should have control and ability to specify what kind of > offer is generated. We can use the exisitng HTTP connection to get all > the additional restrictions and options for the call. It is normally > known to the application if the security is needed and supported. The > functionality of figuring out device capabilities and user intent of > this call (secure call to the bank or public video chat) should be left > to the application and should not be part of this specification. What's > currently is missing is ability to transmit and receive media. The rest > of the features, such as getting events including new call event from > the server, sending events to the server, maintaining a persistent > connection from behind firewall and NAT is already present in the > current web infrastructure. We do not need a new signaling protocol or > standard. We do not need to add an existing signaling protocol not > implemented by the browser such as SIP. It adds no new functionality and > makes standard bigger and more difficult to comply. All that is needed > is media. > _____________ > Roman Shpount > > > On Sun, Sep 11, 2011 at 9:39 AM, Timothy B. Terriberry > > wrote: > > * The level of media protection to use (NONE, SDES-SRTP or > DTLS-SRTP) should be set by the web app > > > Why wouldn't this devolve to, "Don't communicate anything. Instead, > try to create a PeerConnection with DTLS-SRTP, and when that fails, > try to create a second one with NONE," in the actual webapp. > > Or, more likely, since NONE will have a better chance of working > with legacy devices, "Try to create a PeerConnection with NONE, and > when that fails, try to create a second one with DTLS-SRTP." > Assuming anyone bothers with the second step. Having the choice of > SDES-SRTP or DTLS-SRTP will also make it more likely people won't > bother with either, as they won't know which one to use. We can try > to create incentives with browser chrome, but there's only so much > that can do. > > _________________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/__listinfo/rtcweb > > > From pravindran@sonusnet.com Sun Sep 11 23:55: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 BBC6021F87C2 for ; Sun, 11 Sep 2011 23:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, J_BACKHAIR_53=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 D50uSki0g0f9 for ; Sun, 11 Sep 2011 23:55:58 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9F34A21F8797 for ; Sun, 11 Sep 2011 23:55:58 -0700 (PDT) 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 p8C6wSBI026644; Mon, 12 Sep 2011 02:58:28 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Sep 2011 02:57:58 -0400 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: Mon, 12 Sep 2011 12:27:54 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0A19@sonusinmail02.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP vs Websocket in RTCWeb [was RE: [rtcweb] SIP MUST NOT be used in browser?] Thread-Index: AcxuYLv74sRbRYyWTw6p8sklFnpfFwCTmtUAABp9t1A= References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net><4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net><2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com><4E67AD3D.9000005@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com><4E686663.1050900@alvestrand.no><4E68CB68.3020100@alcatel-lucent.com><4E68D182.2090003@alvestrand.no><4E68D742.4010203@alcatel-lucent.com><4E68D8B5.7010602@alvestrand.no><4E6915F2.5000007@alcatel-lucent.com> <4E691CC6.9050905@stpeter.im> From: "Ravindran Parthasarathi" To: "Ravindran Parthasarathi" , "Peter Saint-Andre" , X-OriginalArrivalTime: 12 Sep 2011 06:57:58.0285 (UTC) FILETIME=[4DF3DBD0:01CC7119] Cc: rtcweb@ietf.org Subject: [rtcweb] SIP vs Websocket in RTCWeb [was RE: SIP MUST NOT be used 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, 12 Sep 2011 06:55:59 -0000 Changing the title for giving the clear context of discussion. Peter, Thanks for forwarding info about draft-ietf-hybi-thewebsocketprotocol. I started this mail thread to know whether RTCWeb1.0 is a unofficial RFC3261bis for the line side (endpoint to access server) :-) [I really don't know the better term for the line side]. Endpoint may be desktop, smart phone (android), laptop, tablet, CPE, etc., Till reading this draft, I assumed websocket as a socket layer for HTTP and it is bad assumption :-(. In short, browser is able to create two way communication with webserver (which has globally routable address). Two browser creating websocket with web servers will be able to communicate with each other. This architecture exactly fits in SIP world as =20 SIP UA <---->B2BUA<----->SIP UA And resultant as browser<---> webserver <----> browser. I tend to agree with you that Websocket looks as a better choice for this simple web architecture as there is no need of identity exchange here because webserver knows and authenticated both browsers with the corresponding identity. In fact, B2BUA with globally routable address will interop better with any endpoint for that matter. The difference comes into picture for federation (interop between servers). I'm not very clear whether websocket is intended for federation as well or not. Most of the discussion RTCWeb points to use SIP as a federation protocol which may change later. I'm interested knowing your view here. For this mail, I assume that SIP as a federation protocol of RTCWeb1.0 and I'm ready to change if it is the right thing to do :-) I'm asking for the single protocol based on my gateway implementation experience in signaling protocol like SIP, H.323, and basic of MEGACO, Q.931 (ISDN) etc., My understanding is that mapping of between tow protocols leads to get the common set in both protocol and under utilization of specific protocol functionality. The mapping is not perfect lot of times and one of the example which I know in IETF product is RFC 3398. It is not possible in RFC 3398 to proper reverse mapping of cause code for ISUP in case conversion in first gateway converts ISUP to SIP, second gateway converts is SIP to ISUP, ISUP cause code value in second gateway is not same what is received in first gateway and this leads to lot of interop issue which includes passing of reason SIP header with Q.931 IE recently as per IETF-80 decision (workaround bug fix). This is not the only mapping failure which I have seen during the gateway implementation. So, I prefer to look for the strong reason for putting multiple protocol (SIP, websocket) as a RTCWeb architecture.=20 Apart from this, my understanding is that websocket + REST XML is the best choice in web world but SIP + REST XML is an overkill. My understanding is based on SIPREC metadata XML design where I explored to make REST XML which is generic for SIP and other protocols, but I realized that REST XML is overkill for SIP as it has dialog context in both server & client. Please let me know your comments on this. Also, Endpoint shall be single IETF protocol for real-time communication rather than having two protocols (SIP, websocket) for any application. It looks inconsistent for Endpoint application to use SIP and Endpoint browser application to use websocket. IMO, IETF should give some clarity for better real-time network design here. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Peter Saint-Andre >Sent: Friday, September 09, 2011 1:22 AM >To: igor.faynberg@alcatel-lucent.com >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote >recording - RTC-Web client acting as SIPREC session recording client] > >On 9/8/11 1:22 PM, Igor Faynberg wrote: >>> On 09/08/11 16:54, Igor Faynberg wrote: >>> ... >> >>> If the issue is getting a signal from a Web server to a client, >>> there's approximately 100 ways to get notifications from the server >to >>> the client using HTTP (hanging GET being one of them). >> >> I thought that COMET-like polling is inefficient. Hanging GETs >> require server resources to hold a TCP session o open. Firewalls and >IE7 >> time out a GET after 30-60 seconds. >> >>> Now that WS is getting standardized, there will be 101. >>> >> >> 101st, seems to be a solution, I agree. But it has not finished >> standardization, > >draft-ietf-hybi-thewebsocketprotocol is close to approve as a Proposed >Standard (discussed on this morning's IESG telechat, still a few issues >to clean up). Not that PS means finalization. > >> while SIP has. > >SIP is not a full Standard. rfc3261bis, anyone? ;-) > >Peter > >-- >Peter Saint-Andre >https://stpeter.im/ > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Mon Sep 12 00:29: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 084F221F8560 for ; Mon, 12 Sep 2011 00:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.314 X-Spam-Level: X-Spam-Status: No, score=-6.314 tagged_above=-999 required=5 tests=[AWL=-0.015, 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 5w+vML1zHWlx for ; Mon, 12 Sep 2011 00:29: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 CBBEA21F84DB for ; Mon, 12 Sep 2011 00:29:50 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-c1-4e6db568010d Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 88.A7.20773.865BD6E4; Mon, 12 Sep 2011 09:31:52 +0200 (CEST) Received: from [150.132.141.36] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 12 Sep 2011 09:31:51 +0200 Message-ID: <4E6DB567.5040704@ericsson.com> Date: Mon, 12 Sep 2011 09:31:51 +0200 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Justin Uberti References: <4E69B77E.7090205@ericsson.com> <56C22F41-852F-4B20-A907-1181FE77E854@csperkins.org> <58801C7D-AAD4-4C27-A2C2-6378AF18DBFE@edvina.net> <4E6A1107.8090302@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Convey "label" X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 07:29:52 -0000 On 2011-09-09 18:14, Justin Uberti wrote: > > > On Fri, Sep 9, 2011 at 9:13 AM, Stefan Håkansson LK > > wrote: > > On 2011-09-09 14:58, Justin Uberti wrote: > > > > On Fri, Sep 9, 2011 at 3:55 AM, Olle E. Johansson > > >> wrote: > > > 9 sep 2011 kl. 09:07 skrev Colin Perkins: > > > On 9 Sep 2011, at 07:53, Olle E. Johansson wrote: > >> 9 sep 2011 kl. 08:51 skrev Stefan Håkansson LK: > >>> there was a discussion yesterday of how to convey the Id (aka > "label") of a MediaStream object when it is sent over a > PeerConnection. Presumable this info would be in the SDP > offer (or > whatever we end up using). There was a discussion on if > CNAME could > be used or if we need something new. > >>> > >>> You mentioned that it would be quite easy to add a new element > or attribute if we would need that. Could you explain a bit > more? > >> > >> Just a kind reminder that there are application specific fields > that we can use in RTCP too... > > > > > > I was actually thinking of a new RTCP SDES item type to convey > the label. > > > Side note: I know we're not talking SIP, but it actually touches > Hadriel's Session ID proposal too... > > > It's not clear to me that we need a MediaStream to have a label, > or any > identifier other than CNAME, unless it's meant to be some sort of > "display name" for that particular stream. If there are other > expected > usages of the label, I'd be interested to know what they are. > > The main purpose of an identifier of MediaStream's I see is to be > able to reference them after transport over a PeerConnection. If > several MediaStreams are sent over a PC, you need to be able to > reference them - all the receiving app gets is "addstream" events. > > Of course you could add them one by one in a determined order, but > that would mean that set up takes longer than required. > > I'm not sure CNAME can fulfill this purpose in all cases or not. > > > Right, I agree the app needs to be able to say "this video feed is for > user A" and "this video feed is for user B", if for no other reason than > to be able to display a user identifier underneath the appropriate video > feed. However as mentioned previously I think that this implies that > each feed (i.e. track) requires an identifier, not necessarily the > stream. So I propose we add a unique label attribute for tracks, which > is essentially a handle; this handle allows clear identification of a > track, and can be passed around in application messaging if needed. We > may also want to allow a non-unique display name to be provided as well. This is an interesting idea. However, in the html5 spec media elements deal with 'media resources' which can have multiple tracks of audio and video. To be able to reuse what is already in place (e.g. audio and video elements) I think we should conform to this. Besides, if you can identify the MediaStream, it is quite straightforward to reference a specific track in it as it is the same tracks on both sides of the PeerConnection. > > I see no harm in having MediaStream's label be the CNAME, as a portable > handle for MediaStreams, but I haven't yet heard a use case where one > would use this handle instead of the track handle. > > > > _________________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/__listinfo/rtcweb > > > From matthew.kaufman@skype.net Mon Sep 12 00:40: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 F20C621F8672 for ; Mon, 12 Sep 2011 00:40:46 -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 xxrQxo9sbBKY for ; Mon, 12 Sep 2011 00:40:45 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE2821F8663 for ; Mon, 12 Sep 2011 00:40:45 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id A2EEA16E2; Mon, 12 Sep 2011 09:42:46 +0200 (CEST) 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=3af6QI2JSfds/0 cm/JoLJ2J6wUI=; b=LG1NmPosf+ByeFhA1tYjVkD7zudWK/CklPyuVMZnw8gTa7 zAxPo3TFiCGficJCKTTj0QDsTLbFSjSCi817oSwBb2QMrrpTNTd/s/H0hExcb9if v7toFLpyuTdcIMsSa6BKXmwouAgNshx5TbwtiTvLzVV9w22cpW0xtoY7Vfifo= 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=C2jnAlfg105B+R1F1Y6C0F XznDvUa3A0RQBazkJL8H4Cu4FdftGkxV5KqgAYaNdJC8eNDPsh6h9bcM6SvULzh4 AjE2TKC0b9CzPs/oaO72hqGNTMQEusNlMmc0XI5EwOcmq9Yo22LHlI6SvxwD8C/g M9jPIeIAh0d8iAVl/6gZc= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id A14997F8; Mon, 12 Sep 2011 09:42:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 87D0835070B5; Mon, 12 Sep 2011 09:42:46 +0200 (CEST) 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 1hA+pZzH76Yz; Mon, 12 Sep 2011 09:42:45 +0200 (CEST) Received: from Matthew-Kaufman-Air.local (c-217-115-41-36.cust.bredband2.com [217.115.41.36]) by zimbra.skype.net (Postfix) with ESMTPSA id 973AD350704F; Mon, 12 Sep 2011 09:42:45 +0200 (CEST) Message-ID: <4E6DB7F4.3090404@skype.net> Date: Mon, 12 Sep 2011 09:42:44 +0200 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Timothy B. Terriberry" References: <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org>, <4E6AE22A.2070106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se>, <4E6C16FF.1000706@jesup.org> <4E6CB9F7.2060208@mozilla.com> In-Reply-To: <4E6CB9F7.2060208@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 07:40:47 -0000 On 9/11/11 3:39 PM, Timothy B. Terriberry wrote: >> * The level of media protection to use (NONE, SDES-SRTP or DTLS-SRTP) >> should be set by the web app > > Why wouldn't this devolve to, "Don't communicate anything. Instead, > try to create a PeerConnection with DTLS-SRTP, and when that fails, > try to create a second one with NONE," in the actual webapp. Yes. > > Or, more likely, since NONE will have a better chance of working with > legacy devices, "Try to create a PeerConnection with NONE, and when > that fails, try to create a second one with DTLS-SRTP." Assuming > anyone bothers with the second step. Yes, I believe this is why ekr suggested in his email that DTLS-SRTP-only is more likely to result in encrypted connections than having both choices available is. > Having the choice of SDES-SRTP or DTLS-SRTP will also make it more > likely people won't bother with either, as they won't know which one > to use. Agree. This is the best reason for not supporting SDES for keying. > We can try to create incentives with browser chrome, but there's only > so much that can do. Agree. The best way to evaluate this is "if I was the one sitting in a cafe using this, what would I want my browser to do"... and the answer to *that* question is "I always want DTLS-SRTP between my browser and the other end, or worst case, the gateway". (Even if there seem to be good reasons to support plain RTP.) Matthew Kaufman From matthew.kaufman@skype.net Mon Sep 12 01:31: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 0F76521F86EC for ; Mon, 12 Sep 2011 01:31:00 -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 nU4fpJ+Of2IR for ; Mon, 12 Sep 2011 01:30:59 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9C921F86DD for ; Mon, 12 Sep 2011 01:30:58 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 19EA8170E; Mon, 12 Sep 2011 10:33:01 +0200 (CEST) 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=D5DIzja7SzSlkL CBgc1+BiIuKFY=; b=sYUOceBP6uCUF5sBY9/oKsp0TqwK1mtmiiM3z0ScH4YWfB +kMimkdQiFwgd6XNlPS2O+GDyN0wqsYcjLXwOQEJVSDbd32z7zqKcLQ01+oIJiN4 ctOucb5a1+8NbSpDFPcQlv9jQhNFWTsOtOowEv/EjcIf4EMYUFEl7JZrNw2bU= 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=E8aV6na3grE2rrVxYGXvkU KRutuyH9uepbQuA9zxiTMl+s6ijl3y4H8JYf5cPRA2uF1gbfwGL9fZ5pBhU1Ob0r lJ8EJnCSjKaE/6ptC8MMDRaswdv31zBK78hTWoK4gKBjhv383MSn3W3+LFcytIo1 WxJTWBGqilf/fI0YwA0YM= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 183947F6; Mon, 12 Sep 2011 10:33:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id E77963507368; Mon, 12 Sep 2011 10:33:00 +0200 (CEST) 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 zr0v-Tny9+iY; Mon, 12 Sep 2011 10:33:00 +0200 (CEST) Received: from Matthew-Kaufman-Air.local (c-217-115-41-36.cust.bredband2.com [217.115.41.36]) by zimbra.skype.net (Postfix) with ESMTPSA id BBC79350758D; Mon, 12 Sep 2011 10:32:59 +0200 (CEST) Message-ID: <4E6DC3BA.4090706@skype.net> Date: Mon, 12 Sep 2011 10:32:58 +0200 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Roman Shpount References: <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <1541FDA8-C3F6-4D24-BEC4-60EDACB6B582@edvina.net> <903DEDB7-CA26-4354-90B2-BE97B78B0A34@skype.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randell Jesup , Jonathan Lennox , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 08:31:00 -0000 On 9/12/11 4:45 AM, Roman Shpount wrote: > Not sure if you want to configure TURN servers per organization. It is > not guaranteed that the TURN server will be used for the call. > Additionally you do want TURN server on the public internet, out side > of the corporate network. I think what you are trying to accomplish > should be implemented via proxy. SOCKS5 proxy can be used for media > and can be used to enforce corporate policies. True, but there's no reason why a TURN server couldn't also be used, assuming that there is a way to specify a server (and the long-term credentials to be used) SOCKS is particularly bad for UDP, and even SOCKS5 doesn't improve much upon that... this does bring up the question of whether or not the use cases should be updated to ensure that a client being a SOCKS proxy can use RTCWEB. Matthew Kaufman From matthew.kaufman@skype.net Mon Sep 12 01:32: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 9D40621F86A6 for ; Mon, 12 Sep 2011 01:32:23 -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 GTsvBFvJHkyP for ; Mon, 12 Sep 2011 01:32:23 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 16FF921F8567 for ; Mon, 12 Sep 2011 01:32:23 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 8650E170F; Mon, 12 Sep 2011 10:34:25 +0200 (CEST) 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=RUNdFdR6Y6pN4s b8ftq45aWUjN4=; b=FFDY3DTpsTOWz8FZgWHoR1omEw1AG1yZ/sac2TwU70ofP+ NIZ9T4s1aw9Wtm/QvFEHLMAqU3Oig7WlAqG7dFUNXjO4RMdMsIQyhJRNS4BhGMk6 xzIGcb48AKzrMfmfOr7s3aXVQt4373J8qP8W9KNWtXbnLZkW3lpvcRw+9Qd+s= 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=vi/vtkWx+A8fywASHx/8ZV MiK+XI9UuTFtv/+ZVm0GeKndjtHVqiMmMXB1se8BbWi8ci+19rORFpl/CkDyK2V8 x+qQmZ99sRs/rjc3Ok8Z3ojZ92EHfxWTURKPNmZu9Qsr2YaG91wFvtCF6f1/df34 frCrFaeX1nSVl33ed8lWk= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 841FC7F6; Mon, 12 Sep 2011 10:34:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 43DA01672683; Mon, 12 Sep 2011 10:34:25 +0200 (CEST) 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 XHsXHc+dFs4w; Mon, 12 Sep 2011 10:34:24 +0200 (CEST) Received: from Matthew-Kaufman-Air.local (c-217-115-41-36.cust.bredband2.com [217.115.41.36]) by zimbra.skype.net (Postfix) with ESMTPSA id 39E5D1672681; Mon, 12 Sep 2011 10:34:24 +0200 (CEST) Message-ID: <4E6DC40F.3080504@skype.net> Date: Mon, 12 Sep 2011 10:34:23 +0200 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <2E239D6FCD033C4BAF15F386A979BF510F09ED@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F09ED@sonusinmail02.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 08:32:23 -0000 On 9/11/11 10:29 PM, Ravindran Parthasarathi wrote: > John, > > Please let me know whether the updated text works for you: > > New requirements: > Fyy1: The browser MUST be able to send in real-time to an another > browser/session recording server(SRS) that are being transmitted to and > received from remote browser. > > Ayy1: The web application MUST be able to ask the browser to transmit in > real-time to another browser/session recording server(SRS) that are > being transmitted to and received from remote browser. I still maintain that adding these requirements opens a huge can of security and resource utilization worms. I really think these need to be addressed early before we make this one of the mandatory-to-support cases. Matthew Kaufman From oej@edvina.net Mon Sep 12 01:37: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 39FF921F85F1 for ; Mon, 12 Sep 2011 01:37:41 -0700 (PDT) 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.088, 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 OyV7SxzkrnGt for ; Mon, 12 Sep 2011 01:37:40 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id A06B821F84D6 for ; Mon, 12 Sep 2011 01:37:40 -0700 (PDT) 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 36D4D754BCE4; Mon, 12 Sep 2011 08:39:40 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <4E6DC40F.3080504@skype.net> Date: Mon, 12 Sep 2011 10:39:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E239D6FCD033C4BAF15F386A979BF510F09ED@sonusinmail02.sonusnet.com> <4E6DC40F.3080504@skype.net> To: Matthew Kaufman X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 08:37:41 -0000 12 sep 2011 kl. 10:34 skrev Matthew Kaufman: > On 9/11/11 10:29 PM, Ravindran Parthasarathi wrote: >> John, >>=20 >> Please let me know whether the updated text works for you: >>=20 >> New requirements: >> Fyy1: The browser MUST be able to send in real-time to an another >> browser/session recording server(SRS) that are being transmitted to = and >> received from remote browser. >>=20 >> Ayy1: The web application MUST be able to ask the browser to transmit = in >> real-time to another browser/session recording server(SRS) that are >> being transmitted to and received from remote browser. >=20 > I still maintain that adding these requirements opens a huge can of = security and resource utilization worms. >=20 > I really think these need to be addressed early before we make this = one of the mandatory-to-support cases. Agree. It will be really hard to include this in the rtcweb architecture = as a mandatory-to-support case.=20 In the cases where "someone else", i.e. not the browser user, wants to = control recording, I assume there will always be a media handling server = or gateway where recording can happen anyway. Allowing a third-party to = initiate duplication of media streams in the browser has huge security = impacts. /O= From HKaplan@acmepacket.com Mon Sep 12 04:54: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 1B96B21F8B1D for ; Mon, 12 Sep 2011 04:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, J_CHICKENPOX_18=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 Jy-hfMbXqp4l for ; Mon, 12 Sep 2011 04:54:15 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 84A4321F84D7 for ; Mon, 12 Sep 2011 04:54:10 -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; Mon, 12 Sep 2011 07:56:00 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 12 Sep 2011 07:56:00 -0400 From: Hadriel Kaplan To: Cullen Jennings Thread-Topic: [rtcweb] Use of offer / answer semantics Thread-Index: AQHMcULwBBWdt3opOU64g1pg5dZ3tQ== Date: Mon, 12 Sep 2011 11:56:00 +0000 Message-ID: <2E693A54-A8E7-46D8-94C6-7028F5497436@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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 11:54:16 -0000 (sorry about the length of the email) Well, you asked for rough consensus, so I'll give my 2 cents:=20 I think building-in/requiring full SDP and in particular the offer/answer m= odel is a big mistake. As I said at the mic at IETF-81, by doing this you = are restricting/limiting the application of Rtcweb. You are imposing a par= ticular model of usage into the Javascript API, which is contrary to the ve= ry notion of having a Javascript API to begin with. =20 Note here I am talking about full SDP and offer/answer, not the tokens assi= gned for media info that we happen to encode in SDP, and which only compris= e a portion of SDP - we'll need standardized tokens or enum values for thos= e in the API itself, so those are fine as IANA-registered strings. In particular, here're my arguments: 1) It should be recognized that for anything but the simplest case of SIP-b= ased calling from the rtcweb server to SIP peers, the domain/scope of this = SDP offer/answer will only be between the browser and its server. In other= words, the SDP state, sess-version number, media lines, etc., will only be= meaningful between the browser and server, and a new set of those will exi= st between the server and any peer(s) it talks to using SIP. Because if an= ything more complicated happens in SIP, such as forked calls, then either t= he browser SDP code has to understand such scenarios as well, or else the s= erver will handle it itself - and I don't think you really want to complica= te the browser to handle all possible SDP offer/answer cases. Furthermore,= while we assume the server will speak SIP to peers, it may well speak XMPP= , H.323, IAX, or whatever. And thus again this SDP exchange will only be h= appening (from an SDP layer perspective) between the browser and server. I= only point this out because people may think they're getting something for= free here, and minimizing the complexity of the javascript or server - tha= t's not the case. 2) One of the advantages of an rtcweb model is the clients (ie, browsers) d= on't need to be upgraded for new functionality - only the javascript does, = unless something needs changing in the API itself. But if the browser is g= enerating the full SDP and handling offer/answer, as your proposal has it, = then whenever we need to change SDP handling we need to upgrade the browser= s. For example, there's this lovely sdp-cap-neg mechanism. If we don't sp= ecify the browser has to handle receiving sdp-cap-neg offers on day-1, then= the extra attribute lines will be ignored and the SDP answer won't do it. = But it's possible for the javascript script to be upgraded to handle sdp-c= ap-neg offers itself and choose alternates from within it without upgrading= the browser... except now we won't because the browser's doing SDP, and th= e browser needs to be updated. Or I suppose the javascript could munge the= SDP it gives to the browser, and munge back what it gets back from the bro= wser - but that just shows how silly it is to have SDP be used in the brows= er to begin with. 3) The converse problem of #2: browsers upgrading with new SDP functionalit= y that the javascript doesn't know about but needs to. For example, suppos= e you've built a rtcweb app for trading floor communications. I won't go i= nto the details of how trading floor calls work, but one of their requireme= nts is no time lag when they press a specific line on their phone, and they= are instantly talking (no ringing/handset pickup). So what your javascrip= t does is actually create a voice channel to every line at the beginning, a= nd just puts them all on "hold" until the user presses a specific line. To= avoid the delay of signaling when the user presses to talk, your javascrip= t never tells the other side about the media being put on/off hold - it's a= lways active bidirectional RTP media as far as that's concerned, and you do= n't pass the SDP back/forth unless something really changes like addressing= info. Internet Explorer v24 doesn't seem to have a problem with this, bec= ause it happens not to know/support/care-about the SDP direction attributes= either. So you deploy this thing and all seems well. Unbeknownst to you,= Internet Explorer v25 makes a small change to its SDP engine, adding suppo= rt for the direction attribute such that whenever its media is on hold it s= ets the SDP to a=3Dinactive, and if it receives a=3Dinactive it doesn't sen= d RTP. Your Rtcweb app will now break, as the call starts out with the med= ia being a=3Dinactive and no SDP gets exchanged to update it back to a=3Dse= ndrecv. 4) You may feel like SDP belongs in the browser because it's about "media s= tuff", but that's misleading - its descriptions relate to media sessions, b= ut it includes information from the application layer as well, rather than = purely from a media library. The *browser* only knows a portion of the det= ails. For example, the following IANA-registered SDP attributes would be u= nknown to a media library in the browser and only known to the javascript: = cat, keywds, tool, type, charset, lang, setup, connection, confid, userid, = floorid, and probably a bunch more that I can't be bothered to look up. An= d here's a use-case example: suppose I create an Rtcweb app which can make = media-loopback calls for testing stuff. It can't answer such calls, since = the browser media library doesn't support loopback, but it can *generate* t= he calls since the generator side can simply let the user speak into the mi= c and hear himself/herself on the speakers to verify the media works to the= loopback end. (see http://tools.ietf.org/html/draft-ietf-mmusic-media-loop= back-15) All the *browser* needs to do is support normal audio RTP, wherea= s the javascript or server needs to generate an SDP offer with the loopback= attribute, if it uses SIP. It won't work if the browser is the one creati= ng SDP and handling the offer/answer. =20 5) Architecturally, I don't understand why the *browser* needs to know abou= t sessions. I'm not talking about individual "media sessions", but rather = the SIP concept of "sessions". SDP offer/answer requires this knowledge - = it needs to know when a session begins, ends, and its context/state. Minim= ally it needs to know this to group media info together (ie, to know that t= he audio and video are tied to the same session), and to handle the origin = line sess-version number, and session-level attributes. Why should the _br= owser_ need to know that? What should it care whether the audio and video = being used by a javascript are tied to one call vs. two separate calls?? W= hy should it even know there is such a thing as a "call"? It's a media lib= rary. Keep it simple stupid. 6) You ask below in your email what the alternative to using SDP offer/answ= er would be between the browser and server. The answer to it seems obvious= to me: NOTHING. There is no need for a standardized protocol to convey me= dia info between the browser and server. The only need is for a standard t= o convey the media/ICE/SRTP capabilities and command/setting primitives in = an API between javascript and the browser. That's it. The javascript deve= loper can convey that information however he/she feels it appropriate to th= e server, in HTTP, if it even needs conveying to the server. That's kinda = the whole POINT of using javascript! Let the developer develop. If they w= ant to use an SDP offer/answer model, they can code javascript to do so. I= f they want to send a binary blob instead, even to a separate server, they = can. The HTTP interface is their job, not ours. -hadriel On Sep 6, 2011, at 10:46 AM, Cullen Jennings wrote: >=20 > In my roll as an individual contributor, I want to propose some text that= I think we can get rough consensus on around that helps specify which part= s of the signaling issues we agree on and which we don't.=20 >=20 > At the last meeting, my read of the the room was there was a fair amount = of agreement in the room that offer / answer semantics with SDP are what w= e want to use. I don't think there was was broad agreement on if one should= use SIP or not, or for that matter jingle. If we can nail down this decisi= ons as the direction the WG is going, it will really help make progress. Wh= at I would like to do is propose some following principles in the text belo= w. If we have agreement on these, then they would go into the overview docu= ment and help guide the design of other documents. I want to highlight that= none of the principles below imply that we would need to use SIP in the br= owsers - the principals would all work fine if we there was signaling gatew= ay in the web server that converged SIP to whatever proprietary HTML / JS = / HTTP that the applications wanted to use between the browser and the web = server.=20 >=20 >=20 >=20 > 1) The media negotiations will be done using the same SDP offer/answer se= mantics that are used in SIP.=20 >=20 > 2) It will be possible to gateway between legacy SIP devices that support= ICE and appropriate RTP / SDP mechanisms and codecs without using a media = gateway. A signaling gateway to convert between the signaling on the web si= de to the SIP signaling may be needed.=20 >=20 > 3) When a new codec is specified, and the SPD for the new codec is specif= ied in the MMUSIC WG, no other standardization would should be required for= it to be possible to use that in the web browsers. Adding a new codecs whi= ch might have new SDP parameters should not change the APIs between the bro= wser and javascript application. As soon as the browsers support the new co= dec, old applications written before the codecs was specified should automa= tically be able to use the new codec where appropriate with no changes to t= he JS applications.=20 >=20 >=20 > People has looked at alternatives to all these in a fair amount of detai= l. For example, we have considered alternatives to the SDP offer / answer s= uch as the advertisement proposal draft (draft-peterson-sipcore-advprop-01)= and discussed that several times in the WG. The primary issues identified = with this was concerns over mapping this to legacy SDP. Similarly people ha= ve considered a replacement for SDP in the SDPng work which was eventually = abandoned due to the difficulty of having a incentive for implementations t= o migrate from SDP to SDPng.=20 >=20 > We have also considered just sending audio and video directly over someth= ing like DTLS and not suing RTP. The WG has clearly rejected this due to a = variety of reasons - the desire not to to have the operating expense of med= ia gateway and reduction in quality of experience is obviously a high prior= ity goal for the designs of the RTP multiplexing draft.=20 >=20 > The JS API is being developed by W3C but when proposing APIs that should = violate the third principal, such as the the API in section 4 of draft-jenn= ings-rtcweb-api-00, it is clear that many people that are more from the bro= wser and web application world do not want such an API.=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From oej@edvina.net Mon Sep 12 05: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 A91E521F8496 for ; Mon, 12 Sep 2011 05:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 Jscbj2BAuxXa for ; Mon, 12 Sep 2011 05:13:19 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 2556521F8841 for ; Mon, 12 Sep 2011 05:13:19 -0700 (PDT) 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 01EB3754BCE4; Mon, 12 Sep 2011 12:15:19 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <2E693A54-A8E7-46D8-94C6-7028F5497436@acmepacket.com> Date: Mon, 12 Sep 2011 14:15:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <97018FB6-442E-4B11-B448-E8DBDA71FCF5@edvina.net> References: <2E693A54-A8E7-46D8-94C6-7028F5497436@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1244.3) Cc: "" Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 12:13:19 -0000 12 sep 2011 kl. 13:56 skrev Cullen Jennings: >> 2) It will be possible to gateway between legacy SIP devices that = support ICE and appropriate RTP / SDP mechanisms and codecs without = using a media gateway. A signaling gateway to convert between the = signaling on the web side to the SIP signaling may be needed.=20 A media gateway (like turn) is also needed when RTP endpoints are using = different address families (ipv4 / IPv6). /O From keith.drage@alcatel-lucent.com Mon Sep 12 06: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 5A64F21F8B54 for ; Mon, 12 Sep 2011 06:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.844 X-Spam-Level: X-Spam-Status: No, score=-105.844 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGBpjD2BnF2m for ; Mon, 12 Sep 2011 06:43:17 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 33CDE21F8B46 for ; Mon, 12 Sep 2011 06:43:16 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8CDj8tG000804 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Sep 2011 15:45:10 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 12 Sep 2011 15:45:10 +0200 From: "DRAGE, Keith (Keith)" To: Bernard Aboba , "oej@edvina.net" , "rtcweb@ietf.org" Date: Mon, 12 Sep 2011 15:42:20 +0200 Thread-Topic: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] Thread-Index: AcxwDeHQiNtgQB6CQ/CJCYRrZ5tJHQBQ7tew Message-ID: References: , <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com>, <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com>, <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net>, <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com>, <4E67C3F7.7020304@jesup.org>, <4E67F003.6000108@jesup.org>, <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se>, , , , <4E6A56D4.2030602@skype.net>, , , <4E6A81EC.3080002@jesup.org>, <78CC1B42-392D-4311-9417-33CC702A2FD1@edvina.net> 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_EDC0A1AE77C57744B664A310A0B23AE220BA41FBFRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 13:43:18 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE220BA41FBFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe in Japan privacy concerns of the caller outweigh the desire to re= ceive all information at the call taker. Regards Keith ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Bernard Aboba Sent: 11 September 2011 00:04 To: oej@edvina.net; rtcweb@ietf.org Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] [BA] Can you provide a citation for the assertion that confidentiality coul= d be *required* for an emergency services call? I am not aware of any such a regulatory requirement in the US. ________________________________ From: oej@edvina.net Date: Sat, 10 Sep 2011 09:17:16 +0200 To: rtcweb@ietf.org Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] 9 sep 2011 kl. 23:15 skrev Randell Jesup: 3) May simplify/improve some E911 cases. Might be important; likely not. 911/112 cases might be typical phone calls that *require* confidentiality. = In Sweden 112 is used for a lot more than accidents - call the priest, repo= rt child abuse and others that really are calls that in now way should be l= istened-in to by other users on the LAN or the IP network. /O _______________________________________________ rtcweb mailing list rtcweb@= ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_EDC0A1AE77C57744B664A310A0B23AE220BA41FBFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I believe in Japan privacy concerns of the= caller outweigh the desire to receive all information at the call taker.

 

Regards

 

Keith

 

From:= rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 11 September 2011 00:0= 4
To: oej@edvina.net; rtcweb@ietf.org
Subject: Re: [rtcweb] AVPF [= was: Encryption mandate (and offer/answer)]

 

[BA] Can you provide a citati= on for the assertion that confidentiality could be *required* for an emergency services call?

I am not aware of any such a regulatory requirement in the US.

From: oej@edvina.net
Date: Sat, 10 Sep 2011 09:17:16 +0200
To: rtcweb@ietf.org
Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)]

9 sep 2011 kl. 23:15 skrev Randell Jesup:

 

3) Ma= y simplify/improve some E911 cases.  Might be important; likely not.

 

911/112 cases might be typical phone calls that *requir= e* confidentiality. In = Sweden 112 is used for a lot more than accidents - call the priest, report child a= buse and others that really are calls that in now way should be listened-in to b= y other users on the LAN or the IP network.

 

/O


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

--_000_EDC0A1AE77C57744B664A310A0B23AE220BA41FBFRMRSSXCHMBSC3d_-- From mperumal@cisco.com Mon Sep 12 08:20: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 5D64521F854E for ; Mon, 12 Sep 2011 08:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.398 X-Spam-Level: X-Spam-Status: No, score=-10.398 tagged_above=-999 required=5 tests=[AWL=0.200, 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 G5-Vy-4oyyGg for ; Mon, 12 Sep 2011 08:20:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id AD9EB21F853E for ; Mon, 12 Sep 2011 08:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=50303; q=dns/txt; s=iport; t=1315840967; x=1317050567; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=FzfG9cjidq1yhKxUixvqPlBNwPPUihtCd/BlGdfQdnI=; b=THtZ2rzX3O4GF9T1y+87gnbM71IKdt6KH/KWoElj9jtmDXSPXF31Ey7e UJcEC659WRfZvhVPqceXZrN1c0bR+cAez7MOmoOeMDyjRZEQWcaGcJ4Ed gjd5f82YPnTSksmn7HBbFymPcANfnyFUp6mTRzlQAL0DN2jR3dnLYfjLI A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgAAD4jbk5Io8US/2dsb2JhbAA4CYJNliaPE3iBUgEBAQEDEgEJEQNJEAIBCA4DAQMBAQsGEAECBAEGASUgAwYIAQEEAQoHAQgTB6AiAZ1Zg0iCRmAEh2uQcIwG X-IronPort-AV: E=Sophos;i="4.68,368,1312156800"; d="scan'208,217";a="115045298" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 12 Sep 2011 15:22:27 +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 p8CFMQdf019599; Mon, 12 Sep 2011 15:22:26 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); Mon, 12 Sep 2011 20:52:26 +0530 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC715F.C6B929F7" Date: Mon, 12 Sep 2011 20:52:17 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202065582FF@XMB-BGL-414.cisco.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0989@sonusinmail02.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording client] Thread-Index: Acxt9AbN3JhWXoAGQEWrQ9SN744t+wARGUtgAMkSJbA= References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net><4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net><2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com><4E67AD3D.9000005@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com><4E686663.1050900@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F0989@sonusinmail02.sonusnet.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Ravindran Parthasarathi" , "Harald Alvestrand" X-OriginalArrivalTime: 12 Sep 2011 15:22:26.0413 (UTC) FILETIME=[C729A9D0:01CC715F] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 15:20:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC715F.C6B929F7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Asking for the browser to support SIP is like asking for the OS kernel to support 100s of SIP specs to cater to various kinds of applications, instead of implementing what portion of SIP you care about in the application itself -- it just doesn't look scalable. Even if you want to experiment with a new SIP header you would have to wait for the browser vendor to release the new version of the browser or make changes to the browser code yourself, severely hampering application development. =20 Muthu =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ravindran Parthasarathi Sent: Thursday, September 08, 2011 8:44 PM To: Harald Alvestrand Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording client] =20 Harald, =20 I'm proposing for "SIP UA framework for RTCWeb browser", the framework provides Javascript API. In case you mean the same as "SIP lite". I'm fine with it. SIP UA framework helps to support two-party communication from RTCWeb browser and uses HTTP as presence or configuration interface.=20 =20 As I mentioned in the another mail, I'm talking about INVITE subset of RFC 3261 in browser. =20 =20 Thanks Partha =20 From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Thursday, September 08, 2011 12:23 PM To: Ravindran Parthasarathi Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] =20 On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote:=20 Harald, =20 For browser as a SIP UA application, browser has to no need to compliant with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also agree with you that browser-to-browser communication, I could not see the strong reason for supporting S/MIME. As part of the RTCWeb architecture & solution, we will able to explore the SIP UA requirement for making browser SIP compliant. So you're advocating for creating a "SIP lite" subset that RTCWEB browsers implement. I think we have been down this road before, and it's not a happy one. But sure - if you want us to implement some part of SIP, *please start stating what part* rather than making wooly statements. Subsets are Real Hard Work. Say for example, forking does not make sense in case of browser as SIP UA application, forked response will be rejected with CANCEL in browser without Javascript intervention. The main requirement is to build the right SIP UA framework in browser by which Javascript developer will be able to use to the maximum extent without impacting the basic 2 two party communication in the internet. =20 =20 As mailed in another thread, RTCWEB client + RTCWeb server makes to feel a modern exchange in web world (Plain Old Telephony System phone with exchange architecture). I think so because POTS phones are dumb which does not know its identity and every event like offhook, onhook has to passed to exchange (webserver) whereas RTCWeb client (browser) has to pass every event to webserver and webserver has whole intelligence to make it work. Don't forget that the RTCWEB client (the browser) contains an open, fully programmable application platform - the Javascript engine. That's a HUGE difference to the POTS phone. I got this feel more when someone is talking about MEGACO or MGCP between RTCWEB client & webserver. My understanding is that SIP does not fit well to legacy telephone-based paradigm by any means but MEGACO or MGCP are the better choice which maps to SS7 architecture well. I'm interested in seeing RTCWeb client perform the basic routing rather than webserver does the routing on behalf of RTCWEb client. =20 I agree with you that in case it is local exchange (same site like skype or Google hangout) communication, there will be no need of signaling but I'm interested in communication with one of the Google real-time user in internet without having any Google id. I believe that SIP will make it work. If by saying "the Google real time user in Internet", you mean a Google Talk user, you have that already. It's called Google Voice. It uses SIP, but not in the browser. Talking to someone who doesn't want to talk to you is an use case we don't intend to support. =20 Thanks Partha =20 From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Wednesday, September 07, 2011 11:13 PM To: Ravindran Parthasarathi Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] =20 On 09/07/11 19:29, Ravindran Parthasarathi wrote:=20 Matthew, =20 When I asked for SIP, I have meant RFC 3261 only. This is 269 pages, and has 26 normative dependencies including S/MIME. It's not a small dependency. The basic reason for asking SIP is to make the basic call works between browser to browser across web servers. Without SIP in browser, it is not going happen. Innovative application is going to be proprietary whether it is HTTP or SIP or any other protocol for that matter. =20 My reasoning are as follows: SIP makes browser more intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG.=20 Why does that "intelligence" need to be in the browser, rather than in the Javascript? The importance of basic call interop is that there is no need of many individual id like skype id, Google id and yahoo id by everyone in the world to communicate others. I wish to have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.=20 This only makes sense for applications that fit the "call an identified party" paradigm. SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provider. There is no need to build two different signaling logic in VoIP servers for each service. Your own example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible to avoided by having one signaling protocol. One protocol can be achieved by multiple applications choosing to implement one protocol. It doesn't have to be enforced by the prtoocol being embedded in the browser. =20 In RTCWEB does not standardize the signaling protocol interface between browsers, the interop across webservers is next to impossible and it will be restricted to single webserver (company) only. Please let me know in case I'm missing something here. I think the main thing you are missing is that there are many applications that people want to build on top of RTCWEB that are not telephones, and will not fit with telephone-based paradigms. =20 ------_=_NextPart_001_01CC715F.C6B929F7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Asking for the browser to support SIP is like asking for the OS kernel to = support 100s of SIP specs to cater to various kinds of = applications, instead of implementing what portion of SIP you care about in the = application itself -- it just doesn't look scalable. Even if you want to experiment with a = new SIP header you would have to wait for the browser vendor to release the new = version of the browser or make changes to the browser code yourself, severely = hampering application development.

 

Muthu

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ravindran = Parthasarathi
Sent: Thursday, September 08, 2011 8:44 PM
To: Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was = RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording = client]

 

Harald,

 

I’m proposing for “SIP UA framework for = RTCWeb browser”, the framework provides Javascript API. In case you mean = the same as “SIP lite”. I’m fine with it. SIP UA framework = helps to support two-party communication from RTCWeb browser and uses HTTP as presence or configuration interface.

 

As I mentioned in the another mail, I’m talking = about INVITE subset of RFC 3261 in browser.  

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Thursday, September 08, 2011 12:23 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; = rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remote recording - RTC-Web client acting as SIPREC session recording = client]

 

On 09/08/2011 07:09 AM, Ravindran Parthasarathi = wrote:

Harald,

 

For browser as a SIP UA application, browser has to no need to compliant = with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also agree with = you that browser-to-browser communication, I could not see the strong reason for supporting S/MIME. As part of the RTCWeb architecture & solution, we = will able to explore the SIP UA requirement for making browser SIP = compliant.

So you're advocating = for creating a "SIP lite" subset that RTCWEB browsers = implement.
I think we have been down this road before, and it's not a happy = one.
But sure - if you want us to implement some part of SIP, *please start = stating what part* rather than making wooly statements.

Subsets are Real Hard Work.

Say for example, forking does not make sense in case of browser as SIP UA application, forked response will be rejected with CANCEL in browser = without Javascript intervention. The main requirement is to build the right SIP = UA framework in browser by which Javascript developer will be able to use = to the maximum extent without impacting the basic 2 two party communication in = the internet. 

 

As mailed in another thread, RTCWEB client + RTCWeb server makes to feel a = modern exchange in web world (Plain Old Telephony System phone with exchange = architecture). I think so because POTS phones are dumb which does not know its identity = and every event like offhook, onhook has to passed to exchange (webserver) = whereas RTCWeb client (browser) has to pass every event to webserver and = webserver has whole intelligence to make it work.

Don't forget that = the RTCWEB client (the browser) contains an open, fully programmable application = platform - the Javascript engine. That's a HUGE difference to the POTS = phone.

I got this feel more when someone is talking about MEGACO or MGCP between = RTCWEB client & webserver. My understanding is that SIP does not fit well = to legacy telephone-based paradigm by any means but MEGACO or MGCP are the = better choice which maps to SS7 architecture well. I’m interested in = seeing RTCWeb client perform the basic routing rather than webserver does the routing = on behalf of RTCWEb client.

 

I agree with you that in case it is local exchange (same site like skype = or Google hangout) communication, there will be no need of signaling but = I’m interested in communication with one of the Google real-time user in = internet without having any Google id.  I believe that SIP will make it = work.

If by saying = "the Google real time user in Internet", you mean a Google Talk user, you have = that already. It's called Google Voice. It uses SIP, but not in the = browser.

Talking to someone who doesn't want to talk to you is an use case we = don't intend to support.

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:harald@alvestrand.no] =
Sent: Wednesday, September 07, 2011 11:13 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lu= cent.com; rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remote recording - RTC-Web client acting as SIPREC session recording = client]

 

On 09/07/11 19:29, Ravindran Parthasarathi wrote: =

Matthew,

 

When I asked for SIP, I have meant RFC 3261 only.

This is 269 pages, and has 26 normative = dependencies including S/MIME. It's not a small dependency.



The basic reason for asking SIP is to make the basic call works between = browser to browser across web servers. Without SIP in browser, it is not going = happen. Innovative application is going to be proprietary whether it is HTTP or = SIP or any other protocol for that matter.

 

My reasoning are as follows:

SIP makes browser more = intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG. =

Why does that "intelligence" need to be in the browser, rather than in the Javascript?

The importance of basic call = interop is that there is no need of many individual id like skype id, Google = id  and yahoo id by everyone in the world to communicate others. I wish to = have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.

This only makes = sense for applications that fit the "call an identified party" = paradigm.

SIP helps to interop for = basic call with other existing realtime application in Enterprise & Telecom = provider.

There is no need to build two different signaling logic in VoIP servers for each service. Your own = example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible = to avoided by having one signaling protocol.

One protocol can be = achieved by multiple applications choosing to implement one protocol.
It doesn't have to be enforced by the prtoocol being embedded in the = browser.

 

In RTCWEB does not standardize the signaling protocol interface between = browsers, the interop across webservers is next to impossible and it will be = restricted to single webserver (company) only. Please let  me know in case = I’m missing something here.


I think the main thing you are missing is that there are many = applications that people want to build on top of RTCWEB that are not telephones, and will = not fit with telephone-based paradigms.

 

------_=_NextPart_001_01CC715F.C6B929F7-- From stpeter@stpeter.im Mon Sep 12 08:53: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 6CF0A21F8BB8 for ; Mon, 12 Sep 2011 08:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.05 X-Spam-Level: X-Spam-Status: No, score=-102.05 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, J_BACKHAIR_53=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 RWlhrRDYhySF for ; Mon, 12 Sep 2011 08:53:08 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBB021F8511 for ; Mon, 12 Sep 2011 08:53:08 -0700 (PDT) Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E4FC841959; Mon, 12 Sep 2011 09:58:22 -0600 (MDT) Message-ID: <4E6E2B5F.7030307@stpeter.im> Date: Mon, 12 Sep 2011 09:55:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net><4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net><2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com><4E67AD3D.9000005@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com><4E686663.1050900@alvestrand.no><4E68CB68.3020100@alcatel-lucent.com><4E68D182.2090003@alvestrand.no><4E68D742.4010203@alcatel-lucent.com><4E68D8B5.7010602@alvestrand.no><4E6915F2.5000007@alcatel-lucent.com> <4E691CC6.9050905@stpeter.im> <2E239D6FCD033C4BAF15F386A979BF510F0A19@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0A19@sonusinmail02.sonusnet.com> X-Enigmail-Version: 1.3.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP vs Websocket in RTCWeb [was RE: SIP MUST NOT be used 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, 12 Sep 2011 15:53:09 -0000 On 9/12/11 12:57 AM, Ravindran Parthasarathi wrote: > Changing the title for giving the clear context of discussion. > > Peter, > > Thanks for forwarding info about draft-ietf-hybi-thewebsocketprotocol. I > started this mail thread to know whether RTCWeb1.0 is a unofficial > RFC3261bis for the line side (endpoint to access server) :-) [I really > don't know the better term for the line side]. Endpoint may be desktop, > smart phone (android), laptop, tablet, CPE, etc., > > Till reading this draft, I assumed websocket as a socket layer for HTTP > and it is bad assumption :-(. In short, browser is able to create two > way communication with webserver (which has globally routable address). > Two browser creating websocket with web servers will be able to > communicate with each other. This architecture exactly fits in SIP world > as > > SIP UA <---->B2BUA<----->SIP UA > > And resultant as browser<---> webserver <----> browser. I tend to > agree with you that Websocket looks as a better choice for this simple > web architecture as there is no need of identity exchange here because > webserver knows and authenticated both browsers with the corresponding > identity. In fact, B2BUA with globally routable address will interop > better with any endpoint for that matter. The difference comes into > picture for federation (interop between servers). I'm not very clear > whether websocket is intended for federation as well or not. Most of the > discussion RTCWeb points to use SIP as a federation protocol which may > change later. I'm interested knowing your view here. For this mail, I > assume that SIP as a federation protocol of RTCWeb1.0 and I'm ready to > change if it is the right thing to do :-) I think that the protocol used for server-to-server federation is a matter for the service providers and thus is not in scope for RTCWeb. Some s2s links might use SIP, some might use XMPP/Jingle, etc. Peter -- Peter Saint-Andre https://stpeter.im/ From pkyzivat@alum.mit.edu Mon Sep 12 09:40: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 57D2821F8BBE for ; Mon, 12 Sep 2011 09:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-MT5x7eOGjZ for ; Mon, 12 Sep 2011 09:40:10 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5D85521F8696 for ; Mon, 12 Sep 2011 09:40:10 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta13.westchester.pa.mail.comcast.net with comcast id XpBM1h00127AodY5DsiEik; Mon, 12 Sep 2011 16:42:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta19.westchester.pa.mail.comcast.net with comcast id XsiC1h01w0tdiYw3fsiDFf; Mon, 12 Sep 2011 16:42:13 +0000 Message-ID: <4E6E3667.1020003@alum.mit.edu> Date: Mon, 12 Sep 2011 12:42:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org>, <4E6AE22A.2070106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se>, <4E6C16FF.1000706@jesup.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 16:40:11 -0000 On 9/11/11 4:49 AM, Stefan Hkansson LK wrote: > In my mind I had built a slightly different model of how this would work. In essence, the SDP o/a would not be allowed to negotiate encryption or not, that should be set when creating the PeerConnection object: > > * The level of media protection to use (NONE, SDES-SRTP or DTLS-SRTP) should be set by the web app when a PeerConnection object is created (possibly part of the configuration string) > * One pre-requisite for the PeerConnection to enter the open state (and for streams to be set up) must be that the same level of protection is selected by both peer apps > * We should never allow any SDP o/a to negotiate away from the selected level of protection. > > This would work just fine in the most common use cases as it is the same app, served by the same server, running in both browsers, and since support of NONE, SDES-SRTP and DTLS-SRTP in browsers should be mandated. The service provider/app developer decides. > > The tricky part would be interop. But if we take the browser to browser, but the app coming from different sources case, the two teams developing the apps must communicate any way to make them interop. Agreeing on whether to use NONE, SDES-SRTP or DTLS-SRTP is just one detail to agree on. > > Developers of apps to interop with legacy must acquire enough info about the system to interop with to make the right setting of PeerConnection for the specific case. I think I can buy this approach up to this point - that the JS in the browser can know that something special is required because its an interop case. The harder point is knowing *what* is required in the interop case. If the goal is to avoid needing a media gateway in this case, then what is required will be determined as part of the O/A. Or it can contractually negotiated for each different federation target. Hadriel seems to be arguing that a media gateway will always be needed in the federation case. Making that assumption will certainly simplify rtcweb, but it also ensures a cost for federation. It is essentially the same cost that is incurred when sip users and service providers require the use of SBCs at their borders. So far that has been a cost that people have willingly paid. This can be abstracted as a partitioning of the features covered by RFC 3264 O/A into categories: - features to be entirely fixed for rtcweb - features to be chosen/negotiated by the web application using application-specific logic and communicated to the browser via JS prior to session establishment. - features to be negotiated via o/a by the browser - features to be negotiated via o/a in JS running in the browser Then the discussion has been about people arguing for different partitionings - mostly extremes. Some that I am seeing: 1) (Cullen) everything should be negotiated by o/a in the browser. (Presumably with some interaction with JS for ICE candidate selection.) The logical conclusion of this (I'm not sure Cullen is arguing for this) is that capneg must be included and used to handle the security negotiation. 2) (Hadriel?) The security mechanism, and use of ICE, is fixed for rtcweb. ICE candidate selection and all the rest of o/a is handled in JS. (That is just a stab - sorry if I have mis-characterized. Please jump in and correct me.) This is a fundamental decision to make. When federating, features that are chosen prior to session establishment will be the result of private agreements and result in a form of balkanization. When federating via sip to a target that doesn't have fixed values for features that must be pre-agreed, the only option will be a media gateway. Thanks, Paul > Remember, the primary target for this activity is browser-to-browser. This should be simple and straightforward for the app developer. That the app developer would have to think a bit more for interop cases is quite OK IMO. > > Stefan > ________________________________________ > From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Randell Jesup [randell-ietf@jesup.org] > Sent: Sunday, September 11, 2011 4:03 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] > > On 9/10/2011 8:16 PM, Christer Holmberg wrote: >> >>> The exact same thing could arise if we had somebody with an urgent >>> desire to do secure media with fallback to insecure media in SIP. >>> All the arguments against capneg would be exactly the same. >>> >>> The problem is that people aren't finding capneg a usable solution to >>> this problem, just the way that people didn't find SDPng a solution to >>> the inadequacies of SDP. >>> >>> While it is possible for rtcweb to adopt its own solution to the >>> problem, that only solves half the problem. And it then creates an >>> interop problem with SIP. >> A send-a-new-offer-if-the-first-offers-fails mechanism would be backward compatible - assuming the offerer can guess why the first offer failed. >> >> Also, using the AVP and RTP profiles, together with attributes that specifies the AVPF and SRTP stuff would also work. Of course, it goes against the current AVPF and SRTP specifications, and since current legacy deployments would not understand such attributes, they would always end up using AVP and RTP. > > I think what you've speced here is basically similar to the > draft-best-effort-srtp proposal. > > > -- > Randell Jesup > randell-ietf@jesup.org > > _______________________________________________ > 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 dzonatas@gmail.com Mon Sep 12 10:10: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 4229121F8C20 for ; Mon, 12 Sep 2011 10:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[AWL=-1.296, BAYES_00=-2.599, J_BACKHAIR_25=1, J_BACKHAIR_53=1, 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 NdZQ5qYRTwjO for ; Mon, 12 Sep 2011 10:10:20 -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 5035221F8B11 for ; Mon, 12 Sep 2011 10:10:20 -0700 (PDT) Received: by gyd12 with SMTP id 12so361660gyd.31 for ; Mon, 12 Sep 2011 10:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=l1Ko0JnMFCJ1Nj5xr0QZmRDAgAEGxsaf/2xwjvG44Rw=; b=m7kaJHe0igkeYFIETCnyYReg9cmy+a2F4jfQwqyG6OG/BK02i72UmSC469aZYsfmac JSVoIRuAgvoSP7LCSvgmI20nipFadB7MzgljcaMCYPKZ4Watk/1uohka/0jH1JZWd2SI nZdu9gHcB+DZe+X2dzs6+k/RJJHmFXdFpDp+8= Received: by 10.42.148.129 with SMTP id r1mr1111050icv.272.1315847539043; Mon, 12 Sep 2011 10:12:19 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net [70.133.70.225]) by mx.google.com with ESMTPS id v16sm22970599ibe.0.2011.09.12.10.12.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Sep 2011 10:12:18 -0700 (PDT) Message-ID: <4E6E3DEE.8080200@gmail.com> Date: Mon, 12 Sep 2011 10:14:22 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net><4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net><2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com><4E67AD3D.9000005@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com><4E686663.1050900@alvestrand.no><4E68CB68.3020100@alcatel-lucent.com><4E68D182.2090003@alvestrand.no><4E68D742.4010203@alcatel-lucent.com><4E68D8B5.7010602@alvestrand.no><4E6915F2.5000007@alcatel-lucent.com> <4E691CC6.9050905@stpeter.im> <2E239D6FCD033C4BAF15F386A979BF510F0A19@sonusinmail02.sonusnet.com> <4E6E2B5F.7030307@stpeter.im> In-Reply-To: <4E6E2B5F.7030307@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] SIP vs Websocket in RTCWeb [was RE: SIP MUST NOT be used 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, 12 Sep 2011 17:10:21 -0000 On 09/12/2011 08:55 AM, Peter Saint-Andre wrote: > On 9/12/11 12:57 AM, Ravindran Parthasarathi wrote: > >> Changing the title for giving the clear context of discussion. >> >> Peter, >> >> Thanks for forwarding info about draft-ietf-hybi-thewebsocketprotocol. I >> started this mail thread to know whether RTCWeb1.0 is a unofficial >> RFC3261bis for the line side (endpoint to access server) :-) [I really >> don't know the better term for the line side]. Endpoint may be desktop, >> smart phone (android), laptop, tablet, CPE, etc., >> >> Till reading this draft, I assumed websocket as a socket layer for HTTP >> and it is bad assumption :-(. In short, browser is able to create two >> way communication with webserver (which has globally routable address). >> Two browser creating websocket with web servers will be able to >> communicate with each other. This architecture exactly fits in SIP world >> as >> >> SIP UA<---->B2BUA<----->SIP UA >> >> And resultant as browser<---> webserver<----> browser. I tend to >> agree with you that Websocket looks as a better choice for this simple >> web architecture as there is no need of identity exchange here because >> webserver knows and authenticated both browsers with the corresponding >> identity. In fact, B2BUA with globally routable address will interop >> better with any endpoint for that matter. The difference comes into >> picture for federation (interop between servers). I'm not very clear >> whether websocket is intended for federation as well or not. Most of the >> discussion RTCWeb points to use SIP as a federation protocol which may >> change later. I'm interested knowing your view here. For this mail, I >> assume that SIP as a federation protocol of RTCWeb1.0 and I'm ready to >> change if it is the right thing to do :-) >> > I think that the protocol used for server-to-server federation is a > matter for the service providers and thus is not in scope for RTCWeb. > Some s2s links might use SIP, some might use XMPP/Jingle, etc. > > Peter > > Yesterday I thought browser-hints could help with transitions to federation, especially for RTCWeb-to-SIP: http://tools.ietf.org/html/draft-nottingham-http-browser-hints-02 Thanks. -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From pravindran@sonusnet.com Mon Sep 12 11:39: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 4EB5421F8C5E for ; Mon, 12 Sep 2011 11:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, J_BACKHAIR_25=1, J_BACKHAIR_53=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 fTnYPpFYnGYc for ; Mon, 12 Sep 2011 11:39:50 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDA721F8BA9 for ; Mon, 12 Sep 2011 11:39:48 -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 p8CIgKdY000884; Mon, 12 Sep 2011 14:42:20 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Sep 2011 14:41:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Sep 2011 00:11:47 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0AA1@sonusinmail02.sonusnet.com> In-Reply-To: <4E6E3DEE.8080200@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SIP vs Websocket in RTCWeb [was RE: SIP MUST NOT be used in browser?] Thread-Index: AcxxbyiI1ZGw8iMET8KpIUdoCLDKQAACygIg References: <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net><4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net><2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com><4E67AD3D.9000005@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com><4E686663.1050900@alvestrand.no><4E68CB68.3020100@alcatel-lucent.com><4E68D182.2090003@alvestrand.no><4E68D742.4010203@alcatel-lucent.com><4E68D8B5.7010602@alvestrand.no><4E6915F2.5000007@alcatel-lucent.com> <4E691CC6.9050905@stpeter.im> <2E239D6FCD033C4BAF15F386A979BF510F0A19@sonusinmail02.sonusnet.com><4E6E2B5F.7030307@stpeter.im> <4E6E3DEE.8080200@gmail.c om> From: "Ravindran Parthasarathi" To: "Dzonatas Sol" , , "Peter Saint-Andre" X-OriginalArrivalTime: 12 Sep 2011 18:41:50.0151 (UTC) FILETIME=[A21B3570:01CC717B] Subject: Re: [rtcweb] SIP vs Websocket in RTCWeb [was RE: SIP MUST NOT be used 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, 12 Sep 2011 18:39:51 -0000 Peter, > I think that the protocol used for server-to-server federation is a=20 > matter for the service providers and thus is not in scope for RTCWeb. Sec 4.2.5 of draft-ietf-rtcweb-use-cases-and-requirements-04 includes the usecase for federation. My assumption is based on this usecases. Till now, there is no better protocol than SIP exists for this discussion. > Some s2s links might use SIP, some might use XMPP/Jingle, etc. > I agree with you that signaling interop is not focus of RTCWeb and only one webserver is solution space then your solution looks like working. Even then, I prefer single signaling protocol rather than ad-hoc signaling protocol by each web developer. Dzonatas, I lean towards SIP federation because of the maturity of the SIP protocol. Last 10 years of bug fix in SIP stack makes it more stable now :-)=20 Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Dzonatas Sol >Sent: Monday, September 12, 2011 10:44 PM >To: rtcweb@ietf.org >Subject: Re: [rtcweb] SIP vs Websocket in RTCWeb [was RE: SIP MUST NOT >be used in browser?] > >On 09/12/2011 08:55 AM, Peter Saint-Andre wrote: >> On 9/12/11 12:57 AM, Ravindran Parthasarathi wrote: >> >>> Changing the title for giving the clear context of discussion. >>> >>> Peter, >>> >>> Thanks for forwarding info about draft-ietf-hybi- >thewebsocketprotocol. I >>> started this mail thread to know whether RTCWeb1.0 is a unofficial >>> RFC3261bis for the line side (endpoint to access server) :-) [I >really >>> don't know the better term for the line side]. Endpoint may be >desktop, >>> smart phone (android), laptop, tablet, CPE, etc., >>> >>> Till reading this draft, I assumed websocket as a socket layer for >HTTP >>> and it is bad assumption :-(. In short, browser is able to create two >>> way communication with webserver (which has globally routable >address). >>> Two browser creating websocket with web servers will be able to >>> communicate with each other. This architecture exactly fits in SIP >world >>> as >>> >>> SIP UA<---->B2BUA<----->SIP UA >>> >>> And resultant as browser<---> webserver<----> browser. I tend to >>> agree with you that Websocket looks as a better choice for this >simple >>> web architecture as there is no need of identity exchange here >because >>> webserver knows and authenticated both browsers with the >corresponding >>> identity. In fact, B2BUA with globally routable address will interop >>> better with any endpoint for that matter. The difference comes into >>> picture for federation (interop between servers). I'm not very clear >>> whether websocket is intended for federation as well or not. Most of >the >>> discussion RTCWeb points to use SIP as a federation protocol which >may >>> change later. I'm interested knowing your view here. For this mail, I >>> assume that SIP as a federation protocol of RTCWeb1.0 and I'm ready >to >>> change if it is the right thing to do :-) >>> >> I think that the protocol used for server-to-server federation is a >> matter for the service providers and thus is not in scope for RTCWeb. >> Some s2s links might use SIP, some might use XMPP/Jingle, etc. >> >> Peter >> >> > >Yesterday I thought browser-hints could help with transitions to >federation, especially for RTCWeb-to-SIP: > >http://tools.ietf.org/html/draft-nottingham-http-browser-hints-02 > >Thanks. > >-- >--- http://twitter.com/Dzonatas_Sol --- >Web Development, Software Engineering >Ag-Biotech, Virtual Reality, Consultant > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Mon Sep 12 11:55: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 7AF2C21F8CB7 for ; Mon, 12 Sep 2011 11:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.114, 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 KFfeXJV2venc for ; Mon, 12 Sep 2011 11:55:44 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6260D21F8CB2 for ; Mon, 12 Sep 2011 11:55:37 -0700 (PDT) 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 p8CIw77W011250; Mon, 12 Sep 2011 14:58:07 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Sep 2011 14:57:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC717D.D4DCEB1E" Date: Tue, 13 Sep 2011 00:27:34 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0AA2@sonusinmail02.sonusnet.com> In-Reply-To: <1D062974A4845E4D8A343C6538049202065582FF@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording client] Thread-Index: Acxt9AbN3JhWXoAGQEWrQ9SN744t+wARGUtgAMkSJbAAB9H90A== References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net><4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net><2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com><4E67AD3D.9000005@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com><4E686663.1050900@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F0989@sonusinmail02.sonusnet.com> <1D062974A4845E4D8A343C6538049202065582FF@XMB-BGL-414.cisco.com> From: "Ravindran Parthasarathi" To: "Muthu Arul Mozhi Perumal (mperumal)" , "Harald Alvestrand" X-OriginalArrivalTime: 12 Sep 2011 18:57:37.0073 (UTC) FILETIME=[D6840A10:01CC717D] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 18:55:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC717D.D4DCEB1E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Muthu, =20 Browser is yet another application in the system which has the programming environment using Javascript. I explained my point of view in another mail thread: http://www.ietf.org/mail-archive/web/rtcweb/current/msg01058.html. My proposal is similar to SIP stack with C or C++ API but RTCWeb API is designed based on Javascript. Like normal SIP stack, the new headers shall be added by the use of Javascript API. SIP stack in browser shall composes of transaction layer, encoding & decoding of the SIP message, and UAC & UAS functionality mentioned in RFC 3261. I agree that agreed upon NAT traversal mechanism of signaling protocol has to be supported for RTCWeb. Jquery library shall be built for the high level API's. =20 These sort of SIP framework will scale for any sort innovative real-time application with better performance compare to any other protocol known in IETF. As the core SIP stack is build within browser, javascript programmer will focus on application and not on the protocol intricacies. =20 Thanks Partha =20 From: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20 Sent: Monday, September 12, 2011 8:52 PM To: Ravindran Parthasarathi; Harald Alvestrand Cc: rtcweb@ietf.org Subject: RE: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording client] =20 Asking for the browser to support SIP is like asking for the OS kernel to support 100s of SIP specs to cater to various kinds of applications, instead of implementing what portion of SIP you care about in the application itself -- it just doesn't look scalable. Even if you want to experiment with a new SIP header you would have to wait for the browser vendor to release the new version of the browser or make changes to the browser code yourself, severely hampering application development. =20 Muthu =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ravindran Parthasarathi Sent: Thursday, September 08, 2011 8:44 PM To: Harald Alvestrand Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording client] =20 Harald, =20 I'm proposing for "SIP UA framework for RTCWeb browser", the framework provides Javascript API. In case you mean the same as "SIP lite". I'm fine with it. SIP UA framework helps to support two-party communication from RTCWeb browser and uses HTTP as presence or configuration interface.=20 =20 As I mentioned in the another mail, I'm talking about INVITE subset of RFC 3261 in browser. =20 =20 Thanks Partha =20 From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Thursday, September 08, 2011 12:23 PM To: Ravindran Parthasarathi Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] =20 On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote:=20 Harald, =20 For browser as a SIP UA application, browser has to no need to compliant with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also agree with you that browser-to-browser communication, I could not see the strong reason for supporting S/MIME. As part of the RTCWeb architecture & solution, we will able to explore the SIP UA requirement for making browser SIP compliant. So you're advocating for creating a "SIP lite" subset that RTCWEB browsers implement. I think we have been down this road before, and it's not a happy one. But sure - if you want us to implement some part of SIP, *please start stating what part* rather than making wooly statements. Subsets are Real Hard Work. Say for example, forking does not make sense in case of browser as SIP UA application, forked response will be rejected with CANCEL in browser without Javascript intervention. The main requirement is to build the right SIP UA framework in browser by which Javascript developer will be able to use to the maximum extent without impacting the basic 2 two party communication in the internet. =20 =20 As mailed in another thread, RTCWEB client + RTCWeb server makes to feel a modern exchange in web world (Plain Old Telephony System phone with exchange architecture). I think so because POTS phones are dumb which does not know its identity and every event like offhook, onhook has to passed to exchange (webserver) whereas RTCWeb client (browser) has to pass every event to webserver and webserver has whole intelligence to make it work. Don't forget that the RTCWEB client (the browser) contains an open, fully programmable application platform - the Javascript engine. That's a HUGE difference to the POTS phone. I got this feel more when someone is talking about MEGACO or MGCP between RTCWEB client & webserver. My understanding is that SIP does not fit well to legacy telephone-based paradigm by any means but MEGACO or MGCP are the better choice which maps to SS7 architecture well. I'm interested in seeing RTCWeb client perform the basic routing rather than webserver does the routing on behalf of RTCWEb client. =20 I agree with you that in case it is local exchange (same site like skype or Google hangout) communication, there will be no need of signaling but I'm interested in communication with one of the Google real-time user in internet without having any Google id. I believe that SIP will make it work. If by saying "the Google real time user in Internet", you mean a Google Talk user, you have that already. It's called Google Voice. It uses SIP, but not in the browser. Talking to someone who doesn't want to talk to you is an use case we don't intend to support. =20 Thanks Partha =20 From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Wednesday, September 07, 2011 11:13 PM To: Ravindran Parthasarathi Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] =20 On 09/07/11 19:29, Ravindran Parthasarathi wrote:=20 Matthew, =20 When I asked for SIP, I have meant RFC 3261 only. This is 269 pages, and has 26 normative dependencies including S/MIME. It's not a small dependency. The basic reason for asking SIP is to make the basic call works between browser to browser across web servers. Without SIP in browser, it is not going happen. Innovative application is going to be proprietary whether it is HTTP or SIP or any other protocol for that matter. =20 My reasoning are as follows: SIP makes browser more intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG.=20 Why does that "intelligence" need to be in the browser, rather than in the Javascript? The importance of basic call interop is that there is no need of many individual id like skype id, Google id and yahoo id by everyone in the world to communicate others. I wish to have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.=20 This only makes sense for applications that fit the "call an identified party" paradigm. SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provider. There is no need to build two different signaling logic in VoIP servers for each service. Your own example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible to avoided by having one signaling protocol. One protocol can be achieved by multiple applications choosing to implement one protocol. It doesn't have to be enforced by the prtoocol being embedded in the browser. =20 In RTCWEB does not standardize the signaling protocol interface between browsers, the interop across webservers is next to impossible and it will be restricted to single webserver (company) only. Please let me know in case I'm missing something here. I think the main thing you are missing is that there are many applications that people want to build on top of RTCWEB that are not telephones, and will not fit with telephone-based paradigms. =20 ------_=_NextPart_001_01CC717D.D4DCEB1E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Muthu,

 

Browser is yet another application in the system which = has the programming environment using Javascript.  I explained my point of = view in another mail thread: http://www.ietf.org/mail-archive/web/rtcweb/current/msg01058.html. My proposal is similar to SIP stack with C or C++ API but RTCWeb API is designed based on Javascript. Like normal SIP stack, the new headers = shall be added by the use of Javascript API. SIP stack in browser shall composes = of transaction layer, encoding & decoding of the SIP message, and UAC = & UAS functionality mentioned in RFC 3261. I agree that agreed upon NAT = traversal mechanism of signaling protocol has to be supported for RTCWeb. =  Jquery library shall be built for the high level = API’s.

 

These sort of SIP framework will scale for any sort = innovative real-time application with better performance compare to any other = protocol known in IETF. As the core SIP stack is build within browser, javascript programmer will focus on application and not on the protocol = intricacies.

 

Thanks

Partha

 

From: Muthu Arul Mozhi Perumal = (mperumal) [mailto:mperumal@cisco.com]
Sent: Monday, September 12, 2011 8:52 PM
To: Ravindran Parthasarathi; Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: RE: [rtcweb] SIP MUST NOT be used in browser?[was = RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording = client]

 

Asking for the browser to support SIP is like asking = for the OS kernel to support 100s of SIP specs to cater to various kinds of applications, instead of implementing what portion of SIP you care about = in the application itself -- it just doesn't look scalable. Even if you want to experiment with a new SIP header you would have to wait for the browser = vendor to release the new version of the browser or make changes to the browser = code yourself, severely hampering application = development.

 

Muthu

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ravindran = Parthasarathi
Sent: Thursday, September 08, 2011 8:44 PM
To: Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was = RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording = client]

 

Harald,

 

I’m proposing for “SIP UA framework for = RTCWeb browser”, the framework provides Javascript API. In case you mean = the same as “SIP lite”. I’m fine with it. SIP UA framework = helps to support two-party communication from RTCWeb browser and uses HTTP as presence or configuration interface.

 

As I mentioned in the another mail, I’m talking = about INVITE subset of RFC 3261 in browser.  

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Thursday, September 08, 2011 12:23 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; = rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remote recording - RTC-Web client acting as SIPREC session recording = client]

 

On 09/08/2011 07:09 AM, Ravindran Parthasarathi = wrote:

Harald,

 

For browser as a SIP UA application, browser has to no need to compliant = with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also agree with = you that browser-to-browser communication, I could not see the strong reason for supporting S/MIME. As part of the RTCWeb architecture & solution, we = will able to explore the SIP UA requirement for making browser SIP = compliant.

So you're advocating = for creating a "SIP lite" subset that RTCWEB browsers = implement.
I think we have been down this road before, and it's not a happy = one.
But sure - if you want us to implement some part of SIP, *please start = stating what part* rather than making wooly statements.

Subsets are Real Hard Work.

Say for example, forking does not make sense in case of browser as SIP UA application, forked response will be rejected with CANCEL in browser = without Javascript intervention. The main requirement is to build the right SIP = UA framework in browser by which Javascript developer will be able to use = to the maximum extent without impacting the basic 2 two party communication in = the internet. 

 

As mailed in another thread, RTCWEB client + RTCWeb server makes to feel a = modern exchange in web world (Plain Old Telephony System phone with exchange architecture). I think so because POTS phones are dumb which does not = know its identity and every event like offhook, onhook has to passed to exchange (webserver) whereas RTCWeb client (browser) has to pass every event to webserver and webserver has whole intelligence to make it = work.

Don't forget that = the RTCWEB client (the browser) contains an open, fully programmable application = platform - the Javascript engine. That's a HUGE difference to the POTS = phone.

I got this feel more when someone is talking about MEGACO or MGCP between = RTCWEB client & webserver. My understanding is that SIP does not fit well = to legacy telephone-based paradigm by any means but MEGACO or MGCP are the = better choice which maps to SS7 architecture well. I’m interested in = seeing RTCWeb client perform the basic routing rather than webserver does the = routing on behalf of RTCWEb client.

 

I agree with you that in case it is local exchange (same site like skype = or Google hangout) communication, there will be no need of signaling but = I’m interested in communication with one of the Google real-time user in = internet without having any Google id.  I believe that SIP will make it = work.

If by saying = "the Google real time user in Internet", you mean a Google Talk user, you have = that already. It's called Google Voice. It uses SIP, but not in the = browser.

Talking to someone who doesn't want to talk to you is an use case we = don't intend to support.

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:harald@alvestrand.no] =
Sent: Wednesday, September 07, 2011 11:13 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lu= cent.com; rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remote recording - RTC-Web client acting as SIPREC session recording = client]

 

On 09/07/11 19:29, Ravindran Parthasarathi wrote: =

Matthew,

 

When I asked for SIP, I have meant RFC 3261 only.

This is 269 pages, and has 26 normative = dependencies including S/MIME. It's not a small dependency.



The basic reason for asking SIP is to make the basic call works between = browser to browser across web servers. Without SIP in browser, it is not going = happen. Innovative application is going to be proprietary whether it is HTTP or = SIP or any other protocol for that matter.

 

My reasoning are as follows:

SIP makes browser more = intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG. =

Why does that "intelligence" need to be in the browser, rather than in the Javascript?

The importance of basic call = interop is that there is no need of many individual id like skype id, Google = id  and yahoo id by everyone in the world to communicate others. I wish to = have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.

This only makes = sense for applications that fit the "call an identified party" = paradigm.

SIP helps to interop for = basic call with other existing realtime application in Enterprise & Telecom = provider.

There is no need to build two different signaling logic in VoIP servers for each service. Your own = example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible = to avoided by having one signaling protocol.

One protocol can be = achieved by multiple applications choosing to implement one protocol.
It doesn't have to be enforced by the prtoocol being embedded in the = browser.

 

In RTCWEB does not standardize the signaling protocol interface between = browsers, the interop across webservers is next to impossible and it will be = restricted to single webserver (company) only. Please let  me know in case = I’m missing something here.


I think the main thing you are missing is that there are many = applications that people want to build on top of RTCWEB that are not telephones, and will = not fit with telephone-based paradigms.

 

------_=_NextPart_001_01CC717D.D4DCEB1E-- From jovass@adobe.com Mon Sep 12 14:08: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 9661721F8E2D for ; Mon, 12 Sep 2011 14:08:07 -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 DX4GWQxd9gpr for ; Mon, 12 Sep 2011 14:08:05 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 507F521F8E20 for ; Mon, 12 Sep 2011 14:08:05 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKTm51LUxLXJR9iAq+6lS/z0A+DFhslAB+@postini.com; Mon, 12 Sep 2011 14:10:10 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p8CLA3Ie025286; Mon, 12 Sep 2011 14:10:04 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id p8CLA22d001551; Mon, 12 Sep 2011 14:10:02 -0700 (PDT) Received: from nambx03.corp.adobe.com ([10.8.189.93]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Mon, 12 Sep 2011 14:10:01 -0700 From: Jozsef Vass To: Silvia Pfeiffer , Matthew Kaufman Date: Mon, 12 Sep 2011 14:10:00 -0700 Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] Thread-Index: AcxtyFrH7W+hi6D3R8esNHBnJzn0UgDxjuvg Message-ID: <0FEA137C08A9DF4781EEF745038C969430A50DF699@nambx03.corp.adobe.com> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3EE.50707@jesup.org> <4E67F0A2.1070308@skype.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 21:08:07 -0000 Neither the website nor the documents mention the use of Flash, which is ev= ident if you try the app. They also make use of the acoustic echo cancellat= ion capability available in Flash. Jozsef -----Original Message----- From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com]=20 Sent: Wednesday, September 07, 2011 6:16 PM To: Matthew Kaufman Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecord= ing - RTC-Web client acting as SIPREC session recordingclient] If implementations count for anything, check out: http://phono.com/ and https://docs.google.com/present/view?id=3D0AcNAXuadeXIxZGY4NDl4Z2RfNTlod3Br= OXNjZA&hl=3Den&pli=3D1 They use SIP with web sockets. Cheers, Silvia. On Thu, Sep 8, 2011 at 8:30 AM, Matthew Kaufman = wrote: > On 9/7/11 12:20 PM, Randell Jesup wrote: >> >> I also started from the same point - assume SIP. =A0SIP gives you all=20 >> the things that the zillions of hours and emails to define it and=20 >> define extensions and secure it provides, without having to reinvent=20 >> all those wheels (or ask app developers to reinvent them). =A0Why go=20 >> through the horrible pain of choosing something else, or why throw=20 >> the app developers to the wolves to fend for themselves? >> >> However... >> >> Two things have swayed me. =A0The primary one is the suggestion of=20 >> Offer/Answer in the browser. =A0This breaks out the important=20 >> negotiation piece that almost any application would need, and while=20 >> not perfect, SDP O/A is a zillion times simpler than SIP with all the ex= tensions one could use. > > I agree with this. While I am also opposed to SDP O/A, these are two=20 > unrelated arguments to have... and not baking a SIP phone into the=20 > browser is *more* important than avoiding a repeat of the offer/answer pr= oblems. > >> >> The other thing that swayed me was thinking about federation and the=20 >> apps that will be built with this. =A0A webrtc app talks to its=20 >> (web)server, other webrtc clients running the app that talk to the=20 >> server, and to other webrtc applications/networks that federate with it = (and their clients). >> >> Federation is in the same hands as the person who provides/wrote the app= . >> =A0If they have no interest in federation you can't force it, and they=20 >> may have no use for all the fancy SIP standards. > > And for numerous types of apps (think: server-based augmented reality=20 > systems), "federation" doesn't even make sense. > >> >> On the other hand, if they *want* to either provide access to the=20 >> wider communication net that is the PSTN network, now or in the=20 >> future, or they want easy federation with other networks, it behooves=20 >> them to use SIP or something very close to it or=20 >> equivalent/convertible (at a basic level at >> least) to it. >> >> So what conclusions do I draw from this? >> >> 1) O/A via SDP in the browser simplifies a lot of things (including=20 >> handling new codecs, etc). =A0It doesn't extremely limit an=20 >> application, though we should think about how an application can=20 >> interact with the fmtp/etc parameters used. > > I agree that it would simplify some interop cases, but at an=20 > unfortunate cost in lack of flexibility and functionality. Still not=20 > nearly as bad as if we put a full SIP stack in there though. > >> >> 2) SIP as a *separate* item that can be cleanly and easily *added* to=20 >> a webrtc app to handle the call setup/etc is a good idea. > > I would be open to looking at this again, *after* RTC is already in=20 > browsers and successful, to see if it actually solves a real use case. > > Matthew Kaufman > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From roman@telurix.com Mon Sep 12 14:30: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 1D53621F8E27 for ; Mon, 12 Sep 2011 14:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.582 X-Spam-Level: X-Spam-Status: No, score=-1.582 tagged_above=-999 required=5 tests=[AWL=-1.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, 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 iejyppjYInqx for ; Mon, 12 Sep 2011 14:30:29 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D263321F8E22 for ; Mon, 12 Sep 2011 14:30:28 -0700 (PDT) Received: by gwb20 with SMTP id 20so3282417gwb.31 for ; Mon, 12 Sep 2011 14:32:30 -0700 (PDT) Received: by 10.151.87.13 with SMTP id p13mr1268230ybl.332.1315863150120; Mon, 12 Sep 2011 14:32:30 -0700 (PDT) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx.google.com with ESMTPS id h1sm807198ybi.29.2011.09.12.14.32.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Sep 2011 14:32:29 -0700 (PDT) Received: by gxk28 with SMTP id 28so4189770gxk.27 for ; Mon, 12 Sep 2011 14:32:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.8.66 with SMTP id p2mr3075918pba.442.1315863148401; Mon, 12 Sep 2011 14:32:28 -0700 (PDT) Received: by 10.68.46.227 with HTTP; Mon, 12 Sep 2011 14:32:28 -0700 (PDT) In-Reply-To: <0FEA137C08A9DF4781EEF745038C969430A50DF699@nambx03.corp.adobe.com> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3EE.50707@jesup.org> <4E67F0A2.1070308@skype.net> <0FEA137C08A9DF4781EEF745038C969430A50DF699@nambx03.corp.adobe.com> Date: Mon, 12 Sep 2011 17:32:28 -0400 Message-ID: From: Roman Shpount To: Jozsef Vass Content-Type: multipart/alternative; boundary=bcaec53ae87888960e04acc543df Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 21:30:30 -0000 --bcaec53ae87888960e04acc543df Content-Type: text/plain; charset=ISO-8859-1 Neither do they websockets (they use BOSH http://xmpp.org/about-xmpp/technology-overview/bosh/) or SIP (at least not for client to server communications). _____________ Roman Shpount On Mon, Sep 12, 2011 at 5:10 PM, Jozsef Vass wrote: > Neither the website nor the documents mention the use of Flash, which is > evident if you try the app. They also make use of the acoustic echo > cancellation capability available in Flash. > > Jozsef > > -----Original Message----- > From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com] > Sent: Wednesday, September 07, 2011 6:16 PM > To: Matthew Kaufman > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: > Remoterecording - RTC-Web client acting as SIPREC session recordingclient] > > If implementations count for anything, check out: > > http://phono.com/ > and > > https://docs.google.com/present/view?id=0AcNAXuadeXIxZGY4NDl4Z2RfNTlod3BrOXNjZA&hl=en&pli=1 > > They use SIP with web sockets. > > Cheers, > Silvia. > > > On Thu, Sep 8, 2011 at 8:30 AM, Matthew Kaufman > wrote: > > On 9/7/11 12:20 PM, Randell Jesup wrote: > >> > >> I also started from the same point - assume SIP. SIP gives you all > >> the things that the zillions of hours and emails to define it and > >> define extensions and secure it provides, without having to reinvent > >> all those wheels (or ask app developers to reinvent them). Why go > >> through the horrible pain of choosing something else, or why throw > >> the app developers to the wolves to fend for themselves? > >> > >> However... > >> > >> Two things have swayed me. The primary one is the suggestion of > >> Offer/Answer in the browser. This breaks out the important > >> negotiation piece that almost any application would need, and while > >> not perfect, SDP O/A is a zillion times simpler than SIP with all the > extensions one could use. > > > > I agree with this. While I am also opposed to SDP O/A, these are two > > unrelated arguments to have... and not baking a SIP phone into the > > browser is *more* important than avoiding a repeat of the offer/answer > problems. > > > >> > >> The other thing that swayed me was thinking about federation and the > >> apps that will be built with this. A webrtc app talks to its > >> (web)server, other webrtc clients running the app that talk to the > >> server, and to other webrtc applications/networks that federate with it > (and their clients). > >> > >> Federation is in the same hands as the person who provides/wrote the > app. > >> If they have no interest in federation you can't force it, and they > >> may have no use for all the fancy SIP standards. > > > > And for numerous types of apps (think: server-based augmented reality > > systems), "federation" doesn't even make sense. > > > >> > >> On the other hand, if they *want* to either provide access to the > >> wider communication net that is the PSTN network, now or in the > >> future, or they want easy federation with other networks, it behooves > >> them to use SIP or something very close to it or > >> equivalent/convertible (at a basic level at > >> least) to it. > >> > >> So what conclusions do I draw from this? > >> > >> 1) O/A via SDP in the browser simplifies a lot of things (including > >> handling new codecs, etc). It doesn't extremely limit an > >> application, though we should think about how an application can > >> interact with the fmtp/etc parameters used. > > > > I agree that it would simplify some interop cases, but at an > > unfortunate cost in lack of flexibility and functionality. Still not > > nearly as bad as if we put a full SIP stack in there though. > > > >> > >> 2) SIP as a *separate* item that can be cleanly and easily *added* to > >> a webrtc app to handle the call setup/etc is a good idea. > > > > I would be open to looking at this again, *after* RTC is already in > > browsers and successful, to see if it actually solves a real use case. > > > > Matthew Kaufman > > > > _______________________________________________ > > 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 > --bcaec53ae87888960e04acc543df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Neither do they websockets (they use BOSH http://xmpp.org/about-xmpp/technology-overv= iew/bosh/) or SIP (at least not for client to server communications). _____________
Roman Shpount


On Mon, Sep 12, 2011 at 5:10 PM, Jozsef = Vass <jovass@adobe= .com> wrote:
Neither the website nor the documents mention the use of Flash, which is ev= ident if you try the app. They also make use of the acoustic echo cancellat= ion capability available in Flash.

Jozsef

-----Original Message-----
From: Silvia Pfeiffer [mailto:= silviapfeiffer1@gmail.com]
Sent: Wednesday, September 07, 2011 6:16 PM
To: Matthew Kaufman
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecord= ing - RTC-Web client acting as SIPREC session recordingclient]

If implementations count for anything, check out:

http://phono.com/
and
https://docs.g= oogle.com/present/view?id=3D0AcNAXuadeXIxZGY4NDl4Z2RfNTlod3BrOXNjZA&hl= =3Den&pli=3D1

They use SIP with web sockets.

Cheers,
Silvia.


On Thu, Sep 8, 2011 at 8:30 AM, Matthew Kaufman <matthew.kaufman@skype.net> wrote:
> On 9/7/11 12:20 PM, Randell Jesup wrote:
>>
>> I also started from the same point - assume SIP. =A0SIP gives you = all
>> the things that the zillions of hours and emails to define it and<= br> >> define extensions and secure it provides, without having to reinve= nt
>> all those wheels (or ask app developers to reinvent them). =A0Why = go
>> through the horrible pain of choosing something else, or why throw=
>> the app developers to the wolves to fend for themselves?
>>
>> However...
>>
>> Two things have swayed me. =A0The primary one is the suggestion of=
>> Offer/Answer in the browser. =A0This breaks out the important
>> negotiation piece that almost any application would need, and whil= e
>> not perfect, SDP O/A is a zillion times simpler than SIP with all = the extensions one could use.
>
> I agree with this. While I am also opposed to SDP O/A, these are two > unrelated arguments to have... and not baking a SIP phone into the
> browser is *more* important than avoiding a repeat of the offer/answer= problems.
>
>>
>> The other thing that swayed me was thinking about federation and t= he
>> apps that will be built with this. =A0A webrtc app talks to its >> (web)server, other webrtc clients running the app that talk to the=
>> server, and to other webrtc applications/networks that federate wi= th it (and their clients).
>>
>> Federation is in the same hands as the person who provides/wrote t= he app.
>> =A0If they have no interest in federation you can't force it, = and they
>> may have no use for all the fancy SIP standards.
>
> And for numerous types of apps (think: server-based augmented reality<= br> > systems), "federation" doesn't even make sense.
>
>>
>> On the other hand, if they *want* to either provide access to the<= br> >> wider communication net that is the PSTN network, now or in the >> future, or they want easy federation with other networks, it behoo= ves
>> them to use SIP or something very close to it or
>> equivalent/convertible (at a basic level at
>> least) to it.
>>
>> So what conclusions do I draw from this?
>>
>> 1) O/A via SDP in the browser simplifies a lot of things (includin= g
>> handling new codecs, etc). =A0It doesn't extremely limit an >> application, though we should think about how an application can >> interact with the fmtp/etc parameters used.
>
> I agree that it would simplify some interop cases, but at an
> unfortunate cost in lack of flexibility and functionality. Still not > nearly as bad as if we put a full SIP stack in there though.
>
>>
>> 2) SIP as a *separate* item that can be cleanly and easily *added*= to
>> a webrtc app to handle the call setup/etc is a good idea.
>
> I would be open to looking at this again, *after* RTC is already in > browsers and successful, to see if it actually solves a real use case.=
>
> Matthew Kaufman
>
> _______________________________________________
> 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

--bcaec53ae87888960e04acc543df-- From stpeter@stpeter.im Mon Sep 12 14:37: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 1D2E121F8D53 for ; Mon, 12 Sep 2011 14:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 NUMcRvkjY5zn for ; Mon, 12 Sep 2011 14:37:20 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7D66321F8D4C for ; Mon, 12 Sep 2011 14:37:20 -0700 (PDT) Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AA106419E0; Mon, 12 Sep 2011 15:42:35 -0600 (MDT) Message-ID: <4E6E7C0B.3040201@stpeter.im> Date: Mon, 12 Sep 2011 15:39:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net><4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net><2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com><4E67AD3D.9000005@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com><4E686663.1050900@alvestrand.no><4E68CB68.3020100@alcatel-lucent.com><4E68D182.2090003@alvestrand.no><4E68D742.4010203@alcatel-lucent.com><4E68D8B5.7010602@alvestrand.no><4E6915F2.5000007@alcatel-lucent.com> <4E691CC6.9050905@stpeter.im> <2E239D6FCD033C4BAF15F386A979BF510F0A19@sonusinmail02.sonusnet.com><4E6E2B5F.7030307@stpeter.im> <4E6E3DEE.8080200@gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0AA1@sonusinmail02.sonusnet.c om> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0AA1@sonusinmail02.sonusnet.com> X-Enigmail-Version: 1.3.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP vs Websocket in RTCWeb [was RE: SIP MUST NOT be used 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, 12 Sep 2011 21:37:21 -0000 On 9/12/11 12:41 PM, Ravindran Parthasarathi wrote: > Peter, > > > I think that the protocol used for server-to-server federation > is a >> matter for the service providers and thus is not in scope for RTCWeb. > > > Sec 4.2.5 of draft-ietf-rtcweb-use-cases-and-requirements-04 includes > the usecase for federation. My assumption is based on this usecases. > Till now, there is no better protocol than SIP exists for this > discussion. > >> Some s2s links might use SIP, some might use XMPP/Jingle, etc. >> > > I agree with you that signaling interop is not focus of RTCWeb and only > one webserver is solution space then your solution looks like working. > Even then, I prefer single signaling protocol rather than ad-hoc > signaling protocol by each web developer. Using DNS SRV records, it's easy enough to figure out what protocols are supported by the peer service with which you want to federate. Peter -- Peter Saint-Andre https://stpeter.im/ From Shanmugalingam.Sivasothy@telecom-sudparis.eu Mon Sep 12 14:49: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 84EE321F8E87 for ; Mon, 12 Sep 2011 14:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fibMR7aVIU5 for ; Mon, 12 Sep 2011 14:49:04 -0700 (PDT) Received: from webmail.it-sudparis.eu (webmail.int-evry.fr [157.159.10.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5032021F8E84 for ; Mon, 12 Sep 2011 14:49:03 -0700 (PDT) Received: from webmail.it-sudparis.eu (localhost [127.0.0.1] (may be forged)) by webmail.it-sudparis.eu (8.13.8/8.13.8) with ESMTP id p8CLp7LL001447; Mon, 12 Sep 2011 23:51:07 +0200 Received: (from apache@localhost) by webmail.it-sudparis.eu (8.13.8/8.13.8/Submit) id p8CLp6gR001446; Mon, 12 Sep 2011 23:51:06 +0200 X-Authentication-Warning: webmail.it-sudparis.eu: apache set sender to Shanmugalingam.Sivasothy@telecom-sudparis.eu using -f Received: from 79.94.93.189 ([79.94.93.189]) by webmail.it-sudparis.eu (Horde Framework) with HTTP; Mon, 12 Sep 2011 23:51:06 +0200 Message-ID: <20110912235106.11944d366mqtw6o0@webmail.it-sudparis.eu> Date: Mon, 12 Sep 2011 23:51:06 +0200 From: SHANMUGALINGAM SIVASOTHY To: Peter Saint-Andre References: <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net><4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net><2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com><4E67AD3D.9000005@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com><4E686663.1050900@alvestrand.no><4E68CB68.3020100@alcatel-lucent.com><4E68D182.2090003@alvestrand.no><4E68D742.4010203@alcatel-lucent.com><4E68D8B5.7010602@alvestrand.no><4E6915F2.5000007@alcatel-lucent.com> <4E691CC6.9050905@stpeter.im> <2E239D6FCD033C4BAF15F386A979BF510F0A19@sonusinmail02.sonusnet.com><4E6E2B5F.7030307@stpeter.im> <4E6E3DEE.8080200@gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0AA1@sonusinmail02.sonusnet.c om> <4E6E7C0B.3040201@stpeter.im> In-Reply-To: <4E6E7C0B.3040201@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-Mailman-Approved-At: Mon, 12 Sep 2011 14:59:28 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] signaling protocol X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 21:58:02 -0000 Hi All! Some info on signaling protocol 1. Compositional Control of IP Media, http://www2.research.att.com/~pamela/cmc.pdf 2. Understanding SIP Through Model-Checking, http://www2.research.att.com/~pamela/under2.pdf In paper [1], she argued that new protocol is better than SIP. The comparison includes: A. Transaction vs idempotent B. Program complexity C. Media bundling Enjoy reading. Best regards Siva Quoting Peter Saint-Andre : > On 9/12/11 12:41 PM, Ravindran Parthasarathi wrote: >> Peter, >> >> > I think that the protocol used for server-to-server federation >> is a >>> matter for the service providers and thus is not in scope for RTCWeb. >> >> >> Sec 4.2.5 of draft-ietf-rtcweb-use-cases-and-requirements-04 includes >> the usecase for federation. My assumption is based on this usecases. >> Till now, there is no better protocol than SIP exists for this >> discussion. >> >>> Some s2s links might use SIP, some might use XMPP/Jingle, etc. >>> >> >> I agree with you that signaling interop is not focus of RTCWeb and only >> one webserver is solution space then your solution looks like working. >> Even then, I prefer single signaling protocol rather than ad-hoc >> signaling protocol by each web developer. > > Using DNS SRV records, it's easy enough to figure out what protocols are > supported by the peer service with which you want to federate. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From HKaplan@acmepacket.com Mon Sep 12 16:15: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 2E0E521F8EEC for ; Mon, 12 Sep 2011 16:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 aTGvuOZ8k+b0 for ; Mon, 12 Sep 2011 16:15:38 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 57AE221F8EEA for ; Mon, 12 Sep 2011 16:15:38 -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; Mon, 12 Sep 2011 19:17:35 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 12 Sep 2011 19:17:35 -0400 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] Thread-Index: AQHMcaInV9u+0Arv+EmqYITZjPuIBw== Date: Mon, 12 Sep 2011 23:17:34 +0000 Message-ID: <9F61090F-6D74-4E59-9AE7-CDE55501655F@acmepacket.com> References: <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org>, <4E6AE22A.2070106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se>, <4E6C16FF.1000706@jesup.org> <4E6E3667.1020003@alum.mit.edu> In-Reply-To: <4E6E3667.1020003@alum.mit.edu> 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: <9E848381869EC048881FFDF2E068B99F@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 12 Sep 2011 23:15:39 -0000 On Sep 12, 2011, at 12:42 PM, Paul Kyzivat wrote: > The harder point is knowing *what* is required in the interop case. > If the goal is to avoid needing a media gateway in this case, then what i= s required will be determined as part of the O/A. Or it can contractually n= egotiated for each different federation target. >=20 > Hadriel seems to be arguing that a media gateway will always be needed in= the federation case. Making that assumption will certainly simplify rtcweb= , but it also ensures a cost for federation. It is essentially the same cos= t that is incurred when sip users and service providers require the use of = SBCs at their borders. So far that has been a cost that people have willing= ly paid. I am not arguing a media gateway would always be needed for federation. I = said one would be needed to interface/federate with SIP in the PSTN. Betwe= en two rtcweb domains, no media gateway would/should be required. (there ma= y be one anyway, but hopefully not just to make the call work for interop) > Then the discussion has been about people arguing for different partition= ings - mostly extremes. Some that I am seeing: >=20 > 1) (Cullen) everything should be negotiated by o/a in the browser. > (Presumably with some interaction with JS for ICE candidate > selection.) The logical conclusion of this (I'm not sure Cullen > is arguing for this) is that capneg must be included and used > to handle the security negotiation. Only if SRTP is optional - if it's mandatory to use always, then obviously = you don't need cap-neg for it. >=20 > 2) (Hadriel?) The security mechanism, and use of ICE, > is fixed for rtcweb. ICE candidate selection and all the > rest of o/a is handled in JS. Right - if the rtcweb application as a whole needs to use SDP offer/answer = at all, it could do so in the JS or in the server. The browser should stay= the heck away from it. Browsers should be as dumb as we can keep them. T= hat's the secret sauce to successful web apps, imho - the client browser is= dumb, but the javascript its executing is smart. The browser doesn't know= I'm browsing emails in gmail. It's just executing code issuing API calls = for GUI elements. If an Operating System came with an RTP library built in= to it, would you therefor expect the operating system to do SDP offer/answe= r? Or would you expect it to expose an API of discrete RTP attributes/sett= ings for the application to interface to and do with as it wished? -hadriel From HKaplan@acmepacket.com Mon Sep 12 20:48: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 BB15A21F8AF4 for ; Mon, 12 Sep 2011 20:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 zWF9Yy4eLoc4 for ; Mon, 12 Sep 2011 20:48:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2852E21F8AF6 for ; Mon, 12 Sep 2011 20:48:08 -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; Mon, 12 Sep 2011 23:50:12 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 12 Sep 2011 23:50:11 -0400 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] Thread-Index: AQHMccg8V9u+0Arv+EmqYITZjPuIBw== Date: Tue, 13 Sep 2011 03:50:11 +0000 Message-ID: <1671A27A-F98C-447A-AFDD-41B2EEE17431@acmepacket.com> References: <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org>, <4E6AE22A.2070106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se>, <4E6C16FF.1000706@jesup.org> <4E6E3667.1020003@alum.mit.edu> <9F61090F-6D74-4E59-9AE7-CDE55501655F@acmepacket.com> In-Reply-To: <9F61090F-6D74-4E59-9AE7-CDE55501655F@acmepacket.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="us-ascii" Content-ID: <4FB644D35C80BA46BF34ACCDFC6F6BBC@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Sep 2011 03:48:13 -0000 On Sep 12, 2011, at 7:17 PM, Hadriel Kaplan wrote: >=20 > Only if SRTP is optional - if it's mandatory to use always, then obviousl= y you don't need cap-neg for it. >=20 Actually I take that back - you'll need cap-neg anyway, so that a SIP call = sent to rtcweb can use it in a best-effort manner (ie, in case a SIP peer s= ends a default m-line with RTP but with cap-neg for SRTP, so that the rtcwe= b side can process it and answer choosing SRTP). -hadriel From magnus.westerlund@ericsson.com Tue Sep 13 01:41: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 1818E21F84B3 for ; Tue, 13 Sep 2011 01:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.202 X-Spam-Level: X-Spam-Status: No, score=-106.202 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, J_CHICKENPOX_14=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 NM9Wwi-dDVXe for ; Tue, 13 Sep 2011 01:41: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 3962821F8B87 for ; Tue, 13 Sep 2011 01:41:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-08-4e6f17ac9a48 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E5.F4.02839.CA71F6E4; Tue, 13 Sep 2011 10:43:24 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 13 Sep 2011 10:43:24 +0200 Message-ID: <4E6F17AB.4000005@ericsson.com> Date: Tue, 13 Sep 2011 10:43:23 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] MediaStream Label and CNAME X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Sep 2011 08:41:22 -0000 WG, (As an individual contributor) There has been some discussion as result of the presentation of terminology in the RTCWEB Interim meeting last Thursday. The biggest question was why CNAME can't map to MediaStream label. Below we clarify why we think CNAME and label are separate entities. One part in this reasoning has to do with the current definition of media resource () and media elements of html5. The media resource could be a file, or, more relevant to this discussion, a MediaStream. In that usage only a single video track can be played simultaneously and in sync with one or more audio tracks. Thus unless we modify an existing semantics the only way of playing multiple video tracks in sync with one or more audio tracks is to have multiple MediaStream objects. We see the need for supporting multiple synchronized video tracks. We have at least two basic use cases. 1) An endpoint has two or more cameras / video grabbers that a web application wants to use. The user will select different cameras for use for different aspects in the application. Naturally the use would expect audio and video to be synced regardless of camera being viewed. 2) In the use case for centralized mixers one possible video conference RTP mixer usage is an application that takes a number of participants audio and mixes that into a single audio stream. The video streams are selected from among the available and mapped to a number of SSRCs that is the mixers. All these MediaStreams are mapped to the mixers synchronization context represented by a CNAME owned by the mixer. With the current MediaStream semantics this requires multiple objects with different combinations of media tracks to enable simultaneous playback in the browser in a synchronized fashion. We also have some more advanced use cases where having multiple MediaStreams with different but overlapping tracks makes sense. The first is a mesh application with four peers (A-D). If the application in A wants to send Audio plus Video1 to B, and Audio and Video2 to C and Audio plus both Videos to D then that would be different MediaSteam objects unless we change the semantics. We don't believe in modifying the MediaStream semantics unless really necessary. One reason is that we desire an API and behavior that doesn't make the synchronization between streams dependent on how you program things. That can easily occur if the MediaStream object is the sole method for achieving playback synchronization. Another is that MediaStream ties in nicely with the existing html5 media elements. We also see the MediaStream as good choice of representation for the JavaScript developer as it represents resources that commonly should be played together. This argument about programming things in different ways may sound abstract. But in reality it is a simple as synchronization should be possible independent if a programmer calls getUserMedia multiple times rather than trying to clone and disable tracks in a MediaStream object containing all resources of interest. In addition, not supporting synchronization between multiple MediaStreams from a single end-point makes it difficult when the number of tracks a single end-point wishes to transmit changes. This does occur for two reasons. One is that one in fact have an application where one desire to have the functionality to add additional cameras or media grabber devices. The second one is in the centralized conference cases where the central node may make changes to how it mixes or switches between media resources. Assuming no structural changes we do see a need for having all media tracks originating from one browser instance to have the same CNAME to enable sync across tracks belonging to different MediaStreams. Thus resulting in the label for a MediaStream being different from the CNAME. The CNAME is in principle a hidden property (at the API level) of a track enabling playback synchronization across multiple MediaStreams having tracks with the same CNAME. In addition we do see the need for having an optimization where a track being part of multiple MediaStreams are only sent once in PeerConnection despite belonging to multiple MediaStream associated with that PeerConnection. We do understand that there are other ways of meeting the goals that we have around tracks and their synchronization and application handles. - A track must be possible to synchronize with any other from the same sync context - The sync identifier must be common over multiple PeerConnection objects within an browser instant. - The programmer needs a logical identifier for media resources that can be transferred between the peers. - Synchronization should not be dependent on how the implementor actually write the code. If it is possible it should just happen. Given our desire to avoid redefining the semantics of MediaStream we saw that keeping the MediaStream label and the CNAME as separate identifiers is required. We have also considered the issue of how to signal the MediaStream label between the two ends of a PeerConnection. Ericsson's suggestion for how to realize this to use the a=ssrc attribute as defined in RFC 5576 carried in the SDP if SDP offer/answer semantics will be used. Otherwise we assume similar information structures can be created. A MediaStream object will have a label, e.g. "61ca6552-968a-435d-88d9-a4727f2ed515". The MediaStream will contain tracks, each track is mapped to an SSRC in a particular RTP session. In the SDP the SSRC part of the MediaStream will in its list of a=ssrc attributes contain one that reads "a=ssrc:345678123 mslabel=61ca6552-968a-435d-88d9-a4727f2ed515" In the case a particular track is part of multiple MediaStream objects the SSRC will have multiple mslabel values, one for each MediaStream label. As the CNAME is required to be included when using the a=ssrc attribute the receiving end-point will also a priori know how these tracks relate to synchronization contexts. This signaling may be a bit of a problem for legacy applications where a signaling gateway commonly will not know the legacy client's SSRC values prior to it actually sending MediaStreams. To support this use case we do suggest that any received SSRC for which explicit MediaStream indication hasn't happened is automatically assigned its own MediaStream with local generated labels. The receiving web application can combine multiple MediaStreams to a single MediaStream if necessary. As we propose the CNAME as a hidden property of the underlying track playback sync will still be possible. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From tim@phonefromhere.com Tue Sep 13 03: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 A494221F8ABB for ; Tue, 13 Sep 2011 03:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 7LwHIVFdt5d5 for ; Tue, 13 Sep 2011 03:09:45 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id F208B21F8A62 for ; Tue, 13 Sep 2011 03:09:44 -0700 (PDT) Received: from [192.168.157.49] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 9D7BE37A90C; Tue, 13 Sep 2011 11:24:31 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F09EC@sonusinmail02.sonusnet.com> Date: Tue, 13 Sep 2011 11:11:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <4E68CB68.3020100@alcatel-lucent.com> <4E68D182.2090003@alvestrand.no> <4E68D742.4010203@alcatel-lucent.com> <4E68D8B5.7010602@alvestrand.no> <4E6915F2.5000007@alcatel-lucent.com><4E691CC6.9050905@stpeter.im> <4E695648.2000001@alcatel-lucent.com> <017201cc6ef8$33f571d0$9be 05570$@c om> <2E239D6FCD033C4BAF15F386A979BF510F09EC@sonusinmail02.sonusnet.com> To: Ravindran Parthasarathi X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used 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: Tue, 13 Sep 2011 10:09:48 -0000 Minor nit - Phono isn't a javascript SIP Stack. It is a javascript XMPP = stack. The server-side gateways out to SIP etc. Tim. On 11 Sep 2011, at 21:13, Ravindran Parthasarathi wrote: > Hi Aaron, >=20 > Javascript SIP stacks (Ex: phono.com) exists already and RTCWeb1.0 is > not a gating factor for those development. My worry is that RTCWeb1.0 = is > standardized and then identify the gap in signaling which is not a = good > protocol design. It is better to discuss with signaling rather than = just > solving media protocol requirement alone. In case any implementation > deployed, the backward compatibility has to be provided till the end = of > the product and RTCWeb1.0 is a not an exception. >=20 > For the time factor concern, let us work for the quick closer and I = have > no disagreement there. But I have problem in case it is mentioned as = the > issues will not be solved to meet the WG deadline. >=20 > Thanks > Partha >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf >> Of Aaron Clauson >> Sent: Friday, September 09, 2011 7:26 PM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] SIP MUST NOT be used in browser? >>=20 >> Another 2 cents from a SIP person. >>=20 >> I think attempting to incorporate SIP (or Jingle et al) into RTCWeb >> would be >> a bad idea for the reason that it would significantly slow down and >> complicate the standard. If SIP is included in RTCWeb then there will >> need >> to be a discussion, already emerging here, about which parts of SIP = to >> include and all the other intricacies of SIP; transports, sips vs = sip, >> request routing etc etc. >>=20 >> Writing a javascript SIP stack is a small task compared to getting = the >> RTCWeb media capabilities built into browsers. As soon as the first >> browser >> appears that supports RTP then javascript SIP stacks will start = popping >> up >> all over the place. >>=20 >> I for one would love to be able to process calls in my browser and to > be >> able to do it yesterday. Slowing the RTCWeb process down for = something >> that >> will take care of itself anyway, namely readily available javascript >> signalling libraries, would be a shame. >>=20 >> Aaron >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From tim@phonefromhere.com Tue Sep 13 03:29: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 715C421F8B0D for ; Tue, 13 Sep 2011 03:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 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 uPu1OsYj+L67 for ; Tue, 13 Sep 2011 03:29:48 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 9473921F8B11 for ; Tue, 13 Sep 2011 03:29:47 -0700 (PDT) Received: from [192.168.157.49] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 8D46C37A907; Tue, 13 Sep 2011 11:44:47 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: <0FEA137C08A9DF4781EEF745038C969430A50DF699@nambx03.corp.adobe.com> Date: Tue, 13 Sep 2011 11:31:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1F0985A4-3D8A-4CD3-BB44-A2A4A2FAA8DA@phonefromhere.com> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <4E67C3EE.50707@jesup.org> <4E67F0A2.1070308@skype.net> <0FEA137C08A9DF4781EEF745038C969430A50DF699@nambx03.corp.adobe.com> To: Jozsef Vass X-Mailer: Apple Mail (2.1244.3) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Sep 2011 10:29:49 -0000 Phono does not always use Flash and when it does, it uses flash _only_ = to access the media. Phono is structured as a XMPP implementation in Javascript that handles = all the signalling to remote XMPP servers. It then has what you might think of as an Javascript = ServiceProviderInterface layer that provides the streaming of audio = from the microphone/speaker to/from an rtp endpoint. (and nothing else) Currently there are 3 (or 4) implementations of the SPI, one uses flash, = a second uses a java applet. It also has=20 plugins for phonegap on iOS and android. All except the flash = implementation speak native RTP.=20 The important point is that the SPI is the same across all these = implementations, so the XMPP layer is independent of the implementation = details of the media access .=20 I hope that clarifies things. Tim. On 12 Sep 2011, at 22:10, Jozsef Vass wrote: > Neither the website nor the documents mention the use of Flash, which = is evident if you try the app. They also make use of the acoustic echo = cancellation capability available in Flash. >=20 > Jozsef >=20 > -----Original Message----- > From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com]=20 > Sent: Wednesday, September 07, 2011 6:16 PM > To: Matthew Kaufman > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remoterecording - RTC-Web client acting as SIPREC session = recordingclient] >=20 > If implementations count for anything, check out: >=20 > http://phono.com/ > and > = https://docs.google.com/present/view?id=3D0AcNAXuadeXIxZGY4NDl4Z2RfNTlod3B= rOXNjZA&hl=3Den&pli=3D1 >=20 > They use SIP with web sockets. >=20 > Cheers, > Silvia. >=20 >=20 > On Thu, Sep 8, 2011 at 8:30 AM, Matthew Kaufman = wrote: >> On 9/7/11 12:20 PM, Randell Jesup wrote: >>>=20 >>> I also started from the same point - assume SIP. SIP gives you all=20= >>> the things that the zillions of hours and emails to define it and=20 >>> define extensions and secure it provides, without having to reinvent=20= >>> all those wheels (or ask app developers to reinvent them). Why go=20= >>> through the horrible pain of choosing something else, or why throw=20= >>> the app developers to the wolves to fend for themselves? >>>=20 >>> However... >>>=20 >>> Two things have swayed me. The primary one is the suggestion of=20 >>> Offer/Answer in the browser. This breaks out the important=20 >>> negotiation piece that almost any application would need, and while=20= >>> not perfect, SDP O/A is a zillion times simpler than SIP with all = the extensions one could use. >>=20 >> I agree with this. While I am also opposed to SDP O/A, these are two=20= >> unrelated arguments to have... and not baking a SIP phone into the=20 >> browser is *more* important than avoiding a repeat of the = offer/answer problems. >>=20 >>>=20 >>> The other thing that swayed me was thinking about federation and the=20= >>> apps that will be built with this. A webrtc app talks to its=20 >>> (web)server, other webrtc clients running the app that talk to the=20= >>> server, and to other webrtc applications/networks that federate with = it (and their clients). >>>=20 >>> Federation is in the same hands as the person who provides/wrote the = app. >>> If they have no interest in federation you can't force it, and they=20= >>> may have no use for all the fancy SIP standards. >>=20 >> And for numerous types of apps (think: server-based augmented reality=20= >> systems), "federation" doesn't even make sense. >>=20 >>>=20 >>> On the other hand, if they *want* to either provide access to the=20 >>> wider communication net that is the PSTN network, now or in the=20 >>> future, or they want easy federation with other networks, it = behooves=20 >>> them to use SIP or something very close to it or=20 >>> equivalent/convertible (at a basic level at >>> least) to it. >>>=20 >>> So what conclusions do I draw from this? >>>=20 >>> 1) O/A via SDP in the browser simplifies a lot of things (including=20= >>> handling new codecs, etc). It doesn't extremely limit an=20 >>> application, though we should think about how an application can=20 >>> interact with the fmtp/etc parameters used. >>=20 >> I agree that it would simplify some interop cases, but at an=20 >> unfortunate cost in lack of flexibility and functionality. Still not=20= >> nearly as bad as if we put a full SIP stack in there though. >>=20 >>>=20 >>> 2) SIP as a *separate* item that can be cleanly and easily *added* = to=20 >>> a webrtc app to handle the call setup/etc is a good idea. >>=20 >> I would be open to looking at this again, *after* RTC is already in=20= >> browsers and successful, to see if it actually solves a real use = case. >>=20 >> Matthew Kaufman >>=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 From oej@edvina.net Tue Sep 13 06:43: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 7087321F873A for ; Tue, 13 Sep 2011 06:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.025, 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 A+hlvtIGopCo for ; Tue, 13 Sep 2011 06:43:46 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECC321F871E for ; Tue, 13 Sep 2011 06:43:46 -0700 (PDT) Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 1BE6F754BCE4; Tue, 13 Sep 2011 13:45:44 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: Date: Tue, 13 Sep 2011 15:45:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6BC2B3B3-CF23-49BE-B116-3A767DFE5800@edvina.net> References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <4E68CB68.3020100@alcatel-lucent.com> <4E68D182.2090003@alvestrand.no> <4E68D742.4010203@alcatel-lucent.com> <4E68D8B5.7010602@alvestrand.no> <4E6915F2.5000007@alcatel-lucent.com><4E691CC6.9050905@stpeter.im> <4E695648.2000001@alcatel-lucent.com> <017201cc6ef8$33f571d0$9be 05570$@c om> <2E239D6FCD033C4BAF15F386A979BF510F09EC@sonusinmail02.sonusnet.com> To: Tim Panton X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used 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: Tue, 13 Sep 2011 13:43:50 -0000 13 sep 2011 kl. 12:11 skrev Tim Panton: > Minor nit - Phono isn't a javascript SIP Stack. It is a javascript = XMPP stack. > The server-side gateways out to SIP etc. A major thing is that you call it a minor nit. That is an important = observation for the specs. /O >=20 > Tim. > On 11 Sep 2011, at 21:13, Ravindran Parthasarathi wrote: >=20 >> Hi Aaron, >>=20 >> Javascript SIP stacks (Ex: phono.com) exists already and RTCWeb1.0 is >> not a gating factor for those development. My worry is that RTCWeb1.0 = is >> standardized and then identify the gap in signaling which is not a = good >> protocol design. It is better to discuss with signaling rather than = just >> solving media protocol requirement alone. In case any implementation >> deployed, the backward compatibility has to be provided till the end = of >> the product and RTCWeb1.0 is a not an exception. >>=20 >> For the time factor concern, let us work for the quick closer and I = have >> no disagreement there. But I have problem in case it is mentioned as = the >> issues will not be solved to meet the WG deadline. >>=20 >> Thanks >> Partha >>=20 >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf >>> Of Aaron Clauson >>> Sent: Friday, September 09, 2011 7:26 PM >>> To: rtcweb@ietf.org >>> Subject: Re: [rtcweb] SIP MUST NOT be used in browser? >>>=20 >>> Another 2 cents from a SIP person. >>>=20 >>> I think attempting to incorporate SIP (or Jingle et al) into RTCWeb >>> would be >>> a bad idea for the reason that it would significantly slow down and >>> complicate the standard. If SIP is included in RTCWeb then there = will >>> need >>> to be a discussion, already emerging here, about which parts of SIP = to >>> include and all the other intricacies of SIP; transports, sips vs = sip, >>> request routing etc etc. >>>=20 >>> Writing a javascript SIP stack is a small task compared to getting = the >>> RTCWeb media capabilities built into browsers. As soon as the first >>> browser >>> appears that supports RTP then javascript SIP stacks will start = popping >>> up >>> all over the place. >>>=20 >>> I for one would love to be able to process calls in my browser and = to >> be >>> able to do it yesterday. Slowing the RTCWeb process down for = something >>> that >>> will take care of itself anyway, namely readily available javascript >>> signalling libraries, would be a shame. >>>=20 >>> Aaron >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From harald@alvestrand.no Tue Sep 13 07:16: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 ED82E21F8B1D for ; Tue, 13 Sep 2011 07:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.159 X-Spam-Level: X-Spam-Status: No, score=-108.159 tagged_above=-999 required=5 tests=[AWL=2.440, 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 rsoQ8wfClhID for ; Tue, 13 Sep 2011 07:16:12 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDBF21F8B1E for ; Tue, 13 Sep 2011 07:16:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4995739E0AF; Tue, 13 Sep 2011 16:18:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkgIE8YAJLaJ; Tue, 13 Sep 2011 16:18:13 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 11F9C39E088; Tue, 13 Sep 2011 16:18:13 +0200 (CEST) Message-ID: <4E6F6624.3070809@alvestrand.no> Date: Tue, 13 Sep 2011 16:18:12 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Elwell, John" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Sep 2011 14:16:17 -0000 I like this text for capturing the use case. I agree with Matthew that it seems to come with some special caveats that we should consider whether we can solve before agreeing that this is an use case we MUST solve - but some of those issues may be issues we will face as a natural consequence of the API proposal anyway. I suggest that Stefan add it to the use case draft under "use cases considered", so that we have the text in the draft, with a note that the WG has not accepted this as a "must do" use case. On 09/09/11 18:41, Elwell, John wrote: > On yesterday's call it was agreed to work on text to cover the remote recording use case. Below is text, based on an earlier proposal and subsequent input. I have focused on the main requirement derived from this use case, relating to copying to a different peer connection, and skipped any more detailed requirements concerning possible mixing of the two directions of audio or injecting any tones / announcements. > > 4.2.yy Remote Session Recording > In this use case, the web application user wishes to record a real-time communication at a remote third party (e.g., a recording device), such that transmitted and received audio, video or other real-time media are transmitted in real-time to the third party. The third party can perform recording, archiving, retrieval, playback, etc., but can also perform real-time analytics on the media. A typical deployment might be in a contact centre. The web application also sends metadata that gives context to the stored media. The web application will ensure that appropriate indications are given to participants so that they are aware of recording. > > New requirements: > Fyy1: The browser MUST be able to send in real-time to a third party media that are being transmitted to and received from remote participants. > > Ayy1: The web application MUST be able to ask the browser to transmit in real-time to a third party media that are being transmitted to and received from remote participants. > > Comments? > > John > > > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ > > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. > Registered No: 5903714, England. > > Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From harald@alvestrand.no Tue Sep 13 07: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 E76FE21F8B0D for ; Tue, 13 Sep 2011 07:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.207 X-Spam-Level: X-Spam-Status: No, score=-108.207 tagged_above=-999 required=5 tests=[AWL=2.392, 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 SKapsGPh4Lvi for ; Tue, 13 Sep 2011 07:29:58 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4378D21F8804 for ; Tue, 13 Sep 2011 07:29:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 39BCA39E0AF for ; Tue, 13 Sep 2011 16:32:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFVIbEb4yTMp for ; Tue, 13 Sep 2011 16:32:03 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id BAF4839E088 for ; Tue, 13 Sep 2011 16:32:03 +0200 (CEST) Message-ID: <4E6F6963.9090702@alvestrand.no> Date: Tue, 13 Sep 2011 16:32:03 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E6F17AB.4000005@ericsson.com> In-Reply-To: <4E6F17AB.4000005@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [rtcweb] Multiple videos in one MediaStream (Re: MediaStream Label and CNAME) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Sep 2011 14:29:59 -0000 On 09/13/11 10:43, Magnus Westerlund wrote: > WG, > (As an individual contributor) > > > There has been some discussion as result of the presentation of > terminology in the RTCWEB Interim meeting last Thursday. The biggest > question was why CNAME can't map to MediaStream label. Below we > clarify why we think CNAME and label are separate entities. > > One part in this reasoning has to do with the current definition of > media resource > () and media > elements of html5. The media resource could be a file, or, more > relevant to this discussion, a MediaStream. In that usage only a single > video track can be played simultaneously and in sync with one or more > audio tracks. > > Thus unless we modify an existing semantics the only way of playing > multiple video tracks in sync with one or more audio tracks is to have > multiple MediaStream objects. Sorry, I think this can be handled with the existing API without any issue. Apologies to those who know JavaScript better than me, but this is a handler that can handle a new incoming video stream NewStreamHandler(stream) { myMultiVideoStream = stream myFirstVideo = new MediaStream(myMultiVideoStream) myFirstVideo.videoTracks.select(1) oneVideoObject.setSource(myFirstVideo.getUrl()) mySecondVideo = new MediaStream(myMultiVideoStream) mySecondVideo.videoTracks.select(2) anotherVideoObject.setSource(mySecondVideo.getUrl()) } I think the API can be improved, but the improvements are unlikely to lose this functionality. (Remember that the API objects are the control surfaces on the stream - the video data will likely go straight from the incoming buffer, through the codec for decoding, and blitted onto the screen; the "copying" from one MediaStream to another MediaStream is purely conceptual.) I don't think it makes sense to discuss the other points before getting this one put to rest. Harald From HKaplan@acmepacket.com Tue Sep 13 07:35: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 450AD21F8B0F for ; Tue, 13 Sep 2011 07:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 Ry2d-wuf40nw for ; Tue, 13 Sep 2011 07:35:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9959421F8B0C for ; Tue, 13 Sep 2011 07:35:53 -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; Tue, 13 Sep 2011 10:37:58 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 13 Sep 2011 10:37:58 -0400 From: Hadriel Kaplan To: Ravindran Parthasarathi Thread-Topic: [rtcweb] Proposed text - remote recording use case Thread-Index: AQHMciK7XwUojQUk70aUevXP868dwg== Date: Tue, 13 Sep 2011 14:37:58 +0000 Message-ID: <8357A942-21EA-4209-82DB-ADFCEB5F32EF@acmepacket.com> References: <2E239D6FCD033C4BAF15F386A979BF510F09ED@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F09ED@sonusinmail02.sonusnet.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="us-ascii" Content-ID: <4BDCDEB88FA3B5468BD2405D63AC4071@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Sep 2011 14:35:54 -0000 inline... On Sep 11, 2011, at 4:29 PM, Ravindran Parthasarathi wrote: > New requirements: > Fyy1: The browser MUST be able to send in real-time to an another > browser/session recording server(SRS) that are being transmitted to and > received from remote browser. That doesn't make sense in English - *what* needs to be sent in real-time? = Removing the word "media" broke the meaning. Also, the media it needs to = replicate/fork may not be to/from another "remote browser" - it could be to= /from a remote gateway, SIP UA, whatever. Really what you want to say is t= o/from a "remote peer". Same issues/comments go for the next requirement. >=20 > Ayy1: The web application MUST be able to ask the browser to transmit in > real-time to another browser/session recording server(SRS) that are > being transmitted to and received from remote browser. Same as above. > As I asked in the meeting (but couldn't discuss due to time constraint), > it is possible for browser to do the signaling directly to the SRS > without going through original webserver. The signaling towards > recording is not required to be SIP but it shall be websocket (let > discuss separately). Here, the advantageous in this model is that the > recording signaling hop is reduced to 1 hop (browser to SRS) from 2 > hops (browser to webserver, webserver to SRS). >=20 Actually, I don't think it is possible for the rtcweb browser to properly d= o SIPREC, even if it had a SIP stack to do it with. The reason is the brow= ser doesn't know the full call metadata. The browser doesn't know the call= ing/called party info, for example. Even the javascript itself may not kno= w it, depending on how the application provider does their logic. They cou= ld decide to have some state/logic be handled by the web server, rather tha= n all in the javascript. For example the javascript may just display a lis= t of friends using aliases or icons, and the web server may be the only one= who knows what the friend's AoR/URI actually is for that alias. =20 -hadriel From oej@edvina.net Tue Sep 13 07: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 29CC321F8487 for ; Tue, 13 Sep 2011 07:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.022, 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 R5RQh4HAdg-n for ; Tue, 13 Sep 2011 07:36:30 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id E1DE321F86EE for ; Tue, 13 Sep 2011 07:36:24 -0700 (PDT) Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id BD0ED754BCE5; Tue, 13 Sep 2011 14:38:29 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: "Olle E. Johansson" In-Reply-To: <4E6F6963.9090702@alvestrand.no> Date: Tue, 13 Sep 2011 16:38:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E6F17AB.4000005@ericsson.com> <4E6F6963.9090702@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Multiple videos in one MediaStream (Re: MediaStream Label and CNAME) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Sep 2011 14:36:31 -0000 13 sep 2011 kl. 16:32 skrev Harald Alvestrand: > On 09/13/11 10:43, Magnus Westerlund wrote: >> WG, >> (As an individual contributor) >>=20 >>=20 >> There has been some discussion as result of the presentation of >> terminology in the RTCWEB Interim meeting last Thursday. The biggest >> question was why CNAME can't map to MediaStream label. Below we >> clarify why we think CNAME and label are separate entities. >>=20 >> One part in this reasoning has to do with the current definition of >> =92media resource=92 >> () and = media >> elements of html5. The =91media resource=92 could be a file, or, more >> relevant to this discussion, a MediaStream. In that usage only a = single >> video track can be played simultaneously and in sync with one or more >> audio tracks. >>=20 >> Thus unless we modify an existing semantics the only way of playing >> multiple video tracks in sync with one or more audio tracks is to = have >> multiple MediaStream objects. > Sorry, I think this can be handled with the existing API without any = issue. > Apologies to those who know JavaScript better than me, but this is a = handler > that can handle a new incoming video stream >=20 > NewStreamHandler(stream) { > myMultiVideoStream =3D stream > myFirstVideo =3D new MediaStream(myMultiVideoStream) > myFirstVideo.videoTracks.select(1) > oneVideoObject.setSource(myFirstVideo.getUrl()) > mySecondVideo =3D new MediaStream(myMultiVideoStream) > mySecondVideo.videoTracks.select(2) > anotherVideoObject.setSource(mySecondVideo.getUrl()) > } >=20 > I think the API can be improved, but the improvements are unlikely to = lose this functionality. > (Remember that the API objects are the control surfaces on the stream = - the video data will likely go straight from the incoming buffer, = through the codec for decoding, and blitted onto the screen; the = "copying" from one MediaStream to another MediaStream is purely = conceptual.) >=20 > I don't think it makes sense to discuss the other points before = getting this one put to rest. >=20 > =20 Just to add to the stew: - For each stream (video, text, audio) you have one outbound and at = least one inbound - If we are going to support SDP and SIP, you will end up with multiple = inbound streams - one at a time or at the same time Forking may lead to multiple incoming streams for one outbound "call". = Early media may lead to one incoming stream, which may be replaced by = another endpoint at "answer time". I think one important question here is if we are going to allow this at = all. If we follow the SIP model we just have to.=20 If possible, I would like to see a restriction in rtcweb so that we push = this complexity to the server, far away from the browser. /O= From harald@alvestrand.no Tue Sep 13 07:49: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 3C84A21F8AE1 for ; Tue, 13 Sep 2011 07:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.253 X-Spam-Level: X-Spam-Status: No, score=-108.253 tagged_above=-999 required=5 tests=[AWL=2.346, 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 oQoMm3wl4ULq for ; Tue, 13 Sep 2011 07:49:17 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4E03621F8804 for ; Tue, 13 Sep 2011 07:49:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5FB6839E0AF; Tue, 13 Sep 2011 16:51:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iENffnVF9Wv5; Tue, 13 Sep 2011 16:51:20 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id BB7A639E088; Tue, 13 Sep 2011 16:51:20 +0200 (CEST) Message-ID: <4E6F6DE8.5040200@alvestrand.no> Date: Tue, 13 Sep 2011 16:51:20 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Olle E. Johansson" References: <4E6F17AB.4000005@ericsson.com> <4E6F6963.9090702@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Multiple videos in one MediaStream (Re: MediaStream Label and CNAME) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Sep 2011 14:49:18 -0000 On 09/13/11 16:38, Olle E. Johansson wrote: > 13 sep 2011 kl. 16:32 skrev Harald Alvestrand: > >> On 09/13/11 10:43, Magnus Westerlund wrote: >>> WG, >>> (As an individual contributor) >>> >>> >>> There has been some discussion as result of the presentation of >>> terminology in the RTCWEB Interim meeting last Thursday. The biggest >>> question was why CNAME can't map to MediaStream label. Below we >>> clarify why we think CNAME and label are separate entities. >>> >>> One part in this reasoning has to do with the current definition of >>> media resource >>> () and media >>> elements of html5. The media resource could be a file, or, more >>> relevant to this discussion, a MediaStream. In that usage only a single >>> video track can be played simultaneously and in sync with one or more >>> audio tracks. >>> >>> Thus unless we modify an existing semantics the only way of playing >>> multiple video tracks in sync with one or more audio tracks is to have >>> multiple MediaStream objects. >> Sorry, I think this can be handled with the existing API without any issue. >> Apologies to those who know JavaScript better than me, but this is a handler >> that can handle a new incoming video stream >> >> NewStreamHandler(stream) { >> myMultiVideoStream = stream >> myFirstVideo = new MediaStream(myMultiVideoStream) >> myFirstVideo.videoTracks.select(1) >> oneVideoObject.setSource(myFirstVideo.getUrl()) >> mySecondVideo = new MediaStream(myMultiVideoStream) >> mySecondVideo.videoTracks.select(2) >> anotherVideoObject.setSource(mySecondVideo.getUrl()) >> } >> >> I think the API can be improved, but the improvements are unlikely to lose this functionality. >> (Remember that the API objects are the control surfaces on the stream - the video data will likely go straight from the incoming buffer, through the codec for decoding, and blitted onto the screen; the "copying" from one MediaStream to another MediaStream is purely conceptual.) >> >> I don't think it makes sense to discuss the other points before getting this one put to rest. >> >> > Just to add to the stew: > > - For each stream (video, text, audio) you have one outbound and at least one inbound Nit: I'm not sure what "stream" refers to in this sentence. For the "hockey game" use case, you have 2 video media stream tracks outbound, presumably from the same PeerConnection, possibly in the same MediaStream (they're in sync), and carried over the same RTP session, too. (That one was added at least partially to make sure we'd allow multiple outbound video streams). > - If we are going to support SDP and SIP, you will end up with multiple inbound streams - one at a time or at the same time > > Forking may lead to multiple incoming streams for one outbound "call". Early media may lead to one incoming stream, which may be replaced by another endpoint at "answer time". > > I think one important question here is if we are going to allow this at all. If we follow the SIP model we just have to. > > If possible, I would like to see a restriction in rtcweb so that we push this complexity to the server, far away from the browser. My preferred place-to-end-up would be that the browser supports media streams and media stream tracks being added and removed at any time during the call, without attaching special semantics to them, and the Javascript being left to sort out whether it's "early", "conference" or "other". From oej@edvina.net Tue Sep 13 07:56: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 49CD121F8B11 for ; Tue, 13 Sep 2011 07:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.019, 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 fFrZDArPm+or for ; Tue, 13 Sep 2011 07:56:16 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 72A6621F8B0E for ; Tue, 13 Sep 2011 07:56:16 -0700 (PDT) Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id BC003754BCE4; Tue, 13 Sep 2011 14:58:18 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: "Olle E. Johansson" In-Reply-To: <4E6F6DE8.5040200@alvestrand.no> Date: Tue, 13 Sep 2011 16:58:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <62375A79-094F-41B9-8DB6-9426922A8ADF@edvina.net> References: <4E6F17AB.4000005@ericsson.com> <4E6F6963.9090702@alvestrand.no> <4E6F6DE8.5040200@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Multiple videos in one MediaStream (Re: MediaStream Label and CNAME) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Sep 2011 14:56:17 -0000 13 sep 2011 kl. 16:51 skrev Harald Alvestrand: > On 09/13/11 16:38, Olle E. Johansson wrote: >> 13 sep 2011 kl. 16:32 skrev Harald Alvestrand: >>=20 >>> On 09/13/11 10:43, Magnus Westerlund wrote: >>>> WG, >>>> (As an individual contributor) >>>>=20 >>>>=20 >>>> There has been some discussion as result of the presentation of >>>> terminology in the RTCWEB Interim meeting last Thursday. The = biggest >>>> question was why CNAME can't map to MediaStream label. Below we >>>> clarify why we think CNAME and label are separate entities. >>>>=20 >>>> One part in this reasoning has to do with the current definition of >>>> =92media resource=92 >>>> () and = media >>>> elements of html5. The =91media resource=92 could be a file, or, = more >>>> relevant to this discussion, a MediaStream. In that usage only a = single >>>> video track can be played simultaneously and in sync with one or = more >>>> audio tracks. >>>>=20 >>>> Thus unless we modify an existing semantics the only way of playing >>>> multiple video tracks in sync with one or more audio tracks is to = have >>>> multiple MediaStream objects. >>> Sorry, I think this can be handled with the existing API without any = issue. >>> Apologies to those who know JavaScript better than me, but this is a = handler >>> that can handle a new incoming video stream >>>=20 >>> NewStreamHandler(stream) { >>> myMultiVideoStream =3D stream >>> myFirstVideo =3D new MediaStream(myMultiVideoStream) >>> myFirstVideo.videoTracks.select(1) >>> oneVideoObject.setSource(myFirstVideo.getUrl()) >>> mySecondVideo =3D new MediaStream(myMultiVideoStream) >>> mySecondVideo.videoTracks.select(2) >>> anotherVideoObject.setSource(mySecondVideo.getUrl()) >>> } >>>=20 >>> I think the API can be improved, but the improvements are unlikely = to lose this functionality. >>> (Remember that the API objects are the control surfaces on the = stream - the video data will likely go straight from the incoming = buffer, through the codec for decoding, and blitted onto the screen; the = "copying" from one MediaStream to another MediaStream is purely = conceptual.) >>>=20 >>> I don't think it makes sense to discuss the other points before = getting this one put to rest. >>>=20 >>>=20 >> Just to add to the stew: >>=20 >> - For each stream (video, text, audio) you have one outbound and at = least one inbound > Nit: I'm not sure what "stream" refers to in this sentence. Sorry - RTP streams. (I'm viewing this with my old SIP eyes...) But yes, = that concept will change in rtcweb with multiplexing. >=20 > For the "hockey game" use case, you have 2 video media stream tracks = outbound, presumably from the same PeerConnection, possibly in the same = MediaStream (they're in sync), and carried over the same RTP session, = too. (That one was added at least partially to make sure we'd allow = multiple outbound video streams). >> - If we are going to support SDP and SIP, you will end up with = multiple inbound streams - one at a time or at the same time >>=20 >> Forking may lead to multiple incoming streams for one outbound = "call". Early media may lead to one incoming stream, which may be = replaced by another endpoint at "answer time". >>=20 >> I think one important question here is if we are going to allow this = at all. If we follow the SIP model we just have to. >>=20 >> If possible, I would like to see a restriction in rtcweb so that we = push this complexity to the server, far away from the browser. > My preferred place-to-end-up would be that the browser supports media = streams and media stream tracks being added and removed at any time = during the call, without attaching special semantics to them, and the = Javascript being left to sort out whether it's "early", "conference" or = "other". Ok, I use my right to change opinion. Let's totally leave the notion of = a "phone call" or "video call" behind. Thanks for the feedback :-) /O= From HKaplan@acmepacket.com Tue Sep 13 09:13: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 9391621F8CA0 for ; Tue, 13 Sep 2011 09:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 zfXYn44DwBfu for ; Tue, 13 Sep 2011 09:13:37 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7A14B21F8C91 for ; Tue, 13 Sep 2011 09:13:37 -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; Tue, 13 Sep 2011 12:15:36 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 13 Sep 2011 12:15:36 -0400 From: Hadriel Kaplan To: Harald Alvestrand , John Elwell Thread-Topic: [rtcweb] Proposed text - remote recording use case Thread-Index: AQHMcjBe44ynxue6Dkeiz3Tz6NhmfQ== Date: Tue, 13 Sep 2011 16:15:35 +0000 Message-ID: <085A341A-9B3D-4DC8-8685-CD9DF811E102@acmepacket.com> References: <4E6F6624.3070809@alvestrand.no> In-Reply-To: <4E6F6624.3070809@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Sep 2011 16:13:38 -0000 Actually, I think remote recording may already be possible without anything= new. Draft-ietf-rtcweb-use-cases-and-requirements-04 has a use-case 4.2.7 for "M= ultiparty video communication", and associated requirements. All you need = for remote recording is the ability for the javascript to create a separate= media stream to the recorder (SRS), as if the SRS were a third participant= , and fork the user's audio/video into both streams. The 4.2.7 requirement= implies that will be possible. What's not handled by that is replicating the received audio/video from the= peer into the recording stream to the SRS - i.e., the browser will be able= to fork the locally generated media, but not the media received from the p= eer. For sessions between two rtcweb browsers controlled by the same provi= der this could still work, since both rtcweb browsers could be told to crea= te streams to the SRS for both halves of media to be recorded. For calls to= /from another domain, if one uses SIP between the servers then one could do= real SIPREC in a logical SIP B2BUA there. -hadriel p.s. the ability for rtcweb browsers to create conf calls by doing half-mix= ing and using a full mesh of media streams is not normal for SIP, and may b= e rather tricky to get to work right if the participants are not in the sam= e domain and SIP has to be used between. Was the intention that such inter= -domain cases would require a centralized conf server instead of direct med= ia meshing? On Sep 13, 2011, at 10:18 AM, Harald Alvestrand wrote: > I like this text for capturing the use case. >=20 > I agree with Matthew that it seems to come with some special caveats that= we should consider whether we can solve before agreeing that this is an us= e case we MUST solve - but some of those issues may be issues we will face = as a natural consequence of the API proposal anyway. >=20 > I suggest that Stefan add it to the use case draft under "use cases consi= dered", so that we have the text in the draft, with a note that the WG has = not accepted this as a "must do" use case. >=20 > On 09/09/11 18:41, Elwell, John wrote: >> On yesterday's call it was agreed to work on text to cover the remote re= cording use case. Below is text, based on an earlier proposal and subsequen= t input. I have focused on the main requirement derived from this use case,= relating to copying to a different peer connection, and skipped any more d= etailed requirements concerning possible mixing of the two directions of au= dio or injecting any tones / announcements. >>=20 >> 4.2.yy Remote Session Recording >> In this use case, the web application user wishes to record a real-time = communication at a remote third party (e.g., a recording device), such that= transmitted and received audio, video or other real-time media are transmi= tted in real-time to the third party. The third party can perform recording= , archiving, retrieval, playback, etc., but can also perform real-time anal= ytics on the media. A typical deployment might be in a contact centre. The = web application also sends metadata that gives context to the stored media.= The web application will ensure that appropriate indications are given to = participants so that they are aware of recording. >>=20 >> New requirements: >> Fyy1: The browser MUST be able to send in real-time to a third party med= ia that are being transmitted to and received from remote participants. >>=20 >> Ayy1: The web application MUST be able to ask the browser to transmit in= real-time to a third party media that are being transmitted to and receive= d from remote participants. >>=20 >> Comments? >>=20 >> John >>=20 >>=20 >> John Elwell >> Tel: +44 1908 817801 (office and mobile) >> Email: john.elwell@siemens-enterprise.com >> http://www.siemens-enterprise.com/uk/ >>=20 >> Siemens Enterprise Communications Limited. >> Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0D= J. >> Registered No: 5903714, England. >>=20 >> Siemens Enterprise Communications Limited is a Trademark Licensee of Sie= mens AG. >>=20 >>=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 From pravindran@sonusnet.com Tue Sep 13 09:43: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 94FE611E8096 for ; Tue, 13 Sep 2011 09:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 aFfbIWnINpx4 for ; Tue, 13 Sep 2011 09:43:38 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9E51411E8094 for ; Tue, 13 Sep 2011 09:43:38 -0700 (PDT) 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 p8DGk7Ur021430; Tue, 13 Sep 2011 12:46:07 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Sep 2011 12:45:00 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Sep 2011 22:14:53 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0B34@sonusinmail02.sonusnet.com> In-Reply-To: <6BC2B3B3-CF23-49BE-B116-3A767DFE5800@edvina.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SIP MUST NOT be used in browser? Thread-Index: AcxyG3OY5c/CPrTVThO2P2Tf5K+9wgAGHO9Q References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <4E68CB68.3020100@alcatel-lucent.com> <4E68D182.2090003@alvestrand.no> <4E68D742.4010203@alcatel-lucent.com> <4E68D8B5.7010602@alvestrand.no> <4E6915F2.5000007@alcatel-lucent.com><4E691CC6.9050905@stpeter.im> <4E695648.2000001@alcatel-lucent.com> <017201cc6ef8$33f571d0$9be 05570$ @c om> <2E23 9D6FCD033C4BAF15F386A979BF510F09EC@sonusinmail02.sonusnet.com> <6BC2B3B3-CF23-49BE-B116-3A767DFE5800@edvina.net> From: "Ravindran Parthasarathi" To: "Olle E. Johansson" , "Tim Panton" X-OriginalArrivalTime: 13 Sep 2011 16:45:00.0316 (UTC) FILETIME=[7A5505C0:01CC7234] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used 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: Tue, 13 Sep 2011 16:43:39 -0000 Tim, Thanks for pointing it out and my example is wrong.=20 My point is that RTCWeb1.0 deliverables is not a gating factor for Javascript based SIP Stack or other signaling protocol using Javascript. Also, RTCWeb signaling protocol selection is important for interop.=20 Thanks Partha >-----Original Message----- >From: Olle E. Johansson [mailto:oej@edvina.net] >Sent: Tuesday, September 13, 2011 7:16 PM >To: Tim Panton >Cc: Ravindran Parthasarathi; rtcweb@ietf.org >Subject: Re: [rtcweb] SIP MUST NOT be used in browser? > > >13 sep 2011 kl. 12:11 skrev Tim Panton: > >> Minor nit - Phono isn't a javascript SIP Stack. It is a javascript >XMPP stack. >> The server-side gateways out to SIP etc. > >A major thing is that you call it a minor nit. That is an important >observation for the specs. > >/O >> >> Tim. >> On 11 Sep 2011, at 21:13, Ravindran Parthasarathi wrote: >> >>> Hi Aaron, >>> >>> Javascript SIP stacks (Ex: phono.com) exists already and RTCWeb1.0 is >>> not a gating factor for those development. My worry is that RTCWeb1.0 >is >>> standardized and then identify the gap in signaling which is not a >good >>> protocol design. It is better to discuss with signaling rather than >just >>> solving media protocol requirement alone. In case any implementation >>> deployed, the backward compatibility has to be provided till the end >of >>> the product and RTCWeb1.0 is a not an exception. >>> >>> For the time factor concern, let us work for the quick closer and I >have >>> no disagreement there. But I have problem in case it is mentioned as >the >>> issues will not be solved to meet the WG deadline. >>> >>> Thanks >>> Partha >>> >>>> -----Original Message----- >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>> Behalf >>>> Of Aaron Clauson >>>> Sent: Friday, September 09, 2011 7:26 PM >>>> To: rtcweb@ietf.org >>>> Subject: Re: [rtcweb] SIP MUST NOT be used in browser? >>>> >>>> Another 2 cents from a SIP person. >>>> >>>> I think attempting to incorporate SIP (or Jingle et al) into RTCWeb >>>> would be >>>> a bad idea for the reason that it would significantly slow down and >>>> complicate the standard. If SIP is included in RTCWeb then there >will >>>> need >>>> to be a discussion, already emerging here, about which parts of SIP >to >>>> include and all the other intricacies of SIP; transports, sips vs >sip, >>>> request routing etc etc. >>>> >>>> Writing a javascript SIP stack is a small task compared to getting >the >>>> RTCWeb media capabilities built into browsers. As soon as the first >>>> browser >>>> appears that supports RTP then javascript SIP stacks will start >popping >>>> up >>>> all over the place. >>>> >>>> I for one would love to be able to process calls in my browser and >to >>> be >>>> able to do it yesterday. Slowing the RTCWeb process down for >something >>>> that >>>> will take care of itself anyway, namely readily available javascript >>>> signalling libraries, would be a shame. >>>> >>>> Aaron >>>> >>>> _______________________________________________ >>>> 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 > >--- >* Olle E Johansson - oej@edvina.net >* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden > > From ibc@aliax.net Tue Sep 13 10:11: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 19DF521F8C53 for ; Tue, 13 Sep 2011 10:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 aWSfA3D20N+u for ; Tue, 13 Sep 2011 10:11:06 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 83A7E21F8BEF for ; Tue, 13 Sep 2011 10:11:06 -0700 (PDT) Received: by qyk32 with SMTP id 32so2890485qyk.10 for ; Tue, 13 Sep 2011 10:13:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.166 with SMTP id r38mr1337189qci.254.1315933992849; Tue, 13 Sep 2011 10:13:12 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Tue, 13 Sep 2011 10:13:12 -0700 (PDT) Date: Tue, 13 Sep 2011 19:13:12 +0200 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] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Tue, 13 Sep 2011 17:11:07 -0000 Hi all, A draft describing a mechanism for usage of WebSocket protocol as the transport between SIP entities has been submitted and can be found at: HTML: http://tools.ietf.org/html/draft-ibc-rtcweb-sip-websocket-00 TXT: http://www.ietf.org/id/draft-ibc-rtcweb-sip-websocket-00.txt Abstract This document specifies a WebSocket subprotocol for a new transport in SIP (Session Initiation Protocol). The WebSocket protocol enables two-way realtime communication between clients (typically web-based applications) and servers. The main goal of this specification is to integrate the SIP protocol within web applications. We produced this initial version after implementing a working prototype. Your feedback is always welcome, The Authors --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Tue Sep 13 10:41: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 A15B621F8B82 for ; Tue, 13 Sep 2011 10:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=-0.043, 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 pM5rBXXzxH6W for ; Tue, 13 Sep 2011 10:41:50 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id DB56421F8B81 for ; Tue, 13 Sep 2011 10:41:49 -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 p8DHiPjH026874; Tue, 13 Sep 2011 13:44:25 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Sep 2011 13:43:00 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 13 Sep 2011 23:12:54 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP) Thread-Index: AcxyOG/sBOMj88yzRPmZLZBdgHCRKAAAxkxQ References: From: "Ravindran Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , X-OriginalArrivalTime: 13 Sep 2011 17:43:00.0849 (UTC) FILETIME=[94E43610:01CC723C] Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Tue, 13 Sep 2011 17:41:50 -0000 SGkgSW5ha2ksDQoNCkkgbGlrZSB0aGUgaWRlYSBvZiB1c2luZyBTSVAgYmV0d2VlbiBicm93c2Vy ICYgc2VydmVyLiANCg0KSSByZWFsbHkgZG9uJ3Qga25vdyB0aGUgc3Ryb25nIHJlYXNvbiBmb3Ig dHVubmVsaW5nIFNJUCBtZXNzYWdlIHdpdGhpbiB3ZWJzb2NrZXQuIEluIGZhY3QsIHdlIGFyZSBk aXNjdXNzaW5nIFNJUCB2cyB3ZWJzb2NrZXQgaW4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50L21zZzAxMDcxLmh0bWwgbWFpbCB0aHJlYWQgYXMgc2ln bmFsaW5nIHByb3RvY29sIGZvciBSVEN3ZWIuIENvdWxkIHlvdSBwbGVhc2UgbWVudGlvbiB0aGUg dGVjaG5pY2FsIGFkdmFudGFnZSBpbiBnb2luZyBpbiB0aGUgcGF0aCBvZiBTSVAgb3ZlciB3ZWJz b2NrZXQgcmF0aGVyIHRoYW4gaGF2aW5nIHBsYWluIFNJUCBjb25uZWN0aW9uIG92ZXIgVENQIG9y IFRMUyBvciAoVURQIG9yIERUTFMpLg0KDQpUaGFua3MNClBhcnRoYQ0KIA0KPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpy dGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+T2YgScOxYWtpIEJheiBDYXN0aWxs bw0KPlNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAxMywgMjAxMSAxMDo0MyBQTQ0KPlRvOiBydGN3 ZWJAaWV0Zi5vcmcNCj5TdWJqZWN0OiBbcnRjd2ViXSBkcmFmdC1pYmMtcnRjd2ViLXNpcC13ZWJz b2NrZXQgLS0gV2ViU29ja2V0IFRyYW5zcG9ydA0KPmZvciBTZXNzaW9uIEluaXRpYXRpb24gUHJv dG9jb2wgKFNJUCkNCj4NCj5IaSBhbGwsDQo+DQo+QSBkcmFmdCBkZXNjcmliaW5nIGEgbWVjaGFu aXNtIGZvciB1c2FnZSBvZiBXZWJTb2NrZXQgcHJvdG9jb2wgYXMgdGhlDQo+dHJhbnNwb3J0IGJl dHdlZW4gU0lQIGVudGl0aWVzIGhhcyBiZWVuIHN1Ym1pdHRlZCBhbmQgY2FuIGJlIGZvdW5kIGF0 Og0KPg0KPiAgSFRNTDogIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWliYy1ydGN3 ZWItc2lwLXdlYnNvY2tldC0wMA0KPiAgVFhUOiAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9k cmFmdC1pYmMtcnRjd2ViLXNpcC13ZWJzb2NrZXQtMDAudHh0DQo+DQo+DQo+QWJzdHJhY3QNCj4N Cj4gICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIFdlYlNvY2tldCBzdWJwcm90b2NvbCBmb3Ig YSBuZXcgdHJhbnNwb3J0DQo+ICAgaW4gU0lQIChTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wp LiAgVGhlIFdlYlNvY2tldCBwcm90b2NvbCBlbmFibGVzDQo+ICAgdHdvLXdheSByZWFsdGltZSBj b21tdW5pY2F0aW9uIGJldHdlZW4gY2xpZW50cyAodHlwaWNhbGx5IHdlYi1iYXNlZA0KPiAgIGFw cGxpY2F0aW9ucykgYW5kIHNlcnZlcnMuICBUaGUgbWFpbiBnb2FsIG9mIHRoaXMgc3BlY2lmaWNh dGlvbiBpcyB0bw0KPiAgIGludGVncmF0ZSB0aGUgU0lQIHByb3RvY29sIHdpdGhpbiB3ZWIgYXBw bGljYXRpb25zLg0KPg0KPg0KPldlIHByb2R1Y2VkIHRoaXMgaW5pdGlhbCB2ZXJzaW9uIGFmdGVy IGltcGxlbWVudGluZyBhIHdvcmtpbmcgcHJvdG90eXBlLg0KPg0KPg0KPllvdXIgZmVlZGJhY2sg aXMgYWx3YXlzIHdlbGNvbWUsDQo+VGhlIEF1dGhvcnMNCj4NCj4NCj4tLQ0KPknDsWFraSBCYXog Q2FzdGlsbG8NCj48aWJjQGFsaWF4Lm5ldD4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj5ydGN3ZWJAaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K From roman@telurix.com Tue Sep 13 10:58: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 72B1911E80B0 for ; Tue, 13 Sep 2011 10:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPcbdB63xdK2 for ; Tue, 13 Sep 2011 10:58:23 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 930FF11E80AD for ; Tue, 13 Sep 2011 10:58:23 -0700 (PDT) Received: by yie12 with SMTP id 12so771815yie.31 for ; Tue, 13 Sep 2011 11:00:30 -0700 (PDT) Received: by 10.236.154.135 with SMTP id h7mr19041118yhk.82.1315936829574; Tue, 13 Sep 2011 11:00:29 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by mx.google.com with ESMTPS id c62sm2365690yhj.25.2011.09.13.11.00.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Sep 2011 11:00:28 -0700 (PDT) Received: by gwb20 with SMTP id 20so802050gwb.31 for ; Tue, 13 Sep 2011 11:00:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.52.106 with SMTP id s10mr305257pbo.40.1315936827537; Tue, 13 Sep 2011 11:00:27 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 13 Sep 2011 11:00:27 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com> Date: Tue, 13 Sep 2011 14:00:27 -0400 Message-ID: From: Roman Shpount To: Ravindran Parthasarathi Content-Type: multipart/alternative; boundary=bcaec543081a26fb6a04acd66b93 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Tue, 13 Sep 2011 17:58:24 -0000 --bcaec543081a26fb6a04acd66b93 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Partha, I am not sure if you understood this from my emails before, but the main advantage is that SIP does not work from behind NAT if TCP or TLS is used. SIP is not intended for this and does not support this. You can try to buil= d something which is somewhat standard to implement SIP over TCP (TLS) from behind NAT, but I do not think this is widely implemented at all. _____________ Roman Shpount On Tue, Sep 13, 2011 at 1:42 PM, Ravindran Parthasarathi < pravindran@sonusnet.com> wrote: > Hi Inaki, > > I like the idea of using SIP between browser & server. > > I really don't know the strong reason for tunneling SIP message within > websocket. In fact, we are discussing SIP vs websocket in > http://www.ietf.org/mail-archive/web/rtcweb/current/msg01071.html mail > thread as signaling protocol for RTCweb. Could you please mention the > technical advantage in going in the path of SIP over websocket rather tha= n > having plain SIP connection over TCP or TLS or (UDP or DTLS). > > Thanks > Partha > > >-----Original Message----- > >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > >Of I=F1aki Baz Castillo > >Sent: Tuesday, September 13, 2011 10:43 PM > >To: rtcweb@ietf.org > >Subject: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport > >for Session Initiation Protocol (SIP) > > > >Hi all, > > > >A draft describing a mechanism for usage of WebSocket protocol as the > >transport between SIP entities has been submitted and can be found at: > > > > HTML: http://tools.ietf.org/html/draft-ibc-rtcweb-sip-websocket-00 > > TXT: http://www.ietf.org/id/draft-ibc-rtcweb-sip-websocket-00.txt > > > > > >Abstract > > > > This document specifies a WebSocket subprotocol for a new transport > > in SIP (Session Initiation Protocol). The WebSocket protocol enables > > two-way realtime communication between clients (typically web-based > > applications) and servers. The main goal of this specification is to > > integrate the SIP protocol within web applications. > > > > > >We produced this initial version after implementing a working prototype. > > > > > >Your feedback is always welcome, > >The Authors > > > > > >-- > >I=F1aki Baz Castillo > > > >_______________________________________________ > >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 > --bcaec543081a26fb6a04acd66b93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Partha,

I am not sure if you understood this from my emails before, = but the main advantage is that SIP does not work from behind NAT if TCP or = TLS is used. SIP is not intended for this and does not support this. You ca= n try to build something which is somewhat standard to implement SIP over T= CP (TLS) from behind NAT, but I do not think this is widely implemented at = all.
_____________
Roman Shpount


On Tue, Sep 13, 2011 at 1:42 PM, Ravindr= an Parthasarathi <pravindran@sonusnet.com> wrote:
Hi Inaki,

I like the idea of using SIP between browser & server.

I really don't know the strong reason for tunneling SIP message within = websocket. In fact, we are discussing SIP vs websocket in http://www.ietf.org/mail-archive/web/rtcweb/current/msg01071.html m= ail thread as signaling protocol for RTCweb. Could you please mention the t= echnical advantage in going in the path of SIP over websocket rather than h= aving plain SIP connection over TCP or TLS or (UDP or DTLS).

Thanks
Partha

>-----Original Message-----
>From: rtcweb-bounces@ietf.or= g [mailto:rtcweb-bounces@iet= f.org] On Behalf
>Of I=F1aki Baz Castillo
>Sent: Tuesday, September 13, 2011 10:43 PM
>To: rtcweb@ietf.org
>Subject: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport=
>for Session Initiation Protocol (SIP)
>
>Hi all,
>
>A draft describing a mechanism for usage of WebSocket protocol as the >transport between SIP entities has been submitted and can be found at:<= br> >
> =A0HTML: =A0http://tools.ietf.org/html/draft-ibc-rtcwe= b-sip-websocket-00
> =A0TXT: =A0 =A0 http://www.ietf.org/id/draft-ibc-rtcwe= b-sip-websocket-00.txt
>
>
>Abstract
>
> =A0 This document specifies a WebSocket subprotocol for a new transpor= t
> =A0 in SIP (Session Initiation Protocol). =A0The WebSocket protocol en= ables
> =A0 two-way realtime communication between clients (typically web-base= d
> =A0 applications) and servers. =A0The main goal of this specification = is to
> =A0 integrate the SIP protocol within web applications.
>
>
>We produced this initial version after implementing a working prototype= .
>
>
>Your feedback is always welcome,
>The Authors
>
>
>--
>I=F1aki Baz Castillo
><ibc@aliax.net>
>_______________________________________________
>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

--bcaec543081a26fb6a04acd66b93-- From ibc@aliax.net Tue Sep 13 11:20: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 1A03721F8C60 for ; Tue, 13 Sep 2011 11:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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+fbLrDqh-5O for ; Tue, 13 Sep 2011 11:20:42 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id F2C7A11E808E for ; Tue, 13 Sep 2011 11:20:41 -0700 (PDT) Received: by qyk32 with SMTP id 32so2958164qyk.10 for ; Tue, 13 Sep 2011 11:22:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.105 with SMTP id q41mr2150039qci.216.1315938167568; Tue, 13 Sep 2011 11:22:47 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Tue, 13 Sep 2011 11:22:47 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com> Date: Tue, 13 Sep 2011 20:22:47 +0200 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] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Tue, 13 Sep 2011 18:20:43 -0000 2011/9/13 Ravindran Parthasarathi : > Hi Inaki, > > I like the idea of using SIP between browser & server. > > I really don't know the strong reason for tunneling SIP message within we= bsocket. In fact, we are discussing SIP vs websocket in http://www.ietf.org= /mail-archive/web/rtcweb/current/msg01071.html mail thread as signaling pro= tocol for RTCweb. Could you please mention the technical advantage in going= in the path of SIP over websocket rather than having plain SIP connection = over TCP or TLS or (UDP or DTLS). Hi Ravindran, SIP is a complex protocol and there are numerous extensions and features in many RFC's extending the SIP protocol. Having to rely on the features implemented in a native SIP stack within the web-browser seems not enough flexible IMHO. I also expect many limitations and lack-of-features in the different SIP implementations of each browser (and each version of the browser). In the other side, if the SIP stack is coded within a JavaScript library and makes usage of the WebSocket protocol, innovation depends on the developer and not on the browser native capabilities. A web page could offer a minimal SIP stack just implementing basic outgoing calls (i.e. "Click2Call" buttons in the web), while another web page could prefer to provide a powerful SIP stack implementing blink/attended transfer, subscription to presence and dialogs/calls, conference features, call-pickup, SIP messaging and so on (imagine such phone integrated within an enterprise intranet). I don't expect that the SIP stack integrated within *every* existing web-browsers would implement all those SIP features in a correct way (because that does not happen neither when using expensive SIP desktop phones or softphones). Also, the specification defined in the draft solves NAT issues (at signaling level) without requiring server side solutions for fixing NAT in clients. WebSocket protocol is becoming a new "transport" protocol. Implementing SIP protocol on top of it can only bring advantages and new possibilities. The specification in the draft is an adaptation of SIP to make use of WebSocket, as it already does with UDP, TCP and SCTP transports. BTW, as said in the first mail, we have published the draft after having a working prototype making usage of the specification described in the document. After that, we see no real advantage on having a native SIP stack within a web browser. The prototype will be shown soon. Best regards. --=20 I=C3=B1aki Baz Castillo From igor.faynberg@alcatel-lucent.com Tue Sep 13 11:27: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 AA92721F8C60 for ; Tue, 13 Sep 2011 11:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.603 X-Spam-Level: X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 1B6dI6EiT8Oi for ; Tue, 13 Sep 2011 11:27:04 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id E3CA721F8C5F for ; Tue, 13 Sep 2011 11:27:03 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p8DIT9t8012727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Sep 2011 13:29:10 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8DIT8oX022176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 13 Sep 2011 13:29:09 -0500 Received: from [135.244.37.245] (faynberg.lra.lucent.com [135.244.37.245]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p8DIT8IL007400; Tue, 13 Sep 2011 13:29:08 -0500 (CDT) Message-ID: <4E6FA0F3.3000902@alcatel-lucent.com> Date: Tue, 13 Sep 2011 14:29:07 -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: <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP) 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, 13 Sep 2011 18:27:04 -0000 SIP (unlike HTTP) is symmetric in that a SIP client can get, asynchronously, messages from another client (e.g., INVITE) or a server (e.g., NOTIFY). Websocket provides a capapility to recieve messages out of the blue. On 9/13/2011 1:42 PM, Ravindran Parthasarathi wrote: > ... > > I really don't know the strong reason for tunneling SIP message within websocket. ... From Markus.Isomaki@nokia.com Tue Sep 13 12:05: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 D470011E80B5 for ; Tue, 13 Sep 2011 12:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 dz+w96rVi7WS for ; Tue, 13 Sep 2011 12:05:56 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3126211E80A2 for ; Tue, 13 Sep 2011 12:05:56 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8DJ7sYv018142; Tue, 13 Sep 2011 22:07:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Sep 2011 22:07:58 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 13 Sep 2011 21:07:57 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.204]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0323.007; Tue, 13 Sep 2011 21:07:57 +0200 From: To: , , Thread-Topic: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP) Thread-Index: AQHMcjy6M4YFVMesM06AtPnj5jvFc5VLqPbw Date: Tue, 13 Sep 2011 19:07:56 +0000 Message-ID: References: <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 13 Sep 2011 19:07:58.0240 (UTC) FILETIME=[732C5A00:01CC7248] X-Nokia-AV: Clean Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Tue, 13 Sep 2011 19:05:57 -0000 SGksDQoNClJhdmluZHJhbiBQYXJ0aGFzYXJhdGhpIHdyb3RlOg0KPg0KPkkgcmVhbGx5IGRvbid0 IGtub3cgdGhlIHN0cm9uZyByZWFzb24gZm9yIHR1bm5lbGluZyBTSVAgbWVzc2FnZSB3aXRoaW4N Cj53ZWJzb2NrZXQuIEluIGZhY3QsIHdlIGFyZSBkaXNjdXNzaW5nIFNJUCB2cyB3ZWJzb2NrZXQg aW4NCj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQv bXNnMDEwNzEuaHRtbCBtYWlsDQo+dGhyZWFkIGFzIHNpZ25hbGluZyBwcm90b2NvbCBmb3IgUlRD d2ViLiBDb3VsZCB5b3UgcGxlYXNlIG1lbnRpb24gdGhlDQo+dGVjaG5pY2FsIGFkdmFudGFnZSBp biBnb2luZyBpbiB0aGUgcGF0aCBvZiBTSVAgb3ZlciB3ZWJzb2NrZXQgcmF0aGVyIHRoYW4NCj5o YXZpbmcgcGxhaW4gU0lQIGNvbm5lY3Rpb24gb3ZlciBUQ1Agb3IgVExTIG9yIChVRFAgb3IgRFRM UykuDQo+DQoNCklmIFNJUCBpcyBpbXBsZW1lbnRlZCBpbiBKYXZhc2NyaXB0LCBhcyBvcHBvc2Vk IHRvICJuYXRpdmVseSIgc3VwcG9ydGVkIGluIHRoZSBicm93c2VyLCBXZWJzb2NrZXQgaXMgdGhl IGJlc3QgdHJhbnNwb3J0IGZvciBpdC4NCg0KSSBjb3VsZCBzZWUgYSBwYXRoIGhlcmUgdGhhdCB0 aGUgU0lQIHNlcnZlciB2ZW5kb3JzIHNob3VsZCBhZGQgU0lQIG92ZXIgV2ViU29ja2V0cyBpbiB0 aGVpciBhcnNlbmFsIG9mIHRyYW5zcG9ydCBvcHRpb25zLCBhbmQgdGhpcyB3YXkgdGhvc2Ugc2Vy dmVycyBjb3VsZCBiZWNvbWUgZWFzaWx5IHVzYWJsZSBieSBXZWJSVEMgcHJvdmlkZXJzLiBBcyBh IGNvdW50ZXJwYXJ0IHdlIHdvdWxkIG5lZWQgYSBnb29kIG9wZW4gc291cmNlIEphdmFzY3JpcHQg U0lQIGxpYnJhcnksIHdpdGggdGhlIFdlYlNvY2tldCBzdXBwb3J0LiBBbmQgdGhlbiwgd291bGRu J3Qgd2UgaGF2ZSBhY2hpZXZlZCB3aGF0IGV2ZXJ5b25lIHdhbnRzPyBXZSBoYXZlIG1hbmFnZWQg dG8ga2VlcCBTSVAgb3V0IG9mIHRoZSBicm93c2VyLCBhcyBzb21lIHBlb3BsZSBsaWtlLiBZZXQg d2UgaGF2ZSBlbmFibGVkIFdlYlJUQyBwcm92aWRlcnMgYW5kIGFwcCBkZXZlbG9wZXJzIHRvIHVz ZSBTSVAsIGFzIHNvbWUgb3RoZXIgcGVvcGxlIHByZWZlci4gQW5kIGZpbmFsbHksIFNJUCBpbmZy YSB2ZW5kb3JzIGNhbiBjb250aW51ZSBzZWxsaW5nIHRoZWlyIGdlYXIsIFdlYlJUQyBjb21wbGlh bnQgOi0pIA0KDQpTbyBtYXliZSB0aGlzIGRyYWZ0IGlzIHNvbWV0aGluZyB0aGF0IHNob3VsZCBi ZSB0YWtlbiB0byBTdGFuZGFyZHMgVHJhY2sgd2l0aGluIHRoZSBSQUkgYXJlYSwgQVNBUC4NCg0K TWFya3VzICANCg== From matthew.kaufman@skype.net Tue Sep 13 12:12: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 C6D7621F8B5F for ; Tue, 13 Sep 2011 12:12:38 -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 ZhrhGklpYG9H for ; Tue, 13 Sep 2011 12:12:38 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 0183B21F8B5E for ; Tue, 13 Sep 2011 12:12:37 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id DF1A07FD; Tue, 13 Sep 2011 21:14:43 +0200 (CEST) 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=p/B4BALPEVg41F MtjoLDFcS4G/c=; b=Nzo03FnkdEDXeQ1ah6lMRsD3k3LFpX2z3+0X8Qsg8xuVGa 3sVFFAoqgO/n53bpYAHXoOQGoxulE+zeqXbfJVCPEv4OoLAst56/gmUv3CCfwpYL qq7xnjsjFVHjZZZ5sliJ95WhT/O+bzYyQdCo7+v+QDFIQcbjO++nUPVMF5ecE= 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=r1TP/840+MpJv5IrlllzWq 3uRzzFAMbkDd7ezZupCi83Nxrp9CIAwEEfrbjmPdvea6tvvtXGrctWvHUyTW8jGS ShPXKhJVIzn4UxY+/xXWlHxysedIY5JyV4t3Kc+HBvo7yMb/5E4yK31QMfPGHaxC PCF0ZhG8DDNTbNTzggwEY= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id DCA747F6; Tue, 13 Sep 2011 21:14:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id B411B3507072; Tue, 13 Sep 2011 21:14:43 +0200 (CEST) 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 buDRtu6LWQ6h; Tue, 13 Sep 2011 21:14:43 +0200 (CEST) Received: from Matthew-Kaufman-Air.local (gw2.rival.se [83.241.158.140]) by zimbra.skype.net (Postfix) with ESMTPSA id A0CBF3506DB5; Tue, 13 Sep 2011 21:14:42 +0200 (CEST) Message-ID: <4E6FABA2.10506@skype.net> Date: Tue, 13 Sep 2011 21:14:42 +0200 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E6F6624.3070809@alvestrand.no> <085A341A-9B3D-4DC8-8685-CD9DF811E102@acmepacket.com> In-Reply-To: <085A341A-9B3D-4DC8-8685-CD9DF811E102@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Sep 2011 19:12:40 -0000 On 9/13/11 6:15 PM, Hadriel Kaplan wrote: > Actually, I think remote recording may already be possible without anything new. > > Draft-ietf-rtcweb-use-cases-and-requirements-04 has a use-case 4.2.7 for "Multiparty video communication", and associated requirements. All you need for remote recording is the ability for the javascript to create a separate media stream to the recorder (SRS), as if the SRS were a third participant, and fork the user's audio/video into both streams. The 4.2.7 requirement implies that will be possible. Correct. > > What's not handled by that is replicating the received audio/video from the peer into the recording stream to the SRS - i.e., the browser will be able to fork the locally generated media, but not the media received from the peer. And I believe that enabling browsers to do that would be a very bad idea. That is specifically why the requirement for recording should be careful to explain the difference between these two and why one might be acceptable while the other not. Matthew Kaufman From Markus.Isomaki@nokia.com Tue Sep 13 12:23: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 6A8F611E80DA for ; Tue, 13 Sep 2011 12:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 dCI83qECEPVr for ; Tue, 13 Sep 2011 12:23:00 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF3311E80BF for ; Tue, 13 Sep 2011 12:23:00 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8DJP4Pl013949; Tue, 13 Sep 2011 22:25:04 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Sep 2011 22:25:03 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 13 Sep 2011 21:25:03 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.204]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0323.007; Tue, 13 Sep 2011 21:25:03 +0200 From: To: , Thread-Topic: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP) Thread-Index: AQHMckIp298+fCo4Jkujo/Y5scK5GJVLrtJQ Date: Tue, 13 Sep 2011 19:25:03 +0000 Message-ID: References: <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 13 Sep 2011 19:25:03.0777 (UTC) FILETIME=[D670E110:01CC724A] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Tue, 13 Sep 2011 19:23:01 -0000 SGkgSW5ha2ksDQoNCkZ1bGx5IGFncmVlIGFib3V0IGV2ZXJ5dGhpbmcgeW91IHNheSBiZWxvdy4g DQoNCkl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIHVuZGVyc3RhbmQgdGhlIHBlcmZvcm1hbmNl IGRpZmZlcmVuY2VzIG9mIHRoZSBuYXRpdmUgdnMuIEphdmFzY3JpcHQgU0lQIHN0YWNrLCBpZiB0 aGVyZSBpcyBhbnl0aGluZyB3ZSBzaG91bGQgYmUgd29ycmllZCBhYm91dC4gVGhpcyBpcyBteSBv bmx5IGNvbmNlcm4gd2hlbiAocGVyaGFwcyBvbmUgZGF5KSBhcHBseWluZyBSVENXZWIgaW4gZGV2 aWNlcyBsaWtlIHNtYXJ0cGhvbmVzLiBJZiB0aGUgSlMgc3RhY2sgd29ya3MgaW4gKGFueSBvZikg dG9kYXkncyBoaWdoIGVuZCBzbWFydHBob25lcyB3aXRob3V0IHByb2JsZW1zLCB3ZSBzaG91bGQg YmUgZmluZS4NCg0KTWFya3VzDQoNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJv bTogcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmDQo+T2YgZXh0IEnDsWFraSBCYXogQ2FzdGlsbG8NCj5TZW50OiAxMyBTZXB0 ZW1iZXIsIDIwMTEgMjE6MjMNCj5UbzogUmF2aW5kcmFuIFBhcnRoYXNhcmF0aGkNCj5DYzogcnRj d2ViQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtydGN3ZWJdIGRyYWZ0LWliYy1ydGN3ZWItc2lw LXdlYnNvY2tldCAtLSBXZWJTb2NrZXQgVHJhbnNwb3J0DQo+Zm9yIFNlc3Npb24gSW5pdGlhdGlv biBQcm90b2NvbCAoU0lQKQ0KPg0KPjIwMTEvOS8xMyBSYXZpbmRyYW4gUGFydGhhc2FyYXRoaSA8 cHJhdmluZHJhbkBzb251c25ldC5jb20+Og0KPj4gSGkgSW5ha2ksDQo+Pg0KPj4gSSBsaWtlIHRo ZSBpZGVhIG9mIHVzaW5nIFNJUCBiZXR3ZWVuIGJyb3dzZXIgJiBzZXJ2ZXIuDQo+Pg0KPj4gSSBy ZWFsbHkgZG9uJ3Qga25vdyB0aGUgc3Ryb25nIHJlYXNvbiBmb3IgdHVubmVsaW5nIFNJUCBtZXNz YWdlIHdpdGhpbg0KPndlYnNvY2tldC4gSW4gZmFjdCwgd2UgYXJlIGRpc2N1c3NpbmcgU0lQIHZz IHdlYnNvY2tldCBpbg0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9ydGN3 ZWIvY3VycmVudC9tc2cwMTA3MS5odG1sIG1haWwNCj50aHJlYWQgYXMgc2lnbmFsaW5nIHByb3Rv Y29sIGZvciBSVEN3ZWIuIENvdWxkIHlvdSBwbGVhc2UgbWVudGlvbiB0aGUNCj50ZWNobmljYWwg YWR2YW50YWdlIGluIGdvaW5nIGluIHRoZSBwYXRoIG9mIFNJUCBvdmVyIHdlYnNvY2tldCByYXRo ZXIgdGhhbg0KPmhhdmluZyBwbGFpbiBTSVAgY29ubmVjdGlvbiBvdmVyIFRDUCBvciBUTFMgb3Ig KFVEUCBvciBEVExTKS4NCj4NCj5IaSBSYXZpbmRyYW4sDQo+DQo+U0lQIGlzIGEgY29tcGxleCBw cm90b2NvbCBhbmQgdGhlcmUgYXJlIG51bWVyb3VzIGV4dGVuc2lvbnMgYW5kIGZlYXR1cmVzIGlu DQo+bWFueSBSRkMncyBleHRlbmRpbmcgdGhlIFNJUCBwcm90b2NvbC4gSGF2aW5nIHRvIHJlbHkg b24gdGhlIGZlYXR1cmVzDQo+aW1wbGVtZW50ZWQgaW4gYSBuYXRpdmUgU0lQIHN0YWNrIHdpdGhp biB0aGUgd2ViLWJyb3dzZXIgc2VlbXMgbm90IGVub3VnaA0KPmZsZXhpYmxlIElNSE8uIEkgYWxz byBleHBlY3QgbWFueSBsaW1pdGF0aW9ucyBhbmQgbGFjay1vZi1mZWF0dXJlcyBpbiB0aGUNCj5k aWZmZXJlbnQgU0lQIGltcGxlbWVudGF0aW9ucyBvZiBlYWNoIGJyb3dzZXIgKGFuZCBlYWNoIHZl cnNpb24gb2YgdGhlDQo+YnJvd3NlcikuDQo+DQo+SW4gdGhlIG90aGVyIHNpZGUsIGlmIHRoZSBT SVAgc3RhY2sgaXMgY29kZWQgd2l0aGluIGEgSmF2YVNjcmlwdCBsaWJyYXJ5IGFuZCBtYWtlcw0K PnVzYWdlIG9mIHRoZSBXZWJTb2NrZXQgcHJvdG9jb2wsIGlubm92YXRpb24gZGVwZW5kcyBvbiB0 aGUgZGV2ZWxvcGVyIGFuZA0KPm5vdCBvbiB0aGUgYnJvd3NlciBuYXRpdmUgY2FwYWJpbGl0aWVz LiBBIHdlYiBwYWdlIGNvdWxkIG9mZmVyIGEgbWluaW1hbCBTSVANCj5zdGFjayBqdXN0IGltcGxl bWVudGluZyBiYXNpYyBvdXRnb2luZyBjYWxscyAoaS5lLiAiQ2xpY2syQ2FsbCIgYnV0dG9ucyBp biB0aGUNCj53ZWIpLCB3aGlsZSBhbm90aGVyIHdlYiBwYWdlIGNvdWxkIHByZWZlciB0byBwcm92 aWRlIGEgcG93ZXJmdWwgU0lQIHN0YWNrDQo+aW1wbGVtZW50aW5nIGJsaW5rL2F0dGVuZGVkIHRy YW5zZmVyLCBzdWJzY3JpcHRpb24gdG8gcHJlc2VuY2UgYW5kDQo+ZGlhbG9ncy9jYWxscywgY29u ZmVyZW5jZSBmZWF0dXJlcywgY2FsbC1waWNrdXAsIFNJUCBtZXNzYWdpbmcgYW5kIHNvIG9uDQo+ KGltYWdpbmUgc3VjaCBwaG9uZSBpbnRlZ3JhdGVkIHdpdGhpbiBhbiBlbnRlcnByaXNlIGludHJh bmV0KS4gSSBkb24ndCBleHBlY3QNCj50aGF0IHRoZSBTSVAgc3RhY2sgaW50ZWdyYXRlZCB3aXRo aW4gKmV2ZXJ5KiBleGlzdGluZyB3ZWItYnJvd3NlcnMgd291bGQNCj5pbXBsZW1lbnQgYWxsIHRo b3NlIFNJUCBmZWF0dXJlcyBpbiBhIGNvcnJlY3Qgd2F5IChiZWNhdXNlIHRoYXQgZG9lcyBub3QN Cj5oYXBwZW4gbmVpdGhlciB3aGVuIHVzaW5nIGV4cGVuc2l2ZSBTSVAgZGVza3RvcCBwaG9uZXMg b3Igc29mdHBob25lcykuDQo+DQo+QWxzbywgdGhlIHNwZWNpZmljYXRpb24gZGVmaW5lZCBpbiB0 aGUgZHJhZnQgc29sdmVzIE5BVCBpc3N1ZXMgKGF0IHNpZ25hbGluZw0KPmxldmVsKSB3aXRob3V0 IHJlcXVpcmluZyBzZXJ2ZXIgc2lkZSBzb2x1dGlvbnMgZm9yIGZpeGluZyBOQVQgaW4gY2xpZW50 cy4NCj4NCj5XZWJTb2NrZXQgcHJvdG9jb2wgaXMgYmVjb21pbmcgYSBuZXcgInRyYW5zcG9ydCIg cHJvdG9jb2wuDQo+SW1wbGVtZW50aW5nIFNJUCBwcm90b2NvbCBvbiB0b3Agb2YgaXQgY2FuIG9u bHkgYnJpbmcgYWR2YW50YWdlcyBhbmQgbmV3DQo+cG9zc2liaWxpdGllcy4gVGhlIHNwZWNpZmlj YXRpb24gaW4gdGhlIGRyYWZ0IGlzIGFuIGFkYXB0YXRpb24gb2YgU0lQIHRvIG1ha2UgdXNlDQo+ b2YgV2ViU29ja2V0LCBhcyBpdCBhbHJlYWR5IGRvZXMgd2l0aCBVRFAsIFRDUCBhbmQgU0NUUCB0 cmFuc3BvcnRzLg0KPg0KPg0KPkJUVywgYXMgc2FpZCBpbiB0aGUgZmlyc3QgbWFpbCwgd2UgaGF2 ZSBwdWJsaXNoZWQgdGhlIGRyYWZ0IGFmdGVyIGhhdmluZyBhDQo+d29ya2luZyBwcm90b3R5cGUg bWFraW5nIHVzYWdlIG9mIHRoZSBzcGVjaWZpY2F0aW9uIGRlc2NyaWJlZCBpbiB0aGUNCj5kb2N1 bWVudC4gQWZ0ZXIgdGhhdCwgd2Ugc2VlIG5vIHJlYWwgYWR2YW50YWdlIG9uIGhhdmluZyBhIG5h dGl2ZSBTSVAgc3RhY2sNCj53aXRoaW4gYSB3ZWIgYnJvd3Nlci4gVGhlIHByb3RvdHlwZSB3aWxs IGJlIHNob3duIHNvb24uDQo+DQo+QmVzdCByZWdhcmRzLg0KPg0KPi0tDQo+ScOxYWtpIEJheiBD YXN0aWxsbw0KPjxpYmNAYWxpYXgubmV0Pg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+cnRjd2ViIG1haWxpbmcgbGlzdA0KPnJ0Y3dlYkBpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo= From mperumal@cisco.com Tue Sep 13 12: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 1A4E711E80AD for ; Tue, 13 Sep 2011 12:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.418 X-Spam-Level: X-Spam-Status: No, score=-10.418 tagged_above=-999 required=5 tests=[AWL=0.180, 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 mOBQtJVi1Dtm for ; Tue, 13 Sep 2011 12:33:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4D54711E80AB for ; Tue, 13 Sep 2011 12:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=60788; q=dns/txt; s=iport; t=1315942518; x=1317152118; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=nf+WduvS5n26vNx0EmRPfBSRiU6k/ipuKq6/ZWH+O2c=; b=QDITQp5d6hU9DfT/eMJ3LNUzQZR3KinVdQ0zjUgzIyuqvqjTy4pa/uSm O/M1FMwztLezjhIpI4vlaeDYEuGi6dr8iPnSePwLKInuDXLDBQLisg2p+ 9EKGWFLFLrQDwEeNj7V7god63GRq0HVQ93TPgok0QYSzmxz3xxfqxykbH M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEAAF6vb05Io8UR/2dsb2JhbAA5CYJNlhWPDniBUwEBBRIBCREDSRACAQgOAwEDAQELBhABAgQBBgElIAMGCAEBBAEKBwEIARIHh1mZGQGeMINIgkZgBIdrkHSMCA X-IronPort-AV: E=Sophos;i="4.68,375,1312156800"; d="scan'208,217";a="115260982" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 13 Sep 2011 19:35:09 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8DJZ8Zb027400; Tue, 13 Sep 2011 19:35:08 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, 14 Sep 2011 01:05:08 +0530 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC724C.3E4EF25D" Date: Wed, 14 Sep 2011 01:05:02 +0530 Message-ID: <1D062974A4845E4D8A343C653804920206648AC6@XMB-BGL-414.cisco.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0AA2@sonusinmail02.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording client] Thread-Index: Acxt9AbN3JhWXoAGQEWrQ9SN744t+wARGUtgAMkSJbAAB9H90AAyRv9w References: <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net><4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net><2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com><4E67AD3D.9000005@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com><4E686663.1050900@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F0989@sonusinmail02.sonusnet.com> <1D062974A4845E4D8A343C6538049202065582FF@XMB-BGL-414.cisco.com> <2E239D6FCD033C4BAF15F386A979BF510F0AA2@sonusinmail02.sonusnet.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Ravindran Parthasarathi" , "Harald Alvestrand" X-OriginalArrivalTime: 13 Sep 2011 19:35:08.0528 (UTC) FILETIME=[3EE68F00:01CC724C] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording client] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Sep 2011 19:33:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC724C.3E4EF25D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable |Like normal SIP stack, the new headers shall be added=20 |by the use of Javascript API. SIP stack in browser=20 |shall composes of transaction layer, encoding & decoding |of the SIP message, and UAC & UAS functionality mentioned=20 |in RFC 3261 =20 With the browser implementing just 3261 the application will more often than not end up implementing 3262, 3311, 3515, 3891, 3892, 3265, 5626 etc, depending on what it wants to do.=20 =20 |As the core SIP stack is build within browser, javascript=20 |programmer will focus on application and not on the protocol=20 |intricacies. =20 This is not true, unless the programmer has JS libraries for what the browser doesn't support at his/her disposal. Implementing a portion of SIP inside the browser doesn't look worth. =20 Muthu =20 =20 From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com]=20 Sent: Tuesday, September 13, 2011 12:28 AM To: Muthu Arul Mozhi Perumal (mperumal); Harald Alvestrand Cc: rtcweb@ietf.org Subject: RE: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording client] =20 Hi Muthu, =20 Browser is yet another application in the system which has the programming environment using Javascript. I explained my point of view in another mail thread: http://www.ietf.org/mail-archive/web/rtcweb/current/msg01058.html. My proposal is similar to SIP stack with C or C++ API but RTCWeb API is designed based on Javascript. Like normal SIP stack, the new headers shall be added by the use of Javascript API. SIP stack in browser shall composes of transaction layer, encoding & decoding of the SIP message, and UAC & UAS functionality mentioned in RFC 3261. I agree that agreed upon NAT traversal mechanism of signaling protocol has to be supported for RTCWeb. Jquery library shall be built for the high level API's. =20 These sort of SIP framework will scale for any sort innovative real-time application with better performance compare to any other protocol known in IETF. As the core SIP stack is build within browser, javascript programmer will focus on application and not on the protocol intricacies. =20 Thanks Partha =20 From: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20 Sent: Monday, September 12, 2011 8:52 PM To: Ravindran Parthasarathi; Harald Alvestrand Cc: rtcweb@ietf.org Subject: RE: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording client] =20 Asking for the browser to support SIP is like asking for the OS kernel to support 100s of SIP specs to cater to various kinds of applications, instead of implementing what portion of SIP you care about in the application itself -- it just doesn't look scalable. Even if you want to experiment with a new SIP header you would have to wait for the browser vendor to release the new version of the browser or make changes to the browser code yourself, severely hampering application development. =20 Muthu =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ravindran Parthasarathi Sent: Thursday, September 08, 2011 8:44 PM To: Harald Alvestrand Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording client] =20 Harald, =20 I'm proposing for "SIP UA framework for RTCWeb browser", the framework provides Javascript API. In case you mean the same as "SIP lite". I'm fine with it. SIP UA framework helps to support two-party communication from RTCWeb browser and uses HTTP as presence or configuration interface.=20 =20 As I mentioned in the another mail, I'm talking about INVITE subset of RFC 3261 in browser. =20 =20 Thanks Partha =20 From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Thursday, September 08, 2011 12:23 PM To: Ravindran Parthasarathi Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] =20 On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote:=20 Harald, =20 For browser as a SIP UA application, browser has to no need to compliant with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also agree with you that browser-to-browser communication, I could not see the strong reason for supporting S/MIME. As part of the RTCWeb architecture & solution, we will able to explore the SIP UA requirement for making browser SIP compliant. So you're advocating for creating a "SIP lite" subset that RTCWEB browsers implement. I think we have been down this road before, and it's not a happy one. But sure - if you want us to implement some part of SIP, *please start stating what part* rather than making wooly statements. Subsets are Real Hard Work. Say for example, forking does not make sense in case of browser as SIP UA application, forked response will be rejected with CANCEL in browser without Javascript intervention. The main requirement is to build the right SIP UA framework in browser by which Javascript developer will be able to use to the maximum extent without impacting the basic 2 two party communication in the internet. =20 =20 As mailed in another thread, RTCWEB client + RTCWeb server makes to feel a modern exchange in web world (Plain Old Telephony System phone with exchange architecture). I think so because POTS phones are dumb which does not know its identity and every event like offhook, onhook has to passed to exchange (webserver) whereas RTCWeb client (browser) has to pass every event to webserver and webserver has whole intelligence to make it work. Don't forget that the RTCWEB client (the browser) contains an open, fully programmable application platform - the Javascript engine. That's a HUGE difference to the POTS phone. I got this feel more when someone is talking about MEGACO or MGCP between RTCWEB client & webserver. My understanding is that SIP does not fit well to legacy telephone-based paradigm by any means but MEGACO or MGCP are the better choice which maps to SS7 architecture well. I'm interested in seeing RTCWeb client perform the basic routing rather than webserver does the routing on behalf of RTCWEb client. =20 I agree with you that in case it is local exchange (same site like skype or Google hangout) communication, there will be no need of signaling but I'm interested in communication with one of the Google real-time user in internet without having any Google id. I believe that SIP will make it work. If by saying "the Google real time user in Internet", you mean a Google Talk user, you have that already. It's called Google Voice. It uses SIP, but not in the browser. Talking to someone who doesn't want to talk to you is an use case we don't intend to support. =20 Thanks Partha =20 From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Wednesday, September 07, 2011 11:13 PM To: Ravindran Parthasarathi Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client] =20 On 09/07/11 19:29, Ravindran Parthasarathi wrote:=20 Matthew, =20 When I asked for SIP, I have meant RFC 3261 only. This is 269 pages, and has 26 normative dependencies including S/MIME. It's not a small dependency. =20 The basic reason for asking SIP is to make the basic call works between browser to browser across web servers. Without SIP in browser, it is not going happen. Innovative application is going to be proprietary whether it is HTTP or SIP or any other protocol for that matter. =20 My reasoning are as follows: SIP makes browser more intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG.=20 Why does that "intelligence" need to be in the browser, rather than in the Javascript? The importance of basic call interop is that there is no need of many individual id like skype id, Google id and yahoo id by everyone in the world to communicate others. I wish to have single id like e-mail id to be maintained by browser-to-browser users to communicate with others.=20 This only makes sense for applications that fit the "call an identified party" paradigm. SIP helps to interop for basic call with other existing realtime application in Enterprise & Telecom provider. There is no need to build two different signaling logic in VoIP servers for each service. Your own example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible to avoided by having one signaling protocol. One protocol can be achieved by multiple applications choosing to implement one protocol. It doesn't have to be enforced by the prtoocol being embedded in the browser. =20 In RTCWEB does not standardize the signaling protocol interface between browsers, the interop across webservers is next to impossible and it will be restricted to single webserver (company) only. Please let me know in case I'm missing something here. I think the main thing you are missing is that there are many applications that people want to build on top of RTCWEB that are not telephones, and will not fit with telephone-based paradigms. =20 ------_=_NextPart_001_01CC724C.3E4EF25D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

|Like normal SIP stack, the new headers shall be added

|by the use of Javascript API. SIP stack in = browser

|shall composes of transaction layer, encoding & = decoding

|of the SIP message, and UAC & UAS functionality mentioned

|in RFC 3261

 

With the browser implementing just 3261 the application will more often than = not end up implementing 3262, 3311, 3515, 3891, 3892, 3265, 5626 etc, depending = on what it wants to do.

 

|As the core SIP stack is build within browser, javascript

|programmer will focus on application and not on the protocol

|intricacies.

 

This is not true, unless the programmer has JS libraries for what the browser doesn't support at his/her disposal. Implementing a portion of SIP = inside the browser doesn't look worth.

 

Muthu  

 

From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com]
Sent: Tuesday, September 13, 2011 12:28 AM
To: Muthu Arul Mozhi Perumal (mperumal); Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: RE: [rtcweb] SIP MUST NOT be used in browser?[was = RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording = client]

 

Hi Muthu,

 

Browser is yet another application in the system which = has the programming environment using Javascript.  I explained my point of = view in another mail thread: http://www.ietf.org/mail-archive/web/rtcweb/current/msg01058.html. My proposal is similar to SIP stack with C or C++ API but RTCWeb API is designed based on Javascript. Like normal SIP stack, the new headers = shall be added by the use of Javascript API. SIP stack in browser shall composes = of transaction layer, encoding & decoding of the SIP message, and UAC = & UAS functionality mentioned in RFC 3261. I agree that agreed upon NAT = traversal mechanism of signaling protocol has to be supported for RTCWeb. =  Jquery library shall be built for the high level = API’s.

 

These sort of SIP framework will scale for any sort = innovative real-time application with better performance compare to any other = protocol known in IETF. As the core SIP stack is build within browser, javascript programmer will focus on application and not on the protocol = intricacies.

 

Thanks

Partha

 

From: Muthu Arul Mozhi Perumal = (mperumal) [mailto:mperumal@cisco.com]
Sent: Monday, September 12, 2011 8:52 PM
To: Ravindran Parthasarathi; Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: RE: [rtcweb] SIP MUST NOT be used in browser?[was = RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording = client]

 

Asking for the browser to support SIP is like asking = for the OS kernel to support 100s of SIP specs to cater to various kinds of applications, instead of implementing what portion of SIP you care about = in the application itself -- it just doesn't look scalable. Even if you want to experiment with a new SIP header you would have to wait for the browser = vendor to release the new version of the browser or make changes to the browser = code yourself, severely hampering application = development.

 

Muthu

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ravindran = Parthasarathi
Sent: Thursday, September 08, 2011 8:44 PM
To: Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was = RE:Remote recording - RTC-Web client acting as SIPREC sessionrecording = client]

 

Harald,

 

I’m proposing for “SIP UA framework for = RTCWeb browser”, the framework provides Javascript API. In case you mean = the same as “SIP lite”. I’m fine with it. SIP UA framework = helps to support two-party communication from RTCWeb browser and uses HTTP as presence or configuration interface.

 

As I mentioned in the another mail, I’m talking = about INVITE subset of RFC 3261 in browser.  

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Thursday, September 08, 2011 12:23 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lucent.com; = rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remote recording - RTC-Web client acting as SIPREC session recording = client]

 

On 09/08/2011 07:09 AM, Ravindran Parthasarathi = wrote:

Harald,

 

For browser as a SIP UA application, browser has to no need to compliant = with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also agree with = you that browser-to-browser communication, I could not see the strong reason for = supporting S/MIME. As part of the RTCWeb architecture & solution, we will able = to explore the SIP UA requirement for making browser SIP = compliant.

So you're advocating = for creating a "SIP lite" subset that RTCWEB browsers = implement.
I think we have been down this road before, and it's not a happy = one.
But sure - if you want us to implement some part of SIP, *please start = stating what part* rather than making wooly statements.

Subsets are Real Hard Work.

Say for example, forking does not make sense in case of browser as SIP UA application, forked response will be rejected with CANCEL in browser = without Javascript intervention. The main requirement is to build the right SIP = UA framework in browser by which Javascript developer will be able to use = to the maximum extent without impacting the basic 2 two party communication in = the internet. 

 

As mailed in another thread, RTCWEB client + RTCWeb server makes to feel a = modern exchange in web world (Plain Old Telephony System phone with exchange architecture). I think so because POTS phones are dumb which does not = know its identity and every event like offhook, onhook has to passed to exchange (webserver) whereas RTCWeb client (browser) has to pass every event to webserver and webserver has whole intelligence to make it = work.

Don't forget that = the RTCWEB client (the browser) contains an open, fully programmable application = platform - the Javascript engine. That's a HUGE difference to the POTS = phone.

I got this feel more when someone is talking about MEGACO or MGCP between = RTCWEB client & webserver. My understanding is that SIP does not fit well = to legacy telephone-based paradigm by any means but MEGACO or MGCP are the = better choice which maps to SS7 architecture well. I’m interested in = seeing RTCWeb client perform the basic routing rather than webserver does the = routing on behalf of RTCWEb client.

 

I agree with you that in case it is local exchange (same site like skype = or Google hangout) communication, there will be no need of signaling but = I’m interested in communication with one of the Google real-time user in = internet without having any Google id.  I believe that SIP will make it = work.

If by saying = "the Google real time user in Internet", you mean a Google Talk user, you have = that already. It's called Google Voice. It uses SIP, but not in the = browser.

Talking to someone who doesn't want to talk to you is an use case we = don't intend to support.

 

Thanks

Partha

 

From: Harald Alvestrand [mailto:harald@alvestrand.no] =
Sent: Wednesday, September 07, 2011 11:13 PM
To: Ravindran Parthasarathi
Cc: Matthew Kaufman; igor.faynberg@alcatel-lu= cent.com; rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: = Remote recording - RTC-Web client acting as SIPREC session recording = client]

 

On 09/07/11 19:29, Ravindran Parthasarathi wrote: =

Matthew,

 

When I asked for SIP, I have meant RFC 3261 only.

This is 269 pages, and has 26 normative = dependencies including S/MIME. It's not a small dependency.

 

The basic reason for asking SIP is to make the basic call works between = browser to browser across web servers. Without SIP in browser, it is not going = happen. Innovative application is going to be proprietary whether it is HTTP or = SIP or any other protocol for that matter.

 

My reasoning are as follows:

SIP makes browser more = intelligence compare to dump signaling mechanism like MEGACO and browser acts as MG. =

Why does that = "intelligence" need to be in the browser, rather than in the Javascript?

The importance of basic call = interop is that there is no need of many individual id like skype id, Google = id  and yahoo id by everyone in the world to communicate others. I wish to = have single id like e-mail id to be maintained by browser-to-browser users to = communicate with others.

This only makes = sense for applications that fit the "call an identified party" = paradigm.

SIP helps to interop for = basic call with other existing realtime application in Enterprise & Telecom = provider.

There is no need to build two different signaling logic in VoIP servers for each service. Your own = example of Bridge line appearance will need two implementation by the single vendor because desktop application or hardphone implementation based on SIP and browser based implementation is depend on HTTP metadata. It is possible = to avoided by having one signaling protocol.

One protocol can be = achieved by multiple applications choosing to implement one protocol.
It doesn't have to be enforced by the prtoocol being embedded in the = browser.

 

In RTCWEB does not standardize the signaling protocol interface between = browsers, the interop across webservers is next to impossible and it will be = restricted to single webserver (company) only. Please let  me know in case = I’m missing something here.


I think the main thing you are missing is that there are many = applications that people want to build on top of RTCWEB that are not telephones, and will = not fit with telephone-based paradigms.

 

------_=_NextPart_001_01CC724C.3E4EF25D-- From jmillan@aliax.net Tue Sep 13 13:48: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 27A9721F8CD5 for ; Tue, 13 Sep 2011 13:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=0.043, 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 UXIn1Vl8bOXr for ; Tue, 13 Sep 2011 13:48:48 -0700 (PDT) Received: from mail-gy0-f194.google.com (mail-gy0-f194.google.com [209.85.160.194]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE9B21F8CD4 for ; Tue, 13 Sep 2011 13:48:48 -0700 (PDT) Received: by gyd10 with SMTP id 10so132096gyd.1 for ; Tue, 13 Sep 2011 13:50:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.14 with SMTP id l14mr9623194ibi.69.1315947054572; Tue, 13 Sep 2011 13:50:54 -0700 (PDT) Received: by 10.231.36.201 with HTTP; Tue, 13 Sep 2011 13:50:54 -0700 (PDT) Date: Tue, 13 Sep 2011 22:50:54 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: rtcweb@ietf.org, Markus.Isomaki@nokia.com Content-Type: multipart/alternative; boundary=00151773e028bb25ca04acd8cc63 Subject: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Tue, 13 Sep 2011 20:48:49 -0000 --00151773e028bb25ca04acd8cc63 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Sep 13, 2011 at 9:25 PM, wrote: > Hi Inaki, > > Fully agree about everything you say below. Hi, Sorry if this mail arrives out of the original mail thread. > > It would be interesting to understand the performance differences of the native vs. Javascript SIP stack, if there is anything we should be worried about. This is my only concern when (perhaps one day) applying RTCWeb in devices like smartphones. If the JS stack works in (any of) today's high en= d smartphones without problems, we should be fine. The are no meaningful performance penalties at all using the JavaScript SIP stack in our prototype. In fact, multiple SIP stack instances can run in a single Web browser freshly. BTW, is there any WebSocket capable web browse= r for smartphones? > > Markus > > >>-----Original Message----- >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >>Of ext I=F1aki Baz Castillo >>Sent: 13 September, 2011 21:23 >>To: Ravindran Parthasarathi >>Cc: rtcweb@ietf.org >>Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport >>for Session Initiation Protocol (SIP) >> >>2011/9/13 Ravindran Parthasarathi : >>> Hi Inaki, >>> >>> I like the idea of using SIP between browser & server. >>> >>> I really don't know the strong reason for tunneling SIP message within >>websocket. In fact, we are discussing SIP vs websocket in >>http://www.ietf.org/mail-archive/web/rtcweb/current/msg01071.html mail >>thread as signaling protocol for RTCweb. Could you please mention the >>technical advantage in going in the path of SIP over websocket rather tha= n >>having plain SIP connection over TCP or TLS or (UDP or DTLS). >> >>Hi Ravindran, >> >>SIP is a complex protocol and there are numerous extensions and features in >>many RFC's extending the SIP protocol. Having to rely on the features >>implemented in a native SIP stack within the web-browser seems not enough >>flexible IMHO. I also expect many limitations and lack-of-features in the >>different SIP implementations of each browser (and each version of the >>browser). >> >>In the other side, if the SIP stack is coded within a JavaScript library and makes >>usage of the WebSocket protocol, innovation depends on the developer and >>not on the browser native capabilities. A web page could offer a minimal SIP >>stack just implementing basic outgoing calls (i.e. "Click2Call" buttons i= n the >>web), while another web page could prefer to provide a powerful SIP stack >>implementing blink/attended transfer, subscription to presence and >>dialogs/calls, conference features, call-pickup, SIP messaging and so on >>(imagine such phone integrated within an enterprise intranet). I don't expect >>that the SIP stack integrated within *every* existing web-browsers would >>implement all those SIP features in a correct way (because that does not >>happen neither when using expensive SIP desktop phones or softphones). >> >>Also, the specification defined in the draft solves NAT issues (at signaling >>level) without requiring server side solutions for fixing NAT in clients. >> >>WebSocket protocol is becoming a new "transport" protocol. >>Implementing SIP protocol on top of it can only bring advantages and new >>possibilities. The specification in the draft is an adaptation of SIP to make use >>of WebSocket, as it already does with UDP, TCP and SCTP transports. >> >> >>BTW, as said in the first mail, we have published the draft after having = a >>working prototype making usage of the specification described in the >>document. After that, we see no real advantage on having a native SIP stack >>within a web browser. The prototype will be shown soon. >> >>Best regards. >> >>-- >>I=F1aki Baz Castillo >> >>_______________________________________________ >>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 > --00151773e028bb25ca04acd8cc63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 13, 2011 at 9:25 PM, =A0<Markus.Isomaki@nokia.com> wrote:
> Hi Ina= ki,
>
> Fully agree about everything you say belo= w.

Hi,

Sorry if this mail arrives= out of the original mail thread.

>
&= gt; It would be interesting to understand the performance differences of th= e native vs. Javascript SIP stack, if there is anything we should be worrie= d about. This is my only concern when (perhaps one day) applying RTCWeb in = devices like smartphones. If the JS stack works in (any of) today's hig= h end smartphones without problems, we should be fine.

The are no meaningful performance penalties at all usin= g the JavaScript SIP stack in our prototype. In fact, multiple SIP stack in= stances can run in a single Web browser freshly. =A0BTW, is there any WebSo= cket capable web browser for smartphones?

>
> Markus
>
>= ;
>>-----Original Message-----
>>From: rtcweb-bounces@ietf.org [mailto:= rtcweb-bounces@ietf.org] On = Behalf
>>Of ext I=F1aki Baz Castillo
>>Sent: 13 Septemb= er, 2011 21:23
>>To: Ravindran Parthasarathi
&g= t;>Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Tra= nsport
>>for Session Initiation Protocol (SIP)
>>
=
>>2011/9/13 Ravindran Parthasarathi <pravindran@sonusnet.com>:
>>> = Hi Inaki,
>>>
>>> I like the idea of using SIP betwe= en browser & server.
>>>
>>> I re= ally don't know the strong reason for tunneling SIP message within
>>websocket. In fact, we are discussing SIP vs websocket in
>>thread as signaling protocol for RTCweb. Could you please ment= ion the
>>technical advantage in going in the path of SIP o= ver websocket rather than
>>having plain SIP connection ove= r TCP or TLS or (UDP or DTLS).
>>
>>Hi Ravindran,
>>
= >>SIP is a complex protocol and there are numerous extensions and fea= tures in
>>many RFC's extending the SIP protocol. Havin= g to rely on the features
>>implemented in a native SIP stack within the web-browser seems= not enough
>>flexible IMHO. I also expect many limitations= and lack-of-features in the
>>different SIP implementation= s of each browser (and each version of the
>>browser).
>>
>>In the other si= de, if the SIP stack is coded within a JavaScript library and makes
>>usage of the WebSocket protocol, innovation depends on the devel= oper and
>>not on the browser native capabilities. A web page could offer= a minimal SIP
>>stack just implementing basic outgoing cal= ls (i.e. "Click2Call" buttons in the
>>web), whil= e another web page could prefer to provide a powerful SIP stack
>>implementing blink/attended transfer, subscription to presence= and
>>dialogs/calls, conference features, call-pickup, SIP= messaging and so on
>>(imagine such phone integrated withi= n an enterprise intranet). I don't expect
>>that the SIP stack integrated within *every* existing web-brow= sers would
>>implement all those SIP features in a correct = way (because that does not
>>happen neither when using expe= nsive SIP desktop phones or softphones).
>>
>>Also, the specification defined in the draf= t solves NAT issues (at signaling
>>level) without requirin= g server side solutions for fixing NAT in clients.
>>
>>WebSocket protocol is becoming a new "transport" pro= tocol.
>>Implementing SIP protocol on top of it can only br= ing advantages and new
>>possibilities. The specification i= n the draft is an adaptation of SIP to make use
>>of WebSocket, as it already does with UDP, TCP and SCTP transp= orts.
>>
>>
>>BTW, as said = in the first mail, we have published the draft after having a
>>working prototype making usage of the specification described in th= e
>>document. After that, we see no real advantage on havin= g a native SIP stack
>>within a web browser. The prototype = will be shown soon.
>>
>>Best regards.
>>
= >>--
>>I=F1aki Baz Castillo
>>_____= __________________________________________
>>rtcweb mailing list
> _______________________________________________
> rt= cweb mailing list
>
--00151773e028bb25ca04acd8cc63-- From Markus.Isomaki@nokia.com Tue Sep 13 14:00: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 6671011E80F2 for ; Tue, 13 Sep 2011 14:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 Nl-ZaRDMch0Z for ; Tue, 13 Sep 2011 14:00:33 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 84B4611E80DB for ; Tue, 13 Sep 2011 14:00:33 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8DL2YuU001791; Wed, 14 Sep 2011 00:02:37 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 00:02:30 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 13 Sep 2011 23:02:29 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.204]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0323.007; Tue, 13 Sep 2011 23:02:29 +0200 From: To: , Thread-Topic: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP) Thread-Index: AQHMclIJVh3fkAsmb0uRhIRZlTGd/ZVLxeng Date: Tue, 13 Sep 2011 21:02: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: multipart/alternative; boundary="_000_E44893DD4E290745BB608EB23FDDB7620AEDD9008AM1MPN1043mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 13 Sep 2011 21:02:30.0529 (UTC) FILETIME=[73606F10:01CC7258] X-Nokia-AV: Clean Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Tue, 13 Sep 2011 21:00:37 -0000 --_000_E44893DD4E290745BB608EB23FDDB7620AEDD9008AM1MPN1043mgdn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable jmillan@aliax.net wrote: > BTW, is there any WebSocket capable web browser for smartphones? I don't know as of today. But IE, Firefox and Chrome are all making their w= ay to smartphones, and they have all some version of the websocket draft im= plemented at least in some experimental form. And everyone else is talking = about "HTML5" support too. So I belive websockets will be there at least so= oner than we will have RTP or STUN. So we will be able to setup the virtual= calls but not transport the media :) RTP and STUN (and SIP, for that matter) implementations are as such availab= le on various smartphone OS's, they just need to be integrated within the b= rowser. Then there are several practical aspects, like the UI, the fact that the ph= one may all of a sudden switch between Wi-Fi and the cellular connectivity,= the other fact that too frequent keepalives will kill the battery, not all= codecs are available and can't be that easily just installed (especially v= ideo encoding would benefit from "HW acceleration"), that if you actually b= rowse (or do some other TCP stuff) at the same time as you use VoIP/RTP, bu= fferbloat will kick in and the call will be garbage for a few seconds - reg= ardless of if the TCP initial window is 3 or 10, and so on. Perhaps worth w= riting a short draft in the near future. Markus From: ext Jos=E9 Luis Mill=E1n [mailto:jmillan@aliax.net] Sent: 13 September, 2011 23:16 To: rtcweb@ietf.org; Isomaki Markus (Nokia-CIC/Espoo) Subject: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for= Session Initiation Protocol (SIP) On Tue, Sep 13, 2011 at 9:25 PM, > wrote: > Hi Inaki, > > Fully agree about everything you say below. Hi, Sorry if this mail arrives out of the original mail thread. > > It would be interesting to understand the performance differences of the = native vs. Javascript SIP stack, if there is anything we should be worried = about. This is my only concern when (perhaps one day) applying RTCWeb in de= vices like smartphones. If the JS stack works in (any of) today's high end = smartphones without problems, we should be fine. The are no meaningful performance penalties at all using the JavaScript SIP= stack in our prototype. In fact, multiple SIP stack instances can run in a= single Web browser freshly. BTW, is there any WebSocket capable web brows= er for smartphones? > > Markus > > >>-----Original Message----- >>From: rtcweb-bounces@ietf.org [mailto:rtc= web-bounces@ietf.org] On Behalf >>Of ext I=F1aki Baz Castillo >>Sent: 13 September, 2011 21:23 >>To: Ravindran Parthasarathi >>Cc: rtcweb@ietf.org >>Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transpo= rt >>for Session Initiation Protocol (SIP) >> >>2011/9/13 Ravindran Parthasarathi >: >>> Hi Inaki, >>> >>> I like the idea of using SIP between browser & server. >>> >>> I really don't know the strong reason for tunneling SIP message within >>websocket. In fact, we are discussing SIP vs websocket in >>http://www.ietf.org/mail-archive/web/rtcweb/current/msg01071.html mail >>thread as signaling protocol for RTCweb. Could you please mention the >>technical advantage in going in the path of SIP over websocket rather tha= n >>having plain SIP connection over TCP or TLS or (UDP or DTLS). >> >>Hi Ravindran, >> >>SIP is a complex protocol and there are numerous extensions and features = in >>many RFC's extending the SIP protocol. Having to rely on the features >>implemented in a native SIP stack within the web-browser seems not enough >>flexible IMHO. I also expect many limitations and lack-of-features in the >>different SIP implementations of each browser (and each version of the >>browser). >> >>In the other side, if the SIP stack is coded within a JavaScript library = and makes >>usage of the WebSocket protocol, innovation depends on the developer and >>not on the browser native capabilities. A web page could offer a minimal = SIP >>stack just implementing basic outgoing calls (i.e. "Click2Call" buttons i= n the >>web), while another web page could prefer to provide a powerful SIP stack >>implementing blink/attended transfer, subscription to presence and >>dialogs/calls, conference features, call-pickup, SIP messaging and so on >>(imagine such phone integrated within an enterprise intranet). I don't ex= pect >>that the SIP stack integrated within *every* existing web-browsers would >>implement all those SIP features in a correct way (because that does not >>happen neither when using expensive SIP desktop phones or softphones). >> >>Also, the specification defined in the draft solves NAT issues (at signal= ing >>level) without requiring server side solutions for fixing NAT in clients. >> >>WebSocket protocol is becoming a new "transport" protocol. >>Implementing SIP protocol on top of it can only bring advantages and new >>possibilities. The specification in the draft is an adaptation of SIP to = make use >>of WebSocket, as it already does with UDP, TCP and SCTP transports. >> >> >>BTW, as said in the first mail, we have published the draft after having = a >>working prototype making usage of the specification described in the >>document. After that, we see no real advantage on having a native SIP sta= ck >>within a web browser. The prototype will be shown soon. >> >>Best regards. >> >>-- >>I=F1aki Baz Castillo >>> >>_______________________________________________ >>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_E44893DD4E290745BB608EB23FDDB7620AEDD9008AM1MPN1043mgdn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

jmi= llan@aliax.net wrote:

> BTW, is there= any WebSocket capable web browser for smartphones?

 

I don’t know as of today. But IE, Firefox and = Chrome are all making their way to smartphones, and they have all some vers= ion of the websocket draft implemented at least in some experimental form. = And everyone else is talking about “HTML5” support too. So I belive websockets will be there at least sooner than we = will have RTP or STUN. So we will be able to setup the virtual calls but no= t transport the media J

 

RTP and STUN (and SIP, for that matter) implementati= ons are as such available on various smartphone OS’s, they just need = to be integrated within the browser.  

 

Then there are several practical aspects, like the U= I, the fact that the phone may all of a sudden switch between Wi-Fi and the= cellular connectivity, the other fact that too frequent keepalives will ki= ll the battery, not all codecs are available and can’t be that easily just installed (especially video = encoding would benefit from “HW acceleration”), that if you act= ually browse (or do some other TCP stuff) at the same time as you use VoIP/= RTP, bufferbloat will kick in and the call will be garbage for a few seconds – regardless of if the TCP initial window = is 3 or 10, and so on. Perhaps worth writing a short draft in the near futu= re.

 

Markus

 <= /p>

 <= /p>

From: ext Jos= =E9 Luis Mill=E1n [mailto:jmillan@aliax.net]
Sent: 13 September, 2011 23:16
To: rtcweb@ietf.org; Isomaki Markus (Nokia-CIC/Espoo)
Subject: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transp= ort for Session Initiation Protocol (SIP)

 

On Tue, Sep 13, 2011 at 9:25 PM,  <Markus.Isomaki@nokia.com> wrote= :

> Hi Inaki,

> 

> Fully agree about everything you say below.

 

Hi,

 

Sorry if this mail arrives out of the original mail = thread.

 

> 

> It would be interesting to understand the perfo= rmance differences of the native vs. Javascript SIP stack, if there is anyt= hing we should be worried about. This is my only concern when (perhaps one = day) applying RTCWeb in devices like smartphones. If the JS stack works in (any of) today's high end smartphone= s without problems, we should be fine.

 

The are no meaningful performance penalties at all u= sing the JavaScript SIP stack in our prototype. In fact, multiple SIP stack= instances can run in a single Web browser freshly.  BTW, is there any= WebSocket capable web browser for smartphones?

 

> 

> Markus

> 

> 

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

>>Of ext I=F1aki Baz Castillo

>>Sent: 13 September, 2011 21:23

>>To: Ravindran Parthasarathi

>>Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-w= ebsocket -- WebSocket Transport

>>for Session Initiation Protocol (SIP)

>> 

>>2011/9/13 Ravindran Parthasarathi <pravindran@sonusnet.com>:<= /o:p>

>>> Hi Inaki,

>>> 

>>> I like the idea of using SIP between br= owser & server.

>>> 

>>> I really don't know the strong reason f= or tunneling SIP message within

>>websocket. In fact, we are discussing SIP vs= websocket in

>>thread as signaling protocol for RTCweb. Cou= ld you please mention the

>>technical advantage in going in the path of = SIP over websocket rather than

>>having plain SIP connection over TCP or TLS = or (UDP or DTLS).

>> 

>>Hi Ravindran,

>> 

>>SIP is a complex protocol and there are nume= rous extensions and features in

>>many RFC's extending the SIP protocol. Havin= g to rely on the features

>>implemented in a native SIP stack within the= web-browser seems not enough

>>flexible IMHO. I also expect many limitation= s and lack-of-features in the

>>different SIP implementations of each browse= r (and each version of the

>>browser).

>> 

>>In the other side, if the SIP stack is coded= within a JavaScript library and makes

>>usage of the WebSocket protocol, innovation = depends on the developer and

>>not on the browser native capabilities. A we= b page could offer a minimal SIP

>>stack just implementing basic outgoing calls= (i.e. "Click2Call" buttons in the

>>web), while another web page could prefer to= provide a powerful SIP stack

>>implementing blink/attended transfer, subscr= iption to presence and

>>dialogs/calls, conference features, call-pic= kup, SIP messaging and so on

>>(imagine such phone integrated within an ent= erprise intranet). I don't expect

>>that the SIP stack integrated within *every*= existing web-browsers would

>>implement all those SIP features in a correc= t way (because that does not

>>happen neither when using expensive SIP desk= top phones or softphones).

>> 

>>Also, the specification defined in the draft= solves NAT issues (at signaling

>>level) without requiring server side solutio= ns for fixing NAT in clients.

>> 

>>WebSocket protocol is becoming a new "t= ransport" protocol.

>>Implementing SIP protocol on top of it can o= nly bring advantages and new

>>possibilities. The specification in the draf= t is an adaptation of SIP to make use

>>of WebSocket, as it already does with UDP, T= CP and SCTP transports.

>> 

>> 

>>BTW, as said in the first mail, we have publ= ished the draft after having a

>>working prototype making usage of the specif= ication described in the

>>document. After that, we see no real advanta= ge on having a native SIP stack

>>within a web browser. The prototype will be = shown soon.

>> 

>>Best regards.

>> 

>>--

>>I=F1aki Baz Castillo

>>____________________________________________= ___

>>rtcweb mailing list

> _______________________________________________=

> rtcweb mailing list

> 

 

--_000_E44893DD4E290745BB608EB23FDDB7620AEDD9008AM1MPN1043mgdn_-- From thomas@cipango.org Tue Sep 13 14:00: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 C4ADD11E80F2 for ; Tue, 13 Sep 2011 14:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.023 X-Spam-Level: ** X-Spam-Status: No, score=2.023 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXKuOwPXeZto for ; Tue, 13 Sep 2011 14:00:50 -0700 (PDT) Received: from mo3.mail-out.ovh.net (19.mo3.mail-out.ovh.net [178.32.98.231]) by ietfa.amsl.com (Postfix) with ESMTP id 9853011E80DB for ; Tue, 13 Sep 2011 14:00:45 -0700 (PDT) Received: from mail33.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo3.mail-out.ovh.net (Postfix) with SMTP id 8181C1000F34 for ; Tue, 13 Sep 2011 23:04:09 +0200 (CEST) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 13 Sep 2011 23:02:46 +0200 Received: from arennes-252-1-122-2.w2-11.abo.wanadoo.fr (HELO avalon.home) (thomas.leseney%nexcom.fr@2.11.249.2) by ns0.ovh.net with SMTP; 13 Sep 2011 23:02:46 +0200 X-Ovh-Mailout: 178.32.228.3 (mo3.mail-out.ovh.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Thomas In-Reply-To: Date: Tue, 13 Sep 2011 23:02:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8840BDF9-99E1-4904-8CCA-54E7C16D7FF3@cipango.org> References: To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) X-Ovh-Tracer-Id: 14192531276857869107 X-Ovh-Remote: 2.11.249.2 (arennes-252-1-122-2.w2-11.abo.wanadoo.fr) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 20 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfedvkedrtdduucetggdotefuucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucgfrhhlucfvnfffucdlvddtmd Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Tue, 13 Sep 2011 21:03:36 -0000 Hi I=F1aki,=20 Thanks for the proposal. This is an approach that we had also in mind = and have just started to prototype a WS transport layer in cipango = (which is an open source SIP Servlets AS based on Jetty).=20 As a result, if you are willing to share the Javascript SIP/WS UA, we'll = be very glad to contribute and provide interoperability feedback.=20 Regards,=20 Thomas Le 13 sept. 2011 =E0 19:13, I=F1aki Baz Castillo a =E9crit : > Hi all, >=20 > A draft describing a mechanism for usage of WebSocket protocol as the > transport between SIP entities has been submitted and can be found at: >=20 > HTML: http://tools.ietf.org/html/draft-ibc-rtcweb-sip-websocket-00 > TXT: http://www.ietf.org/id/draft-ibc-rtcweb-sip-websocket-00.txt >=20 >=20 > Abstract >=20 > This document specifies a WebSocket subprotocol for a new transport > in SIP (Session Initiation Protocol). The WebSocket protocol = enables > two-way realtime communication between clients (typically web-based > applications) and servers. The main goal of this specification is = to > integrate the SIP protocol within web applications. >=20 >=20 > We produced this initial version after implementing a working = prototype. >=20 >=20 > Your feedback is always welcome, > The Authors >=20 >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From randell-ietf@jesup.org Tue Sep 13 14:53: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 1772C11E8127 for ; Tue, 13 Sep 2011 14:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sWTrbCdnG8k for ; Tue, 13 Sep 2011 14:53:22 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF5D11E8117 for ; Tue, 13 Sep 2011 14:53:22 -0700 (PDT) Received: from [12.104.145.50] (helo=[198.18.84.215]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R3awz-0001SU-68 for rtcweb@ietf.org; Tue, 13 Sep 2011 16:55:29 -0500 Message-ID: <4E6FD14F.7070301@jesup.org> Date: Tue, 13 Sep 2011 14:55:27 -0700 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E693A54-A8E7-46D8-94C6-7028F5497436@acmepacket.com> In-Reply-To: <2E693A54-A8E7-46D8-94C6-7028F5497436@acmepacket.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] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Sep 2011 21:53:23 -0000 On 9/12/2011 4:56 AM, Hadriel Kaplan wrote: Not answering the interesting arguments made earlier in his message right now. > 5) Architecturally, I don't understand why the *browser* needs to know about sessions. I'm not talking about individual "media sessions", but rather the SIP concept of "sessions". SDP offer/answer requires this knowledge - it needs to know when a session begins, ends, and its context/state. Minimally it needs to know this to group media info together (ie, to know that the audio and video are tied to the same session), and to handle the origin line sess-version number, and session-level attributes. Why should the _browser_ need to know that? What should it care whether the audio and video being used by a javascript are tied to one call vs. two separate calls?? Why should it even know there is such a thing as a "call"? It's a media library. Keep it simple stupid. The browser needs to know *somehow* that certain sets of audio and video streams need to be synchronized, and be given the tools and data to do so well. And you may want to synchronize multiple video streams to the same audio stream (think the dual-camera case). I am somewhat torn between ease-of-use for the developers (and increased likelihood of them getting it right) and providing a truly generic infrastructure that people *can* build anything on top of - but decreases the likelihood of getting it right, and decreases the likelihood of interop (federation) working or being easy. -- Randell Jesup randell-ietf@jesup.org From bernard_aboba@hotmail.com Tue Sep 13 15:02: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 4635121F8B00 for ; Tue, 13 Sep 2011 15:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[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 X8rZ3mpMG90D for ; Tue, 13 Sep 2011 15:02:46 -0700 (PDT) Received: from blu0-omc3-s30.blu0.hotmail.com (blu0-omc3-s30.blu0.hotmail.com [65.55.116.105]) by ietfa.amsl.com (Postfix) with ESMTP id 398D221F8AFD for ; Tue, 13 Sep 2011 15:02:46 -0700 (PDT) Received: from BLU152-W9 ([65.55.116.74]) by blu0-omc3-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Sep 2011 15:04:50 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_fda25d54-9b53-4ab7-858d-3a2a1d7c67dc_" X-Originating-IP: [198.214.235.57] From: Bernard Aboba To: , , , Date: Tue, 13 Sep 2011 15:04:50 -0700 Importance: Normal In-Reply-To: References: , <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 13 Sep 2011 22:04:50.0826 (UTC) FILETIME=[28C476A0:01CC7261] Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Sep 2011 22:02:47 -0000 --_fda25d54-9b53-4ab7-858d-3a2a1d7c67dc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I really don't know the strong reason for tunneling SIP message within we= bsocket.=20 [BA] Are you questioning the use of Websockets as opposed to other potentia= l mechanisms for tunneling SIP messages over HTTP transport? If the question is why you'd tunnel {SIP=2C XMPP} over HTTP/Websockets at a= ll=2C this enables the implementation of {SIP=2C XMPP} in Javascript. =20 > If SIP is implemented in Javascript=2C as opposed to "natively" supported= in the browser=2C Websocket is the best transport for it. [BA] That may be your opinion. Others may choose to transport SIP over HTT= P or HTTPS=2C or choose some other signaling protocol entirely (e.g. XMPP).= The beauty of RTCWEB is to enable the choice to be made by application de= velopers according to their needs.=20 > I could see a path here that the SIP server vendors should add SIP over W= ebSockets in their arsenal of transport options [BA] They might do that=2C or they could choose to have a "Connection Manag= er" (e.g. something that speaks SIP over Websockets on one side=2C and SIP = over TCP on the other) do the encapsulation/decapsulation. =20 > So maybe this draft is something that should be taken to Standards Track = within the RAI area=2C ASAP. [BA] The main point is that this work need not be done in RTCWEB.=20 = --_fda25d54-9b53-4ab7-858d-3a2a1d7c67dc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B I really don't know the strong reason for tunneling SIP message with= in websocket.

[BA] Are you questioning the use of Websockets a= s opposed to other potential mechanisms for tunneling SIP messages over HTT= P transport?

If the question is why you'd tunnel {SIP=2C XMPP} over = HTTP/Websockets at all=2C =3B this enables the implementation of {SIP= =2C XMPP} in Javascript. =3B

>=3B If SIP is implemented in Ja= vascript=2C as opposed to "natively" supported in the browser=2C Websocket = is the best transport for it.

[BA] That may be your opinion. =3B= Others may choose to transport SIP over HTTP or HTTPS=2C or choose some ot= her signaling protocol entirely (e.g. XMPP). =3B The beauty of RTCWEB i= s to enable the choice to be made by application developers according to th= eir needs.

>=3B I could see a path here that the SIP server vendo= rs should add SIP over WebSockets in their arsenal of transport options
=
[BA] They might do that=2C or they could choose to have a "Connection M= anager" (e.g. something that speaks SIP over Websockets on one side=2C and = SIP over TCP on the other) do the encapsulation/decapsulation. =3B
=
>=3B So maybe this draft is something that should be taken to Standar= ds Track within the RAI area=2C ASAP.

[BA] The main point is that th= is work need not be done in RTCWEB.
= --_fda25d54-9b53-4ab7-858d-3a2a1d7c67dc_-- From dzonatas@gmail.com Tue Sep 13 15:37: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 7BFAD21F8CC4 for ; Tue, 13 Sep 2011 15:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.875 X-Spam-Level: X-Spam-Status: No, score=-3.875 tagged_above=-999 required=5 tests=[AWL=-0.276, 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 iiULzM6KDoNH for ; Tue, 13 Sep 2011 15:37:53 -0700 (PDT) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 22E3321F8C84 for ; Tue, 13 Sep 2011 15:37:53 -0700 (PDT) Received: by gwj18 with SMTP id 18so1363830gwj.27 for ; Tue, 13 Sep 2011 15:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xaOAinYgM4KSlCDqD6ztLulQVF3dYbYKubOs4QResjw=; b=qOsRY2/ynThs9lfzBhS04Fzn+dndBqxCT/MqMbZGn6LgTr2z/u3bhlIgZka1zT1ZVb Pc/wTp0hxmG2w2uKD4bZ7sdC7VA8PWNamyk7eU3+J3bgiQhDJl4Q9Nc5ZTy7zcoOwhHb cCvztiKVfgMIcvX/MEC0aXYHbCOIHwp+T900E= Received: by 10.42.19.8 with SMTP id z8mr1157951ica.274.1315953600041; Tue, 13 Sep 2011 15:40:00 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id g16sm2859437ibs.8.2011.09.13.15.39.58 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Sep 2011 15:39:58 -0700 (PDT) Message-ID: <4E6FDC3D.8070506@gmail.com> Date: Tue, 13 Sep 2011 15:42:05 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: , <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com>, In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Sep 2011 22:37:57 -0000 On 09/13/2011 03:04 PM, Bernard Aboba wrote: > > So maybe this draft is something that should be taken to Standards > Track within the RAI area, ASAP. > > [BA] The main point is that this work need not be done in RTCWEB. > > Right. Notice here in "EAP multiplexing model" (for smartcards): http://tools.ietf.org/html/draft-urien-eap-smartcard-21#section-2.1 In cars, that would be PPPoE instead of PPP if we map from SIP. The developer curve is.... not stateless. -- --- http://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering Ag-Biotech, Virtual Reality, Consultant From dwing@cisco.com Tue Sep 13 16:30: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 41C8A21F8BC3 for ; Tue, 13 Sep 2011 16:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.242 X-Spam-Level: X-Spam-Status: No, score=-103.242 tagged_above=-999 required=5 tests=[AWL=-0.643, 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 n5YrdYpxCiAX for ; Tue, 13 Sep 2011 16:30:20 -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 9F1AF21F8BBF for ; Tue, 13 Sep 2011 16:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2062; q=dns/txt; s=iport; t=1315956748; x=1317166348; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=6oDIkBE73YW33NLeFWwJkhRfTych5EmC3dPR+IvGZyU=; b=GWyxzknX2WOorZUiljuG8tLi/pmTwULWVkdsmtjscKOMry6mqTyk3d2B 7r6TeZ3vEr5JlWYuv8vNNKKvV+ssq7fL5zHKhEXAYvg2fXA453cODMVFz eZ6GQkPyUaYCx60RCN5ubzz8573CU77SGp4R29rDzb72PYwFqOv4hm0/W U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIAABznb06rRDoH/2dsb2JhbABBmGqBbI0ieIFTAQEEAQEBAQUKARcQNAsMAQMCCQ8CBAEBAScHGQ4VCgkIAQEEARILF4dVBJk6AZ4Rhm4Eh22dEg X-IronPort-AV: E=Sophos;i="4.68,376,1312156800"; d="scan'208";a="1929796" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 13 Sep 2011 23:32:28 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8DNWRRb005348; Tue, 13 Sep 2011 23:32:27 GMT From: "Dan Wing" To: "'Matthew Kaufman'" , "'Timothy B. Terriberry'" References: <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org>, <4E6AE22A.2070106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se>, <4E6C16FF.1000706@jesup.org> <4E6CB9F7.2060208@mozilla.com> <4E6DB7F4.3090404@skype.net> In-Reply-To: <4E6DB7F4.3090404@skype.net> Date: Tue, 13 Sep 2011 16:32:27 -0700 Message-ID: <09b501cc726d$66655360$332ffa20$@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: AcxxH5S5H9TNTFRGQZaqzWV37CkBAQBTYrdw Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 13 Sep 2011 23:30:21 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Matthew Kaufman > Sent: Monday, September 12, 2011 12:43 AM > To: Timothy B. Terriberry > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] > > On 9/11/11 3:39 PM, Timothy B. Terriberry wrote: > >> * The level of media protection to use (NONE, SDES-SRTP or DTLS- > SRTP) > >> should be set by the web app > > > > Why wouldn't this devolve to, "Don't communicate anything. Instead, > > try to create a PeerConnection with DTLS-SRTP, and when that fails, > > try to create a second one with NONE," in the actual webapp. > > Yes. > > > > > Or, more likely, since NONE will have a better chance of working with > > legacy devices, "Try to create a PeerConnection with NONE, and when > > that fails, try to create a second one with DTLS-SRTP." Assuming > > anyone bothers with the second step. > > Yes, I believe this is why ekr suggested in his email that > DTLS-SRTP-only is more likely to result in encrypted connections than > having both choices available is. > > > Having the choice of SDES-SRTP or DTLS-SRTP will also make it more > > likely people won't bother with either, as they won't know which one > > to use. > > Agree. This is the best reason for not supporting SDES for keying. SDES is also not as secure as DTLS-SRTP, reference RFC5479. -d > > We can try to create incentives with browser chrome, but there's only > > so much that can do. > Agree. > > The best way to evaluate this is "if I was the one sitting in a cafe > using this, what would I want my browser to do"... and the answer to > *that* question is "I always want DTLS-SRTP between my browser and the > other end, or worst case, the gateway". (Even if there seem to be good > reasons to support plain RTP.) > > Matthew Kaufman > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Tue Sep 13 17:41: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 0719221F8B25 for ; Tue, 13 Sep 2011 17:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.105, 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 z2k1l4yiC8+h for ; Tue, 13 Sep 2011 17:41:54 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8653C21F8B1F for ; Tue, 13 Sep 2011 17:41:54 -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 p8E0iTFt008847; Tue, 13 Sep 2011 20:44:29 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Sep 2011 20:34:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC7276.008678ED" Date: Wed, 14 Sep 2011 06:03:59 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0B39@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket Thread-Index: AcxyYSvPFy4cdaaUR3+IplZ5mHD2LwAEF6Pg References: , <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com>, From: "Ravindran Parthasarathi" To: "Bernard Aboba" , , , X-OriginalArrivalTime: 14 Sep 2011 00:34:06.0181 (UTC) FILETIME=[02933150:01CC7276] Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 00:41:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC7276.008678ED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I agree with Markus for the performance concern of SIP stack in JS and it is based on SIP Stack implementation comparison between Java & C/C++ implementation. Also, I understand the concern by Roman that RFC 3261 does not consider NAT issue into its protocol design and it requires RFC 5626 implementation.=20 =20 I have explained my point of view between websocket & SIP in http://www.ietf.org/mail-archive/web/rtcweb/current/msg01058.html. SIP with websocket is a overkill instead SIP with RFC 5626 or websocket with XML (like Jingle) shall be used. I'm saying SIP with websocket as overkill because of the following reason: =20 1) Websocket helps for creating two communication between browser & server. =20 2) Server has all the intelligence required for routing between peer browsers or peer server. There is no need of one layer (SIP) above to create the dialog but lightweight XML signaling mechanism works. =20 Only limitation, I'm seeing with websocket + XML is that it calls for gateway in case of federation. I wish to hear the comments from Inaki & other author on this. =20 Apart from this, I don't know believe in providing the platform for signaling in IETF but IETF has to standardize anyone of the protocol as a standard rather than developer choice. It may be common practice for generalized products to provide platform for developing any signaling protocol (SIP, Jingle, H.323, MEGACO) but IETF should not follow path for any protocol which breaks the spirit of standardization. Let us compare any number protocols and at least recommend one signaling protocol as a choice for IETF RTCWeb client which has to be present natively for web developers. =20 Thanks Partha =20 =20 =20 From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Wednesday, September 14, 2011 3:35 AM To: markus.isomaki@nokia.com; Ravindran Parthasarathi; ibc@aliax.net; rtcweb@ietf.org Subject: RE: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket =20 > I really don't know the strong reason for tunneling SIP message within websocket.=20 [BA] Are you questioning the use of Websockets as opposed to other potential mechanisms for tunneling SIP messages over HTTP transport? If the question is why you'd tunnel {SIP, XMPP} over HTTP/Websockets at all, this enables the implementation of {SIP, XMPP} in Javascript. =20 > If SIP is implemented in Javascript, as opposed to "natively" supported in the browser, Websocket is the best transport for it. [BA] That may be your opinion. Others may choose to transport SIP over HTTP or HTTPS, or choose some other signaling protocol entirely (e.g. XMPP). The beauty of RTCWEB is to enable the choice to be made by application developers according to their needs.=20 > I could see a path here that the SIP server vendors should add SIP over WebSockets in their arsenal of transport options [BA] They might do that, or they could choose to have a "Connection Manager" (e.g. something that speaks SIP over Websockets on one side, and SIP over TCP on the other) do the encapsulation/decapsulation. =20 > So maybe this draft is something that should be taken to Standards Track within the RAI area, ASAP. [BA] The main point is that this work need not be done in RTCWEB.=20 ------_=_NextPart_001_01CC7276.008678ED Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I agree with Markus for the performance concern of SIP = stack in  JS and it is based on  SIP Stack implementation = comparison  between Java & C/C++ implementation.  Also, I understand the = concern by Roman that RFC 3261 does not consider NAT issue into its protocol = design and it requires RFC 5626 implementation.

 

I have explained my point of view between websocket & = SIP in http://www.ietf.org/mail-archive/web/rtcweb/current/msg01058.html. SIP with websocket is a overkill instead SIP with RFC 5626 or websocket = with XML (like Jingle) shall be used.  I’m saying SIP with websocket = as overkill because of the following reason:

 

1)      Websocket helps for creating two communication between = browser & server.  

2)      Server has all the intelligence required for routing = between peer browsers or peer server.

    = ;    There is no need of one layer (SIP) above to create the dialog but lightweight XML signaling mechanism works.

 

Only limitation, I’m seeing with websocket + XML is = that it calls for gateway in case of federation. I wish to hear the comments = from Inaki & other author on this.

 

Apart from this, I don’t know believe in providing = the platform for signaling in IETF but IETF has to standardize anyone of the protocol as a standard rather than developer choice. It may be =  common practice for generalized products to provide platform for developing any = signaling protocol (SIP, Jingle, H.323, MEGACO) but IETF should not follow path = for any protocol which breaks the spirit of standardization. Let us compare any = number protocols and at least recommend one signaling protocol as a choice for IETF = RTCWeb client which has to be present natively for web = developers.

 

Thanks

Partha

 

 

 

From:= Bernard = Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Wednesday, September 14, 2011 3:35 AM
To: markus.isomaki@nokia.com; Ravindran Parthasarathi; = ibc@aliax.net; rtcweb@ietf.org
Subject: RE: [rtcweb] = draft-ibc-rtcweb-sip-vs-websocket

 

> I really don't know the strong reason for tunneling SIP message within websocket.


[BA] Are you questioning the use of Websockets as opposed to other = potential mechanisms for tunneling SIP messages over HTTP transport?

If the question is why you'd tunnel {SIP, XMPP} over HTTP/Websockets at all,  this enables the implementation of {SIP, XMPP} in = Javascript. 

> If SIP is implemented in Javascript, as opposed to = "natively" supported in the browser, Websocket is the best transport for it.

[BA] That may be your opinion.  Others may choose to transport SIP = over HTTP or HTTPS, or choose some other signaling protocol entirely (e.g. = XMPP).  The beauty of RTCWEB is to enable the choice to be made by application developers according to their needs.

> I could see a path here that the SIP server vendors should add SIP = over WebSockets in their arsenal of transport options

[BA] They might do that, or they could choose to have a "Connection Manager" (e.g. something that speaks SIP over Websockets on one = side, and SIP over TCP on the other) do the encapsulation/decapsulation.  =

> So maybe this draft is something that should be taken to Standards = Track within the RAI area, ASAP.

[BA] The main point is that this work need not be done in RTCWEB. =

------_=_NextPart_001_01CC7276.008678ED-- From jmillan@aliax.net Tue Sep 13 13:14: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 CA62D21F8B00 for ; Tue, 13 Sep 2011 13:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16M+WlNzrsOz for ; Tue, 13 Sep 2011 13:14:21 -0700 (PDT) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.213.194]) by ietfa.amsl.com (Postfix) with ESMTP id BE1B521F8AF9 for ; Tue, 13 Sep 2011 13:14:21 -0700 (PDT) Received: by yxj19 with SMTP id 19so129666yxj.1 for ; Tue, 13 Sep 2011 13:16:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.14 with SMTP id l14mr9573586ibi.69.1315944988201; Tue, 13 Sep 2011 13:16:28 -0700 (PDT) Received: by 10.231.36.201 with HTTP; Tue, 13 Sep 2011 13:16:27 -0700 (PDT) Date: Tue, 13 Sep 2011 22:16:27 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: rtcweb@ietf.org, Markus.Isomaki@nokia.com Content-Type: multipart/alternative; boundary=00151773e02890d45104acd8511f X-Mailman-Approved-At: Tue, 13 Sep 2011 20:55:28 -0700 Subject: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Tue, 13 Sep 2011 20:17:17 -0000 --00151773e02890d45104acd8511f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Sep 13, 2011 at 9:25 PM, wrote: > Hi Inaki, > > Fully agree about everything you say below. Hi, Sorry if this mail arrives out of the original mail thread. > > It would be interesting to understand the performance differences of the native vs. Javascript SIP stack, if there is anything we should be worried about. This is my only concern when (perhaps one day) applying RTCWeb in devices like smartphones. If the JS stack works in (any of) today's high en= d smartphones without problems, we should be fine. The are no meaningful performance penalties at all using the JavaScript SIP stack in our prototype. In fact, multiple SIP stack instances can run in a single Web browser freshly. BTW, is there any WebSocket capable web browse= r for smartphones? > > Markus > > >>-----Original Message----- >>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >>Of ext I=F1aki Baz Castillo >>Sent: 13 September, 2011 21:23 >>To: Ravindran Parthasarathi >>Cc: rtcweb@ietf.org >>Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport >>for Session Initiation Protocol (SIP) >> >>2011/9/13 Ravindran Parthasarathi : >>> Hi Inaki, >>> >>> I like the idea of using SIP between browser & server. >>> >>> I really don't know the strong reason for tunneling SIP message within >>websocket. In fact, we are discussing SIP vs websocket in >>http://www.ietf.org/mail-archive/web/rtcweb/current/msg01071.html mail >>thread as signaling protocol for RTCweb. Could you please mention the >>technical advantage in going in the path of SIP over websocket rather tha= n >>having plain SIP connection over TCP or TLS or (UDP or DTLS). >> >>Hi Ravindran, >> >>SIP is a complex protocol and there are numerous extensions and features in >>many RFC's extending the SIP protocol. Having to rely on the features >>implemented in a native SIP stack within the web-browser seems not enough >>flexible IMHO. I also expect many limitations and lack-of-features in the >>different SIP implementations of each browser (and each version of the >>browser). >> >>In the other side, if the SIP stack is coded within a JavaScript library and makes >>usage of the WebSocket protocol, innovation depends on the developer and >>not on the browser native capabilities. A web page could offer a minimal SIP >>stack just implementing basic outgoing calls (i.e. "Click2Call" buttons i= n the >>web), while another web page could prefer to provide a powerful SIP stack >>implementing blink/attended transfer, subscription to presence and >>dialogs/calls, conference features, call-pickup, SIP messaging and so on >>(imagine such phone integrated within an enterprise intranet). I don't expect >>that the SIP stack integrated within *every* existing web-browsers would >>implement all those SIP features in a correct way (because that does not >>happen neither when using expensive SIP desktop phones or softphones). >> >>Also, the specification defined in the draft solves NAT issues (at signaling >>level) without requiring server side solutions for fixing NAT in clients. >> >>WebSocket protocol is becoming a new "transport" protocol. >>Implementing SIP protocol on top of it can only bring advantages and new >>possibilities. The specification in the draft is an adaptation of SIP to make use >>of WebSocket, as it already does with UDP, TCP and SCTP transports. >> >> >>BTW, as said in the first mail, we have published the draft after having = a >>working prototype making usage of the specification described in the >>document. After that, we see no real advantage on having a native SIP stack >>within a web browser. The prototype will be shown soon. >> >>Best regards. >> >>-- >>I=F1aki Baz Castillo >> >>_______________________________________________ >>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 > --00151773e02890d45104acd8511f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Sep 13, 2011 at 9:25 PM, =A0<Markus.Isomaki@nokia.com> wrote:
> Hi Inaki= ,
>
> Fully agree about everything you say below.
<= div>
Hi,

Sorry if this mail arrives = out of the original mail thread.

>
> It would be interesting to understand the performance differences of t= he native vs. Javascript SIP stack, if there is anything we should be worri= ed about. This is my only concern when (perhaps one day) applying RTCWeb in= devices like smartphones. If the JS stack works in (any of) today's hi= gh end smartphones without problems, we should be fine.

The are no meaningful performance penalties at all usin= g the JavaScript SIP stack in our prototype. In fact, multiple SIP stack in= stances can run in a single Web browser freshly. =A0BTW, is there any WebSo= cket capable web browser for smartphones?

>
> Markus
>
>= ;
>>-----Original Message-----
>>From: rtcweb-bounces@ietf.org [mailto:= rtcweb-bounces@ietf.org] On = Behalf
>>Of ext I=F1aki Baz Castillo
>>Sent: 13 Septemb= er, 2011 21:23
>>To: Ravindran Parthasarathi
&g= t;>Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Tra= nsport
>>for Session Initiation Protocol (SIP)
>>
=
>>2011/9/13 Ravindran Parthasarathi <pravindran@sonusnet.com>:
>>> = Hi Inaki,
>>>
>>> I like the idea of using SIP betwe= en browser & server.
>>>
>>> I re= ally don't know the strong reason for tunneling SIP message within
>>websocket. In fact, we are discussing SIP vs websocket in
>>thread as signaling protocol for RTCweb. Could you please ment= ion the
>>technical advantage in going in the path of SIP o= ver websocket rather than
>>having plain SIP connection ove= r TCP or TLS or (UDP or DTLS).
>>
>>Hi Ravindran,
>>
= >>SIP is a complex protocol and there are numerous extensions and fea= tures in
>>many RFC's extending the SIP protocol. Havin= g to rely on the features
>>implemented in a native SIP stack within the web-browser seems= not enough
>>flexible IMHO. I also expect many limitations= and lack-of-features in the
>>different SIP implementation= s of each browser (and each version of the
>>browser).
>>
>>In the other si= de, if the SIP stack is coded within a JavaScript library and makes
>>usage of the WebSocket protocol, innovation depends on the devel= oper and
>>not on the browser native capabilities. A web page could offer= a minimal SIP
>>stack just implementing basic outgoing cal= ls (i.e. "Click2Call" buttons in the
>>web), whil= e another web page could prefer to provide a powerful SIP stack
>>implementing blink/attended transfer, subscription to presence= and
>>dialogs/calls, conference features, call-pickup, SIP= messaging and so on
>>(imagine such phone integrated withi= n an enterprise intranet). I don't expect
>>that the SIP stack integrated within *every* existing web-brow= sers would
>>implement all those SIP features in a correct = way (because that does not
>>happen neither when using expe= nsive SIP desktop phones or softphones).
>>
>>Also, the specification defined in the draf= t solves NAT issues (at signaling
>>level) without requirin= g server side solutions for fixing NAT in clients.
>>
>>WebSocket protocol is becoming a new "transport" pro= tocol.
>>Implementing SIP protocol on top of it can only br= ing advantages and new
>>possibilities. The specification i= n the draft is an adaptation of SIP to make use
>>of WebSocket, as it already does with UDP, TCP and SCTP transp= orts.
>>
>>
>>BTW, as said = in the first mail, we have published the draft after having a
>>working prototype making usage of the specification described in th= e
>>document. After that, we see no real advantage on havin= g a native SIP stack
>>within a web browser. The prototype = will be shown soon.
>>
>>Best regards.
>>
= >>--
>>I=F1aki Baz Castillo
>>_____= __________________________________________
>>rtcweb mailing list
> _______________________________________________
> rt= cweb mailing list
>

--00151773e02890d45104acd8511f-- From binod.pg@oracle.com Tue Sep 13 21:36: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 EE9F321F87F0 for ; Tue, 13 Sep 2011 21:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeFOhUuP9n+r for ; Tue, 13 Sep 2011 21:36:42 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0171121F86AA for ; Tue, 13 Sep 2011 21:36:41 -0700 (PDT) Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8E4ckNd021245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 04:38:48 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8E4cjvI008302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 04:38:46 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8E4cd86000850; Tue, 13 Sep 2011 23:38:39 -0500 Received: from [192.168.0.10] (/192.18.192.76) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Sep 2011 21:38:39 -0700 Message-Id: <1810E0F6-9600-4BF5-82A9-ADCC07103999@oracle.com> From: Binod PG To: Bernard Aboba In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-140-512978918 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Sep 2011 10:08:31 +0530 References: , <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com>, X-Mailer: Apple Mail (2.936) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090209.4E702FD9.0008,ss=1,re=0.000,fgs=0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 04:36:43 -0000 --Apple-Mail-140-512978918 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 14-Sep-11, at 3:34 AM, Bernard Aboba wrote: > > I really don't know the strong reason for tunneling SIP message > within websocket. > > [BA] Are you questioning the use of Websockets as opposed to other > potential mechanisms for tunneling SIP messages over HTTP transport? > > If the question is why you'd tunnel {SIP, XMPP} over HTTP/Websockets > at all, this enables the implementation of {SIP, XMPP} in Javascript. > > > If SIP is implemented in Javascript, as opposed to "natively" > supported in the browser, Websocket is the best transport for it. > > [BA] That may be your opinion. Others may choose to transport SIP > over HTTP or HTTPS, or choose some other signaling protocol entirely > (e.g. XMPP). The beauty of RTCWEB is to enable the choice to be > made by application developers according to their needs. How do you see a media gateway library in the (web) server handle all such signaling protocols/transport? Would RTCWeb provide/have a mechanism to indicate the protocol/signal chosen by the application? thanks, Binod. [As an Individual] --Apple-Mail-140-512978918 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On 14-Sep-11, at = 3:34 AM, Bernard Aboba wrote:

> I really don't know the strong reason for = tunneling SIP message within websocket. 

[BA] Are you = questioning the use of Websockets as opposed to other potential = mechanisms for tunneling SIP messages over HTTP transport?

If the = question is why you'd tunnel {SIP, XMPP} over HTTP/Websockets at = all,  this enables the implementation of {SIP, XMPP} in = Javascript.  

> If SIP is = implemented in Javascript, as opposed to "natively" supported in the = browser, Websocket is the best transport for it.

[BA] That may be = your opinion.  Others may choose to transport SIP over HTTP or = HTTPS, or choose some other signaling protocol entirely (e.g. = XMPP).  The beauty of RTCWEB is to enable the choice to be made by = application developers according to their needs. 
=

How do you see a media gateway library = in the (web) server handle all such signaling protocols/transport? Would = RTCWeb provide/have a mechanism
to indicate the = protocol/signal chosen by the = application?

thanks,
Binod.
[= As an Individual]
= --Apple-Mail-140-512978918-- From pmcmanus@mozilla.com Tue Sep 13 21:39: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 AD18221F8BAA for ; Tue, 13 Sep 2011 21:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBRdnhgwAGtS for ; Tue, 13 Sep 2011 21:39:46 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id DA91021F87F0 for ; Tue, 13 Sep 2011 21:39:46 -0700 (PDT) Received: from Patrick-McManuss-MacBook.local (unknown [12.104.145.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 8B85610193; Wed, 14 Sep 2011 00:41:54 -0400 (EDT) Message-ID: <4E703091.10303@mozilla.com> Date: Tue, 13 Sep 2011 21:41:53 -0700 From: Patrick McManus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030802060603060007050003" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Wed, 14 Sep 2011 04:39:47 -0000 This is a multi-part message in MIME format. --------------030802060603060007050003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 9/13/11 1:16 PM, Jos Luis Milln wrote: > is there any WebSocket capable web browser for smartphones? at least Firefox 7 (still on the beta channel for a few more weeks) for android. -Patrick --------------030802060603060007050003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/13/11 1:16 PM, José Luis Millán wrote:
 is there any WebSocket capable web browser for smartphones?

at least Firefox 7 (still on the beta channel for a few more weeks) for android.

-Patrick

--------------030802060603060007050003-- From HKaplan@acmepacket.com Tue Sep 13 22:21: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 C98B421F8C66 for ; Tue, 13 Sep 2011 22:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 6X6iadM0LEv5 for ; Tue, 13 Sep 2011 22:21:00 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 96CE121F8C6C for ; Tue, 13 Sep 2011 22:21:00 -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; Wed, 14 Sep 2011 01:23:05 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 01:23:05 -0400 From: Hadriel Kaplan To: Binod PG Thread-Topic: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket Thread-Index: AQHMcp5hzWFMPh2uPkK6gmL4ZhCr6Q== Date: Wed, 14 Sep 2011 05:23:04 +0000 Message-ID: <7B7B2040-1523-4C10-8B9B-D4EE3FB541A9@acmepacket.com> References: , <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com>, <1810E0F6-9600-4BF5-82A9-ADCC07103999@oracle.com> In-Reply-To: <1810E0F6-9600-4BF5-82A9-ADCC07103999@oracle.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="us-ascii" Content-ID: <4BFF11ACBA75E547AEBD74B2A4F2AFCB@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 05:21:01 -0000 On Sep 14, 2011, at 12:38 AM, Binod PG wrote: >=20 > On 14-Sep-11, at 3:34 AM, Bernard Aboba wrote: >>=20 >> [BA] That may be your opinion. Others may choose to transport SIP over = HTTP or HTTPS, or choose some other signaling protocol entirely (e.g. XMPP)= . The beauty of RTCWEB is to enable the choice to be made by application d= evelopers according to their needs.=20 >=20 > How do you see a media gateway library in the (web) server handle all suc= h signaling protocols/transport? Would RTCWeb provide/have a mechanism > to indicate the protocol/signal chosen by the application? No. The server is deployed by the same people who deploy the javascript, s= ince by definition the javascript is provided by that server. It's not a m= ystery to the web server what the "signaling protocol" used between the jav= ascript and the server is - its whatever the developer of the javascript an= d server-side code decides it to be. It doesn't have to be any standard wh= atsoever, because there is no interoperability problem to solve between the= m. It could be XMPP, or it could be SIP, or it could be MGCP, or it could = be Skinny/SCCP, or it could be create-your-own. There may well be pre-pack= aged js libraries available which do it all for you, but they can do it how= ever they like.=20 -hadriel From john.elwell@siemens-enterprise.com Tue Sep 13 22:48: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 E5B1B21F8C74 for ; Tue, 13 Sep 2011 22:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.042 X-Spam-Level: X-Spam-Status: No, score=-103.042 tagged_above=-999 required=5 tests=[AWL=-0.443, 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 TpEICbuQYssW for ; Tue, 13 Sep 2011 22:48:31 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id B764F21F8C66 for ; Tue, 13 Sep 2011 22:48:30 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 1577B23F04AA; Wed, 14 Sep 2011 07:50:36 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 14 Sep 2011 07:50:36 +0200 From: "Elwell, John" To: Hadriel Kaplan , Ravindran Parthasarathi Date: Wed, 14 Sep 2011 07:50:34 +0200 Thread-Topic: [rtcweb] Proposed text - remote recording use case Thread-Index: AQHMciK7XwUojQUk70aUevXP868dwpVMX0ww Message-ID: References: <2E239D6FCD033C4BAF15F386A979BF510F09ED@sonusinmail02.sonusnet.com> <8357A942-21EA-4209-82DB-ADFCEB5F32EF@acmepacket.com> In-Reply-To: <8357A942-21EA-4209-82DB-ADFCEB5F32EF@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 05:48:32 -0000 =20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: 13 September 2011 15:38 > To: Ravindran Parthasarathi > Cc: Elwell, John; > Subject: Re: [rtcweb] Proposed text - remote recording use case >=20 > inline... >=20 > On Sep 11, 2011, at 4:29 PM, Ravindran Parthasarathi wrote: >=20 > > New requirements: > > Fyy1: The browser MUST be able to send in real-time to an another > > browser/session recording server(SRS) that are being=20 > transmitted to and > > received from remote browser. >=20 > That doesn't make sense in English - *what* needs to be sent=20 > in real-time? Removing the word "media" broke the meaning. =20 > Also, the media it needs to replicate/fork may not be to/from=20 > another "remote browser" - it could be to/from a remote=20 > gateway, SIP UA, whatever. Really what you want to say is=20 > to/from a "remote peer". > Same issues/comments go for the next requirement. [JRE] I agree the modified words don't make sense and would like to stick t= o the words I proposed at the start of this thread. >=20 > >=20 > > Ayy1: The web application MUST be able to ask the browser=20 > to transmit in > > real-time to another browser/session recording server(SRS) that are > > being transmitted to and received from remote browser. >=20 > Same as above. >=20 > > As I asked in the meeting (but couldn't discuss due to time=20 > constraint), > > it is possible for browser to do the signaling directly to the SRS > > without going through original webserver. The signaling towards > > recording is not required to be SIP but it shall be websocket (let > > discuss separately). Here, the advantageous in this model=20 > is that the > > recording signaling hop is reduced to 1 hop (browser to SRS) from 2 > > hops (browser to webserver, webserver to SRS). > >=20 >=20 > Actually, I don't think it is possible for the rtcweb browser=20 > to properly do SIPREC, even if it had a SIP stack to do it=20 > with. The reason is the browser doesn't know the full call=20 > metadata. The browser doesn't know the calling/called party=20 > info, for example. Even the javascript itself may not know=20 > it, depending on how the application provider does their=20 > logic. They could decide to have some state/logic be handled=20 > by the web server, rather than all in the javascript. For=20 > example the javascript may just display a list of friends=20 > using aliases or icons, and the web server may be the only=20 > one who knows what the friend's AoR/URI actually is for that alias. =20 [JRE] Quite so. Metadata would come from the application, but whether this = is server-side or client-side is out of scope for RTC-Web. The important th= ing is that an application that is able to do the SIP and Metadata part of = SIPREC can ask the browser to do the media part. John >=20 > -hadriel >=20 > = From john.elwell@siemens-enterprise.com Tue Sep 13 22:51: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 A1DEF21F8B3A for ; Tue, 13 Sep 2011 22:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.04 X-Spam-Level: X-Spam-Status: No, score=-103.04 tagged_above=-999 required=5 tests=[AWL=-0.441, 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 7Cl8FR3ivcq7 for ; Tue, 13 Sep 2011 22:51:26 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id CAAB221F8A91 for ; Tue, 13 Sep 2011 22:51:25 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 16B451EB8461; Wed, 14 Sep 2011 07:53:31 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 14 Sep 2011 07:53:31 +0200 From: "Elwell, John" To: Hadriel Kaplan , Harald Alvestrand Date: Wed, 14 Sep 2011 07:53:29 +0200 Thread-Topic: [rtcweb] Proposed text - remote recording use case Thread-Index: AQHMcjBe44ynxue6Dkeiz3Tz6NhmfZVMYF4g Message-ID: References: <4E6F6624.3070809@alvestrand.no> <085A341A-9B3D-4DC8-8685-CD9DF811E102@acmepacket.com> In-Reply-To: <085A341A-9B3D-4DC8-8685-CD9DF811E102@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 05:51:28 -0000 =20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: 13 September 2011 17:16 > To: Harald Alvestrand; Elwell, John > Cc: Elwell, John; rtcweb@ietf.org > Subject: Re: [rtcweb] Proposed text - remote recording use case >=20 > Actually, I think remote recording may already be possible=20 > without anything new. >=20 > Draft-ietf-rtcweb-use-cases-and-requirements-04 has a=20 > use-case 4.2.7 for "Multiparty video communication", and=20 > associated requirements. All you need for remote recording=20 > is the ability for the javascript to create a separate media=20 > stream to the recorder (SRS), as if the SRS were a third=20 > participant, and fork the user's audio/video into both=20 > streams. The 4.2.7 requirement implies that will be possible. >=20 > What's not handled by that is replicating the received=20 > audio/video from the peer into the recording stream to the=20 > SRS - i.e., the browser will be able to fork the locally=20 > generated media, but not the media received from the peer. =20 > For sessions between two rtcweb browsers controlled by the=20 > same provider this could still work, since both rtcweb=20 > browsers could be told to create streams to the SRS for both=20 > halves of media to be recorded. For calls to/from another=20 > domain, if one uses SIP between the servers then one could do=20 > real SIPREC in a logical SIP B2BUA there. [JRE] I don't think that is good enough - it should not be necessary to rel= y on a remote peer to send its media to the recorder, particularly in feder= ation cases. Both directions of media should come from the one peer. John >=20 > -hadriel > p.s. the ability for rtcweb browsers to create conf calls by=20 > doing half-mixing and using a full mesh of media streams is=20 > not normal for SIP, and may be rather tricky to get to work=20 > right if the participants are not in the same domain and SIP=20 > has to be used between. Was the intention that such=20 > inter-domain cases would require a centralized conf server=20 > instead of direct media meshing? >=20 >=20 > On Sep 13, 2011, at 10:18 AM, Harald Alvestrand wrote: >=20 > > I like this text for capturing the use case. > >=20 > > I agree with Matthew that it seems to come with some=20 > special caveats that we should consider whether we can solve=20 > before agreeing that this is an use case we MUST solve - but=20 > some of those issues may be issues we will face as a natural=20 > consequence of the API proposal anyway. > >=20 > > I suggest that Stefan add it to the use case draft under=20 > "use cases considered", so that we have the text in the=20 > draft, with a note that the WG has not accepted this as a=20 > "must do" use case. > >=20 > > On 09/09/11 18:41, Elwell, John wrote: > >> On yesterday's call it was agreed to work on text to cover=20 > the remote recording use case. Below is text, based on an=20 > earlier proposal and subsequent input. I have focused on the=20 > main requirement derived from this use case, relating to=20 > copying to a different peer connection, and skipped any more=20 > detailed requirements concerning possible mixing of the two=20 > directions of audio or injecting any tones / announcements. > >>=20 > >> 4.2.yy Remote Session Recording > >> In this use case, the web application user wishes to=20 > record a real-time communication at a remote third party=20 > (e.g., a recording device), such that transmitted and=20 > received audio, video or other real-time media are=20 > transmitted in real-time to the third party. The third party=20 > can perform recording, archiving, retrieval, playback, etc.,=20 > but can also perform real-time analytics on the media. A=20 > typical deployment might be in a contact centre. The web=20 > application also sends metadata that gives context to the=20 > stored media. The web application will ensure that=20 > appropriate indications are given to participants so that=20 > they are aware of recording. > >>=20 > >> New requirements: > >> Fyy1: The browser MUST be able to send in real-time to a=20 > third party media that are being transmitted to and received=20 > from remote participants. > >>=20 > >> Ayy1: The web application MUST be able to ask the browser=20 > to transmit in real-time to a third party media that are=20 > being transmitted to and received from remote participants. > >>=20 > >> Comments? > >>=20 > >> John > >>=20 > >>=20 > >> John Elwell > >> Tel: +44 1908 817801 (office and mobile) > >> Email: john.elwell@siemens-enterprise.com > >> http://www.siemens-enterprise.com/uk/ > >>=20 > >> Siemens Enterprise Communications Limited. > >> Registered office: Brickhill Street, Willen Lake, Milton=20 > Keynes, MK15 0DJ. > >> Registered No: 5903714, England. > >>=20 > >> Siemens Enterprise Communications Limited is a Trademark=20 > Licensee of Siemens AG. > >>=20 > >>=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 >=20 > = From binod.pg@oracle.com Tue Sep 13 22:51: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 C7ED221F8C5B for ; Tue, 13 Sep 2011 22:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5GAf3-Ryb7x for ; Tue, 13 Sep 2011 22:51:57 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id E506A21F8C58 for ; Tue, 13 Sep 2011 22:51:56 -0700 (PDT) Received: from rtcsinet22.oracle.com (rtcsinet22.oracle.com [66.248.204.30]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8E5s1c7032354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Sep 2011 05:54:03 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8E5rxkl028065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 05:54:00 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8E5rsTu029934; Wed, 14 Sep 2011 00:53:54 -0500 Received: from dhcp-cblr03-229-154.India.Sun.COM (/129.158.229.154) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 13 Sep 2011 22:53:54 -0700 Message-Id: From: Binod PG To: Hadriel Kaplan In-Reply-To: <7B7B2040-1523-4C10-8B9B-D4EE3FB541A9@acmepacket.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Sep 2011 11:23:50 +0530 References: , <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com>, <1810E0F6-9600-4BF5-82A9-ADCC07103999@oracle.com> <7B7B2040-1523-4C10-8B9B-D4EE3FB541A9@acmepacket.com> X-Mailer: Apple Mail (2.936) X-Source-IP: rtcsinet22.oracle.com [66.248.204.30] X-CT-RefId: str=0001.0A090207.4E70417B.0149,ss=1,re=0.000,fgs=0 Cc: "" Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 05:51:57 -0000 On 14-Sep-11, at 10:53 AM, Hadriel Kaplan wrote: > > On Sep 14, 2011, at 12:38 AM, Binod PG wrote: > >> >> On 14-Sep-11, at 3:34 AM, Bernard Aboba wrote: >>> >>> [BA] That may be your opinion. Others may choose to transport SIP >>> over HTTP or HTTPS, or choose some other signaling protocol >>> entirely (e.g. XMPP). The beauty of RTCWEB is to enable the >>> choice to be made by application developers according to their >>> needs. >> >> How do you see a media gateway library in the (web) server handle >> all such signaling protocols/transport? Would RTCWeb provide/have a >> mechanism >> to indicate the protocol/signal chosen by the application? > > No. The server is deployed by the same people who deploy the > javascript, since by definition the javascript is provided by that > server. It's not a mystery to the web server what the "signaling > protocol" used between the javascript and the server is - its > whatever the developer of the javascript and server-side code > decides it to be. It doesn't have to be any standard whatsoever, > because there is no interoperability problem to solve between them. > It could be XMPP, or it could be SIP, or it could be MGCP, or it > could be Skinny/SCCP, or it could be create-your-own. There may > well be pre-packaged js libraries available which do it all for you, > but they can do it however they like. A webserver can host multiple web applications (potentially from multiple vendors altogether). If some web applications need to gateway between browser and another legacy protocol (eg: SIP, XMPP....), then a good number of applications would like to use a generic media gateway component or library. For someone to develop such a media gateway library, doesn't it need to know, what protocol it is brokering? Or you do not consider that to be an important aspect? - Binod. From pravindran@sonusnet.com Tue Sep 13 23: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 8CC1321F8C7A for ; Tue, 13 Sep 2011 23:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 AW+kqzSTZh+D for ; Tue, 13 Sep 2011 23:01:59 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 79CEF21F8C2B for ; Tue, 13 Sep 2011 23:01:59 -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 p8E64ZVf022461; Wed, 14 Sep 2011 02:04:35 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 01:57:31 -0400 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, 14 Sep 2011 11:27:28 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0B4E@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Proposed text - remote recording use case Thread-Index: AQHMciK7XwUojQUk70aUevXP868dwpVMX0wwgAABGYA= References: <2E239D6FCD033C4BAF15F386A979BF510F09ED@sonusinmail02.sonusnet.com> <8357A942-21EA-4209-82DB-ADFCEB5F32EF@acmepacket.com> From: "Ravindran Parthasarathi" To: "Elwell, John" , "Hadriel Kaplan" X-OriginalArrivalTime: 14 Sep 2011 05:57:31.0566 (UTC) FILETIME=[3115F4E0:01CC72A3] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 06:02:00 -0000 John, I'm fine with Hadriel proposal of "remote peer" instead "remote browser or SRS" but not the original wordings. At this moment, I'm not convinced whether SIPREC SRS will interop with RTCWeb browser because the signaling protocol is an open item in RTCWeb. The recording could be done by two websocket from browser wherein one websocket towards webserver and other towards recorder. How these entities interact with each other has to be discussed & defined. Please let me know the reason why this approach may not be followed in RTCWeb. Thanks Partha=20 >-----Original Message----- >From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >Sent: Wednesday, September 14, 2011 11:21 AM >To: Hadriel Kaplan; Ravindran Parthasarathi >Cc: >Subject: RE: [rtcweb] Proposed text - remote recording use case > > > >> -----Original Message----- >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> Sent: 13 September 2011 15:38 >> To: Ravindran Parthasarathi >> Cc: Elwell, John; >> Subject: Re: [rtcweb] Proposed text - remote recording use case >> >> inline... >> >> On Sep 11, 2011, at 4:29 PM, Ravindran Parthasarathi wrote: >> >> > New requirements: >> > Fyy1: The browser MUST be able to send in real-time to an another >> > browser/session recording server(SRS) that are being >> transmitted to and >> > received from remote browser. >> >> That doesn't make sense in English - *what* needs to be sent >> in real-time? Removing the word "media" broke the meaning. >> Also, the media it needs to replicate/fork may not be to/from >> another "remote browser" - it could be to/from a remote >> gateway, SIP UA, whatever. Really what you want to say is >> to/from a "remote peer". >> Same issues/comments go for the next requirement. >[JRE] I agree the modified words don't make sense and would like to >stick to the words I proposed at the start of this thread. > >> >> > >> > Ayy1: The web application MUST be able to ask the browser >> to transmit in >> > real-time to another browser/session recording server(SRS) that are >> > being transmitted to and received from remote browser. >> >> Same as above. >> >> > As I asked in the meeting (but couldn't discuss due to time >> constraint), >> > it is possible for browser to do the signaling directly to the SRS >> > without going through original webserver. The signaling towards >> > recording is not required to be SIP but it shall be websocket (let >> > discuss separately). Here, the advantageous in this model >> is that the >> > recording signaling hop is reduced to 1 hop (browser to SRS) from 2 >> > hops (browser to webserver, webserver to SRS). >> > >> >> Actually, I don't think it is possible for the rtcweb browser >> to properly do SIPREC, even if it had a SIP stack to do it >> with. The reason is the browser doesn't know the full call >> metadata. The browser doesn't know the calling/called party >> info, for example. Even the javascript itself may not know >> it, depending on how the application provider does their >> logic. They could decide to have some state/logic be handled >> by the web server, rather than all in the javascript. For >> example the javascript may just display a list of friends >> using aliases or icons, and the web server may be the only >> one who knows what the friend's AoR/URI actually is for that alias. >[JRE] Quite so. Metadata would come from the application, but whether >this is server-side or client-side is out of scope for RTC-Web. The >important thing is that an application that is able to do the SIP and >Metadata part of SIPREC can ask the browser to do the media part. > >John > > >> >> -hadriel >> >> From Ranjit.Avasarala@Polycom.com Tue Sep 13 23:21: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 25D7C21F85F6 for ; Tue, 13 Sep 2011 23:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.363 X-Spam-Level: X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 HE0thlw5e8qj for ; Tue, 13 Sep 2011 23:21:32 -0700 (PDT) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDA821F85F1 for ; Tue, 13 Sep 2011 23:21:31 -0700 (PDT) Received: from hkgmboxprd22.polycom.com ([fe80::557a:beb0:19b1:3a9e]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Wed, 14 Sep 2011 14:23:38 +0800 From: "Avasarala, Ranjit" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "rtcweb@ietf.org" Date: Wed, 14 Sep 2011 14:23:34 +0800 Thread-Topic: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP) Thread-Index: AcxyOI9L+V5pmaCaQjiwi1QRuRscgwAbKeuQ Message-ID: <1F2A2C70609D9E41844A2126145FC09802585056@HKGMBOXPRD22.polycom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Wed, 14 Sep 2011 06:21:33 -0000 SGkgSW5ha2kNCg0KSSBoYXZlIGZldyBpbml0aWFsIGNvbW1lbnRzIG9uIHlvdXIgZHJhZnQNCg0K MSkgaW4gU2VjdGlvbiAzLCBpdHMgbWVudGlvbmVkIHRoYXQgdGhlcmUgaXMgbm8gcmVhbCBiZW5l Zml0IG9mIHVzaW5nIFNJUCBvdmVyIFdlYnNvY2tldHMuIElmIHRoaXMgaXMgdGhlIGNhc2UsIHdo eSBhcmUgeW91IHByb3Bvc2luZyBpbnRlZ3JhdGluZyBTSVAgd2l0aCBXZWJzb2NrZXRzPw0KMikg QWxzbyBqdXN0IGludGVncmF0aW5nIFNJUCBmb3Igc2lnbmFsaW5nIGNhc2UgaXMgcmVhbGx5IG5v IHVzZSwgYXMgdGhlcmUgYXJlIHNldmVyYWwgb3RoZXIgd2F5cyBvZiBhY2hpZXZpbmcgc2lnbmFs aW5nIGluIHdlYiAtIEUuZy4gdXNpbmcgbGliamluZ2xlIG9mIFdlYlJUQywgZXRjDQozKSBJbiBT ZWN0aW9uIDQsIHlvdSBtZW50aW9uZWQgdGhhdCBzaW5jZSBXZWJzb2NrZXQgaXMgYSByZWxpYWJs ZSB0cmFuc3BvcnQgcHJvdG9jb2wsIHRoZSB3ZWJzb2NrZXQgc3ViLXByb3RvY29sIGRlZmluZWQg Zm9yIFNJUCBhbHNvIGJlY29tZXMgcmVsaWFibGUuIEkgZG9uJ3QgYWdyZWUgd2l0aCB0aGlzIC0g VGhlIHdlYnNvY2tldCBjb25uZWN0aW9uIGlzIGFjdHVhbGx5IGluaXRpYXRlZCBieSB0aGUgd2Vi IGJyb3dzZXIgY2xpZW50IHRvd2FyZHMgdGhlIHdlYiBzZXJ2ZXIgYW5kIHRoaXMgY29ubmVjdGlv biBuZWVkcyB0byBiZSBrZXB0IGFsaXZlIHRocm91Z2ggc29tZSBrZWVwIGFsaXZlIG1lY2hhbmlz bS4gT3RoZXJ3aXNlIHRoZSBjb25uZWN0aW9uIG1heSBjbG9zZS4gSSBhbSBub3Qgc3VyZSBvZiBy ZWxpYWJpbGl0eS4NCjQpIEluIFNlY3Rpb24gNC4xLEkgYW0gbm90IGNsZWFyIG9mIHRoZSBWaWEg dHJhbnNwb3J0IHBhcmFtZXRlciBoYXZpbmcgdGhlIHZhbHVlIG9mICJXUyIuIFdoeSBkbyB5b3Ug bmVlZCB0aGlzIHdoZW4gdGhlIHdob2xlIFNJUCBtZXNzYWdlIGlzIGdvaW5nIGFzIHBhcnQgb2Yg V2ViU29ja2V0IHBheWxvYWQgW1VzaW5nIHdlYnNvY2tldCBBUEldPw0KDQpUaGFucw0KDQpSZWdh cmRzDQpSYW5qaXQNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcnRjd2Vi LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEnDsWFraSBCYXogQ2FzdGlsbG8NClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAxMywg MjAxMSAxMDo0MyBQTQ0KVG86IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogW3J0Y3dlYl0gZHJh ZnQtaWJjLXJ0Y3dlYi1zaXAtd2Vic29ja2V0IC0tIFdlYlNvY2tldCBUcmFuc3BvcnQgZm9yIFNl c3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKQ0KDQpIaSBhbGwsDQoNCkEgZHJhZnQgZGVz Y3JpYmluZyBhIG1lY2hhbmlzbSBmb3IgdXNhZ2Ugb2YgV2ViU29ja2V0IHByb3RvY29sIGFzIHRo ZQ0KdHJhbnNwb3J0IGJldHdlZW4gU0lQIGVudGl0aWVzIGhhcyBiZWVuIHN1Ym1pdHRlZCBhbmQg Y2FuIGJlIGZvdW5kIGF0Og0KDQogIEhUTUw6ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pYmMtcnRjd2ViLXNpcC13ZWJzb2NrZXQtMDANCiAgVFhUOiAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9pZC9kcmFmdC1pYmMtcnRjd2ViLXNpcC13ZWJzb2NrZXQtMDAudHh0DQoNCg0KQWJz dHJhY3QNCg0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBXZWJTb2NrZXQgc3VicHJvdG9j b2wgZm9yIGEgbmV3IHRyYW5zcG9ydA0KICAgaW4gU0lQIChTZXNzaW9uIEluaXRpYXRpb24gUHJv dG9jb2wpLiAgVGhlIFdlYlNvY2tldCBwcm90b2NvbCBlbmFibGVzDQogICB0d28td2F5IHJlYWx0 aW1lIGNvbW11bmljYXRpb24gYmV0d2VlbiBjbGllbnRzICh0eXBpY2FsbHkgd2ViLWJhc2VkDQog ICBhcHBsaWNhdGlvbnMpIGFuZCBzZXJ2ZXJzLiAgVGhlIG1haW4gZ29hbCBvZiB0aGlzIHNwZWNp ZmljYXRpb24gaXMgdG8NCiAgIGludGVncmF0ZSB0aGUgU0lQIHByb3RvY29sIHdpdGhpbiB3ZWIg YXBwbGljYXRpb25zLg0KDQoNCldlIHByb2R1Y2VkIHRoaXMgaW5pdGlhbCB2ZXJzaW9uIGFmdGVy IGltcGxlbWVudGluZyBhIHdvcmtpbmcgcHJvdG90eXBlLg0KDQoNCllvdXIgZmVlZGJhY2sgaXMg YWx3YXlzIHdlbGNvbWUsDQpUaGUgQXV0aG9ycw0KDQoNCi0tIA0KScOxYWtpIEJheiBDYXN0aWxs bw0KPGliY0BhbGlheC5uZXQ+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K From Markus.Isomaki@nokia.com Tue Sep 13 23:57: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 0599D21F8B70 for ; Tue, 13 Sep 2011 23:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 UNTcBS3x7509 for ; Tue, 13 Sep 2011 23:57:01 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3319621F8B52 for ; Tue, 13 Sep 2011 23:57:00 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8E6x1xr006354; Wed, 14 Sep 2011 09:59:07 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 09:58:50 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 08:58:43 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.204]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0323.007; Wed, 14 Sep 2011 08:58:43 +0200 From: To: , , , Thread-Topic: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket Thread-Index: AQHMcmEvDLfcdR4ELUe0eYbl0qA1j5VMbifw Date: Wed, 14 Sep 2011 06:58:43 +0000 Message-ID: References: , <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com>, 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 06:58:50.0415 (UTC) FILETIME=[C1D9C3F0:01CC72AB] X-Nokia-AV: Clean Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 06:57:04 -0000 Hi, Bernard Aboba [BA] wrote: >> If SIP is implemented in Javascript, as opposed to "natively" supported = in the browser, Websocket is the best transport for it. > >[BA] That may be your opinion.=A0 Others may choose to transport SIP over = HTTP or HTTPS, or choose some other signaling protocol entirely (e.g. XMPP)= .=A0 The beauty of RTCWEB is to enable the choice to be made by application= developers according to their needs.=20 People can continue using HTTP ("COMET") for this type of purposes as long = as they like. I think Websockes is just a more optimal way due to smaller o= verhead and cleaner connection management. But it is upto the service provi= der, and of course availability of Websockets in browsers is an important f= actor too. >> I could see a path here that the SIP server vendors should add SIP over = WebSockets in their arsenal of transport options >[BA] They might do that, or they could choose to have a "Connection Manage= r" (e.g. something that speaks SIP over Websockets on one side, and SIP ove= r TCP on the other) do the encapsulation/decapsulation.=A0=20 Right. I suppose there are these type of things for XMPP already, i.e. spea= king XMPP over BOSH/HTTP one way and XMPP over TCP the other. The same coul= d be useful for SIP, if Javascript SIP stacks gain popularity. (They are ce= rtainly popular on this list, but I'm not sure if that is a good measure of= the "real world" :-). People could make their deployments without a formal= standardization of SIP over HTTP or SIP over Websockets too, at least as l= ong as the Javascript stack and the "connection manager" came from the same= provider. Hmm, perhaps that is good enough.=20 Markus From saul@ag-projects.com Wed Sep 14 00:00: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 6BB1821F8B6E for ; Wed, 14 Sep 2011 00:00:24 -0700 (PDT) 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=[AWL=0.086, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNN8MMiNtwJl for ; Wed, 14 Sep 2011 00:00:24 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id B58C521F8B54 for ; Wed, 14 Sep 2011 00:00:23 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id ED8ADB01B7; Wed, 14 Sep 2011 09:02:30 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 2BAB3B017D; Wed, 14 Sep 2011 09:02:30 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <1F2A2C70609D9E41844A2126145FC09802585056@HKGMBOXPRD22.polycom.com> Date: Wed, 14 Sep 2011 09:02:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <49CE50E8-9698-4D65-899B-4AA2CD57B195@ag-projects.com> References: <1F2A2C70609D9E41844A2126145FC09802585056@HKGMBOXPRD22.polycom.com> To: "Avasarala, Ranjit" X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Wed, 14 Sep 2011 07:00:24 -0000 Hi, On Sep 14, 2011, at 8:23 AM, Avasarala, Ranjit wrote: > Hi Inaki >=20 > I have few initial comments on your draft >=20 > 1) in Section 3, its mentioned that there is no real benefit of using = SIP over Websockets. If this is the case, why are you proposing = integrating SIP with Websockets? That's not exactly what it says. It says that there is no real benefit = in using SIP over WbSocket *IF* not using it within a browser. And we = are talking browsers here :-) > 2) Also just integrating SIP for signaling case is really no use, as = there are several other ways of achieving signaling in web - E.g. using = libjingle of WebRTC, etc Then if you'd want to interoperate with SIP you'd have to build a = gateway, whereas if we already use SIP, no gateway is needed, just a new = transport. > 3) In Section 4, you mentioned that since Websocket is a reliable = transport protocol, the websocket sub-protocol defined for SIP also = becomes reliable. I don't agree with this - The websocket connection is = actually initiated by the web browser client towards the web server and = this connection needs to be kept alive through some keep alive = mechanism. Otherwise the connection may close. I am not sure of = reliability. Have a look at section 8. Since the WebSocket keepalive is not yet = standardized a TCP style (CRLFCRLF) keepalive could be used. I would = consider WebSocket reliable, do you see it as UDP? > 4) In Section 4.1,I am not clear of the Via transport parameter having = the value of "WS". Why do you need this when the whole SIP message is = going as part of WebSocket payload [Using websocket API]? >=20 The packet may traverse numerous proxies, someone might be interested in = knowing it. Its also consistent, since the packet did originate in a WS = transport. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From john.elwell@siemens-enterprise.com Wed Sep 14 00:20: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 0E1F421F8C5D for ; Wed, 14 Sep 2011 00:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.037 X-Spam-Level: X-Spam-Status: No, score=-103.037 tagged_above=-999 required=5 tests=[AWL=-0.438, 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 ps5B4iFgAbRW for ; Wed, 14 Sep 2011 00:20:12 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id CB19C21F8BBC for ; Wed, 14 Sep 2011 00:20:10 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 94CDE1EB8408; Wed, 14 Sep 2011 09:22:16 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 14 Sep 2011 09:22:16 +0200 From: "Elwell, John" To: Harald Alvestrand Date: Wed, 14 Sep 2011 09:22:15 +0200 Thread-Topic: [rtcweb] Proposed text - remote recording use case Thread-Index: AcxyH/wNzasH9QUlQ62qWTyBKXEmCwAjngMQ Message-ID: References: <4E6F6624.3070809@alvestrand.no> In-Reply-To: <4E6F6624.3070809@alvestrand.no> 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] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 07:20:15 -0000 =20 > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 > Sent: 13 September 2011 15:18 > To: Elwell, John > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Proposed text - remote recording use case >=20 > I like this text for capturing the use case. >=20 > I agree with Matthew that it seems to come with some special caveats=20 > that we should consider whether we can solve before agreeing=20 > that this=20 > is an use case we MUST solve - but some of those issues may=20 > be issues we=20 > will face as a natural consequence of the API proposal anyway. >=20 > I suggest that Stefan add it to the use case draft under "use cases=20 > considered", so that we have the text in the draft, with a=20 > note that the=20 > WG has not accepted this as a "must do" use case. [JRE] Yes, in the interests of not holding things up, that would be accepta= ble. If we decide to promote it at some point to a "must do", we would need= to add more text addressing Matthew's concerns. John >=20 > On 09/09/11 18:41, Elwell, John wrote: > > On yesterday's call it was agreed to work on text to cover=20 > the remote recording use case. Below is text, based on an=20 > earlier proposal and subsequent input. I have focused on the=20 > main requirement derived from this use case, relating to=20 > copying to a different peer connection, and skipped any more=20 > detailed requirements concerning possible mixing of the two=20 > directions of audio or injecting any tones / announcements. > > > > 4.2.yy Remote Session Recording > > In this use case, the web application user wishes to record=20 > a real-time communication at a remote third party (e.g., a=20 > recording device), such that transmitted and received audio,=20 > video or other real-time media are transmitted in real-time=20 > to the third party. The third party can perform recording,=20 > archiving, retrieval, playback, etc., but can also perform=20 > real-time analytics on the media. A typical deployment might=20 > be in a contact centre. The web application also sends=20 > metadata that gives context to the stored media. The web=20 > application will ensure that appropriate indications are=20 > given to participants so that they are aware of recording. > > > > New requirements: > > Fyy1: The browser MUST be able to send in real-time to a=20 > third party media that are being transmitted to and received=20 > from remote participants. > > > > Ayy1: The web application MUST be able to ask the browser=20 > to transmit in real-time to a third party media that are=20 > being transmitted to and received from remote participants. > > > > Comments? > > > > John > > > > > > John Elwell > > Tel: +44 1908 817801 (office and mobile) > > Email: john.elwell@siemens-enterprise.com > > http://www.siemens-enterprise.com/uk/ > > > > Siemens Enterprise Communications Limited. > > Registered office: Brickhill Street, Willen Lake, Milton=20 > Keynes, MK15 0DJ. > > Registered No: 5903714, England. > > > > Siemens Enterprise Communications Limited is a Trademark=20 > Licensee of Siemens AG. > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > >=20 > = From ibc@aliax.net Wed Sep 14 01:41: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 CA57C21F8ABB for ; Wed, 14 Sep 2011 01:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 h6DOnxz8ij-B for ; Wed, 14 Sep 2011 01:41:24 -0700 (PDT) Received: from mail-qw0-f42.google.com (mail-qw0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4A821F849B for ; Wed, 14 Sep 2011 01:41:22 -0700 (PDT) Received: by qwi4 with SMTP id 4so1924284qwi.29 for ; Wed, 14 Sep 2011 01:43:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.42.76 with SMTP id r12mr2579421qce.178.1315989810200; Wed, 14 Sep 2011 01:43:30 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Wed, 14 Sep 2011 01:43:30 -0700 (PDT) In-Reply-To: <1F2A2C70609D9E41844A2126145FC09802585056@HKGMBOXPRD22.polycom.com> References: <1F2A2C70609D9E41844A2126145FC09802585056@HKGMBOXPRD22.polycom.com> Date: Wed, 14 Sep 2011 10:43:30 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Avasarala, Ranjit" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Wed, 14 Sep 2011 08:41:24 -0000 2011/9/14 Avasarala, Ranjit : > I have few initial comments on your draft Hi Ranjit, replies inline: > 1) in Section 3, its mentioned that there is no real benefit of using SIP= over Websockets. If this is the case, why are you proposing integrating SI= P with Websockets? As Saul pointed out, the text says: There is no benefit on using SIP over WebSocket transport between two SIP nodes when none of them runs within a web browser. JavaScript can open a WebSocket connection from a web browser to a server, but not an arbitrary TCP or UDP connection. > 2) Also just integrating SIP for signaling case is really no use, as ther= e are several other ways of achieving signaling in web - E.g. using libjing= le of WebRTC, etc The fact that there are other alternatives for signaling in the web does not mean that using SIP is invalid. If I want to build a SIP phone in a web, why should I use libjingle rather than SIP protocol? Why should I code a complex server behaving as a gateway between Jingle and SIP protocols? Any protocol conversion (i.e. from Jingle to SIP) means loss of features. Our draft proposes the contrary: no protocol conversion (just SIP), and just transport protocol conversion (as already exists in SIP when bridging UDP/TCP/TLS-TCP/SCTP...). > 3) In Section 4, you mentioned that since Websocket is a reliable transpo= rt protocol, the websocket sub-protocol defined for SIP also becomes reliab= le. I don't agree with this - The websocket connection is actually initiate= d by the web browser client towards the web server and this connection need= s to be kept alive through some keep alive mechanism. Otherwise the connect= ion may close. I am not sure of reliability. "Reliability" does not mean that. "Reliability" means data delivery acknowledgment in the transport. This is true in TCP (so also in WebSocket which works on top of TCP) and false in UDP (which is not a reliable transport protocol). The keep-alive mechanism is needed for cases in which there is a NAT router in the path. Those routers usually close a TCP connection after some minutes of inactivity. This happens in any TCP connection from client to server through a NAT box. > 4) In Section 4.1,I am not clear of the Via transport parameter having th= e value of "WS". Why do you need this when the whole SIP message is going a= s part of WebSocket payload [Using websocket API]? This is how SIP protocol works and this is explained in RFC 3261. You can also check a similar example for SIP over SCTP transport at: http://tools.ietf.org/html/rfc4168#section-4 Best regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Sep 14 02:21: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 1910321F877F for ; Wed, 14 Sep 2011 02:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypZcwyt8tcva for ; Wed, 14 Sep 2011 02:21:24 -0700 (PDT) Received: from mail-qw0-f42.google.com (mail-qw0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 53CEC21F8B9F for ; Wed, 14 Sep 2011 02:21:24 -0700 (PDT) Received: by qwi4 with SMTP id 4so1952214qwi.29 for ; Wed, 14 Sep 2011 02:23:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.105 with SMTP id q41mr2688758qci.216.1315992212592; Wed, 14 Sep 2011 02:23:32 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Wed, 14 Sep 2011 02:23:32 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0B39@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F0B39@sonusinmail02.sonusnet.com> Date: Wed, 14 Sep 2011 11:23:32 +0200 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] draft-ibc-rtcweb-sip-vs-websocket X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 09:21:25 -0000 2011/9/14 Ravindran Parthasarathi : > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0There is no need of one layer = (SIP) above to create the dialog but > lightweight XML signaling mechanism works. Hi Ravindran, I've replied to a similar question in this mail (point 2): http://www.ietf.org/mail-archive/web/rtcweb/current/msg01120.html Best regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed Sep 14 02:43: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 78E1C21F8C50 for ; Wed, 14 Sep 2011 02:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=-0.078, 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 lo4S5xKHh3Cq for ; Wed, 14 Sep 2011 02:43:52 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A682621F8C4E for ; Wed, 14 Sep 2011 02:43:51 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-16-4e7077d70fad Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5F.02.02839.7D7707E4; Wed, 14 Sep 2011 11:45:59 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 14 Sep 2011 11:45:59 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "Avasarala, Ranjit" Date: Wed, 14 Sep 2011 11:45:58 +0200 Thread-Topic: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP) Thread-Index: AcxyumVC07B8o1AdQ2iJA8C9lrx4owABNXqg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21A@ESESSCMS0356.eemea.ericsson.se> References: <1F2A2C70609D9E41844A2126145FC09802585056@HKGMBOXPRD22.polycom.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] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Wed, 14 Sep 2011 09:43:52 -0000 Hi, Thanks for putting the draft together. I agree with Markus, and others, that WebSocket is a feasible solution in t= he case of using a JS SIP app. >> 1) in Section 3, its mentioned that there is no real=20 >> benefit of using SIP over Websockets. If this is the case,=20 >> why are you proposing integrating SIP with Websockets? >=20 > As Saul pointed out, the text says: >=20 > There is no benefit on using SIP over WebSocket transport between > two SIP nodes when none of them runs within a web browser. >=20 > JavaScript can open a WebSocket connection from a web browser=20 > to a server, but not an arbitrary TCP or UDP connection. I have a comment, related to this. The text says: "Even more, the WebSocket protocol is not symmetric since just a WebSocket client can open a connection to a WebSocket server (a WebSocket client does not listen for incoming connections)." But, this is of course also true when you DO use a browser, but it's not re= ally addressed in the draft. You need to describe that it is assumed that t= he WebSocket connection has been established at the point when the browser = is supposed to be able to receive incoming SIP calls. For example, the WebSocket could be established once the JS app is download= ed, or when the JS SIP client registers (similar to how SIP Outbound works)= . >> 3) In Section 4, you mentioned that since Websocket is a=20 >> reliable transport protocol, the websocket sub-protocol=20 >> defined for SIP also becomes reliable. I don't agree with=20 >> this - The websocket connection is actually initiated by the=20 >> web browser client towards the web server and this connection=20 >> needs to be kept alive through some keep alive mechanism.=20 >> Otherwise the connection may close. I am not sure of reliability. >>=20 > "Reliability" does not mean that. "Reliability" means data=20 > delivery acknowledgment in the transport. This is true in TCP=20 > (so also in WebSocket which works on top of TCP) and false in=20 > UDP (which is not a reliable transport protocol). >=20 > The keep-alive mechanism is needed for cases in which there=20 > is a NAT router in the path. Those routers usually close a=20 > TCP connection after some minutes of inactivity. This happens=20 > in any TCP connection from client to server through a NAT box. Since WebSocket provides a keep-alive function, you can of course use that.= I guess it could still be mentioned that a SIP level mechanism exists. Regards, Christer= From christer.holmberg@ericsson.com Wed Sep 14 02:46: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 9C23621F8B58 for ; Wed, 14 Sep 2011 02:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 XgJX7G0feJSE for ; Wed, 14 Sep 2011 02:46:36 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id DBE7B21F8B54 for ; Wed, 14 Sep 2011 02:46:35 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-c4-4e70787b6bf6 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 66.82.02839.B78707E4; Wed, 14 Sep 2011 11:48:44 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 14 Sep 2011 11:48:43 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Date: Wed, 14 Sep 2011 11:48:43 +0200 Thread-Topic: STUN for keep-alive Thread-Index: Acxyw30r82gF7xzoSe2t1rt6OG8s+w== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@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] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 09:46:36 -0000 Hi, Assuming we would use ICE for media authorization, it has been indicated th= at, for legacy interoperability, a gateway would be required in many cases = (as the legacy entities might not support ICE). ICE "bundles" functions together, meaning that if you use STUN for media au= thorization purpose (which is a part of the connectivity check purpose), yo= u will also use STUN for keep-alive purpose (for UDP based media). My question is: would we be able to relax the requirement to use STUN for k= eep-alive? Because, eventhough the keep-alives messages aren't authenticate= d, and do not trigger responses, a gateway would still have to process them= , and since a gateway typically would serve a large number of browser clien= ts, that could have quite big performance impact (the number of STUN keep-a= lives sent per session of course depend on how much other media traffic the= re is, but still). So, for RTP based media, one could use RTP, and for UDP based data channels= "dummy" UDP packets (unless there is a protocol on top of UDP which provid= es a keep-alive mechanism itself). Regards, Christer From magnus.westerlund@ericsson.com Wed Sep 14 02:51: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 21A8121F8B75 for ; Wed, 14 Sep 2011 02:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.5 X-Spam-Level: X-Spam-Status: No, score=-106.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 Zc+Uu8TPhZzR for ; Wed, 14 Sep 2011 02:51: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 44CE021F8B6E for ; Wed, 14 Sep 2011 02:51:51 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-98-4e7079b7061f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7B.83.02839.7B9707E4; Wed, 14 Sep 2011 11:53:59 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Wed, 14 Sep 2011 11:53:58 +0200 Message-ID: <4E7079B5.2060803@ericsson.com> Date: Wed, 14 Sep 2011 11:53:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <4E6F17AB.4000005@ericsson.com> <4E6F6963.9090702@alvestrand.no> In-Reply-To: <4E6F6963.9090702@alvestrand.no> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Multiple videos in one MediaStream (Re: MediaStream Label and CNAME) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 09:51:52 -0000 On 2011-09-13 16:32, Harald Alvestrand wrote: > On 09/13/11 10:43, Magnus Westerlund wrote: >> WG, >> (As an individual contributor) >> >> >> There has been some discussion as result of the presentation of >> terminology in the RTCWEB Interim meeting last Thursday. The biggest >> question was why CNAME can't map to MediaStream label. Below we >> clarify why we think CNAME and label are separate entities. >> >> One part in this reasoning has to do with the current definition of >> media resource >> () and media >> elements of html5. The media resource could be a file, or, more >> relevant to this discussion, a MediaStream. In that usage only a single >> video track can be played simultaneously and in sync with one or more >> audio tracks. >> >> Thus unless we modify an existing semantics the only way of playing >> multiple video tracks in sync with one or more audio tracks is to have >> multiple MediaStream objects. > Sorry, I think this can be handled with the existing API without any issue. > Apologies to those who know JavaScript better than me, but this is a handler > that can handle a new incoming video stream > > NewStreamHandler(stream) { > myMultiVideoStream = stream > myFirstVideo = new MediaStream(myMultiVideoStream) > myFirstVideo.videoTracks.select(1) > oneVideoObject.setSource(myFirstVideo.getUrl()) > mySecondVideo = new MediaStream(myMultiVideoStream) > mySecondVideo.videoTracks.select(2) > anotherVideoObject.setSource(mySecondVideo.getUrl()) > } > > I think the API can be improved, but the improvements are unlikely to > lose this functionality. > (Remember that the API objects are the control surfaces on the stream - > the video data will likely go straight from the incoming buffer, through > the codec for decoding, and blitted onto the screen; the "copying" from > one MediaStream to another MediaStream is purely conceptual.) > > I don't think it makes sense to discuss the other points before getting > this one put to rest. Harald, If I read this correctly, what you are doing is to creating two media streams based on a first media stream. Thus you have multiple mediaStream objects that contains tracks that has a common synchronziation context. So from my point of view you have very well demonstrated why you need CNAME to be a property associated with the tracks in the media stream and not be the label for the mediaStream. Or how do you see the label for the media stream being handled when you create two mediaStream objects from the incomming "stream" that has one label? Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From pravindran@sonusnet.com Wed Sep 14 03:02: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 EC4E021F8BFB for ; Wed, 14 Sep 2011 03:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=-0.044, 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 oi6IlZpcpcuz for ; Wed, 14 Sep 2011 03:02:05 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 61B5D21F8BE9 for ; Wed, 14 Sep 2011 03:02:05 -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 p8EA4gFL016063; Wed, 14 Sep 2011 06:04:42 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 06:03:18 -0400 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, 14 Sep 2011 15:33:14 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0B8A@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket Thread-Index: Acxyv/un6hIW/g2xSgGU1j+DC15AxQAAONDQ References: <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F0B39@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 14 Sep 2011 10:03:18.0259 (UTC) FILETIME=[86CCBC30:01CC72C5] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 10:02:06 -0000 SGkgSW5ha2ksDQoNCjxzbmlwPiANCg0KVGhlIGZhY3QgdGhhdCB0aGVyZSBhcmUgb3RoZXIgYWx0 ZXJuYXRpdmVzIGZvciBzaWduYWxpbmcgaW4gdGhlIHdlYiBkb2VzIG5vdCBtZWFuIHRoYXQgdXNp bmcgU0lQIGlzIGludmFsaWQuDQpJZiBJIHdhbnQgdG8gYnVpbGQgYSBTSVAgcGhvbmUgaW4gYSB3 ZWIsIHdoeSBzaG91bGQgSSB1c2UgbGliamluZ2xlIHJhdGhlciB0aGFuIFNJUCBwcm90b2NvbD8g V2h5IHNob3VsZCBJIGNvZGUgYSBjb21wbGV4IHNlcnZlciBiZWhhdmluZyBhcyBhIGdhdGV3YXkg YmV0d2VlbiBKaW5nbGUgYW5kIFNJUCBwcm90b2NvbHM/DQoNCkFueSBwcm90b2NvbCBjb252ZXJz aW9uIChpLmUuIGZyb20gSmluZ2xlIHRvIFNJUCkgbWVhbnMgbG9zcyBvZiBmZWF0dXJlcy4gT3Vy IGRyYWZ0IHByb3Bvc2VzIHRoZSBjb250cmFyeTogbm8gcHJvdG9jb2wgY29udmVyc2lvbiAoanVz dCBTSVApLCBhbmQganVzdCB0cmFuc3BvcnQgcHJvdG9jb2wgY29udmVyc2lvbiAoYXMgYWxyZWFk eSBleGlzdHMgaW4gU0lQIHdoZW4gYnJpZGdpbmcgVURQL1RDUC9UTFMtVENQL1NDVFAuLi4pLg0K PC9zbmlwPiANCg0KSSBhZ3JlZSB3aXRoIHlvdXIgcHJvYmxlbSBzdGF0ZW1lbnQuIEkgaGF2ZSBy YWlzZWQgdGhlIHNhbWUgY29uY2VybiBpbiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNnMDA4NDUuaHRtbC4gSU1PLCB5b3VyIHNvbHV0aW9uIGlz IGEgd29ya2Fyb3VuZCBhbmQgd2Ugd2lsbCBlbmQtdXAgd2l0aCB5b3VyIHNvbHV0aW9uIGluIGNh c2Ugc2lnbmFsaW5nIHByb3RvY29sIGlzIG5vdCBzdGFuZGFyZGl6ZWQgYXMgcGFydCBvZiBSVENX ZWIuDQoNClRoYW5rcw0KUGFydGhhDQoNCg0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj5Gcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86aWJjQGFsaWF4Lm5ldF0NCj5TZW50 OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxNCwgMjAxMSAyOjU0IFBNDQo+VG86IFJhdmluZHJhbiBQ YXJ0aGFzYXJhdGhpDQo+Q2M6IEJlcm5hcmQgQWJvYmE7IG1hcmt1cy5pc29tYWtpQG5va2lhLmNv bTsgcnRjd2ViQGlldGYub3JnOyBSb21hbg0KPlNocG91bnQNCj5TdWJqZWN0OiBSZTogW3J0Y3dl Yl0gZHJhZnQtaWJjLXJ0Y3dlYi1zaXAtdnMtd2Vic29ja2V0DQo+DQo+MjAxMS85LzE0IFJhdmlu ZHJhbiBQYXJ0aGFzYXJhdGhpIDxwcmF2aW5kcmFuQHNvbnVzbmV0LmNvbT46DQo+DQo+PiDCoMKg wqDCoMKgwqAgwqBUaGVyZSBpcyBubyBuZWVkIG9mIG9uZSBsYXllciAoU0lQKSBhYm92ZSB0byBj cmVhdGUgdGhlIGRpYWxvZw0KPmJ1dA0KPj4gbGlnaHR3ZWlnaHQgWE1MIHNpZ25hbGluZyBtZWNo YW5pc20gd29ya3MuDQo+DQo+SGkgUmF2aW5kcmFuLCBJJ3ZlIHJlcGxpZWQgdG8gYSBzaW1pbGFy IHF1ZXN0aW9uIGluIHRoaXMgbWFpbCAocG9pbnQgMik6DQo+ICBodHRwOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNnMDExMjAuaHRtbA0KPg0KPg0KPkJl c3QgcmVnYXJkcy4NCj4NCj4NCj4tLQ0KPknDsWFraSBCYXogQ2FzdGlsbG8NCj48aWJjQGFsaWF4 Lm5ldD4NCg== From harald@alvestrand.no Wed Sep 14 03:19: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 BC45E21F8C1E for ; Wed, 14 Sep 2011 03:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.298 X-Spam-Level: X-Spam-Status: No, score=-108.298 tagged_above=-999 required=5 tests=[AWL=2.301, 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 om4-yhc9WtSZ for ; Wed, 14 Sep 2011 03:19:15 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C446A21F8BFE for ; Wed, 14 Sep 2011 03:19:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D7B0539E0BB; Wed, 14 Sep 2011 12:21:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKK-H8Gcb3cO; Wed, 14 Sep 2011 12:21:22 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 37F5A39E098; Wed, 14 Sep 2011 12:21:22 +0200 (CEST) Message-ID: <4E708022.1020506@alvestrand.no> Date: Wed, 14 Sep 2011 12:21:22 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Magnus Westerlund References: <4E6F17AB.4000005@ericsson.com> <4E6F6963.9090702@alvestrand.no> <4E7079B5.2060803@ericsson.com> In-Reply-To: <4E7079B5.2060803@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Multiple videos in one MediaStream (Re: MediaStream Label and CNAME) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 10:19:15 -0000 On 09/14/11 11:53, Magnus Westerlund wrote: > On 2011-09-13 16:32, Harald Alvestrand wrote: >> On 09/13/11 10:43, Magnus Westerlund wrote: >>> WG, >>> (As an individual contributor) >>> >>> >>> There has been some discussion as result of the presentation of >>> terminology in the RTCWEB Interim meeting last Thursday. The biggest >>> question was why CNAME can't map to MediaStream label. Below we >>> clarify why we think CNAME and label are separate entities. >>> >>> One part in this reasoning has to do with the current definition of >>> media resource >>> () and media >>> elements of html5. The media resource could be a file, or, more >>> relevant to this discussion, a MediaStream. In that usage only a single >>> video track can be played simultaneously and in sync with one or more >>> audio tracks. >>> >>> Thus unless we modify an existing semantics the only way of playing >>> multiple video tracks in sync with one or more audio tracks is to have >>> multiple MediaStream objects. >> Sorry, I think this can be handled with the existing API without any issue. >> Apologies to those who know JavaScript better than me, but this is a handler >> that can handle a new incoming video stream >> >> NewStreamHandler(stream) { >> myMultiVideoStream = stream >> myFirstVideo = new MediaStream(myMultiVideoStream) >> myFirstVideo.videoTracks.select(1) >> oneVideoObject.setSource(myFirstVideo.getUrl()) >> mySecondVideo = new MediaStream(myMultiVideoStream) >> mySecondVideo.videoTracks.select(2) >> anotherVideoObject.setSource(mySecondVideo.getUrl()) >> } >> >> I think the API can be improved, but the improvements are unlikely to >> lose this functionality. >> (Remember that the API objects are the control surfaces on the stream - >> the video data will likely go straight from the incoming buffer, through >> the codec for decoding, and blitted onto the screen; the "copying" from >> one MediaStream to another MediaStream is purely conceptual.) >> >> I don't think it makes sense to discuss the other points before getting >> this one put to rest. > Harald, > > If I read this correctly, what you are doing is to creating two media > streams based on a first media stream. Thus you have multiple > mediaStream objects that contains tracks that has a common > synchronziation context. So from my point of view you have very well > demonstrated why you need CNAME to be a property associated with the > tracks in the media stream and not be the label for the mediaStream. That's a good point. My thinking when typing this was that stuff that happens inside a browser is synchronized "enough" by default, so that we don't need to carry the label along in order to keep synchronity between myFirstVideo and mySecondVideo. This may or may not be optimistic; input sought. The audio tracks inside myFirstVideo are declared as synchronized to the myFirstVideo video track by virtue of being inside the same MediaStream object; this carries over to them being synchronized if myFirstVideo is connected to another PeerConnection, if this is allowed (see "recording" discussion). (In this case, I think the CNAME should NOT be the same as that coming in over the incoming PeerConnection). > Or how do you see the label for the media stream being handled when you > create two mediaStream objects from the incomming "stream" that has one > label? My original thinking was that a CNAME is created for any MediaStream at creation time, so that we're operating with three CNAMEs in the example above. Another possibility is that CNAME is a property of the attachment of a MediaStream to a PeerConnection object; this has the advantage that the CNAME property is only defined in the cases where we need it, but we don't have to carry the baggage of actually generating CNAMEs for MediaStreams that are not connected to PeerConnections. From mperumal@cisco.com Wed Sep 14 03: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 CA6BF21F8C4E for ; Wed, 14 Sep 2011 03:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.435 X-Spam-Level: X-Spam-Status: No, score=-10.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDkmV5CSRTYh for ; Wed, 14 Sep 2011 03:23:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C715121F8C47 for ; Wed, 14 Sep 2011 03:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3168; q=dns/txt; s=iport; t=1315995919; x=1317205519; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=+C4R/CDBvLgK/hoyu4B86OzJZpFRJNbdmBLBik6de38=; b=KM17zTtEoaBUcG1eVQFwEax40Pp5+no+r+idFB/VmwXo3P7aojT8JTBz NwTFcGh2kqJj0ukvOuBR2icxWfK0uNBJ/W3W2rKL2VX2Vr/+XRBdj4a0D 9DFINU/gDnwROl2STcwhQzTRAs6xtbI1atE/5fx0Pj4b8eImbJiYQvMx7 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcAAFiAcE5Io8US/2dsb2JhbABBmGuPD3iBUwEBBQEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAEKCAgah1mXQAGeL4YOYASHbJB3jAk X-IronPort-AV: E=Sophos;i="4.68,379,1312156800"; d="scan'208";a="115373281" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 14 Sep 2011 10:25:16 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8EAPGWw024602; Wed, 14 Sep 2011 10:25:16 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, 14 Sep 2011 15:55:16 +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, 14 Sep 2011 15:55:13 +0530 Message-ID: <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] STUN for keep-alive Thread-Index: Acxyw30r82gF7xzoSe2t1rt6OG8s+wAA6iNw References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Christer Holmberg" , X-OriginalArrivalTime: 14 Sep 2011 10:25:16.0137 (UTC) FILETIME=[9850F590:01CC72C8] Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 10:23:10 -0000 Christer, |Because, eventhough the keep-alives messages aren't authenticated,=20 |and do not trigger responses, a gateway would still have to process=20 |them, and since a gateway typically would serve a large number of=20 |browser clients, that could have quite big performance impact=20 |(the number of STUN keep-alives sent per session of course depend=20 |on how much other media traffic there is, but still). STUN keepalives are required by ICE only in the absence of media traffic. Here are the snip from RFC 5245: 10. Keepalives If there has been no packet sent on the candidate pair ICE is using for a media component for Tr seconds (where packets include those defined for the component (RTP or RTCP) and previous keepalives), an agent MUST generate a keepalive on that pair. Tr SHOULD be configurable and SHOULD have a default of 15 seconds. Tr MUST NOT be configured to less than 15 seconds. 20.2.3. Keepalives STUN keepalives (in the form of STUN Binding Indications) are sent in the middle of a media session. However, they are sent only in the absence of actual media traffic. In deployments that are not utilizing Voice Activity Detection (VAD), the keepalives are never used and there is no increase in bandwidth usage. When VAD is being used, keepalives will be sent during silence periods. This involves a single packet every 15-20 seconds, far less than the packet every 20-30 ms that is sent when there is voice. Therefore, keepalives don't have any real impact on capacity planning. Do you think there is still a problem? Muthu |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg |Sent: Wednesday, September 14, 2011 3:19 PM |To: rtcweb@ietf.org |Subject: [rtcweb] STUN for keep-alive | | |Hi, | |Assuming we would use ICE for media authorization, it has been indicated that, for legacy |interoperability, a gateway would be required in many cases (as the legacy entities might not support |ICE). | |ICE "bundles" functions together, meaning that if you use STUN for media authorization purpose (which |is a part of the connectivity check purpose), you will also use STUN for keep-alive purpose (for UDP |based media). | |My question is: would we be able to relax the requirement to use STUN for keep-alive? Because, |eventhough the keep-alives messages aren't authenticated, and do not trigger responses, a gateway |would still have to process them, and since a gateway typically would serve a large number of browser |clients, that could have quite big performance impact (the number of STUN keep-alives sent per session |of course depend on how much other media traffic there is, but still). | |So, for RTP based media, one could use RTP, and for UDP based data channels "dummy" UDP packets |(unless there is a protocol on top of UDP which provides a keep-alive mechanism itself). | |Regards, | |Christer | |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Wed Sep 14 03:27: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 8426321F8C40 for ; Wed, 14 Sep 2011 03:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 mIAaJ8LSDPHS for ; Wed, 14 Sep 2011 03:27:10 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7A47521F8B8E for ; Wed, 14 Sep 2011 03:27:10 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-eb-4e7081fe01ba Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 91.31.20773.EF1807E4; Wed, 14 Sep 2011 12:29:18 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 14 Sep 2011 12:29:18 +0200 From: Christer Holmberg To: "Muthu Arul Mozhi Perumal (mperumal)" , "rtcweb@ietf.org" Date: Wed, 14 Sep 2011 12:29:17 +0200 Thread-Topic: [rtcweb] STUN for keep-alive Thread-Index: Acxyw30r82gF7xzoSe2t1rt6OG8s+wAA6iNwAABiKWA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.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== Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 10:27:11 -0000 Hi,=20 >|Because, eventhough the keep-alives messages aren't authenticated, and=20 >|do not trigger responses, a gateway would still have to=20 >|process them, and since a gateway typically would serve a large number of= browser=20 >|clients, that could have quite big performance impact (the number of=20 >|STUN keep-alives sent per session of course depend on how much other=20 >|media traffic there is, but still). >=20 >STUN keepalives are required by ICE only in the absence of=20 >media traffic. Yes. That's what I meant with the: "(the number of STUN keep-alives sent per session of course depend on how = much other media traffic there is, but still)" ...statement :) >Here are the snip from RFC 5245: >=20 > >10. Keepalives >=20 >If there has been no packet sent on the candidate pair ICE is=20 >using for a media component for Tr seconds (where packets=20 >include those defined for the component (RTP or RTCP) and=20 >previous keepalives), an agent MUST generate a keepalive on=20 >that pair. Tr SHOULD be configurable and SHOULD have a=20 >default of 15 seconds. Tr MUST NOT be configured to less=20 >than 15 seconds. > >=20 > >20.2.3. Keepalives >=20 >STUN keepalives (in the form of STUN Binding Indications) are=20 >sent in the middle of a media session. However, they are=20 >sent only in the absence of actual media traffic. In=20 >deployments that are not utilizing Voice Activity Detection=20 >(VAD), the keepalives are never used and there is no increase=20 >in bandwidth usage. When VAD is being used, keepalives will=20 >be sent during silence periods. This involves a single=20 >packet every 15-20 seconds, far less than the packet every=20 >20-30 ms that is sent when there is voice. Therefore,=20 >keepalives don't have any real impact on capacity planning. > >=20 >Do you think there is still a problem? Well, it depends on the amount of outgoing media traffic, but in cases wher= e you only receive media you would still need to send keep-alives. Regards, Christer= From jmillan@aliax.net Wed Sep 14 03:40: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 AF7AD21F8CB3 for ; Wed, 14 Sep 2011 03:40:20 -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.032, 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 lWAcon2T-cTc for ; Wed, 14 Sep 2011 03:40:20 -0700 (PDT) Received: from mail-yi0-f66.google.com (mail-yi0-f66.google.com [209.85.218.66]) by ietfa.amsl.com (Postfix) with ESMTP id E2A3821F8CA9 for ; Wed, 14 Sep 2011 03:40:19 -0700 (PDT) Received: by yia25 with SMTP id 25so101962yia.1 for ; Wed, 14 Sep 2011 03:42:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.0.221 with SMTP id 29mr10828883ibc.56.1315996948327; Wed, 14 Sep 2011 03:42:28 -0700 (PDT) Received: by 10.231.36.201 with HTTP; Wed, 14 Sep 2011 03:42:26 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0B8A@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F0B39@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F0B8A@sonusinmail02.sonusnet.com> Date: Wed, 14 Sep 2011 12:42:26 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: Ravindran Parthasarathi Content-Type: multipart/alternative; boundary=00151773d3d2a16f0c04ace46a98 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 10:40:20 -0000 --00151773d3d2a16f0c04ace46a98 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Let's clarify that the submitted draft states a way to adopt WebSocket as a transport protocol for SIP. This makes feasible the SIP communication between WebSocket capable nodes and nodes using other transports defined in SIP, which facilitates the inter-operation within nowadays implementations and implementations to be defined in this group. We are not proposing this specification as the unique/only signaling protocol within WebRTC. That's another subject out of the scope of the draft. Regards. 2011/9/14 Ravindran Parthasarathi > Hi Inaki, > > > > The fact that there are other alternatives for signaling in the web does > not mean that using SIP is invalid. > If I want to build a SIP phone in a web, why should I use libjingle rathe= r > than SIP protocol? Why should I code a complex server behaving as a gatew= ay > between Jingle and SIP protocols? > > Any protocol conversion (i.e. from Jingle to SIP) means loss of features. > Our draft proposes the contrary: no protocol conversion (just SIP), and j= ust > transport protocol conversion (as already exists in SIP when bridging > UDP/TCP/TLS-TCP/SCTP...). > > > I agree with your problem statement. I have raised the same concern in > http://www.ietf.org/mail-archive/web/rtcweb/current/msg00845.html. IMO, > your solution is a workaround and we will end-up with your solution in ca= se > signaling protocol is not standardized as part of RTCWeb. > > Thanks > Partha > > > > >-----Original Message----- > >From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] > >Sent: Wednesday, September 14, 2011 2:54 PM > >To: Ravindran Parthasarathi > >Cc: Bernard Aboba; markus.isomaki@nokia.com; rtcweb@ietf.org; Roman > >Shpount > >Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket > > > >2011/9/14 Ravindran Parthasarathi : > > > >> There is no need of one layer (SIP) above to create the dialog > >but > >> lightweight XML signaling mechanism works. > > > >Hi Ravindran, I've replied to a similar question in this mail (point 2): > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg01120.html > > > > > >Best regards. > > > > > >-- > >I=F1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00151773d3d2a16f0c04ace46a98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Let's clarify that the submitted draft states a = way to adopt WebSocket as a transport protocol for SIP. =A0This makes feasi= ble the SIP communication between WebSocket capable nodes and nodes using o= ther transports defined in SIP, which facilitates the=A0inter-operation=A0w= ithin nowadays implementations and implementations to be defined in this gr= oup.=A0=A0=A0=A0

We are not proposing this specificati= on as the unique/only signaling protocol within WebRTC. That's another subject out of the scope of the draft.

Regards.


2= 011/9/14 Ravindran Parthasarathi <pravindran@sonusnet.com>
Hi Inaki,

<snip>

The fact that there are other alternatives for signaling in the web does no= t mean that using SIP is invalid.
If I want to build a SIP phone in a web, why should I use libjingle rather = than SIP protocol? Why should I code a complex server behaving as a gateway= between Jingle and SIP protocols?

Any protocol conversion (i.e. from Jingle to SIP) means loss of features. O= ur draft proposes the contrary: no protocol conversion (just SIP), and just= transport protocol conversion (as already exists in SIP when bridging UDP/= TCP/TLS-TCP/SCTP...).
</snip>

I agree with your problem statement. I have raised the same concern in http://www.ietf.org/mail-archive/web/rtcweb/current/msg008= 45.html. IMO, your solution is a workaround and we will end-up with you= r solution in case signaling protocol is not standardized as part of RTCWeb= .

Thanks
Partha



>-----Original Message-----
>From: I=F1aki Baz Castillo [mailto:ibc= @aliax.net]
>Sent: Wednesday, September 14, 2011 2:54 PM
>To: Ravindran Parthasarathi
>Cc: Bernard Aboba; markus.i= somaki@nokia.com; rtcweb@ietf.org; Roman
>Shpount
>Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket
>
>2011/9/14 Ravindran Parthasarathi <pravindran@sonusnet.com>:
>
>> =A0=A0=A0=A0=A0=A0 =A0There is no need of one layer (SIP) above to= create the dialog
>but
>> lightweight XML signaling mechanism works.
>
>Hi Ravindran, I've replied to a similar question in this mail (poin= t 2):
> =A0http://www.ietf.org/mail-archive/web/rtcweb/cu= rrent/msg01120.html
>
>
>Best regards.
>
>
>--
>I=F1aki Baz Castillo
><ibc@aliax.net>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--00151773d3d2a16f0c04ace46a98-- From ibc@aliax.net Wed Sep 14 03:41: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 6085A21F8AAA for ; Wed, 14 Sep 2011 03:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95KsHeTuXEGU for ; Wed, 14 Sep 2011 03:41:35 -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 79A9A21F8A95 for ; Wed, 14 Sep 2011 03:41:35 -0700 (PDT) Received: by qyk33 with SMTP id 33so1369066qyk.10 for ; Wed, 14 Sep 2011 03:43:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.105 with SMTP id q41mr2741418qci.216.1315997023826; Wed, 14 Sep 2011 03:43:43 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Wed, 14 Sep 2011 03:43:43 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21A@ESESSCMS0356.eemea.ericsson.se> References: <1F2A2C70609D9E41844A2126145FC09802585056@HKGMBOXPRD22.polycom.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB21A@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 14 Sep 2011 12:43:43 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Wed, 14 Sep 2011 10:41:36 -0000 2011/9/14 Christer Holmberg : > I have a comment, related to this. > > The text says: > > =C2=A0 "Even more, the WebSocket protocol is not symmetric since > =C2=A0 just a WebSocket client can open a connection to a WebSocket serve= r > =C2=A0 (a WebSocket client does not listen for incoming connections)." > > But, this is of course also true when you DO use a browser, but it's not = really addressed in the draft. You need to describe that it is assumed that= the WebSocket connection has been established at the point when the browse= r is supposed to be able to receive incoming SIP calls. Hi Christer. IMHO that is already addressed in the draft: ---------------------------------------------------- 6. WebSocket Client Usage As stated in [I-D.ietf-hybi-thewebsocketprotocol], a WebSocket URI [RFC3986] is given to the WebSocket client (typically within a web- based application) who resolves the URI destination and establishes a WebSocket connection with the corresponding server (by performing the handshake and negotiation procedures described in [I-D.ietf-hybi-thewebsocketprotocol]). ----------------------------------------------------- > For example, the WebSocket could be established once the JS app is downlo= aded, But that is obvious given the WebSocket protocol nature. The client MUST establish a WebSocket connection with the server before attempting to send or receive WebSocket messages. Could you please point to the exact section in the draft in which you miss such explanation? We'll be very glad to improve it. > or when the JS SIP client registers (similar to how SIP Outbound works). In normal scenarios the client must register in order to receive incoming SIP calls, but that is not a MUST. For example a WebSocket server could route INVITE requests to connected WebSocket clients without previous SIP registration made by the clients. It would be up to the provider local policy. I don't think the draft should mandate SIP registration in order to receive calls (neither RFC 3261 mandates it), as registration is just one of the existing ways for receiving incoming calls, but not the unique. Am I wrong? >> The keep-alive mechanism is needed for cases in which there >> is a NAT router in the path. Those routers usually close a >> TCP connection after some minutes of inactivity. This happens >> in any TCP connection from client to server through a NAT box. > > Since WebSocket provides a keep-alive function, you can of course use tha= t. Current limitation exists in WebSocket API since it does not provide a way for the client to send Ping frames to the server. Please check the open request in the W3C tracker about this topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=3D13104#c3 > I guess it could still be mentioned that a SIP level mechanism exists. I assume you mean the CRLF+CRLF mechanism defined in RFC 5626 "Managing Client-Initiated Connections in SIP" which is a technique for SIP clients to keep the connection open by sending CRLF+CRLF and receiving CRLF reply from the proxy/server. RFC 5626 says: --------------------------------- 3.5.1. CRLF Keep-Alive Technique This approach can only be used with connection-oriented transports such as TCP or SCTP. The client periodically sends a double-CRLF (the "ping") then waits to receive a single CRLF (the "pong"). If the client does not receive a "pong" within an appropriate amount of time, it considers the flow failed. ------------------------------- Since SIP WebSocket transport (as defined in the draft) is also a reliable transport, we could mention the usage of this keepalive technique in the draft, is it ok? Thanks a lot for your input. Best regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed Sep 14 03:45: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 6103A21F8CB2 for ; Wed, 14 Sep 2011 03:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 DAa7Hu8ZlICf for ; Wed, 14 Sep 2011 03:45:19 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9111A21F8CA9 for ; Wed, 14 Sep 2011 03:45:18 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-3a-4e70863ee777 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D8.CD.02839.E36807E4; Wed, 14 Sep 2011 12:47:26 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 14 Sep 2011 12:47:26 +0200 From: Christer Holmberg To: "rtcweb@ietf.org" Date: Wed, 14 Sep 2011 12:47:25 +0200 Thread-Topic: New Version Notification for draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt Thread-Index: Acxyyd6aOvfK+MMFTn6XQAfby+UjdAAASajQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233EDB29F@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] FW: New Version Notification for draft-holmberg-mmusic-sdp-multiplex-negotiation-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: Wed, 14 Sep 2011 10:45:20 -0000 =20 Hi, I've submitted a draft in MMUSIC, which defines a mechanism and grouping fr= amework extension in order to negotiate multiplexing of media associated wi= th multiple m=3D lines. The main difference from Harald's previous proposal is that it defines the = usage of the same port number value for multiple m=3D lines, and every m=3D= line is used to describe media even in the case of multiplex. Comments are welcome :) Regards, Christer > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: 14. syyskuuta 2011 13:32 > To: Christer Holmberg > Cc: Christer Holmberg > Subject: New Version Notification for=20 > draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt >=20 > A new version of I-D,=20 > draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt has=20 > been successfully submitted by Christer Holmberg and posted=20 > to the IETF repository. >=20 > Filename: draft-holmberg-mmusic-sdp-multiplex-negotiation > Revision: 00 > Title: Multiplexing Negotiation Using Session=20 > Description Protocol (SDP) Port Numbers > Creation date: 2011-09-14 > WG ID: Individual Submission > Number of pages: 9 >=20 > Abstract: > This document defines how to use the Session Description Protocol > (SDP) in order to negotiate the usage of multiplexed media. >=20 > =20 > =20 >=20 >=20 > The IETF Secretariat > = From christer.holmberg@ericsson.com Wed Sep 14 04:09: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 1585B21F8C9C for ; Wed, 14 Sep 2011 04:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.079 X-Spam-Level: X-Spam-Status: No, score=-6.079 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxTL-iM9ESOz for ; Wed, 14 Sep 2011 04:09:13 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id AFE8521F8C9B for ; Wed, 14 Sep 2011 04:09:12 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-0d-4e708bd8db91 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D6.98.20773.8DB807E4; Wed, 14 Sep 2011 13:11:20 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 14 Sep 2011 13:11:20 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 14 Sep 2011 13:11:18 +0200 Thread-Topic: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP) Thread-Index: Acxyyy0csspcLj+8R/e32BKosoNEDAAANzpA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233EDB2D1@ESESSCMS0356.eemea.ericsson.se> References: <1F2A2C70609D9E41844A2126145FC09802585056@HKGMBOXPRD22.polycom.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB21A@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] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Wed, 14 Sep 2011 11:09:14 -0000 Hi,=20 >> I have a comment, related to this. >> >> The text says: >> >> =A0 "Even more, the WebSocket protocol is not symmetric since >> =A0 just a WebSocket client can open a connection to a=20 >> WebSocket server (a WebSocket client does not listen for incoming=20 >> connections)." >> >> But, this is of course also true when you DO use a browser,=20 >> but it's not really addressed in the draft. You need to=20 >> describe that it is assumed that the WebSocket connection has=20 >> been established at the point when the browser is supposed to=20 >> be able to receive incoming SIP calls. >=20 > Hi Christer. IMHO that is already addressed in the draft: >=20 > ---------------------------------------------------- > 6. WebSocket Client Usage >=20 > As stated in [I-D.ietf-hybi-thewebsocketprotocol], a WebSocket URI > [RFC3986] is given to the WebSocket client (typically within a web- > based application) who resolves the URI destination and=20 > establishes a WebSocket connection with the corresponding server (by=20 > performing the handshake and negotiation procedures described in > [I-D.ietf-hybi-thewebsocketprotocol]). > ----------------------------------------------------- Well, that describes HOW the WebSocket is established. -------- >>For example, the WebSocket could be established once the JS app is=20 >>downloaded, >=20 >But that is obvious given the WebSocket protocol nature. The=20 >client MUST establish a WebSocket connection with the server=20 >before attempting to send or receive WebSocket messages. Of course. But, as you describe the WebSocket usage for SIP, I think it nee= ds to be stated WHEN that can occur for SIP. -------- >Could you please point to the exact section in the draft in=20 >which you miss such explanation? We'll be very glad to improve it. I would like something like: "When the WebSocket is used to transport SIP traffic, the WebSocket MUST b= e established at the point where the browser SIP application shall be able to place and receive SIP calls. = Based on local policy, this might e.g. occur once the JavaScript SIP application has been downloaded from th= e web server, or when the SIP user using the browser application registers itself to a SIP registrar= (assuming that calls cannot be placed or received before that)." I guess text text could fit either in section 4.x, or in section 6.=20 -------- >>or when the JS SIP client registers (similar to how SIP=20 >>Outbound works). >=20 >In normal scenarios the client must register in order to=20 >receive incoming SIP calls, but that is not a MUST. For=20 >example a WebSocket server could route INVITE requests to=20 >connected WebSocket clients without previous SIP registration=20 >made by the clients. It would be up to the provider local=20 >policy. I don't think the draft should mandate SIP=20 >registration in order to receive calls (neither RFC 3261=20 >mandates it), as registration is just one of the existing=20 >ways for receiving incoming calls, but not the unique. Am I wrong? I was not suggesting that we mandate registration. It was just an example o= f when one could choose to establish the WebSocket, IF the browser shall be= able to receive incoming calls after registration. If it shall be able to = receive incoming calls before the registration (or, if there is no registra= tion in the first place), the WebSocket needs to be established at some oth= er point. -------- >>> The keep-alive mechanism is needed for cases in which=20 >>> there is a NAT router in the path. Those routers usually close a TCP co= nnection=20 >>> after some minutes of inactivity. This happens in any TCP=20 >>> connection from client to server through a NAT box. >> >> Since WebSocket provides a keep-alive function, you can of=20 >> course use that. >=20 > Current limitation exists in WebSocket API since it does not=20 > provide a way for the client to send Ping frames to the=20 > server. Please check the open request in the W3C tracker=20 > about this topic: >=20 > http://www.w3.org/Bugs/Public/show_bug.cgi?id=3D13104#c3 >=20 >=20 >> I guess it could still be mentioned that a SIP level=20 >> mechanism exists. >=20 > I assume you mean the CRLF+CRLF mechanism defined in RFC 5626=20 > "Managing Client-Initiated Connections in SIP" which is a=20 > technique for SIP clients to keep the connection open by=20 > sending CRLF+CRLF and receiving CRLF reply from the proxy/server. >=20 > RFC 5626 says: >=20 > --------------------------------- > 3.5.1. CRLF Keep-Alive Technique >=20 > This approach can only be used with connection-oriented transports > such as TCP or SCTP. The client periodically sends a double-CRLF > (the "ping") then waits to receive a single CRLF (the "pong"). If > the client does not receive a "pong" within an appropriate=20 > amount of > time, it considers the flow failed. > ------------------------------- >=20 >=20 > Since SIP WebSocket transport (as defined in the draft) is=20 > also a reliable transport, we could mention the usage of this=20 > keepalive technique in the draft, is it ok? I think it's better to refer to RFC 6223, which only covers the keep-alive = part of RFC 5626. (RFC 5626 contains also contains other stuff that most likely doesn't apply= for the browser case). -------- Regards, Christer From mperumal@cisco.com Wed Sep 14 04:22: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 5E41321F8A97 for ; Wed, 14 Sep 2011 04:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIvoDtkCqRwF for ; Wed, 14 Sep 2011 04:22:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id AC17D21F8AF1 for ; Wed, 14 Sep 2011 04:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3061; q=dns/txt; s=iport; t=1315999448; x=1317209048; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=XIs8Z7bB/qMFnzc6kMXFYCIrlBTHqeHs5qKatOf3cpE=; b=NAFNoR5Vm1+HIUm5w898wTQdBJFNt7ru663ZlMv7Dm53CTCzMjEURwFe DyUmkb5wOdaBi+5VmSgpyId0Dpp7YRbxBAS6Qqrc/Pqh6hw82ErnYf5IO y4silSQHGkpN/vRoGyb0unHtIRPq78+FM0fQJPW+nSNUty1YcAMwKjGRM Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcAABGOcE5Io8UR/2dsb2JhbABBmGuPD3iBUwEBBRIBHQpLBAIBCBEEAQELBhcBBgFFCQgBAQQBCggIGp9uAZ41hg5gBIdskHeMCQ X-IronPort-AV: E=Sophos;i="4.68,380,1312156800"; d="scan'208";a="115383244" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 14 Sep 2011 11:23:53 +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 p8EBNrKc004538; Wed, 14 Sep 2011 11:23:53 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, 14 Sep 2011 16:53:53 +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, 14 Sep 2011 16:53:52 +0530 Message-ID: <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] STUN for keep-alive Thread-Index: Acxyw30r82gF7xzoSe2t1rt6OG8s+wAA6iNwAABiKWAAAWch4A== References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Christer Holmberg" , X-OriginalArrivalTime: 14 Sep 2011 11:23:53.0212 (UTC) FILETIME=[C8A803C0:01CC72D0] Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 11:22:04 -0000 |Well, it depends on the amount of outgoing media traffic,=20 |but in cases where you only receive media you would still=20 |need to send keep-alives. If you are not sending anything the NAT binding in that direction will likely timeout. On the other hand, if you are operating in a controlled environment ICE already allows you to set the STUN keepalive duration to the longest duration possible in your environment, so it is already flexible. However, it mandates STUN keepalives to be used when an agent is a full ICE implementation and is communicating with a peer that supports ICE (lite/full). Are you saying it should allow a different UDP keepalive method because it can possible have a lesser performance impact? Muthu |-----Original Message----- |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] |Sent: Wednesday, September 14, 2011 3:59 PM |To: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org |Subject: RE: [rtcweb] STUN for keep-alive | | |Hi, | |>|Because, eventhough the keep-alives messages aren't authenticated, and |>|do not trigger responses, a gateway would still have to |>|process them, and since a gateway typically would serve a large number of browser |>|clients, that could have quite big performance impact (the number of |>|STUN keep-alives sent per session of course depend on how much other |>|media traffic there is, but still). |> |>STUN keepalives are required by ICE only in the absence of |>media traffic. | |Yes. That's what I meant with the: | | "(the number of STUN keep-alives sent per session of course depend on how much other media |traffic there is, but still)" | |...statement :) | |>Here are the snip from RFC 5245: |> |> |>10. Keepalives |> |>If there has been no packet sent on the candidate pair ICE is |>using for a media component for Tr seconds (where packets |>include those defined for the component (RTP or RTCP) and |>previous keepalives), an agent MUST generate a keepalive on |>that pair. Tr SHOULD be configurable and SHOULD have a |>default of 15 seconds. Tr MUST NOT be configured to less |>than 15 seconds. |> |> |> |>20.2.3. Keepalives |> |>STUN keepalives (in the form of STUN Binding Indications) are |>sent in the middle of a media session. However, they are |>sent only in the absence of actual media traffic. In |>deployments that are not utilizing Voice Activity Detection |>(VAD), the keepalives are never used and there is no increase |>in bandwidth usage. When VAD is being used, keepalives will |>be sent during silence periods. This involves a single |>packet every 15-20 seconds, far less than the packet every |>20-30 ms that is sent when there is voice. Therefore, |>keepalives don't have any real impact on capacity planning. |> |> |>Do you think there is still a problem? | |Well, it depends on the amount of outgoing media traffic, but in cases where you only receive media |you would still need to send keep-alives. | |Regards, | |Christer From christer.holmberg@ericsson.com Wed Sep 14 04:28: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 0681A21F8CA7 for ; Wed, 14 Sep 2011 04:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 Bw0ad8ZgQ3Ou for ; Wed, 14 Sep 2011 04:28: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 20CDF21F8CA5 for ; Wed, 14 Sep 2011 04:28:46 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-c8-4e709066f974 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 0B.B5.02839.660907E4; Wed, 14 Sep 2011 13:30:46 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 14 Sep 2011 13:30:46 +0200 From: Christer Holmberg To: "Muthu Arul Mozhi Perumal (mperumal)" , "rtcweb@ietf.org" Date: Wed, 14 Sep 2011 13:30:44 +0200 Thread-Topic: [rtcweb] STUN for keep-alive Thread-Index: Acxyw30r82gF7xzoSe2t1rt6OG8s+wAA6iNwAABiKWAAAWch4AAAqu/Q Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.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== Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 11:28:48 -0000 Hi,=20 >>|Well, it depends on the amount of outgoing media traffic, but in cases=20 >>|where you only receive media you would still need to send keep-alives. >=20 > If you are not sending anything the NAT binding in that=20 > direction will likely timeout. On the other hand, if you are=20 > operating in a controlled environment ICE already allows you=20 > to set the STUN keepalive duration to the longest duration=20 > possible in your environment, so it is already flexible. Sure, but there is still a max time between the keep-alives. >However, it mandates STUN keepalives to be used when an agent=20 >is a full ICE implementation and is communicating with a peer=20 >that supports ICE (lite/full). Are you saying it should allow=20 >a different UDP keepalive method because it can possible have=20 >a lesser performance impact? Yes. Also, it's not only about how often the STUN keep-alives would be sent, and= the perfomance impact that would have. Using e.g. RTP, the media handler w= ould not have to be prepared to receive the STUN keep-alives in the first p= lace, it could simply just relay whatever comes on the media plane. Regards, Christer > |-----Original Message----- > |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > |Sent: Wednesday, September 14, 2011 3:59 PM > |To: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org > |Subject: RE: [rtcweb] STUN for keep-alive > | > | > |Hi, > | > |>|Because, eventhough the keep-alives messages aren't authenticated, > and > |>|do not trigger responses, a gateway would still have to=20 > process them,=20 > |>|and since a gateway typically would serve a large > number of browser > |>|clients, that could have quite big performance impact (the=20 > number of=20 > |>|STUN keep-alives sent per session of course depend on how=20 > much other=20 > |>|media traffic there is, but still). > |> > |>STUN keepalives are required by ICE only in the absence of media=20 > |>traffic. > | > |Yes. That's what I meant with the: > | > | "(the number of STUN keep-alives sent per session of course > depend on how much other media > |traffic there is, but still)" > | > |...statement :) > | > |>Here are the snip from RFC 5245: > |> > |> > |>10. Keepalives > |> > |>If there has been no packet sent on the candidate pair ICE is using=20 > |>for a media component for Tr seconds (where packets include those=20 > |>defined for the component (RTP or RTCP) and previous=20 > keepalives), an=20 > |>agent MUST generate a keepalive on that pair. Tr SHOULD be=20 > |>configurable and SHOULD have a default of 15 seconds. Tr=20 > MUST NOT be=20 > |>configured to less than 15 seconds. > |> > |> > |> > |>20.2.3. Keepalives > |> > |>STUN keepalives (in the form of STUN Binding Indications)=20 > are sent in=20 > |>the middle of a media session. However, they are sent only in the=20 > |>absence of actual media traffic. In deployments that are=20 > not utilizing=20 > |>Voice Activity Detection (VAD), the keepalives are never used and=20 > |>there is no increase in bandwidth usage. When VAD is being used,=20 > |>keepalives will be sent during silence periods. This involves a=20 > |>single packet every 15-20 seconds, far less than the packet every=20 > |>20-30 ms that is sent when there is voice. Therefore, keepalives=20 > |>don't have any real impact on capacity planning. > |> > |> > |>Do you think there is still a problem? > | > |Well, it depends on the amount of outgoing media traffic,=20 > but in cases > where you only receive media > |you would still need to send keep-alives. > | > |Regards, > | > |Christer > = From mperumal@cisco.com Wed Sep 14 05:06: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 4DF9921F8906 for ; Wed, 14 Sep 2011 05:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.46 X-Spam-Level: X-Spam-Status: No, score=-10.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGxvJ5OL3pq7 for ; Wed, 14 Sep 2011 05:06:46 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E0DD621F8888 for ; Wed, 14 Sep 2011 05:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=4802; q=dns/txt; s=iport; t=1316002135; x=1317211735; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=rRygDkcyiQCe/G0Owhcz5WIt9MvmuS2ijN82VcddYNE=; b=HW9MtW9efMjxTAxkaGxEPrvuMSakn0GD7z1m+DJN3VrKZghKus4VbXWU //3W8taxI7grnaLRMiWpGZUIhuvOBEVQSMvVik3B3ACFv1oHqKOhZt3KQ ZBX/GR6eE90/V2YJCHhpXE8A93mPhJ8DiaB5Ns2GhGMHVT3anSGb3TR2T c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcAABCYcE5Io8US/2dsb2JhbABBmGuPD3iBUwEBBRIBHQpLBAIBCBEEAQELBhcBBgFFCQgBAQQBCggIGp9iAZ4yhg5gBIdskHeMCQ X-IronPort-AV: E=Sophos;i="4.68,380,1312156800"; d="scan'208";a="54545762" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 14 Sep 2011 12:08:51 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8EC8jFH012358; Wed, 14 Sep 2011 12:08:50 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, 14 Sep 2011 17:38:46 +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, 14 Sep 2011 17:38:45 +0530 Message-ID: <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] STUN for keep-alive Thread-Index: Acxyw30r82gF7xzoSe2t1rt6OG8s+wAA6iNwAABiKWAAAWch4AAAqu/QAABRLRA= References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Christer Holmberg" , X-OriginalArrivalTime: 14 Sep 2011 12:08:46.0985 (UTC) FILETIME=[0E452790:01CC72D7] Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 12:06:47 -0000 |Sure, but there is still a max time between the keep-alives. You are free to set it to a very long duration that disables keepalives for all practical purposes (assuming such duration is represented by a 32-bit unsigned integer you can set it to ~136 years). |Using e.g. RTP, the media handler would not have to be=20 |prepared to receive the STUN keep-alives in the first place,=20 |it could simply just relay whatever comes on the media plane. If the media handles can handle STUN binding requests efficiently I don't see why they can't handle STUN binding indications (keepalives) in a similar manner. On the other hand, if the media handles aren't STUN aware and are just relaying STUN binding requests in the media plane as UDP/RTP, they would do the same also for STUN keepalives. Muthu |-----Original Message----- |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] |Sent: Wednesday, September 14, 2011 5:01 PM |To: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org |Subject: RE: [rtcweb] STUN for keep-alive | | |Hi, | |>>|Well, it depends on the amount of outgoing media traffic, but in cases |>>|where you only receive media you would still need to send keep-alives. |> |> If you are not sending anything the NAT binding in that |> direction will likely timeout. On the other hand, if you are |> operating in a controlled environment ICE already allows you |> to set the STUN keepalive duration to the longest duration |> possible in your environment, so it is already flexible. | |Sure, but there is still a max time between the keep-alives. | |>However, it mandates STUN keepalives to be used when an agent |>is a full ICE implementation and is communicating with a peer |>that supports ICE (lite/full). Are you saying it should allow |>a different UDP keepalive method because it can possible have |>a lesser performance impact? | |Yes. | |Also, it's not only about how often the STUN keep-alives would be sent, and the perfomance impact that |would have. Using e.g. RTP, the media handler would not have to be prepared to receive the STUN keep- |alives in the first place, it could simply just relay whatever comes on the media plane. | |Regards, | |Christer | | | | |> |-----Original Message----- |> |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] |> |Sent: Wednesday, September 14, 2011 3:59 PM |> |To: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org |> |Subject: RE: [rtcweb] STUN for keep-alive |> | |> | |> |Hi, |> | |> |>|Because, eventhough the keep-alives messages aren't authenticated, |> and |> |>|do not trigger responses, a gateway would still have to |> process them, |> |>|and since a gateway typically would serve a large |> number of browser |> |>|clients, that could have quite big performance impact (the |> number of |> |>|STUN keep-alives sent per session of course depend on how |> much other |> |>|media traffic there is, but still). |> |> |> |>STUN keepalives are required by ICE only in the absence of media |> |>traffic. |> | |> |Yes. That's what I meant with the: |> | |> | "(the number of STUN keep-alives sent per session of course |> depend on how much other media |> |traffic there is, but still)" |> | |> |...statement :) |> | |> |>Here are the snip from RFC 5245: |> |> |> |> |> |>10. Keepalives |> |> |> |>If there has been no packet sent on the candidate pair ICE is using |> |>for a media component for Tr seconds (where packets include those |> |>defined for the component (RTP or RTCP) and previous |> keepalives), an |> |>agent MUST generate a keepalive on that pair. Tr SHOULD be |> |>configurable and SHOULD have a default of 15 seconds. Tr |> MUST NOT be |> |>configured to less than 15 seconds. |> |> |> |> |> |> |> |>20.2.3. Keepalives |> |> |> |>STUN keepalives (in the form of STUN Binding Indications) |> are sent in |> |>the middle of a media session. However, they are sent only in the |> |>absence of actual media traffic. In deployments that are |> not utilizing |> |>Voice Activity Detection (VAD), the keepalives are never used and |> |>there is no increase in bandwidth usage. When VAD is being used, |> |>keepalives will be sent during silence periods. This involves a |> |>single packet every 15-20 seconds, far less than the packet every |> |>20-30 ms that is sent when there is voice. Therefore, keepalives |> |>don't have any real impact on capacity planning. |> |> |> |> |> |>Do you think there is still a problem? |> | |> |Well, it depends on the amount of outgoing media traffic, |> but in cases |> where you only receive media |> |you would still need to send keep-alives. |> | |> |Regards, |> | |> |Christer |> From ibc@aliax.net Wed Sep 14 05:16: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 13C5821F8C81 for ; Wed, 14 Sep 2011 05:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 B0zgZ7zhnRYw for ; Wed, 14 Sep 2011 05:16:08 -0700 (PDT) Received: from mail-qw0-f46.google.com (mail-qw0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6646321F8B84 for ; Wed, 14 Sep 2011 05:16:08 -0700 (PDT) Received: by qwj8 with SMTP id 8so63652qwj.19 for ; Wed, 14 Sep 2011 05:18:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.105 with SMTP id q41mr2807875qci.216.1316002693847; Wed, 14 Sep 2011 05:18:13 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Wed, 14 Sep 2011 05:18:13 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233EDB2D1@ESESSCMS0356.eemea.ericsson.se> References: <1F2A2C70609D9E41844A2126145FC09802585056@HKGMBOXPRD22.polycom.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB21A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2D1@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 14 Sep 2011 14:18:13 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Wed, 14 Sep 2011 12:16:09 -0000 2011/9/14 Christer Holmberg : >>Could you please point to the exact section in the draft in >>which you miss such explanation? We'll be very glad to improve it. > > I would like something like: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0"When the WebSocket is used to transport SIP t= raffic, the WebSocket MUST be established at the point where > =C2=A0 =C2=A0 =C2=A0 =C2=A0the browser SIP application shall be able to p= lace and receive SIP calls. Based on local policy, this might > =C2=A0 =C2=A0 =C2=A0 =C2=A0e.g. occur once the JavaScript SIP application= has been downloaded from the web server, or when the > =C2=A0 =C2=A0 =C2=A0 =C2=A0SIP user using the browser application registe= rs itself to a SIP registrar (assuming that calls cannot be > =C2=A0 =C2=A0 =C2=A0 =C2=A0placed or received before that)." > > I guess text text could fit either in section 4.x, or in section 6. Thanks a lot. I've added a very similar text in section 6 (second paragraph= ): ------------------------------ 6. WebSocket Client Usage As stated in [I-D.ietf-hybi-thewebsocketprotocol], a WebSocket URI [RFC3986] is given to the WebSocket client who resolves the URI destination and establishes a WebSocket connection with the corresponding server (by performing the handshake and negotiation procedures described in [I-D.ietf-hybi-thewebsocketprotocol]). The WebSocket connection MUST be established at the point where the client application (typically a web-based application) shall be able to place and receive SIP calls. Based on local policy, this might e.g. occur once the JavaScript SIP application has been downloaded from the web server, or when the SIP user using the web-browser application registers itself to a SIP registrar (assuming that calls cannot be placed or received before that). The client application is supposed to be provided with SIP account configuration values (as an AoR, outbound proxy and so on). Such values are used by the client application when generating SIP messages. ----------------------------- > I was not suggesting that we mandate registration. It was just an example= of when one could choose to establish the WebSocket, IF the browser shall = be able to receive incoming calls after registration. If it shall be able t= o receive incoming calls before the registration (or, if there is no regist= ration in the first place), the WebSocket needs to be established at some o= ther point. It's clear now :) > I think it's better to refer to RFC 6223, which only covers the keep-aliv= e part of RFC 5626. > > (RFC 5626 contains also contains other stuff that most likely doesn't app= ly for the browser case). Good point. It will be mentioned in version -01 of the draft (along with the above text addition suggested by you). Thanks a lot for your input. Regards. --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Wed Sep 14 05: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 B9DBC21F8BF9 for ; Wed, 14 Sep 2011 05:40:19 -0700 (PDT) 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.087, 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 5jjeLrNfYXcy for ; Wed, 14 Sep 2011 05:40:19 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBA221F8BEE for ; Wed, 14 Sep 2011 05:40: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; Wed, 14 Sep 2011 08:42:26 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 08:42:26 -0400 From: Hadriel Kaplan To: Randell Jesup Thread-Topic: [rtcweb] Use of offer / answer semantics Thread-Index: AQHMctvBvq5+M1/n60mDk2w9ROy7og== Date: Wed, 14 Sep 2011 12:42:26 +0000 Message-ID: References: <2E693A54-A8E7-46D8-94C6-7028F5497436@acmepacket.com> <4E6FD14F.7070301@jesup.org> In-Reply-To: <4E6FD14F.7070301@jesup.org> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Use of offer / answer semantics X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 12:40:19 -0000 On Sep 13, 2011, at 5:55 PM, Randell Jesup wrote: > The browser needs to know *somehow* that certain sets of audio and video = streams need to be synchronized, and be given the tools and data to do so w= ell. And you may want to synchronize multiple video streams to the same au= dio stream (think the dual-camera case). Good point. =20 > I am somewhat torn between ease-of-use for the developers (and increased = likelihood of them getting it right) and providing a truly generic infrastr= ucture that people *can* build anything on top of - but decreases the likel= ihood of getting it right, and decreases the likelihood of interop (federat= ion) working or being easy. I agree of course, but I wonder if it wouldn't cause more harm than good in= the end. I'm not a web-app developer, but I have to imagine that variance= s in browser functionality across browser vendors and versions must be a ni= ghtmare. Even if it bloats my javascript, I would rather be in control and= able to work across them more than rely on them all getting upgraded. And= my assumption is the less intelligence and knowledge built into the browse= r, the less variance and bugs there'd be in them. I mean what are the odds= we even get a browser-built-in SDP engine right the first time? =20 And do we keep upgrading the browsers to get things like sdp-cap-neg, telep= resence/CLUE attributes, SIPREC attributes, etc.? =20 There is maybe another option: keep the API to the browser as discrete medi= a settings not SDP, but the IETF or W3C provides an open-source javascript = library/code-snippet that handles SDP. In other words instead of building = the SDP into the browser, keep it as javascript but make such a javascript = available/approved by the IETF/W3C, for example have the code in an RFC. T= hat way if we screw it up the web-app developers can fix it (and we can pub= lish an update); and if the web-app developer needs more complex SDP they'l= l have the code and can modify it; and if they don't need SDP they don't bo= ther using the library; and the browsers don't need upgrading. -hadriel From christer.holmberg@ericsson.com Wed Sep 14 06:05: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 7F1D021F8CB6 for ; Wed, 14 Sep 2011 06:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 1BlET9rmISic for ; Wed, 14 Sep 2011 06:05: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 C1CEA21F8CCA for ; Wed, 14 Sep 2011 06:05:33 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-bd-4e70a71da6bf Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 84.16.02839.D17A07E4; Wed, 14 Sep 2011 15:07:42 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 14 Sep 2011 15:07:41 +0200 From: Christer Holmberg To: "Muthu Arul Mozhi Perumal (mperumal)" , "rtcweb@ietf.org" Date: Wed, 14 Sep 2011 15:07:40 +0200 Thread-Topic: [rtcweb] STUN for keep-alive Thread-Index: Acxyw30r82gF7xzoSe2t1rt6OG8s+wAA6iNwAABiKWAAAWch4AAAqu/QAABRLRAAAxn+QA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.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== Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 13:05:35 -0000 Hi,=20 >>|Sure, but there is still a max time between the keep-alives. >=20 >You are free to set it to a very long duration that disables=20 >keepalives for all practical purposes (assuming such duration=20 >is represented by a 32-bit unsigned integer you can set it to=20 >~136 years). Yes, but at the end of the day something has to be sent in order to keep th= e NAT binding open. >>|Using e.g. RTP, the media handler would not have to be prepared to=20 >>|receive the STUN keep-alives in the first place, it could=20 >>|simply just=20 >>|relay whatever comes on the media plane. >=20 > If the media handles can handle STUN binding requests=20 > efficiently I don't see why they can't handle STUN binding=20 > indications (keepalives) in a similar manner. I believe it knows when to expect those. But, in any case, the main reason = behind the proposal is to decrease the number of STUN requests. > On the other hand, if the media handles aren't STUN aware and are just=20 > relaying STUN binding requests in the media plane as UDP/RTP,=20 > they would do the same also for STUN keepalives. Sure, I was talking about the case where the gateway terminates ICE and STU= N. Regards, Christer > |-----Original Message----- > |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > |Sent: Wednesday, September 14, 2011 5:01 PM > |To: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org > |Subject: RE: [rtcweb] STUN for keep-alive > | > | > |Hi, > | > |>>|Well, it depends on the amount of outgoing media traffic, but in > cases > |>>|where you only receive media you would still need to send > keep-alives. > |> > |> If you are not sending anything the NAT binding in that direction=20 > |> will likely timeout. On the other hand, if you are operating in a=20 > |> controlled environment ICE already allows you to set the STUN=20 > |> keepalive duration to the longest duration possible in your=20 > |> environment, so it is already flexible. > | > |Sure, but there is still a max time between the keep-alives. > | > |>However, it mandates STUN keepalives to be used when an agent is a=20 > |>full ICE implementation and is communicating with a peer=20 > that supports=20 > |>ICE (lite/full). Are you saying it should allow a different UDP=20 > |>keepalive method because it can possible have a lesser performance=20 > |>impact? > | > |Yes. > | > |Also, it's not only about how often the STUN keep-alives=20 > would be sent, > and the perfomance impact that > |would have. Using e.g. RTP, the media handler would not have to be > prepared to receive the STUN keep- > |alives in the first place, it could simply just relay=20 > whatever comes on > the media plane. > | > |Regards, > | > |Christer > | > | > | > | > |> |-----Original Message----- > |> |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > |> |Sent: Wednesday, September 14, 2011 3:59 PM > |> |To: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org > |> |Subject: RE: [rtcweb] STUN for keep-alive > |> | > |> | > |> |Hi, > |> | > |> |>|Because, eventhough the keep-alives messages aren't=20 > authenticated, > |> and > |> |>|do not trigger responses, a gateway would still have to > |> process them, > |> |>|and since a gateway typically would serve a large > |> number of browser > |> |>|clients, that could have quite big performance impact (the > |> number of > |> |>|STUN keep-alives sent per session of course depend on how > |> much other > |> |>|media traffic there is, but still). > |> |> > |> |>STUN keepalives are required by ICE only in the absence of media=20 > |> |>traffic. > |> | > |> |Yes. That's what I meant with the: > |> | > |> | "(the number of STUN keep-alives sent per session of course > |> depend on how much other media > |> |traffic there is, but still)" > |> | > |> |...statement :) > |> | > |> |>Here are the snip from RFC 5245: > |> |> > |> |> > |> |>10. Keepalives > |> |> > |> |>If there has been no packet sent on the candidate pair=20 > ICE is using=20 > |> |>for a media component for Tr seconds (where packets=20 > include those=20 > |> |>defined for the component (RTP or RTCP) and previous > |> keepalives), an > |> |>agent MUST generate a keepalive on that pair. Tr SHOULD be=20 > |> |>configurable and SHOULD have a default of 15 seconds. Tr > |> MUST NOT be > |> |>configured to less than 15 seconds. > |> |> > |> |> > |> |> > |> |>20.2.3. Keepalives > |> |> > |> |>STUN keepalives (in the form of STUN Binding Indications) > |> are sent in > |> |>the middle of a media session. However, they are sent=20 > only in the=20 > |> |>absence of actual media traffic. In deployments that are > |> not utilizing > |> |>Voice Activity Detection (VAD), the keepalives are never=20 > used and=20 > |> |>there is no increase in bandwidth usage. When VAD is=20 > being used,=20 > |> |>keepalives will be sent during silence periods. This involves a=20 > |> |>single packet every 15-20 seconds, far less than the=20 > packet every=20 > |> |>20-30 ms that is sent when there is voice. Therefore,=20 > keepalives=20 > |> |>don't have any real impact on capacity planning. > |> |> > |> |> > |> |>Do you think there is still a problem? > |> | > |> |Well, it depends on the amount of outgoing media traffic, > |> but in cases > |> where you only receive media > |> |you would still need to send keep-alives. > |> | > |> |Regards, > |> | > |> |Christer > |> > = From matthew.kaufman@skype.net Wed Sep 14 06:14: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 3470121F8BE8 for ; Wed, 14 Sep 2011 06:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVoFwr+G2hQT for ; Wed, 14 Sep 2011 06:14:52 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 16B4D21F8BE9 for ; Wed, 14 Sep 2011 06:14:51 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 2B33D1705; Wed, 14 Sep 2011 15:16:59 +0200 (CEST) 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=vDWN7c9KbyspTP 0jLjAZmKWSO2c=; b=c/MiFQby9zfeqJY1IT/cidTIrI5JAVjaeSucmheSXfW1Se OeOQZxkFozhnLfsroyUgAWmXBveEFs3GulhIdkJlztOPIYGj4v9+F5fDGovPHR/Z XvEEUWSfD8mOZtL9OpoGkzOfK61+mX3SiU2sL+1DFFWTRFwt8lJ0J997LGw7w= 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=cn3r1YR6Ca3YshdiIn95R9 sTjit2HXX0lnxgBTQu6pV/zCgXoSLbPcYsH+qm3e4os4scpDWsmtpspip9Ns7hQa 6Fng/1ESTH/vyBEIwz3kl2pxdtf5GUuNoLhCTP+DLYH5tQgM1ijHTwViBUA1zgrB Jh+vYga8V0YxMrjfkLRK8= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 298FF7F6; Wed, 14 Sep 2011 15:16:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 06FB81672684; Wed, 14 Sep 2011 15:16:58 +0200 (CEST) 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 zazSJ6GkW0yN; Wed, 14 Sep 2011 15:16:58 +0200 (CEST) Received: from Matthew-Kaufman-Air.local (c-217-115-41-36.cust.bredband2.com [217.115.41.36]) by zimbra.skype.net (Postfix) with ESMTPSA id 4DC8A1672682; Wed, 14 Sep 2011 15:16:58 +0200 (CEST) Message-ID: <4E70A943.5060307@skype.net> Date: Wed, 14 Sep 2011 15:16:51 +0200 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Magnus Westerlund References: <4E6F17AB.4000005@ericsson.com> In-Reply-To: <4E6F17AB.4000005@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MediaStream Label and CNAME X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 13:14:56 -0000 On 9/13/11 10:43 AM, Magnus Westerlund wrote: > ...In the SDP the SSRC part of the MediaStream will in its list of a=ssrc > attributes contain one that reads > > "a=ssrc:345678123 mslabel=61ca6552-968a-435d-88d9-a4727f2ed515" > > In the case a particular track is part of multiple MediaStream objects > the SSRC will have multiple mslabel values... And so we continue down the path of requiring the Javascript API to emit and consume SDP... Matthew Kaufman From magnus.westerlund@ericsson.com Wed Sep 14 06: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 A42B121F8BE7 for ; Wed, 14 Sep 2011 06:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.501 X-Spam-Level: X-Spam-Status: No, score=-106.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 bgy5tD+L3s7x for ; Wed, 14 Sep 2011 06:28: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 F328E21F8C2A for ; Wed, 14 Sep 2011 06:27:52 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-2f-4e70ac590f96 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 92.D9.02839.95CA07E4; Wed, 14 Sep 2011 15:30:01 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Wed, 14 Sep 2011 15:30:01 +0200 Message-ID: <4E70AC55.2020409@ericsson.com> Date: Wed, 14 Sep 2011 15:29:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <4E6F17AB.4000005@ericsson.com> <4E6F6963.9090702@alvestrand.no> <4E7079B5.2060803@ericsson.com> <4E708022.1020506@alvestrand.no> In-Reply-To: <4E708022.1020506@alvestrand.no> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Multiple videos in one MediaStream (Re: MediaStream Label and CNAME) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 13:28:01 -0000 Hi, See below. On 2011-09-14 12:21, Harald Alvestrand wrote: > On 09/14/11 11:53, Magnus Westerlund wrote: >> On 2011-09-13 16:32, Harald Alvestrand wrote: >>> On 09/13/11 10:43, Magnus Westerlund wrote: >> If I read this correctly, what you are doing is to creating two media >> streams based on a first media stream. Thus you have multiple >> mediaStream objects that contains tracks that has a common >> synchronziation context. So from my point of view you have very well >> demonstrated why you need CNAME to be a property associated with the >> tracks in the media stream and not be the label for the mediaStream. > That's a good point. > > My thinking when typing this was that stuff that happens inside a > browser is synchronized "enough" by default, so that we don't need to > carry the label along in order to keep synchronity between myFirstVideo > and mySecondVideo. This may or may not be optimistic; input sought. I am not certain that would work well. In reality you do need to keep track of all your media resources against some reference clock. As offset etc are depending on the context the streams comes from I think in most cases you do need to track them. You can't rely on them being sync only because they are local. My suggestion is that the CNAME never is exposed in the API. It is something that happens under the hood and only really present when transmitting the tracks over RTP where each SSRC will expose the CNAME it is associated with. > > The audio tracks inside myFirstVideo are declared as synchronized to the > myFirstVideo video track by virtue of being inside the same MediaStream > object; this carries over to them being synchronized if myFirstVideo is > connected to another PeerConnection, if this is allowed (see "recording" > discussion). (In this case, I think the CNAME should NOT be the same as > that coming in over the incoming PeerConnection). Can we please keep the forwarding of media stream separate from just the basics. I will come back to the forwarding case and my view on how CNAME and label needs to be handled in these cases. Lets start with the basic case when you media stream cloning/forking on the receiver side. A singel mediaStream with a label and one audio and 2 video is received. They are from one synchronization context. You clone the media stream into a second one where only the second video is selected for playback and the first MS has the audio and the first video. If one uses the received CNAME as indicator that they are the same context and play them back this works fine. But unless the label and cname is inherited and kept you broken sync. And you have in fact mandated a less from obvious implementation method to achieve synchronized playback. But it requires correct implementation on the sending side. Also, if the application uses the data channel or a channel over the webserver to tell each other about what it is doing with the different tracks, the label either needs to be different for the different clones or you can't separate which mediaStream object you are referring to. If we look at this from the senders perspective, the sender must create a single media stream in an object it can't directly play back locally for self view without splitting as it contains two video tracks. And if the application want to distribute the second camera as an identifiable labeled entity and still be synchronized with the first camera and the audio I don't understand how to accomplish this with the current API unless you can have multiple mediaStreams with still allows for sync. If relaying of media is allowed I have the following view. I think the CNAME should be maintained if the media in itself isn't modified. If it is mixed or changed, or combined in the node, then a new CNAME shall be created. When it comes to the MediaStream label it will implicitly be the same. You receive the MediaStream from one PeerConnection. Then you add it to another. In this JS instance it is the same MediaStream. You just have to keep in mind if you refer to operations that should be done on the transmission of that MS or local operations on it (thus more associated with what you receive). >> Or how do you see the label for the media stream being handled when you >> create two mediaStream objects from the incomming "stream" that has one >> label? > My original thinking was that a CNAME is created for any MediaStream at > creation time, so that we're operating with three CNAMEs in the example > above. I think that is a bad idea. This as it doesn't match the synchronization context of the actual stream. All tracks in all three MS are in fact from the same sync context. It also makes it very easy for a careless implementor to destroy the information it in fact may want. > > Another possibility is that CNAME is a property of the attachment of a > MediaStream to a PeerConnection object; this has the advantage that the > CNAME property is only defined in the cases where we need it, but we > don't have to carry the baggage of actually generating CNAMEs for > MediaStreams that are not connected to PeerConnections. My view is that it should be associated with the actual track source node. So any media coming from a local device in a browser instance will have the same CNAME as they are related to the same wall clock and captured in a common time space. As it is unlikely that the implementor of the webapp actually can determine if any source is coming from another physical context. And capturing multiple physical contexts on a common time base isn't a problem as long as all individual tracks that one wants to capture are on the same time base. I would also like to point out that due to that an implementor may call getusermedia more than once in the program, thus creating different MediaStream objects but for a potential overlapping set of underlying media sources. Shouldn't these be possible to sync as they in reality are as they are coming from all local devices? Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Sep 14 06: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 8153121F8BE8 for ; Wed, 14 Sep 2011 06:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.903 X-Spam-Level: X-Spam-Status: No, score=-105.903 tagged_above=-999 required=5 tests=[AWL=-0.504, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_74=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 IGkOyLX4lH5A for ; Wed, 14 Sep 2011 06:53:18 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C305E21F8BBE for ; Wed, 14 Sep 2011 06:53:17 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-4e-4e70b24ecfa4 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E3.64.20773.E42B07E4; Wed, 14 Sep 2011 15:55:26 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 14 Sep 2011 15:55:25 +0200 Message-ID: <4E70B24C.6070708@ericsson.com> Date: Wed, 14 Sep 2011 15:55:24 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Matthew Kaufman References: <4E6F17AB.4000005@ericsson.com> <4E70A943.5060307@skype.net> In-Reply-To: <4E70A943.5060307@skype.net> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] MediaStream Label and CNAME X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 13:53:18 -0000 On 2011-09-14 15:16, Matthew Kaufman wrote: > On 9/13/11 10:43 AM, Magnus Westerlund wrote: >> ...In the SDP the SSRC part of the MediaStream will in its list of a=ssrc >> attributes contain one that reads >> >> "a=ssrc:345678123 mslabel=61ca6552-968a-435d-88d9-a4727f2ed515" >> >> In the case a particular track is part of multiple MediaStream objects >> the SSRC will have multiple mslabel values... > > And so we continue down the path of requiring the Javascript API to emit > and consume SDP... Well, as there are no other API proposal that exists in the W3C WG currently I don't know what else I can use in the examples. But in fact what is needed is a signaling channel between the peers that can carry a list of RTP Session:SSRC value = label value. I think that can be applied to a number of different signaling and API alternatives. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From jonathan@vidyo.com Wed Sep 14 07:44: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 74DED21F8CBC for ; Wed, 14 Sep 2011 07:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 Ki8c6j-knLap for ; Wed, 14 Sep 2011 07:44:39 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9224E21F8B90 for ; Wed, 14 Sep 2011 07:44:39 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 01E24553BD3; Wed, 14 Sep 2011 10:46:47 -0400 (EDT) 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 00BAD553AF2; Wed, 14 Sep 2011 10:46:45 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Wed, 14 Sep 2011 10:45:47 -0400 From: Jonathan Lennox To: Christer Holmberg , "Muthu Arul Mozhi Perumal (mperumal)" , "rtcweb@ietf.org" Date: Wed, 14 Sep 2011 10:45:47 -0400 Thread-Topic: [rtcweb] STUN for keep-alive Thread-Index: Acxyw30r82gF7xzoSe2t1rt6OG8s+wAA6iNwAABiKWAACPIQoA== Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@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 Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 14:44:40 -0000 Christer Holmberg writes: > Well, it depends on the amount of outgoing media traffic, but in cases wh= ere you only receive media you would still need to send keep-alives. Remember, RTCWeb is (probably) mandating RTP/RTCP mux. I'd need to do some= math to be certain, but I'm pretty sure that in almost all normal circumst= ances, the RTCP regular reporting interval should be significantly smaller = than the STUN keepalive interval. From ibc@aliax.net Wed Sep 14 07:54: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 38B2B21F88A0 for ; Wed, 14 Sep 2011 07:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 cKXnilKcoIrv for ; Wed, 14 Sep 2011 07:54:49 -0700 (PDT) Received: from mail-qw0-f46.google.com (mail-qw0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7C41A21F888A for ; Wed, 14 Sep 2011 07:54:49 -0700 (PDT) Received: by qwj8 with SMTP id 8so170744qwj.19 for ; Wed, 14 Sep 2011 07:56:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.105 with SMTP id q41mr2959838qci.216.1316012217191; Wed, 14 Sep 2011 07:56:57 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Wed, 14 Sep 2011 07:56:57 -0700 (PDT) Date: Wed, 14 Sep 2011 16:56:57 +0200 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] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 14:54:50 -0000 Hi all, There are some threads about the need (or not) for a well defined signaling protocol within WebRTC. I would like to comment about it. WebRTC defines multimedia capabilities for web-browsers and mandates protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566). The aim of these protocols is to enable multimedia streams between a web-browser and other endpoint (which could also be a web-browser). But having the above is not enough since a signaling protocol/mechanism for managing the media sessions is required (for requesting a multimedia session to the endpoint, for terminating it, for putting it in hold...). Both SIP and XMPP (with Jingle) behave as a signaling protocol and manage multimedia sessions based on SDP descriptions (SIP uses plain SDP grammar as defined in RFC 4566 while XMPP uses a XML version of the SDP format). So both SIP and XMPP could be a good choice. But also any custom signaling protocol carrying like-SDP information. If WebRTC mandates a specific signaling protocol then all the web providers should incorporate such a protocol within their infrastructure, which seems not feasible for me (let's say web pages served by hosting datacenters which just provide an Apache server for the web developer, for example). So I wonder: why is a specific signaling protocol needed at all? AFAIK the only we need is an API (within WebRTC) to manage multimedia sessions (start it, terminate it, use codec XXXX, put on hold...). How the client application (let's assume the JavaScript code) obtains such information should be out of the scope of WebRTC. The client application (JavaScript) just needs to retrieve (via HTTP, WebSocket or whatever) the "SDP" information provided by the endpoint and use such data for making API calls to the WebRTC stack by passing as arguments the remote peer IP, port, type of session, codec to use, and so on. For example, if a web page makes usage of SIP over WebSocket or XMPP over WebSocket, the signaling (also containing SDP information) would be carried within SIP or XMPP messages. The only reqiremente would be for the WebSocket server to be integrated within a SIP proxy/server implementing draft-ibc-rtcweb-sip-websocket or a XMPP server implementing draft-moffitt-xmpp-over-websocket. The client application (JavaScript in the web page) should parse the SDP bodies and make WebRTC calls when appropriate to initiate or answer multimedia sessions. And then we get full interoperability with SIP/XMPP world out there (without requiring a server/gateway performing conversion of application level protocols). In the same way, other web page which just requires multimedia sessions between web-browsers, could prefer to implement a simple and custom JSON format as a signaling mechanism on top of WebSocket (or use HTTP Comet, long-polling, etc). It could map the SDP definition into a JSON struct. Again the JavaScript code parses the SDP information and calls WebRTC API functions to manage multimedia sessions. The only requirement would be for the HTTP server to implement WebSocket or HTTP Comet (or nothing if HTTP long polling is used). So my proposal is that WebRTC should not mandate a signaling protocol in the web-browser, but just define a requeriment for managing multimedia sessions from the JavaScript code given a well defined API. IMHO this is the way that fits well with the flexibility of the web and lets each web provider to decide which technology to use as signaling protocol, rather than forcing him to implement SIP/XMPP/other-protocol in server side. Best regards. --=20 I=C3=B1aki Baz Castillo From randell-ietf@jesup.org Wed Sep 14 08:02: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 D5D1121F8B04 for ; Wed, 14 Sep 2011 08:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-JrgmdYQvfm for ; Wed, 14 Sep 2011 08:02:54 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 5C78D21F8AF5 for ; Wed, 14 Sep 2011 08:02:54 -0700 (PDT) Received: from [12.104.145.50] (helo=[198.18.84.215]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R3r1L-0006hI-2W for rtcweb@ietf.org; Wed, 14 Sep 2011 10:05:03 -0500 Message-ID: <4E70C27A.9040805@jesup.org> Date: Wed, 14 Sep 2011 08:04:26 -0700 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 15:02:54 -0000 On 9/14/2011 7:45 AM, Jonathan Lennox wrote: > Christer Holmberg writes: >> Well, it depends on the amount of outgoing media traffic, but in cases where you only receive media you would still need to send keep-alives. > Remember, RTCWeb is (probably) mandating RTP/RTCP mux. I'd need to do some math to be certain, but I'm pretty sure that in almost all normal circumstances, the RTCP regular reporting interval should be significantly smaller than the STUN keepalive interval. Agreed; I think it would require a bizarre session setup (RR=0) to force the RTCP interval out far enough to cause problems. (Don't forget to include the +- 50% in the calculation.) RFC 3556: o If RR is zero, then the proportion of participants that are senders can never be greater than RS/(RS+RR), and therefore non-senders never get any RTCP bandwidth independent of the number of senders. Obviously, RR values near 0 could also cause a problem. A statement about not using RR values that would result in RTCP intervals greater than N should be enough I think. BTW: Have we mandated that RTP & RTCP be muxed always to all destinations, or that it must be supported and offered? If you're talking to a legacy device that doesn't mux, what happens? -- Randell Jesup randell-ietf@jesup.org From magnus.westerlund@ericsson.com Wed Sep 14 08:06: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 72C8921F8C47 for ; Wed, 14 Sep 2011 08:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.497 X-Spam-Level: X-Spam-Status: No, score=-106.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 4W0pwKoRv4wc for ; Wed, 14 Sep 2011 08:06:53 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7728F21F8B75 for ; Wed, 14 Sep 2011 08:06:48 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-42-4e70c3883e93 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 74.D9.02839.883C07E4; Wed, 14 Sep 2011 17:08:57 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Wed, 14 Sep 2011 17:08:56 +0200 Message-ID: <4E70C387.1070707@ericsson.com> Date: Wed, 14 Sep 2011 17:08:55 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 15:06:54 -0000 Hi, There has been this long thread with the subject partially containing "AVPF". I want to clarify something in this context around AVPF. Rather than the SRTP question. An end-point that is AVPF compliant is in fact interoperable with an AVP one as long as the trr-int parameter is set reasonably large. A parameter value of 1.5-5 seconds (I would recommend 3s) will ensure that they are in fact compatible. This avoids the risk of any side timing out the other if the AVP side is using the default 5 s minimum interval. Based on this one could in fact have the RTCWEB nodes always use AVPF for RTP/RTCP Behavior. The AVPF feedback messages are explicitly negotiated and will only be used when agreed on. This leaves us with any signaling incompatibilities when talking to a legacy device. If one don't want to use cap-neg I see two directions to go: 1) RTCWEB end-point will always signal AVPF or SAVPF. I signalling gateway to legacy will change that by removing the F to AVP or SAVP. 2) RTCWEB end-point will always use AVPF but signal it as AVP. It will detect the AVPF capabilities of the other end-point based on the signaling of the feedback events intended to be used. I think 1) is cleaner for the future. 2) might be more pragmatic. In both cases I believe there are methods for negotiating a lower trr-int than some AVP fallback value to preserve interoperability. However, this still don't resolve the question if the "S" should be in front of the RTP profile indicator or not. But it might help by removing the F or not in the profile. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From sisalem@iptel.org Wed Sep 14 08:09: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 E0A1421F8B71 for ; Wed, 14 Sep 2011 08:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6blsZJvzytx for ; Wed, 14 Sep 2011 08:09:11 -0700 (PDT) Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4144F21F8B61 for ; Wed, 14 Sep 2011 08:09:11 -0700 (PDT) Received: by mail.iptel.org (Postfix, from userid 103) id 6A8FC37054B; Wed, 14 Sep 2011 17:11:19 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.iptel.org with ESMTPSA id D859E37053D Message-ID: <4E70C415.20000@iptel.org> Date: Wed, 14 Sep 2011 17:11:17 +0200 From: sisalem User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <4E70C27A.9040805@jesup.org> In-Reply-To: <4E70C27A.9040805@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 15:09:12 -0000 as far as I remember this was more thought for multicast sessions. for unicast the interval was 5 seconds (+-50%) cheers On 9/14/11 5:04 PM, Randell Jesup wrote: > On 9/14/2011 7:45 AM, Jonathan Lennox wrote: >> Christer Holmberg writes: >>> Well, it depends on the amount of outgoing media traffic, but in >>> cases where you only receive media you would still need to send >>> keep-alives. >> Remember, RTCWeb is (probably) mandating RTP/RTCP mux. I'd need to >> do some math to be certain, but I'm pretty sure that in almost all >> normal circumstances, the RTCP regular reporting interval should be >> significantly smaller than the STUN keepalive interval. > > Agreed; I think it would require a bizarre session setup (RR=0) to > force the RTCP interval out far enough to cause problems. (Don't > forget to include the +- 50% in the calculation.) > > RFC 3556: > > o If RR is zero, then the proportion of participants that are > senders can never be greater than RS/(RS+RR), and therefore > non-senders never get any RTCP bandwidth independent of the > number of senders. > > > Obviously, RR values near 0 could also cause a problem. A statement > about not using RR values that would result in RTCP intervals greater > than N should be enough I think. > > BTW: Have we mandated that RTP & RTCP be muxed always to all > destinations, or that it must be supported and offered? If you're > talking to a legacy device that doesn't mux, what happens? > From magnus.westerlund@ericsson.com Wed Sep 14 08:19: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 C48F521F8CEB for ; Wed, 14 Sep 2011 08:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 Lax5SK-FnyL9 for ; Wed, 14 Sep 2011 08:19:28 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id AA70C21F8CEA for ; Wed, 14 Sep 2011 08:19:27 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-cb-4e70c6808314 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1B.41.20773.086C07E4; Wed, 14 Sep 2011 17:21:36 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Wed, 14 Sep 2011 17:21:35 +0200 Message-ID: <4E70C67E.9070105@ericsson.com> Date: Wed, 14 Sep 2011 17:21:34 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Jonathan Lennox References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 15:19:28 -0000 On 2011-09-14 16:45, Jonathan Lennox wrote: > Christer Holmberg writes: >> Well, it depends on the amount of outgoing media traffic, but in >> cases where you only receive media you would still need to send >> keep-alives. > > Remember, RTCWeb is (probably) mandating RTP/RTCP mux. I'd need to > do some math to be certain, but I'm pretty sure that in almost all > normal circumstances, the RTCP regular reporting interval should be > significantly smaller than the STUN keepalive interval. You don't need to do the math, I have already done it and it got included into RFC 6263 and quoted below. But, my personal view is that for all reasonable configurations of RTCP you are in fact transmitting RTCP in each direction more often than the ICE default of 15 seconds. ---- Quote Start Here ---- 8. RTCP Flow Keepalive RTCP packets are sent periodically and can thus normally keep the NAT mappings open as long as they are sent frequently enough. There are two conditions for that. First, RTCP needs to be used bidirectionally and in a symmetric fashion, as described in [RFC4961]. Secondly, RTCP needs to be sent frequently enough. However, there are certain configurations that can break this latter assumption. There are two factors that need to be considered to ensure that RTCP is sent frequently enough. First, the RTCP bandwidth needs to be sufficiently large so that transmission will occur more frequently than the longest acceptable packet transmission interval (Tr). The worst-case RTCP interval (Twc) can be calculated using this formula by inserting the max value of the following parameters: o Maximum RTCP packet size (avg_rtcp_size_max) o Maximum number of participants (members_max) o RTCP receiver bandwidth (rtcp_bw) The RTCP bandwidth value to use here is for a worst case, which will be the receiver proportion when all members except one are not senders. This can be approximated to be all members. Thus, for sessions where RR and RS values [RFC3556] are used, then rtcp_bw shall be set to RR. For sessions where the [RFC3550]-defined proportions of RTCP bandwidth are used (i.e., 1/4 of the bandwidth for senders and 3/4 of the bandwidth for receivers), then rtcp_bw will be 5% of 3/4 of the AS value [RFC4566] in bits per second. Twc = 1.5 / 1.21828 * members_max * rtcp_bw / avg_rtcp_size_max * 8 The second factor is the minimum RTCP interval Tmin defined in [RFC3550]. Its base value is 5 seconds, but it might also be scaled to 360 divided by the session bandwidth in kbps. The Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) [RFC4585] also allows for the setting of a trr-int parameter, which is a minimal RTCP interval for regular RTCP packets. It is also used as the Tmin value in the regular Td calculation. An analysis of the algorithm shows that the longest possible regular RTCP interval is: RTCP_int_max = trr-int * 1.5 + Td * 1.5 / 1.21828 And as long as there is sufficient bandwidth according to criteria 1 below, then the algorithm can be simplified by setting Td = trr-int, giving RTCP_int_max = trr-int * (1.5 + 1.5 / 1.21828) = 2.73123 * trr-int Thus, the requirements for the RTCP parameters are as follows for functioning keepalive: 1. Ensure that sufficient RTCP bandwidth is provided by calculating Twc, and ensure that the resulting value is less than or equal to Tr. 2. If AVP or SAVP [RFC3711] is used, the Tmin value can't be greater than Tr divided by 1.5 / (e-3/2). 3. If AVPF or SAVPF [RFC5124] is to be used, trr-min must not be set to a value greater than Tr / 3. ----- End of Quote ---- -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From henry.sinnreich@gmail.com Wed Sep 14 08:37: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 20A6F21F85AA for ; Wed, 14 Sep 2011 08:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.013 X-Spam-Level: X-Spam-Status: No, score=-3.013 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3o-2Zsr0Cwz for ; Wed, 14 Sep 2011 08:37:37 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5326121F856A for ; Wed, 14 Sep 2011 08:37:37 -0700 (PDT) Received: by yxt33 with SMTP id 33so1689631yxt.31 for ; Wed, 14 Sep 2011 08:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=MLFbFy1bSddmCq5vIK8Frd1QDfp2Asj9EjWzw6Xrn/A=; b=h3EM8unW2XryneUWrrEbPmmZm7g3tvzZ9Ra3Op29pcgItX2wBG41JWnVGNRu3plyfe HZ3Ap8odllO0k94//yxU/uPfkjR9DPs78I7IFqSfUNmJI9RN6v6z0WPFx2xI1J3+s61a IRvJUwuv8YoLujkrbJmB89b1M+uLMu/wxV+vI= Received: by 10.150.183.15 with SMTP id g15mr163947ybf.37.1316014786414; Wed, 14 Sep 2011 08:39:46 -0700 (PDT) Received: from [192.168.15.2] (cpe-76-184-224-113.tx.res.rr.com [76.184.224.113]) by mx.google.com with ESMTPS id b4sm8147262ank.3.2011.09.14.08.39.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Sep 2011 08:39:44 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 14 Sep 2011 10:39:40 -0500 From: Henry Sinnreich To: =?ISO-8859-1?B?SfFha2k=?= Baz Castillo , Message-ID: Thread-Topic: [rtcweb] About defining a signaling protocol for WebRTC (or not) Thread-Index: Acxy9IQOdSmFoAqb+Uii2V30vpVrEQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 15:37:38 -0000 +1 Thanks, Henry On 9/14/11 9:56 AM, "I=F1aki Baz Castillo" wrote: > Hi all, There are some threads about the need (or not) for a well > defined signaling protocol within WebRTC. I would like to comment about > it. WebRTC defines multimedia capabilities for web-browsers and > mandates protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566). > The aim of these protocols is to enable multimedia streams between > a web-browser and other endpoint (which could also be a web-browser). But > having the above is not enough since a signaling protocol/mechanism for > managing the media sessions is required (for requesting a multimedia session > to the endpoint, for terminating it, for putting it in hold...). Both SIP and > XMPP (with Jingle) behave as a signaling protocol and manage multimedia > sessions based on SDP descriptions (SIP uses plain SDP grammar as defined in > RFC 4566 while XMPP uses a XML version of the SDP format). So both SIP and > XMPP could be a good choice. But also any custom signaling protocol carrying > like-SDP information. If WebRTC mandates a specific signaling protocol then > all the web providers should incorporate such a protocol within > their infrastructure, which seems not feasible for me (let's say web > pages served by hosting datacenters which just provide an Apache server > for the web developer, for example). So I wonder: why is a specific signaling > protocol needed at all? AFAIK the only we need is an API (within WebRTC) to > manage multimedia sessions (start it, terminate it, use codec XXXX, put on > hold...). How the client application (let's assume the JavaScript code) > obtains such information should be out of the scope of WebRTC. The > client application (JavaScript) just needs to retrieve (via HTTP, WebSocket or > whatever) the "SDP" information provided by the endpoint and use such data for > making API calls to the WebRTC stack by passing as arguments the remote peer > IP, port, type of session, codec to use, and so on. For example, if a web > page makes usage of SIP over WebSocket or XMPP over WebSocket, the signaling > (also containing SDP information) would be carried within SIP or XMPP > messages. The only reqiremente would be for the WebSocket server to be > integrated within a SIP proxy/server implementing > draft-ibc-rtcweb-sip-websocket or a XMPP server implementing > draft-moffitt-xmpp-over-websocket. The client application (JavaScript in the > web page) should parse the SDP bodies and make WebRTC calls when appropriate > to initiate or answer multimedia sessions. And then we get full > interoperability with SIP/XMPP world out there (without requiring a > server/gateway performing conversion of application level protocols). In the > same way, other web page which just requires multimedia sessions between > web-browsers, could prefer to implement a simple and custom JSON format as a > signaling mechanism on top of WebSocket (or use HTTP Comet, long-polling, > etc). It could map the SDP definition into a JSON struct. Again the JavaScript > code parses the SDP information and calls WebRTC API functions to manage > multimedia sessions. The only requirement would be for the HTTP server > to implement WebSocket or HTTP Comet (or nothing if HTTP long polling > is used). So my proposal is that WebRTC should not mandate a signaling > protocol in the web-browser, but just define a requeriment for > managing multimedia sessions from the JavaScript code given a well defined > API. IMHO this is the way that fits well with the flexibility of the web and > lets each web provider to decide which technology to use as signaling > protocol, rather than forcing him to implement SIP/XMPP/other-protocol in > server side. Best regards. -- I=F1aki Baz > Castillo _______________________________________________ rtcwe > b mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Wed Sep 14 09:12: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 F025521F8B7D for ; Wed, 14 Sep 2011 09:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.34 X-Spam-Level: X-Spam-Status: No, score=-108.34 tagged_above=-999 required=5 tests=[AWL=2.259, 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 E9mxVaTAAm-Z for ; Wed, 14 Sep 2011 09:12:23 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E760021F8B6C for ; Wed, 14 Sep 2011 09:12:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0215F39E0D2; Wed, 14 Sep 2011 18:14:31 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Se+ImpjndWBY; Wed, 14 Sep 2011 18:14:30 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 9110039E098; Wed, 14 Sep 2011 18:14:30 +0200 (CEST) Message-ID: <4E70D2E6.1000809@alvestrand.no> Date: Wed, 14 Sep 2011 18:14:30 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 16:12:24 -0000 On 09/14/11 15:07, Christer Holmberg wrote: > Hi, > >>> |Sure, but there is still a max time between the keep-alives. >> You are free to set it to a very long duration that disables >> keepalives for all practical purposes (assuming such duration >> is represented by a 32-bit unsigned integer you can set it to >> ~136 years). > Yes, but at the end of the day something has to be sent in order to keep the NAT binding open. > >>> |Using e.g. RTP, the media handler would not have to be prepared to >>> |receive the STUN keep-alives in the first place, it could >>> |simply just >>> |relay whatever comes on the media plane. >> If the media handles can handle STUN binding requests >> efficiently I don't see why they can't handle STUN binding >> indications (keepalives) in a similar manner. > I believe it knows when to expect those. But, in any case, the main reason behind the proposal is to decrease the number of STUN requests. I think it's a more urgent desire that we should minimize the number of variants of protocols in use. Defining a variant of ICE that modifies the keepalive mechanism seems to me like a Bad Idea. Harald From ibc@aliax.net Wed Sep 14 09:36: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 E5D9221F8B10 for ; Wed, 14 Sep 2011 09:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 KzMVEbEytG57 for ; Wed, 14 Sep 2011 09:36:58 -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 5F7E421F856A for ; Wed, 14 Sep 2011 09:36:58 -0700 (PDT) Received: by qyk33 with SMTP id 33so1739464qyk.10 for ; Wed, 14 Sep 2011 09:39:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.166 with SMTP id r38mr19573qci.254.1316018345643; Wed, 14 Sep 2011 09:39:05 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Wed, 14 Sep 2011 09:39:05 -0700 (PDT) In-Reply-To: References: <1F2A2C70609D9E41844A2126145FC09802585056@HKGMBOXPRD22.polycom.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB21A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2D1@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 14 Sep 2011 18:39:05 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Wed, 14 Sep 2011 16:36:59 -0000 2011/9/14 I=C3=B1aki Baz Castillo : >> I think it's better to refer to RFC 6223, which only covers the keep-ali= ve part of RFC 5626. >> >> (RFC 5626 contains also contains other stuff that most likely doesn't ap= ply for the browser case). > > Good point. It will be mentioned in version -01 of the draft (along > with the above text addition suggested by you). Hi Christer, I've added the following text at the end of section 8: ------------------------------------------------------- 8. WebSocket Connection Keep Alive [...] The client application MAY also use Network Address Translation (NAT) keep-alive mechanisms defined for the SIP protocol, such as the mechanism described in [RFC6223]. ---------------------------------------------------------- It will be submitted in revision -01 of the draft. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Wed Sep 14 09:40: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 9281E21F8B76 for ; Wed, 14 Sep 2011 09:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24q5WyLpxbjr for ; Wed, 14 Sep 2011 09:40:35 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id B2B8721F8B14 for ; Wed, 14 Sep 2011 09:40:35 -0700 (PDT) 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 p8EGhCAj018400; Wed, 14 Sep 2011 12:43:13 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 12:41:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC72FD.3155E247" Date: Wed, 14 Sep 2011 22:11:46 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0BDE@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket Thread-Index: AcxyywLkuZKJDsNPS9a1eKG7b1+HbgAMMgtA References: <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F0B39@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F0B8A@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: =?iso-8859-1?Q?Jos=E9_Luis_Mill=E1n?= X-OriginalArrivalTime: 14 Sep 2011 16:41:49.0902 (UTC) FILETIME=[333FE6E0:01CC72FD] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 16:40:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC72FD.3155E247 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jose/Inaki, =20 IIUC, this draft is not directly related to RTCWeb but RTCWeb developer = may use it as an one of the option. ISTM, this draft has to be tracked = in sipcore or dispatch for adding the new transport layer to SIP = protocol. =20 Thanks Partha =20 From: Jos=E9 Luis Mill=E1n [mailto:jmillan@aliax.net]=20 Sent: Wednesday, September 14, 2011 4:12 PM To: Ravindran Parthasarathi Cc: I=F1aki Baz Castillo; rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket =20 Hi, =20 Let's clarify that the submitted draft states a way to adopt WebSocket = as a transport protocol for SIP. This makes feasible the SIP = communication between WebSocket capable nodes and nodes using other = transports defined in SIP, which facilitates the inter-operation within = nowadays implementations and implementations to be defined in this = group. =20 =20 We are not proposing this specification as the unique/only signaling = protocol within WebRTC. That's another subject out of the scope of the = draft. =20 Regards. =20 =20 2011/9/14 Ravindran Parthasarathi Hi Inaki, The fact that there are other alternatives for signaling in the web does = not mean that using SIP is invalid. If I want to build a SIP phone in a web, why should I use libjingle = rather than SIP protocol? Why should I code a complex server behaving as = a gateway between Jingle and SIP protocols? Any protocol conversion (i.e. from Jingle to SIP) means loss of = features. Our draft proposes the contrary: no protocol conversion (just = SIP), and just transport protocol conversion (as already exists in SIP = when bridging UDP/TCP/TLS-TCP/SCTP...). I agree with your problem statement. I have raised the same concern in = http://www.ietf.org/mail-archive/web/rtcweb/current/msg00845.html. IMO, = your solution is a workaround and we will end-up with your solution in = case signaling protocol is not standardized as part of RTCWeb. Thanks Partha >-----Original Message----- >From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] >Sent: Wednesday, September 14, 2011 2:54 PM >To: Ravindran Parthasarathi >Cc: Bernard Aboba; markus.isomaki@nokia.com; rtcweb@ietf.org; Roman >Shpount >Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket > >2011/9/14 Ravindran Parthasarathi : > >> There is no need of one layer (SIP) above to create the = dialog >but >> lightweight XML signaling mechanism works. > >Hi Ravindran, I've replied to a similar question in this mail (point = 2): > http://www.ietf.org/mail-archive/web/rtcweb/current/msg01120.html > > >Best regards. > > >-- >I=F1aki Baz Castillo > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------_=_NextPart_001_01CC72FD.3155E247 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jose/Inaki,

 

IIUC, this draft is not directly related to RTCWeb but = RTCWeb developer may use it as an one of the option. ISTM, this draft has to be tracked in sipcore or dispatch for adding the new transport layer to SIP protocol.

 

Thanks

Partha

 

From:= Jos=E9 = Luis Mill=E1n [mailto:jmillan@aliax.net]
Sent: Wednesday, September 14, 2011 4:12 PM
To: Ravindran Parthasarathi
Cc: I=F1aki Baz Castillo; rtcweb@ietf.org
Subject: Re: [rtcweb] = draft-ibc-rtcweb-sip-vs-websocket

 

Hi,

 

Let's clarify that the submitted draft states a way = to adopt WebSocket as a transport protocol for SIP.  This makes feasible the = SIP communication between WebSocket capable nodes and nodes using other = transports defined in SIP, which facilitates the inter-operation within = nowadays implementations and implementations to be defined in this group.    

 

We are not proposing this = specification as the unique/only signaling protocol within WebRTC. That's another subject = out of the scope of the draft.

 

Regards.

 

 

2011/9/14 Ravindran Parthasarathi <pravindran@sonusnet.com>

Hi Inaki,

<snip>

The fact that there are other alternatives for signaling in the web does = not mean that using SIP is invalid.
If I want to build a SIP phone in a web, why should I use libjingle = rather than SIP protocol? Why should I code a complex server behaving as a gateway = between Jingle and SIP protocols?

Any protocol conversion (i.e. from Jingle to SIP) means loss of = features. Our draft proposes the contrary: no protocol conversion (just SIP), and just transport protocol conversion (as already exists in SIP when bridging UDP/TCP/TLS-TCP/SCTP...).
</snip>

I agree with your problem statement. I have raised the same concern in = http://www.ietf.org/mail-archive/web/rtcweb/current/msg= 00845.html. IMO, your solution is a workaround and we will end-up with your solution = in case signaling protocol is not standardized as part of RTCWeb.

Thanks
Partha



>-----Original Message-----
>From: I=F1aki Baz Castillo [mailto:ibc@aliax.net]
>Sent: Wednesday, September 14, 2011 2:54 PM
>To: Ravindran Parthasarathi
>Cc: Bernard Aboba; markus.isomaki@nokia.com; rtcweb@ietf.org; Roman
>Shpount
>Subject: Re: [rtcweb] = draft-ibc-rtcweb-sip-vs-websocket

>
>2011/9/14 Ravindran Parthasarathi <pravindran@sonusnet.com>:<= br> >
>>         There is no need of = one layer (SIP) above to create the dialog
>but
>> lightweight XML signaling mechanism works.
>
>Hi Ravindran, I've replied to a similar question in this mail (point = 2):
>  http://www.ietf.org/mail-archive/web/rtcweb/current/msg= 01120.html
>
>
>Best regards.
>
>
>--
>I=F1aki Baz Castillo
><ibc@aliax.net>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

 

------_=_NextPart_001_01CC72FD.3155E247-- From randell-ietf@jesup.org Wed Sep 14 10:08: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 47B0321F8C30 for ; Wed, 14 Sep 2011 10:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 iw4OKWKLJmnl for ; Wed, 14 Sep 2011 10:08:13 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id B52B821F8C2A for ; Wed, 14 Sep 2011 10:08:13 -0700 (PDT) Received: from [216.1.177.180] (helo=[172.16.169.201]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R3syc-0002ag-LS for rtcweb@ietf.org; Wed, 14 Sep 2011 12:10:23 -0500 Message-ID: <4E70DFF3.1030104@jesup.org> Date: Wed, 14 Sep 2011 10:10:11 -0700 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E70C387.1070707@ericsson.com> In-Reply-To: <4E70C387.1070707@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] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 17:08:14 -0000 On 9/14/2011 8:08 AM, Magnus Westerlund wrote: > This leaves us with any signaling incompatibilities when talking to a > legacy device. If one don't want to use cap-neg I see two directions to go: > > 1) RTCWEB end-point will always signal AVPF or SAVPF. I signalling > gateway to legacy will change that by removing the F to AVP or SAVP. > > 2) RTCWEB end-point will always use AVPF but signal it as AVP. It will > detect the AVPF capabilities of the other end-point based on the > signaling of the feedback events intended to be used. > > I think 1) is cleaner for the future. 2) might be more pragmatic. I think this is something we should consider; I'll note that WorldGate has been using option 2 for the last 7 or so years with no problems. -- Randell Jesup randell-ietf@jesup.org From ekr@rtfm.com Wed Sep 14 10:11: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 B275A21F8B8F for ; Wed, 14 Sep 2011 10:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.898 X-Spam-Level: X-Spam-Status: No, score=-102.898 tagged_above=-999 required=5 tests=[AWL=0.079, 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 aodXLnqqMuNy for ; Wed, 14 Sep 2011 10:11:31 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E2C7A21F8B67 for ; Wed, 14 Sep 2011 10:11:30 -0700 (PDT) Received: by wyg24 with SMTP id 24so1941730wyg.31 for ; Wed, 14 Sep 2011 10:13:39 -0700 (PDT) Received: by 10.227.28.141 with SMTP id m13mr87757wbc.37.1316020419810; Wed, 14 Sep 2011 10:13:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.196.9 with HTTP; Wed, 14 Sep 2011 10:13:19 -0700 (PDT) In-Reply-To: <4E70D2E6.1000809@alvestrand.no> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> From: Eric Rescorla Date: Wed, 14 Sep 2011 10:13:19 -0700 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 17:11:31 -0000 One new concern in this context is maintaining the consent freshness. The browser needs to be sure that the recipient of traffic is stil responding in a way that can't be forged. It's likely RTCP provides this (though we'd need to analyze to be sure) but perhaps better would be to mandate STUN checks at enough frequency that you get some sort of level of freshness.... maybe every 2 minutes or someth= ing. -Ekr On Wed, Sep 14, 2011 at 9:14 AM, Harald Alvestrand w= rote: > On 09/14/11 15:07, Christer Holmberg wrote: >> >> Hi, >> >>>> |Sure, but there is still a max time between the keep-alives. >>> >>> You are free to set it to a very long duration that disables >>> keepalives for all practical purposes (assuming such duration >>> is represented by a 32-bit unsigned integer you can set it to >>> ~136 years). >> >> Yes, but at the end of the day something has to be sent in order to keep >> the NAT binding open. >> >>>> |Using e.g. RTP, the media handler would not have to be prepared to >>>> |receive the STUN keep-alives in the first place, it could >>>> |simply just >>>> |relay whatever comes on the media plane. >>> >>> If the media handles can handle STUN binding requests >>> efficiently I don't see why they can't handle STUN binding >>> indications (keepalives) in a similar manner. >> >> I believe it knows when to expect those. But, in any case, the main reas= on >> behind the proposal is to decrease the number of STUN requests. > > I think it's a more urgent desire that we should minimize the number of > variants of protocols in use. > Defining a variant of ICE that modifies the keepalive mechanism seems to = me > like a Bad Idea. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Harald > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From christer.holmberg@ericsson.com Wed Sep 14 10:18: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 96AAD21F867F for ; Wed, 14 Sep 2011 10:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 HcIiEhQTRHEF for ; Wed, 14 Sep 2011 10:18:25 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C27FC21F8669 for ; Wed, 14 Sep 2011 10:18:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-d1-4e70e26180c0 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C9.77.02839.162E07E4; Wed, 14 Sep 2011 19:20:33 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 14 Sep 2011 19:20:33 +0200 From: Christer Holmberg To: 'Eric Rescorla' , Harald Alvestrand Date: Wed, 14 Sep 2011 19:20:33 +0200 Thread-Topic: [rtcweb] STUN for keep-alive Thread-Index: AcxzAaYXiEbbEf6vQNCvKho/0qR2SQAAKSyA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 17:18:25 -0000 Hi,=20 >One new concern in this context is maintaining the consent freshness. >The browser needs to be sure that the recipient of traffic is stil respond= ing in a way that can't be forged. It's likely RTCP provides this (though w= e'd need to analyze to be sure) but perhaps better would be to mandate STUN= checks=20 >at enough frequency that you get some sort of level of freshness.... maybe= every 2 minutes or something. Please note that the STUN keep-alives are implemented using STUN indication= messages, so there are no replies (nor does the receiver perform an authen= tication check). Regards, Christer On Wed, Sep 14, 2011 at 9:14 AM, Harald Alvestrand w= rote: > On 09/14/11 15:07, Christer Holmberg wrote: >> >> Hi, >> >>>> |Sure, but there is still a max time between the keep-alives. >>> >>> You are free to set it to a very long duration that disables=20 >>> keepalives for all practical purposes (assuming such duration is=20 >>> represented by a 32-bit unsigned integer you can set it to >>> ~136 years). >> >> Yes, but at the end of the day something has to be sent in order to=20 >> keep the NAT binding open. >> >>>> |Using e.g. RTP, the media handler would not have to be prepared to=20 >>>> |receive the STUN keep-alives in the first place, it could simply=20 >>>> |just relay whatever comes on the media plane. >>> >>> If the media handles can handle STUN binding requests efficiently I=20 >>> don't see why they can't handle STUN binding indications=20 >>> (keepalives) in a similar manner. >> >> I believe it knows when to expect those. But, in any case, the main=20 >> reason behind the proposal is to decrease the number of STUN requests. > > I think it's a more urgent desire that we should minimize the number=20 > of variants of protocols in use. > Defining a variant of ICE that modifies the keepalive mechanism seems=20 > to me like a Bad Idea. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Harald > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From goran.ap.eriksson@ericsson.com Wed Sep 14 10:19: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 8A4CC21F8B50 for ; Wed, 14 Sep 2011 10:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8yH3lqyXkqI for ; Wed, 14 Sep 2011 10:19: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 A206121F8783 for ; Wed, 14 Sep 2011 10:19:55 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-3f-4e70e2bc7915 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 95.CD.20773.CB2E07E4; Wed, 14 Sep 2011 19:22:04 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.112]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 14 Sep 2011 19:22:04 +0200 From: =?iso-8859-1?Q?G=F6ran_Eriksson_AP?= To: Eric Rescorla , Harald Alvestrand Date: Wed, 14 Sep 2011 19:22:04 +0200 Thread-Topic: [rtcweb] STUN for keep-alive Thread-Index: AcxzAtIrLPZKGABkTMGGxQs4774q6A== Message-ID: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: IETF RTCWEB Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 17:19:56 -0000 Can we assume that all PeerConnections will include an audio/video stream- some may have only a 'data' connection between the browsers- can't rely on RTCP can we (assuming we don't use RTCP for generic data)? G=F6ran On 2011-09-14 19:13, "Eric Rescorla" wrote: >One new concern in this context is maintaining the consent freshness. >The browser >needs to be sure that the recipient of traffic is stil responding in a >way that can't be >forged. It's likely RTCP provides this (though we'd need to analyze to >be sure) but >perhaps better would be to mandate STUN checks at enough frequency that >you get some sort of level of freshness.... maybe every 2 minutes or >something. > >-Ekr > >On Wed, Sep 14, 2011 at 9:14 AM, Harald Alvestrand >wrote: >> On 09/14/11 15:07, Christer Holmberg wrote: >>> >>> Hi, >>> >>>>> |Sure, but there is still a max time between the keep-alives. >>>> >>>> You are free to set it to a very long duration that disables >>>> keepalives for all practical purposes (assuming such duration >>>> is represented by a 32-bit unsigned integer you can set it to >>>> ~136 years). >>> >>> Yes, but at the end of the day something has to be sent in order to >>>keep >>> the NAT binding open. >>> >>>>> |Using e.g. RTP, the media handler would not have to be prepared to >>>>> |receive the STUN keep-alives in the first place, it could >>>>> |simply just >>>>> |relay whatever comes on the media plane. >>>> >>>> If the media handles can handle STUN binding requests >>>> efficiently I don't see why they can't handle STUN binding >>>> indications (keepalives) in a similar manner. >>> >>> I believe it knows when to expect those. But, in any case, the main >>>reason >>> behind the proposal is to decrease the number of STUN requests. >> >> I think it's a more urgent desire that we should minimize the number of >> variants of protocols in use. >> Defining a variant of ICE that modifies the keepalive mechanism seems >>to me >> like a Bad Idea. >> >> Harald >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From ekr@rtfm.com Wed Sep 14 10:30: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 F0D1121F8C20 for ; Wed, 14 Sep 2011 10:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=0.077, 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 e1yvFO+85c7Q for ; Wed, 14 Sep 2011 10:30:13 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFBA21F8C10 for ; Wed, 14 Sep 2011 10:30:13 -0700 (PDT) Received: by wwf22 with SMTP id 22so1763309wwf.13 for ; Wed, 14 Sep 2011 10:32:22 -0700 (PDT) Received: by 10.227.28.141 with SMTP id m13mr107639wbc.37.1316021542073; Wed, 14 Sep 2011 10:32:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.196.9 with HTTP; Wed, 14 Sep 2011 10:32:02 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> From: Eric Rescorla Date: Wed, 14 Sep 2011 10:32:02 -0700 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 17:30:14 -0000 On Wed, Sep 14, 2011 at 10:20 AM, Christer Holmberg wrote: > > Hi, > >>One new concern in this context is maintaining the consent freshness. >>The browser needs to be sure that the recipient of traffic is stil responding in a way that can't be forged. It's likely RTCP provides this (though we'd need to analyze to be sure) but perhaps better would be to mandate STUN checks >>at enough frequency that you get some sort of level of freshness.... maybe every 2 minutes or something. > > Please note that the STUN keep-alives are implemented using STUN indication messages, so there are no replies (nor does the receiver perform an authentication check). Oh... I had forgotten that.... that's not good. -Ekr From oej@edvina.net Wed Sep 14 10:35: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 D963421F8C60 for ; Wed, 14 Sep 2011 10:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.017, 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 qfNnwYng0umQ for ; Wed, 14 Sep 2011 10:35:45 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 4C14B21F8C10 for ; Wed, 14 Sep 2011 10:35:45 -0700 (PDT) Received: from [192.168.40.76] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 70CD1754BCE4; Wed, 14 Sep 2011 17:37:51 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0BDE@sonusinmail02.sonusnet.com> Date: Wed, 14 Sep 2011 19:37:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <51FA7327-429D-40FE-8F15-C5C5F8AE3E38@edvina.net> References: <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F0B39@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F0B8A@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F0BDE@sonusinmail02.sonusnet.com> To: "Ravindran Parthasarathi" X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 17:35:46 -0000 14 sep 2011 kl. 18:41 skrev Ravindran Parthasarathi: > Hi Jose/Inaki, > =20 > IIUC, this draft is not directly related to RTCWeb but RTCWeb = developer may use it as an one of the option. ISTM, this draft has to be = tracked in sipcore or dispatch for adding the new transport layer to SIP = protocol. > =20 I agree with you, it's out of scope for this group. Having said that, = it's a very good example of how SIP can be implemented to work with = rtcweb. /O= From eckelcu@cisco.com Wed Sep 14 12:19: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 A956C21F8DAC for ; Wed, 14 Sep 2011 12:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=-0.149, 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 5Xhki2Jg7V0r for ; Wed, 14 Sep 2011 12:19:33 -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 2CFFD21F8DAA for ; Wed, 14 Sep 2011 12:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=1369; q=dns/txt; s=iport; t=1316028103; x=1317237703; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=qSnHSylYpRNYLhIPk87qj3aYjyaMfvoSRi6KRb0JUZ4=; b=D9zxCZDxppYM2/ZnQIe7v/qMkBTA9Or2Fldc3/D8TMAmqrUSbKt1GzMJ 92TRS2Bvb3NdVRT2+Mjhst5ItdHzFyTdMjBrCixWObuatdZPKcTL5NK3P VqYOMjfTh1MWwU10lw50tGfLTw5LontDCmxbk7nxC00CVY3SQE/xleoLk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEAAAL+cE6rRDoH/2dsb2JhbABBmE2Oe3iBUwEBBQEBAQ8BHQo0FwQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggah1mWcgGeT4YOYASHbpB1jCE X-IronPort-AV: E=Sophos;i="4.68,382,1312156800"; d="scan'208";a="2148698" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 14 Sep 2011 19:21:43 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8EJLhA5017017; Wed, 14 Sep 2011 19:21:43 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 12:21:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Sep 2011 12:21:42 -0700 Message-ID: In-Reply-To: <4E70DFF3.1030104@jesup.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] AVPF vs AVP Thread-Index: AcxzATPDyqbuOjDHSLaHbM4uqqn7KAAEgysg References: <4E70C387.1070707@ericsson.com> <4E70DFF3.1030104@jesup.org> From: "Charles Eckel (eckelcu)" To: "Randell Jesup" , X-OriginalArrivalTime: 14 Sep 2011 19:21:42.0760 (UTC) FILETIME=[8909DE80:01CC7313] Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 19:19:33 -0000 Option 2 is what is documented as the best practice for interoperability purposes within the IMTC as well. Cheers, Charles > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Randell Jesup > Sent: Wednesday, September 14, 2011 10:10 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] AVPF vs AVP >=20 > On 9/14/2011 8:08 AM, Magnus Westerlund wrote: > > This leaves us with any signaling incompatibilities when talking to a > > legacy device. If one don't want to use cap-neg I see two directions to go: > > > > 1) RTCWEB end-point will always signal AVPF or SAVPF. I signalling > > gateway to legacy will change that by removing the F to AVP or SAVP. > > > > 2) RTCWEB end-point will always use AVPF but signal it as AVP. It will > > detect the AVPF capabilities of the other end-point based on the > > signaling of the feedback events intended to be used. > > > > I think 1) is cleaner for the future. 2) might be more pragmatic. >=20 > I think this is something we should consider; I'll note that WorldGate > has been using option 2 for the last 7 or so years with no problems. >=20 > -- > Randell Jesup > randell-ietf@jesup.org >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Wed Sep 14 12:30: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 C6C4421F8D5F for ; Wed, 14 Sep 2011 12:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.421 X-Spam-Level: X-Spam-Status: No, score=-108.421 tagged_above=-999 required=5 tests=[AWL=2.178, 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 u3umeu0Ejdg7 for ; Wed, 14 Sep 2011 12:30:30 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 25CCB21F8D55 for ; Wed, 14 Sep 2011 12:30:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3BAF239E0D2 for ; Wed, 14 Sep 2011 21:32:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5CVOIHj+WrS for ; Wed, 14 Sep 2011 21:32:37 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id BA68439E098 for ; Wed, 14 Sep 2011 21:32:37 +0200 (CEST) Message-ID: <4E710155.8080409@alvestrand.no> Date: Wed, 14 Sep 2011 21:32:37 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E70C387.1070707@ericsson.com> In-Reply-To: <4E70C387.1070707@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 19:30:30 -0000 On 09/14/11 17:08, Magnus Westerlund wrote: > Hi, > > There has been this long thread with the subject partially containing > "AVPF". I want to clarify something in this context around AVPF. Rather > than the SRTP question. > > An end-point that is AVPF compliant is in fact interoperable with an AVP > one as long as the trr-int parameter is set reasonably large. A > parameter value of 1.5-5 seconds (I would recommend 3s) will ensure that > they are in fact compatible. This avoids the risk of any side timing out > the other if the AVP side is using the default 5 s minimum interval. > > Based on this one could in fact have the RTCWEB nodes always use AVPF > for RTP/RTCP Behavior. The AVPF feedback messages are explicitly > negotiated and will only be used when agreed on. > > This leaves us with any signaling incompatibilities when talking to a > legacy device. If one don't want to use cap-neg I see two directions to go: > > 1) RTCWEB end-point will always signal AVPF or SAVPF. I signalling > gateway to legacy will change that by removing the F to AVP or SAVP. > > 2) RTCWEB end-point will always use AVPF but signal it as AVP. It will > detect the AVPF capabilities of the other end-point based on the > signaling of the feedback events intended to be used. > > I think 1) is cleaner for the future. 2) might be more pragmatic. If 2) is more pragmatic, the IETF should update the definition of AVP to allow use of AVPF functionality. The responses seem to indicate that in practice, this is already being done (and this is a clear indication that the concept of "profile" in RTP has failed to achieve its purpose). *shudder* > In both cases I believe there are methods for negotiating a lower > trr-int than some AVP fallback value to preserve interoperability. > > > However, this still don't resolve the question if the "S" should be in > front of the RTP profile indicator or not. But it might help by removing > the F or not in the profile. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Frgatan 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 bernard_aboba@hotmail.com Wed Sep 14 12:52: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 6B51D21F8A55 for ; Wed, 14 Sep 2011 12:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.458 X-Spam-Level: X-Spam-Status: No, score=-100.458 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xC9I0N0HAMXh for ; Wed, 14 Sep 2011 12:52:49 -0700 (PDT) Received: from snt0-omc4-s28.snt0.hotmail.com (snt0-omc4-s28.snt0.hotmail.com [65.55.90.231]) by ietfa.amsl.com (Postfix) with ESMTP id E0D2E21F8AA8 for ; Wed, 14 Sep 2011 12:52:48 -0700 (PDT) Received: from SNT0-EAS96 ([65.55.90.200]) by snt0-omc4-s28.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 12:54:58 -0700 X-Originating-IP: [166.205.14.195] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: <4E70C387.1070707@ericsson.com> <4E70DFF3.1030104@jesup.org> Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: Date: Wed, 14 Sep 2011 14:54:50 -0500 To: "Charles Eckel (eckelcu)" MIME-Version: 1.0 (iPhone Mail 8K2) X-OriginalArrivalTime: 14 Sep 2011 19:54:58.0772 (UTC) FILETIME=[2EC12140:01CC7318] Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 19:52:49 -0000 Here's a vote for Option 2. On Sep 14, 2011, at 2:21 PM, "Charles Eckel (eckelcu)" w= rote: > Option 2 is what is documented as the best practice for interoperability > purposes within the IMTC as well. >=20 > Cheers, > Charles >=20 >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Randell Jesup >> Sent: Wednesday, September 14, 2011 10:10 AM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] AVPF vs AVP >>=20 >> On 9/14/2011 8:08 AM, Magnus Westerlund wrote: >>> This leaves us with any signaling incompatibilities when talking to > a >>> legacy device. If one don't want to use cap-neg I see two directions > to go: >>>=20 >>> 1) RTCWEB end-point will always signal AVPF or SAVPF. I signalling >>> gateway to legacy will change that by removing the F to AVP or SAVP. >>>=20 >>> 2) RTCWEB end-point will always use AVPF but signal it as AVP. It > will >>> detect the AVPF capabilities of the other end-point based on the >>> signaling of the feedback events intended to be used. >>>=20 >>> I think 1) is cleaner for the future. 2) might be more pragmatic. >>=20 >> I think this is something we should consider; I'll note that WorldGate >> has been using option 2 for the last 7 or so years with no problems. >>=20 >> -- >> Randell Jesup >> randell-ietf@jesup.org >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Wed Sep 14 13:06: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 AE68921F8C57 for ; Wed, 14 Sep 2011 13:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.529 X-Spam-Level: X-Spam-Status: No, score=-101.529 tagged_above=-999 required=5 tests=[AWL=1.071, 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 eRgW+g3dcE3E for ; Wed, 14 Sep 2011 13:06:51 -0700 (PDT) Received: from snt0-omc2-s29.snt0.hotmail.com (snt0-omc2-s29.snt0.hotmail.com [65.55.90.104]) by ietfa.amsl.com (Postfix) with ESMTP id A3E2F21F8C55 for ; Wed, 14 Sep 2011 13:06:51 -0700 (PDT) Received: from SNT0-EAS345 ([65.55.90.71]) by snt0-omc2-s29.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 13:09:01 -0700 X-Originating-IP: [166.205.14.195] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: References: Content-Transfer-Encoding: base64 From: Bernard Aboba Content-Type: text/plain; charset="utf-8" In-Reply-To: Date: Wed, 14 Sep 2011 15:08:53 -0500 To: Henry Sinnreich MIME-Version: 1.0 (iPhone Mail 8K2) X-OriginalArrivalTime: 14 Sep 2011 20:09:01.0915 (UTC) FILETIME=[254E8AB0:01CC731A] Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 20:06:52 -0000 KzENCg0KDQoNCk9uIFNlcCAxNCwgMjAxMSwgYXQgMTA6MzkgQU0sICJIZW5yeSBTaW5ucmVpY2gi IDxoZW5yeS5zaW5ucmVpY2hAZ21haWwuY29tPiB3cm90ZToNCg0KPiArMQ0KPiANCj4gVGhhbmtz LCBIZW5yeQ0KPiANCj4gDQo+IE9uIDkvMTQvMTEgOTo1NiBBTSwgIknDsWFraSBCYXogQ2FzdGls bG8iIDxpYmNAYWxpYXgubmV0PiB3cm90ZToNCj4gDQo+PiBIaSBhbGwsDQo+IA0KPiBUaGVyZSBh cmUgc29tZSB0aHJlYWRzIGFib3V0IHRoZSBuZWVkIChvciBub3QpIGZvciBhIHdlbGwNCj4+IGRl ZmluZWQNCj4gc2lnbmFsaW5nIHByb3RvY29sIHdpdGhpbiBXZWJSVEMuIEkgd291bGQgbGlrZSB0 byBjb21tZW50IGFib3V0DQo+PiBpdC4NCj4gDQo+IFdlYlJUQyBkZWZpbmVzIG11bHRpbWVkaWEg Y2FwYWJpbGl0aWVzIGZvciB3ZWItYnJvd3NlcnMgYW5kDQo+PiBtYW5kYXRlcw0KPiBwcm90b2Nv bHMgYXMgUlRQLCBTVFVOLCBJQ0UsIGFuZCB1bmRlcnN0YW5kaW5nIG9mIFNEUCAoUkZDIDQ1NjYp Lg0KPj4gVGhlDQo+IGFpbSBvZiB0aGVzZSBwcm90b2NvbHMgaXMgdG8gZW5hYmxlIG11bHRpbWVk aWEgc3RyZWFtcyBiZXR3ZWVuDQo+PiBhDQo+IHdlYi1icm93c2VyIGFuZCBvdGhlciBlbmRwb2lu dCAod2hpY2ggY291bGQgYWxzbyBiZSBhIHdlYi1icm93c2VyKS4NCj4gDQo+IEJ1dA0KPj4gaGF2 aW5nIHRoZSBhYm92ZSBpcyBub3QgZW5vdWdoIHNpbmNlIGEgc2lnbmFsaW5nDQo+IHByb3RvY29s L21lY2hhbmlzbSBmb3INCj4+IG1hbmFnaW5nIHRoZSBtZWRpYSBzZXNzaW9ucyBpcyByZXF1aXJl ZCAoZm9yDQo+IHJlcXVlc3RpbmcgYSBtdWx0aW1lZGlhIHNlc3Npb24NCj4+IHRvIHRoZSBlbmRw b2ludCwgZm9yIHRlcm1pbmF0aW5nIGl0LA0KPiBmb3IgcHV0dGluZyBpdCBpbiBob2xkLi4uKS4N Cj4gDQo+IEJvdGggU0lQIGFuZA0KPj4gWE1QUCAod2l0aCBKaW5nbGUpIGJlaGF2ZSBhcyBhIHNp Z25hbGluZyBwcm90b2NvbCBhbmQNCj4gbWFuYWdlIG11bHRpbWVkaWENCj4+IHNlc3Npb25zIGJh c2VkIG9uIFNEUCBkZXNjcmlwdGlvbnMgKFNJUCB1c2VzIHBsYWluDQo+IFNEUCBncmFtbWFyIGFz IGRlZmluZWQgaW4NCj4+IFJGQyA0NTY2IHdoaWxlIFhNUFAgdXNlcyBhIFhNTCB2ZXJzaW9uIG9m DQo+IHRoZSBTRFAgZm9ybWF0KS4gU28gYm90aCBTSVAgYW5kDQo+PiBYTVBQIGNvdWxkIGJlIGEg Z29vZCBjaG9pY2UuIEJ1dCBhbHNvDQo+IGFueSBjdXN0b20gc2lnbmFsaW5nIHByb3RvY29sIGNh cnJ5aW5nDQo+PiBsaWtlLVNEUCBpbmZvcm1hdGlvbi4NCj4gDQo+IElmIFdlYlJUQyBtYW5kYXRl cyBhIHNwZWNpZmljIHNpZ25hbGluZyBwcm90b2NvbCB0aGVuDQo+PiBhbGwgdGhlIHdlYg0KPiBw cm92aWRlcnMgc2hvdWxkIGluY29ycG9yYXRlIHN1Y2ggYSBwcm90b2NvbCB3aXRoaW4NCj4+IHRo ZWlyDQo+IGluZnJhc3RydWN0dXJlLCB3aGljaCBzZWVtcyBub3QgZmVhc2libGUgZm9yIG1lIChs ZXQncyBzYXkgd2ViDQo+PiBwYWdlcw0KPiBzZXJ2ZWQgYnkgaG9zdGluZyBkYXRhY2VudGVycyB3 aGljaCBqdXN0IHByb3ZpZGUgYW4gQXBhY2hlIHNlcnZlcg0KPj4gZm9yDQo+IHRoZSB3ZWIgZGV2 ZWxvcGVyLCBmb3IgZXhhbXBsZSkuDQo+IA0KPiBTbyBJIHdvbmRlcjogd2h5IGlzIGEgc3BlY2lm aWMgc2lnbmFsaW5nDQo+PiBwcm90b2NvbCBuZWVkZWQgYXQgYWxsPyBBRkFJSw0KPiB0aGUgb25s eSB3ZSBuZWVkIGlzIGFuIEFQSSAod2l0aGluIFdlYlJUQykgdG8NCj4+IG1hbmFnZSBtdWx0aW1l ZGlhDQo+IHNlc3Npb25zIChzdGFydCBpdCwgdGVybWluYXRlIGl0LCB1c2UgY29kZWMgWFhYWCwg cHV0IG9uDQo+PiBob2xkLi4uKS4gSG93DQo+IHRoZSBjbGllbnQgYXBwbGljYXRpb24gKGxldCdz IGFzc3VtZSB0aGUgSmF2YVNjcmlwdCBjb2RlKQ0KPj4gb2J0YWlucyBzdWNoDQo+IGluZm9ybWF0 aW9uIHNob3VsZCBiZSBvdXQgb2YgdGhlIHNjb3BlIG9mIFdlYlJUQy4gVGhlDQo+PiBjbGllbnQN Cj4gYXBwbGljYXRpb24gKEphdmFTY3JpcHQpIGp1c3QgbmVlZHMgdG8gcmV0cmlldmUgKHZpYSBI VFRQLCBXZWJTb2NrZXQNCj4gb3INCj4+IHdoYXRldmVyKSB0aGUgIlNEUCIgaW5mb3JtYXRpb24g cHJvdmlkZWQgYnkgdGhlIGVuZHBvaW50IGFuZCB1c2UNCj4gc3VjaCBkYXRhIGZvcg0KPj4gbWFr aW5nIEFQSSBjYWxscyB0byB0aGUgV2ViUlRDIHN0YWNrIGJ5IHBhc3NpbmcgYXMNCj4gYXJndW1l bnRzIHRoZSByZW1vdGUgcGVlcg0KPj4gSVAsIHBvcnQsIHR5cGUgb2Ygc2Vzc2lvbiwgY29kZWMg dG8gdXNlLCBhbmQNCj4gc28gb24uDQo+IA0KPiBGb3IgZXhhbXBsZSwgaWYgYSB3ZWINCj4+IHBh Z2UgbWFrZXMgdXNhZ2Ugb2YgU0lQIG92ZXIgV2ViU29ja2V0IG9yIFhNUFANCj4gb3ZlciBXZWJT b2NrZXQsIHRoZSBzaWduYWxpbmcNCj4+IChhbHNvIGNvbnRhaW5pbmcgU0RQIGluZm9ybWF0aW9u KSB3b3VsZA0KPiBiZSBjYXJyaWVkIHdpdGhpbiBTSVAgb3IgWE1QUA0KPj4gbWVzc2FnZXMuIFRo ZSBvbmx5IHJlcWlyZW1lbnRlIHdvdWxkIGJlDQo+IGZvciB0aGUgV2ViU29ja2V0IHNlcnZlciB0 byBiZQ0KPj4gaW50ZWdyYXRlZCB3aXRoaW4gYSBTSVAgcHJveHkvc2VydmVyDQo+IGltcGxlbWVu dGluZw0KPj4gZHJhZnQtaWJjLXJ0Y3dlYi1zaXAtd2Vic29ja2V0IG9yIGEgWE1QUCBzZXJ2ZXIN Cj4gaW1wbGVtZW50aW5nDQo+PiBkcmFmdC1tb2ZmaXR0LXhtcHAtb3Zlci13ZWJzb2NrZXQuIFRo ZSBjbGllbnQgYXBwbGljYXRpb24NCj4gKEphdmFTY3JpcHQgaW4gdGhlDQo+PiB3ZWIgcGFnZSkg c2hvdWxkIHBhcnNlIHRoZSBTRFAgYm9kaWVzIGFuZCBtYWtlDQo+IFdlYlJUQyBjYWxscyB3aGVu IGFwcHJvcHJpYXRlDQo+PiB0byBpbml0aWF0ZSBvciBhbnN3ZXIgbXVsdGltZWRpYQ0KPiBzZXNz aW9ucy4gQW5kIHRoZW4gd2UgZ2V0IGZ1bGwNCj4+IGludGVyb3BlcmFiaWxpdHkgd2l0aCBTSVAv WE1QUCB3b3JsZA0KPiBvdXQgdGhlcmUgKHdpdGhvdXQgcmVxdWlyaW5nIGENCj4+IHNlcnZlci9n YXRld2F5IHBlcmZvcm1pbmcgY29udmVyc2lvbiBvZg0KPiBhcHBsaWNhdGlvbiBsZXZlbCBwcm90 b2NvbHMpLg0KPiANCj4gSW4gdGhlDQo+PiBzYW1lIHdheSwgb3RoZXIgd2ViIHBhZ2Ugd2hpY2gg anVzdCByZXF1aXJlcyBtdWx0aW1lZGlhDQo+IHNlc3Npb25zIGJldHdlZW4NCj4+IHdlYi1icm93 c2VycywgY291bGQgcHJlZmVyIHRvIGltcGxlbWVudCBhIHNpbXBsZSBhbmQNCj4gY3VzdG9tIEpT T04gZm9ybWF0IGFzIGENCj4+IHNpZ25hbGluZyBtZWNoYW5pc20gb24gdG9wIG9mIFdlYlNvY2tl dCAob3INCj4gdXNlIEhUVFAgQ29tZXQsIGxvbmctcG9sbGluZywNCj4+IGV0YykuIEl0IGNvdWxk IG1hcCB0aGUgU0RQIGRlZmluaXRpb24NCj4gaW50byBhIEpTT04gc3RydWN0LiBBZ2FpbiB0aGUg SmF2YVNjcmlwdA0KPj4gY29kZSBwYXJzZXMgdGhlIFNEUA0KPiBpbmZvcm1hdGlvbiBhbmQgY2Fs bHMgV2ViUlRDIEFQSSBmdW5jdGlvbnMgdG8gbWFuYWdlDQo+PiBtdWx0aW1lZGlhDQo+IHNlc3Np b25zLiBUaGUgb25seSByZXF1aXJlbWVudCB3b3VsZCBiZSBmb3IgdGhlIEhUVFAgc2VydmVyDQo+ PiB0bw0KPiBpbXBsZW1lbnQgV2ViU29ja2V0IG9yIEhUVFAgQ29tZXQgKG9yIG5vdGhpbmcgaWYg SFRUUCBsb25nIHBvbGxpbmcNCj4+IGlzDQo+IHVzZWQpLg0KPiANCj4gU28gbXkgcHJvcG9zYWwg aXMgdGhhdCBXZWJSVEMgc2hvdWxkIG5vdCBtYW5kYXRlIGEgc2lnbmFsaW5nDQo+PiBwcm90b2Nv bA0KPiBpbiB0aGUgd2ViLWJyb3dzZXIsIGJ1dCBqdXN0IGRlZmluZSBhIHJlcXVlcmltZW50IGZv cg0KPj4gbWFuYWdpbmcNCj4gbXVsdGltZWRpYSBzZXNzaW9ucyBmcm9tIHRoZSBKYXZhU2NyaXB0 IGNvZGUgZ2l2ZW4gYSB3ZWxsIGRlZmluZWQNCj4+IEFQSS4NCj4gSU1ITyB0aGlzIGlzIHRoZSB3 YXkgdGhhdCBmaXRzIHdlbGwgd2l0aCB0aGUgZmxleGliaWxpdHkgb2YgdGhlIHdlYg0KPiBhbmQN Cj4+IGxldHMgZWFjaCB3ZWIgcHJvdmlkZXIgdG8gZGVjaWRlIHdoaWNoIHRlY2hub2xvZ3kgdG8g dXNlIGFzDQo+IHNpZ25hbGluZw0KPj4gcHJvdG9jb2wsIHJhdGhlciB0aGFuIGZvcmNpbmcgaGlt IHRvIGltcGxlbWVudA0KPiBTSVAvWE1QUC9vdGhlci1wcm90b2NvbCBpbg0KPj4gc2VydmVyIHNp ZGUuDQo+IA0KPiANCj4gQmVzdCByZWdhcmRzLg0KPiANCj4gLS0gDQo+IEnDsWFraSBCYXoNCj4+ IENhc3RpbGxvDQo+IDxpYmNAYWxpYXgubmV0Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBydGN3ZQ0KPj4gYiBtYWlsaW5nIGxpc3QNCj4gcnRj d2ViQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj d2ViDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj4gcnRjd2ViQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo= From roman@telurix.com Wed Sep 14 13:20: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 AA58321F8C0C for ; Wed, 14 Sep 2011 13:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.713 X-Spam-Level: X-Spam-Status: No, score=-2.713 tagged_above=-999 required=5 tests=[AWL=0.263, 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 zsuWCgpT0U-N for ; Wed, 14 Sep 2011 13:20:08 -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 7F33821F8BE8 for ; Wed, 14 Sep 2011 13:20:08 -0700 (PDT) Received: by ywa6 with SMTP id 6so1953821ywa.31 for ; Wed, 14 Sep 2011 13:22:18 -0700 (PDT) Received: by 10.90.38.10 with SMTP id l10mr278577agl.101.1316031738134; Wed, 14 Sep 2011 13:22:18 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id s15sm9683792ank.8.2011.09.14.13.22.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Sep 2011 13:22:17 -0700 (PDT) Received: by yxt33 with SMTP id 33so1955152yxt.31 for ; Wed, 14 Sep 2011 13:22:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.5.162 with SMTP id t2mr500634pbt.241.1316031736358; Wed, 14 Sep 2011 13:22:16 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Wed, 14 Sep 2011 13:22:16 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Sep 2011 16:22:16 -0400 Message-ID: From: Roman Shpount To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=bcaec52159a528a59d04acec8473 Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 20:20:09 -0000 --bcaec52159a528a59d04acec8473 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 _____________ Roman Shpount On Wed, Sep 14, 2011 at 4:08 PM, Bernard Aboba w= rote: > +1 > > > > On Sep 14, 2011, at 10:39 AM, "Henry Sinnreich" > wrote: > > > +1 > > > > Thanks, Henry > > > > > > On 9/14/11 9:56 AM, "I=F1aki Baz Castillo" wrote: > > > >> Hi all, > > > > There are some threads about the need (or not) for a well > >> defined > > signaling protocol within WebRTC. I would like to comment about > >> it. > > > > WebRTC defines multimedia capabilities for web-browsers and > >> mandates > > protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566). > >> The > > aim of these protocols is to enable multimedia streams between > >> a > > web-browser and other endpoint (which could also be a web-browser). > > > > But > >> having the above is not enough since a signaling > > protocol/mechanism for > >> managing the media sessions is required (for > > requesting a multimedia session > >> to the endpoint, for terminating it, > > for putting it in hold...). > > > > Both SIP and > >> XMPP (with Jingle) behave as a signaling protocol and > > manage multimedia > >> sessions based on SDP descriptions (SIP uses plain > > SDP grammar as defined in > >> RFC 4566 while XMPP uses a XML version of > > the SDP format). So both SIP and > >> XMPP could be a good choice. But also > > any custom signaling protocol carrying > >> like-SDP information. > > > > If WebRTC mandates a specific signaling protocol then > >> all the web > > providers should incorporate such a protocol within > >> their > > infrastructure, which seems not feasible for me (let's say web > >> pages > > served by hosting datacenters which just provide an Apache server > >> for > > the web developer, for example). > > > > So I wonder: why is a specific signaling > >> protocol needed at all? AFAIK > > the only we need is an API (within WebRTC) to > >> manage multimedia > > sessions (start it, terminate it, use codec XXXX, put on > >> hold...). How > > the client application (let's assume the JavaScript code) > >> obtains such > > information should be out of the scope of WebRTC. The > >> client > > application (JavaScript) just needs to retrieve (via HTTP, WebSocket > > or > >> whatever) the "SDP" information provided by the endpoint and use > > such data for > >> making API calls to the WebRTC stack by passing as > > arguments the remote peer > >> IP, port, type of session, codec to use, and > > so on. > > > > For example, if a web > >> page makes usage of SIP over WebSocket or XMPP > > over WebSocket, the signaling > >> (also containing SDP information) would > > be carried within SIP or XMPP > >> messages. The only reqiremente would be > > for the WebSocket server to be > >> integrated within a SIP proxy/server > > implementing > >> draft-ibc-rtcweb-sip-websocket or a XMPP server > > implementing > >> draft-moffitt-xmpp-over-websocket. The client application > > (JavaScript in the > >> web page) should parse the SDP bodies and make > > WebRTC calls when appropriate > >> to initiate or answer multimedia > > sessions. And then we get full > >> interoperability with SIP/XMPP world > > out there (without requiring a > >> server/gateway performing conversion of > > application level protocols). > > > > In the > >> same way, other web page which just requires multimedia > > sessions between > >> web-browsers, could prefer to implement a simple and > > custom JSON format as a > >> signaling mechanism on top of WebSocket (or > > use HTTP Comet, long-polling, > >> etc). It could map the SDP definition > > into a JSON struct. Again the JavaScript > >> code parses the SDP > > information and calls WebRTC API functions to manage > >> multimedia > > sessions. The only requirement would be for the HTTP server > >> to > > implement WebSocket or HTTP Comet (or nothing if HTTP long polling > >> is > > used). > > > > So my proposal is that WebRTC should not mandate a signaling > >> protocol > > in the web-browser, but just define a requeriment for > >> managing > > multimedia sessions from the JavaScript code given a well defined > >> API. > > IMHO this is the way that fits well with the flexibility of the web > > and > >> lets each web provider to decide which technology to use as > > signaling > >> protocol, rather than forcing him to implement > > SIP/XMPP/other-protocol in > >> server side. > > > > > > Best regards. > > > > -- > > I=F1aki Baz > >> Castillo > > > > _______________________________________________ > > rtcwe > >> b 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 > --bcaec52159a528a59d04acec8473 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1
_____________
Roman Shpount


On Wed, Sep 14, 2011 at 4:08 PM, Bernard= Aboba <b= ernard_aboba@hotmail.com> wrote:
+1



On Sep 14, 2011, at 10:39 AM, "Henry Sinnreich" <henry.sinnreich@gmail.com> wrote:
> +1
>
> Thanks, Henry
>
>
> On 9/14/11 9:56 AM, "I=F1aki Baz Castillo" <ibc@aliax.net> wrote:
>
>> Hi all,
>
> There are some threads about the need (or not) for a well
>> defined
> signaling protocol within WebRTC. I would like to comment about
>> it.
>
> WebRTC defines multimedia capabilities for web-browsers and
>> mandates
> protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566).
>> The
> aim of these protocols is to enable multimedia streams between
>> a
> web-browser and other endpoint (which could also be a web-browser). >
> But
>> having the above is not enough since a signaling
> protocol/mechanism for
>> managing the media sessions is required (for
> requesting a multimedia session
>> to the endpoint, for terminating it,
> for putting it in hold...).
>
> Both SIP and
>> XMPP (with Jingle) behave as a signaling protocol and
> manage multimedia
>> sessions based on SDP descriptions (SIP uses plain
> SDP grammar as defined in
>> RFC 4566 while XMPP uses a XML version of
> the SDP format). So both SIP and
>> XMPP could be a good choice. But also
> any custom signaling protocol carrying
>> like-SDP information.
>
> If WebRTC mandates a specific signaling protocol then
>> all the web
> providers should incorporate such a protocol within
>> their
> infrastructure, which seems not feasible for me (let's say web
>> pages
> served by hosting datacenters which just provide an Apache server
>> for
> the web developer, for example).
>
> So I wonder: why is a specific signaling
>> protocol needed at all? AFAIK
> the only we need is an API (within WebRTC) to
>> manage multimedia
> sessions (start it, terminate it, use codec XXXX, put on
>> hold...). How
> the client application (let's assume the JavaScript code)
>> obtains such
> information should be out of the scope of WebRTC. The
>> client
> application (JavaScript) just needs to retrieve (via HTTP, WebSocket > or
>> whatever) the "SDP" information provided by the endpoint= and use
> such data for
>> making API calls to the WebRTC stack by passing as
> arguments the remote peer
>> IP, port, type of session, codec to use, and
> so on.
>
> For example, if a web
>> page makes usage of SIP over WebSocket or XMPP
> over WebSocket, the signaling
>> (also containing SDP information) would
> be carried within SIP or XMPP
>> messages. The only reqiremente would be
> for the WebSocket server to be
>> integrated within a SIP proxy/server
> implementing
>> draft-ibc-rtcweb-sip-websocket or a XMPP server
> implementing
>> draft-moffitt-xmpp-over-websocket. The client application
> (JavaScript in the
>> web page) should parse the SDP bodies and make
> WebRTC calls when appropriate
>> to initiate or answer multimedia
> sessions. And then we get full
>> interoperability with SIP/XMPP world
> out there (without requiring a
>> server/gateway performing conversion of
> application level protocols).
>
> In the
>> same way, other web page which just requires multimedia
> sessions between
>> web-browsers, could prefer to implement a simple and
> custom JSON format as a
>> signaling mechanism on top of WebSocket (or
> use HTTP Comet, long-polling,
>> etc). It could map the SDP definition
> into a JSON struct. Again the JavaScript
>> code parses the SDP
> information and calls WebRTC API functions to manage
>> multimedia
> sessions. The only requirement would be for the HTTP server
>> to
> implement WebSocket or HTTP Comet (or nothing if HTTP long polling
>> is
> used).
>
> So my proposal is that WebRTC should not mandate a signaling
>> protocol
> in the web-browser, but just define a requeriment for
>> managing
> multimedia sessions from the JavaScript code given a well defined
>> API.
> IMHO this is the way that fits well with the flexibility of the web > and
>> lets each web provider to decide which technology to use as
> signaling
>> protocol, rather than forcing him to implement
> SIP/XMPP/other-protocol in
>> server side.
>
>
> Best regards.
>
> --
> I=F1aki Baz
>> Castillo
> <ibc@aliax.net>
> _______________________________________________
> rtcwe
>> b 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

--bcaec52159a528a59d04acec8473-- From victor.pascual.avila@gmail.com Wed Sep 14 13:57: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 84BAC21F8B68 for ; Wed, 14 Sep 2011 13:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wir72d72Va5H for ; Wed, 14 Sep 2011 13:57:02 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E44E521F8B43 for ; Wed, 14 Sep 2011 13:57:01 -0700 (PDT) Received: by wyg24 with SMTP id 24so2133129wyg.31 for ; Wed, 14 Sep 2011 13:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:references:from:content-type:x-mailer:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=A7XUCrrQ0J/Zsl4hD+1tXXpHy5k/hXsR0LGUWK46flA=; b=tWnANvvjeVCnrEf6eX8TOY7qLJmgQXgiY6bPiVF7M4305+AYOd71rPztMpMTApkKJl gmilebQD7Ij8doKrUGWsC3O/jIJgiqykSeLwv+NMGPglbjVdalgYKYOhKecl22zDCDY5 ZZExCVYM+P222374bzPP5gBeb0lI+rJVe2WBM= Received: by 10.216.22.202 with SMTP id t52mr253076wet.100.1316033951103; Wed, 14 Sep 2011 13:59:11 -0700 (PDT) Received: from [192.168.1.26] (47.59-64-87.adsl-dyn.isp.belgacom.be. [87.64.59.47]) by mx.google.com with ESMTPS id fp5sm5446905wbb.2.2011.09.14.13.59.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Sep 2011 13:59:09 -0700 (PDT) References: From: Victor Pascual Content-Type: multipart/alternative; boundary=Apple-Mail-25-571813362 X-Mailer: iPhone Mail (8K2) In-Reply-To: Message-Id: <744B2B16-67AB-432D-92DE-7263C935E151@gmail.com> Date: Wed, 14 Sep 2011 22:59:02 +0200 To: "rtcweb@ietf.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 8K2) Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 20:57:03 -0000 --Apple-Mail-25-571813362 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 On Sep 14, 2011, at 10:22 PM, Roman Shpount wrote: > +1 > _____________ > Roman Shpount >=20 >=20 > On Wed, Sep 14, 2011 at 4:08 PM, Bernard Aboba = wrote: > +1 >=20 >=20 >=20 > On Sep 14, 2011, at 10:39 AM, "Henry Sinnreich" wrote: >=20 > > +1 > > > > Thanks, Henry > > > > > > On 9/14/11 9:56 AM, "I=C3=B1aki Baz Castillo" wrote: > > > >> Hi all, > > > > There are some threads about the need (or not) for a well > >> defined > > signaling protocol within WebRTC. I would like to comment about > >> it. > > > > WebRTC defines multimedia capabilities for web-browsers and > >> mandates > > protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566). > >> The > > aim of these protocols is to enable multimedia streams between > >> a > > web-browser and other endpoint (which could also be a web-browser). > > > > But > >> having the above is not enough since a signaling > > protocol/mechanism for > >> managing the media sessions is required (for > > requesting a multimedia session > >> to the endpoint, for terminating it, > > for putting it in hold...). > > > > Both SIP and > >> XMPP (with Jingle) behave as a signaling protocol and > > manage multimedia > >> sessions based on SDP descriptions (SIP uses plain > > SDP grammar as defined in > >> RFC 4566 while XMPP uses a XML version of > > the SDP format). So both SIP and > >> XMPP could be a good choice. But also > > any custom signaling protocol carrying > >> like-SDP information. > > > > If WebRTC mandates a specific signaling protocol then > >> all the web > > providers should incorporate such a protocol within > >> their > > infrastructure, which seems not feasible for me (let's say web > >> pages > > served by hosting datacenters which just provide an Apache server > >> for > > the web developer, for example). > > > > So I wonder: why is a specific signaling > >> protocol needed at all? AFAIK > > the only we need is an API (within WebRTC) to > >> manage multimedia > > sessions (start it, terminate it, use codec XXXX, put on > >> hold...). How > > the client application (let's assume the JavaScript code) > >> obtains such > > information should be out of the scope of WebRTC. The > >> client > > application (JavaScript) just needs to retrieve (via HTTP, WebSocket > > or > >> whatever) the "SDP" information provided by the endpoint and use > > such data for > >> making API calls to the WebRTC stack by passing as > > arguments the remote peer > >> IP, port, type of session, codec to use, and > > so on. > > > > For example, if a web > >> page makes usage of SIP over WebSocket or XMPP > > over WebSocket, the signaling > >> (also containing SDP information) would > > be carried within SIP or XMPP > >> messages. The only reqiremente would be > > for the WebSocket server to be > >> integrated within a SIP proxy/server > > implementing > >> draft-ibc-rtcweb-sip-websocket or a XMPP server > > implementing > >> draft-moffitt-xmpp-over-websocket. The client application > > (JavaScript in the > >> web page) should parse the SDP bodies and make > > WebRTC calls when appropriate > >> to initiate or answer multimedia > > sessions. And then we get full > >> interoperability with SIP/XMPP world > > out there (without requiring a > >> server/gateway performing conversion of > > application level protocols). > > > > In the > >> same way, other web page which just requires multimedia > > sessions between > >> web-browsers, could prefer to implement a simple and > > custom JSON format as a > >> signaling mechanism on top of WebSocket (or > > use HTTP Comet, long-polling, > >> etc). It could map the SDP definition > > into a JSON struct. Again the JavaScript > >> code parses the SDP > > information and calls WebRTC API functions to manage > >> multimedia > > sessions. The only requirement would be for the HTTP server > >> to > > implement WebSocket or HTTP Comet (or nothing if HTTP long polling > >> is > > used). > > > > So my proposal is that WebRTC should not mandate a signaling > >> protocol > > in the web-browser, but just define a requeriment for > >> managing > > multimedia sessions from the JavaScript code given a well defined > >> API. > > IMHO this is the way that fits well with the flexibility of the web > > and > >> lets each web provider to decide which technology to use as > > signaling > >> protocol, rather than forcing him to implement > > SIP/XMPP/other-protocol in > >> server side. > > > > > > Best regards. > > > > -- > > I=C3=B1aki Baz > >> Castillo > > > > _______________________________________________ > > rtcwe > >> b mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail-25-571813362 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
+1

On Sep 14, 2011= , at 10:22 PM, Roman Shpount <roman@= telurix.com> wrote:

+1
_____________
Roman Shpount


On Wed, Sep 14, 2011 at 4:08 PM, Bernard A= boba <bernard_aboba@hotmail.com&g= t; wrote:
+1



On Sep 14, 2011, at 10:39 AM, "Henry Sinnreich" <henry.sinn= reich@gmail.com> wrote:

> +1
>
> Thanks, Henry
>
>
> On 9/14/11 9:56 AM, "I=C3=B1aki Baz Castillo" <ibc@aliax.net> wrote= :
>
>> Hi all,
>
> There are some threads about the need (or not) for a well
>> defined
> signaling protocol within WebRTC. I would like to comment about
>> it.
>
> WebRTC defines multimedia capabilities for web-browsers and
>> mandates
> protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566).
>> The
> aim of these protocols is to enable multimedia streams between
>> a
> web-browser and other endpoint (which could also be a web-browser).
= >
> But
>> having the above is not enough since a signaling
> protocol/mechanism for
>> managing the media sessions is required (for
> requesting a multimedia session
>> to the endpoint, for terminating it,
> for putting it in hold...).
>
> Both SIP and
>> XMPP (with Jingle) behave as a signaling protocol and
> manage multimedia
>> sessions based on SDP descriptions (SIP uses plain
> SDP grammar as defined in
>> RFC 4566 while XMPP uses a XML version of
> the SDP format). So both SIP and
>> XMPP could be a good choice. But also
> any custom signaling protocol carrying
>> like-SDP information.
>
> If WebRTC mandates a specific signaling protocol then
>> all the web
> providers should incorporate such a protocol within
>> their
> infrastructure, which seems not feasible for me (let's say web
>> pages
> served by hosting datacenters which just provide an Apache server
>> for
> the web developer, for example).
>
> So I wonder: why is a specific signaling
>> protocol needed at all? AFAIK
> the only we need is an API (within WebRTC) to
>> manage multimedia
> sessions (start it, terminate it, use codec XXXX, put on
>> hold...). How
> the client application (let's assume the JavaScript code)
>> obtains such
> information should be out of the scope of WebRTC. The
>> client
> application (JavaScript) just needs to retrieve (via HTTP, WebSocket > or
>> whatever) the "SDP" information provided by the endpoint and use > such data for
>> making API calls to the WebRTC stack by passing as
> arguments the remote peer
>> IP, port, type of session, codec to use, and
> so on.
>
> For example, if a web
>> page makes usage of SIP over WebSocket or XMPP
> over WebSocket, the signaling
>> (also containing SDP information) would
> be carried within SIP or XMPP
>> messages. The only reqiremente would be
> for the WebSocket server to be
>> integrated within a SIP proxy/server
> implementing
>> draft-ibc-rtcweb-sip-websocket or a XMPP server
> implementing
>> draft-moffitt-xmpp-over-websocket. The client application
> (JavaScript in the
>> web page) should parse the SDP bodies and make
> WebRTC calls when appropriate
>> to initiate or answer multimedia
> sessions. And then we get full
>> interoperability with SIP/XMPP world
> out there (without requiring a
>> server/gateway performing conversion of
> application level protocols).
>
> In the
>> same way, other web page which just requires multimedia
> sessions between
>> web-browsers, could prefer to implement a simple and
> custom JSON format as a
>> signaling mechanism on top of WebSocket (or
> use HTTP Comet, long-polling,
>> etc). It could map the SDP definition
> into a JSON struct. Again the JavaScript
>> code parses the SDP
> information and calls WebRTC API functions to manage
>> multimedia
> sessions. The only requirement would be for the HTTP server
>> to
> implement WebSocket or HTTP Comet (or nothing if HTTP long polling
>> is
> used).
>
> So my proposal is that WebRTC should not mandate a signaling
>> protocol
> in the web-browser, but just define a requeriment for
>> managing
> multimedia sessions from the JavaScript code given a well defined
>> API.
> IMHO this is the way that fits well with the flexibility of the web
= > and
>> lets each web provider to decide which technology to use as
> signaling
>> protocol, rather than forcing him to implement
> SIP/XMPP/other-protocol in
>> server side.
>
>
> Best regards.
>
> --
> I=C3=B1aki Baz
>> Castillo
> <i= bc@aliax.net>
> _______________________________________________
> rtcwe
>> b mailing list
> r= tcweb@ietf.org
> https://www.iet= f.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> r= tcweb@ietf.org
> https://www.iet= f.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb= @ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org= /mailman/listinfo/rtcweb

____________________= ___________________________
rtcweb mailing list
rtcweb@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/rtcweb">https://www.ietf.org= /mailman/listinfo/rtcweb
= --Apple-Mail-25-571813362-- From prakash.tester.im@gmail.com Wed Sep 14 13:59: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 A22D121F8C54 for ; Wed, 14 Sep 2011 13:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vw3RZ3WtoLEK for ; Wed, 14 Sep 2011 13:59:28 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 98A8E21F8C39 for ; Wed, 14 Sep 2011 13:59:28 -0700 (PDT) Received: by yxt33 with SMTP id 33so1987040yxt.31 for ; Wed, 14 Sep 2011 14:01:38 -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:content-transfer-encoding; bh=YtAfECuF0BWol1mkugGrcLWt6mOIQDLU5mn/jFvUg8w=; b=BfQyy/AqUU6k2I15hRlpD4I3vfGt7/Fkxi5es7oZ3TJmr9auwzpvaNZiAZff6p2Lib doZ8Ee/7UJ9KLnrCK5L2/uYP5B40modNf+xoEz3DUn/a2WjTFgFWaiUZwf4JtQU7wIg5 NwYg+cq7+cmEKFZFn0HtexE8TaE4RcL+rPMCs= MIME-Version: 1.0 Received: by 10.68.54.161 with SMTP id k1mr576212pbp.125.1316034044431; Wed, 14 Sep 2011 14:00:44 -0700 (PDT) Received: by 10.68.63.42 with HTTP; Wed, 14 Sep 2011 14:00:44 -0700 (PDT) In-Reply-To: <744B2B16-67AB-432D-92DE-7263C935E151@gmail.com> References: <744B2B16-67AB-432D-92DE-7263C935E151@gmail.com> Date: Wed, 14 Sep 2011 14:00:44 -0700 Message-ID: From: Prakash To: Victor Pascual Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 20:59:29 -0000 +1 On Wed, Sep 14, 2011 at 1:59 PM, Victor Pascual wrote: > +1 > On Sep 14, 2011, at 10:22 PM, Roman Shpount wrote: > > +1 > _____________ > Roman Shpount > > > On Wed, Sep 14, 2011 at 4:08 PM, Bernard Aboba > wrote: >> >> +1 >> >> >> >> On Sep 14, 2011, at 10:39 AM, "Henry Sinnreich" >> wrote: >> >> > +1 >> > >> > Thanks, Henry >> > >> > >> > On 9/14/11 9:56 AM, "I=F1aki Baz Castillo" wrote: >> > >> >> Hi all, >> > >> > There are some threads about the need (or not) for a well >> >> defined >> > signaling protocol within WebRTC. I would like to comment about >> >> it. >> > >> > WebRTC defines multimedia capabilities for web-browsers and >> >> mandates >> > protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566). >> >> The >> > aim of these protocols is to enable multimedia streams between >> >> a >> > web-browser and other endpoint (which could also be a web-browser). >> > >> > But >> >> having the above is not enough since a signaling >> > protocol/mechanism for >> >> managing the media sessions is required (for >> > requesting a multimedia session >> >> to the endpoint, for terminating it, >> > for putting it in hold...). >> > >> > Both SIP and >> >> XMPP (with Jingle) behave as a signaling protocol and >> > manage multimedia >> >> sessions based on SDP descriptions (SIP uses plain >> > SDP grammar as defined in >> >> RFC 4566 while XMPP uses a XML version of >> > the SDP format). So both SIP and >> >> XMPP could be a good choice. But also >> > any custom signaling protocol carrying >> >> like-SDP information. >> > >> > If WebRTC mandates a specific signaling protocol then >> >> all the web >> > providers should incorporate such a protocol within >> >> their >> > infrastructure, which seems not feasible for me (let's say web >> >> pages >> > served by hosting datacenters which just provide an Apache server >> >> for >> > the web developer, for example). >> > >> > So I wonder: why is a specific signaling >> >> protocol needed at all? AFAIK >> > the only we need is an API (within WebRTC) to >> >> manage multimedia >> > sessions (start it, terminate it, use codec XXXX, put on >> >> hold...). How >> > the client application (let's assume the JavaScript code) >> >> obtains such >> > information should be out of the scope of WebRTC. The >> >> client >> > application (JavaScript) just needs to retrieve (via HTTP, WebSocket >> > or >> >> whatever) the "SDP" information provided by the endpoint and use >> > such data for >> >> making API calls to the WebRTC stack by passing as >> > arguments the remote peer >> >> IP, port, type of session, codec to use, and >> > so on. >> > >> > For example, if a web >> >> page makes usage of SIP over WebSocket or XMPP >> > over WebSocket, the signaling >> >> (also containing SDP information) would >> > be carried within SIP or XMPP >> >> messages. The only reqiremente would be >> > for the WebSocket server to be >> >> integrated within a SIP proxy/server >> > implementing >> >> draft-ibc-rtcweb-sip-websocket or a XMPP server >> > implementing >> >> draft-moffitt-xmpp-over-websocket. The client application >> > (JavaScript in the >> >> web page) should parse the SDP bodies and make >> > WebRTC calls when appropriate >> >> to initiate or answer multimedia >> > sessions. And then we get full >> >> interoperability with SIP/XMPP world >> > out there (without requiring a >> >> server/gateway performing conversion of >> > application level protocols). >> > >> > In the >> >> same way, other web page which just requires multimedia >> > sessions between >> >> web-browsers, could prefer to implement a simple and >> > custom JSON format as a >> >> signaling mechanism on top of WebSocket (or >> > use HTTP Comet, long-polling, >> >> etc). It could map the SDP definition >> > into a JSON struct. Again the JavaScript >> >> code parses the SDP >> > information and calls WebRTC API functions to manage >> >> multimedia >> > sessions. The only requirement would be for the HTTP server >> >> to >> > implement WebSocket or HTTP Comet (or nothing if HTTP long polling >> >> is >> > used). >> > >> > So my proposal is that WebRTC should not mandate a signaling >> >> protocol >> > in the web-browser, but just define a requeriment for >> >> managing >> > multimedia sessions from the JavaScript code given a well defined >> >> API. >> > IMHO this is the way that fits well with the flexibility of the web >> > and >> >> lets each web provider to decide which technology to use as >> > signaling >> >> protocol, rather than forcing him to implement >> > SIP/XMPP/other-protocol in >> >> server side. >> > >> > >> > Best regards. >> > >> > -- >> > I=F1aki Baz >> >> Castillo >> > >> > _______________________________________________ >> > rtcwe >> >> b mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> > >> > >> > >> > _______________________________________________ >> > rtcweb mailing list >> > rtcweb@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtcweb >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > From internet-drafts@ietf.org Wed Sep 14 14:01: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 F195821F8C98; Wed, 14 Sep 2011 14:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 Oqzp0u9sH8fd; Wed, 14 Sep 2011 14:01:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEB621F8C60; Wed, 14 Sep 2011 14:01:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110914210103.9510.5984.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2011 14:01:03 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-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: Wed, 14 Sep 2011 21:01:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : RTP Requirements for RTC-Web Author(s) : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-00.txt Pages : 22 Date : 2011-09-14 This memo discusses use of RTP in the context of the RTC-Web activity. It discusses important features of RTP that need to be considered by other parts of the RTC-Web framework, describes which RTP profile to use in this environment, and outlines what RTP extensions should be supported. This document is a candidate to become a work item of the RTCWEB working group as <WORKING GROUP DRAFT "MEDIA TRANSPORTS">= ;. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-rtp-usage-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-rtp-usage-00.txt From csp@csperkins.org Wed Sep 14 14:10: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 B02FF21F8D38 for ; Wed, 14 Sep 2011 14:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.546 X-Spam-Level: X-Spam-Status: No, score=-103.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 zZ1+i9X+n0Cq for ; Wed, 14 Sep 2011 14:10:17 -0700 (PDT) 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 B510221F8D3D for ; Wed, 14 Sep 2011 14:10:12 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R3wkW-0005m1-kv for rtcweb@ietf.org; Wed, 14 Sep 2011 21:12:04 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Colin Perkins In-Reply-To: <20110914210103.9510.5984.idtracker@ietfa.amsl.com> Date: Wed, 14 Sep 2011 22:12:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <919FD3CA-1408-446D-850F-CD357C30D820@csperkins.org> References: <20110914210103.9510.5984.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-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: Wed, 14 Sep 2011 21:10:19 -0000 On 14 Sep 2011, at 22:01, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Real-Time Communication in = WEB-browsers Working Group of the IETF. >=20 > Title : RTP Requirements for RTC-Web > Author(s) : Colin Perkins > Magnus Westerlund > Joerg Ott > Filename : draft-ietf-rtcweb-rtp-usage-00.txt > Pages : 22 > Date : 2011-09-14 >=20 > This memo discusses use of RTP in the context of the RTC-Web > activity. It discusses important features of RTP that need to be > considered by other parts of the RTC-Web framework, describes which > RTP profile to use in this environment, and outlines what RTP > extensions should be supported. This version is identical to draft-perkins-rtcweb-rtp-usage-03, apart = from the filename and date. --=20 Colin Perkins http://csperkins.org/ From saul@ag-projects.com Wed Sep 14 15:03: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 F289021F8D80 for ; Wed, 14 Sep 2011 15:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRTTjTVE5Ago for ; Wed, 14 Sep 2011 15:03:11 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE4021F8D74 for ; Wed, 14 Sep 2011 15:03:10 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id E7F58B01B4; Thu, 15 Sep 2011 00:05:18 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 725F4B01A5; Thu, 15 Sep 2011 00:05:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Thu, 15 Sep 2011 00:05:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D1560D0-B5A5-4134-BD01-4468C340B7EE@ag-projects.com> References: To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 14 Sep 2011 22:03:12 -0000 +1 -- Sa=FAl Ibarra Corretg=E9 AG Projects From gao.yang2@zte.com.cn Wed Sep 14 17:56: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 C656021F84BC for ; Wed, 14 Sep 2011 17:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.049 X-Spam-Level: X-Spam-Status: No, score=-100.049 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGq4ts+4Knnj for ; Wed, 14 Sep 2011 17:56:22 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id D2BE121F84B0 for ; Wed, 14 Sep 2011 17:56:21 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 46621977368623; Thu, 15 Sep 2011 08:58:07 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 84831.1847729665; Thu, 15 Sep 2011 08:58:10 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p8F0w6s4091551; Thu, 15 Sep 2011 08:58:06 +0800 (GMT-8) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= MIME-Version: 1.0 X-KeepSent: 3CAEB213:54D7E89A-4825790C:00054129; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 15 Sep 2011 08:58:01 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-09-15 08:58:06, Serialize complete at 2011-09-15 08:58:06 Content-Type: multipart/alternative; boundary="=_alternative 00056DD24825790C_=" X-MAIL: mse02.zte.com.cn p8F0w6s4091551 Cc: rtcweb@ietf.org Subject: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 00:56:22 -0000 This is a multipart message in MIME format. --=_alternative 00056DD24825790C_= Content-Type: text/plain; charset="US-ASCII" > So my proposal is that WebRTC should not mandate a signaling protocol > in the web-browser, but just define a requeriment for managing > multimedia sessions from the JavaScript code given a well defined API. > IMHO this is the way that fits well with the flexibility of the web > and lets each web provider to decide which technology to use as > signaling protocol, rather than forcing him to implement > SIP/XMPP/other-protocol in server side. +1 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00056DD24825790C_= Content-Type: text/html; charset="US-ASCII"

> So my proposal is that WebRTC should not mandate a signaling protocol
> in the web-browser, but just define a requeriment for managing
> multimedia sessions from the JavaScript code given a well defined API.
> IMHO this is the way that fits well with the flexibility of the web
> and lets each web provider to decide which technology to use as
> signaling protocol, rather than forcing him to implement
> SIP/XMPP/other-protocol in server side.


+1 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00056DD24825790C_=-- From HKaplan@acmepacket.com Wed Sep 14 20:19: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 DCD9D21F8A70 for ; Wed, 14 Sep 2011 20:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 lQjw6lz8Rn9L for ; Wed, 14 Sep 2011 20:19:39 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id F2FA821F8A6C for ; Wed, 14 Sep 2011 20:19:38 -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; Wed, 14 Sep 2011 23:21:47 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 23:21:47 -0400 From: Hadriel Kaplan To: Magnus Westerlund Thread-Topic: [rtcweb] AVPF vs AVP Thread-Index: AQHMcvCC1935An+dNEG35IBBpAPmuZVOCl6A Date: Thu, 15 Sep 2011 03:21:46 +0000 Message-ID: References: <4E70C387.1070707@ericsson.com> In-Reply-To: <4E70C387.1070707@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="iso-8859-1" Content-ID: <496C1C6BF0E3D54C98372085A76D3B9E@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 03:19:40 -0000 I am shocked, Shocked!, to see you suggest that we disregard RFC 4585 and S= DP rules, when we have an IETF specified means of indicating multiple profi= le support using RFC 5939 SDP Capability Negotiation. ;) -hadriel On Sep 14, 2011, at 11:08 AM, Magnus Westerlund wrote: > Hi, >=20 > There has been this long thread with the subject partially containing > "AVPF". I want to clarify something in this context around AVPF. Rather > than the SRTP question. >=20 > An end-point that is AVPF compliant is in fact interoperable with an AVP > one as long as the trr-int parameter is set reasonably large. A > parameter value of 1.5-5 seconds (I would recommend 3s) will ensure that > they are in fact compatible. This avoids the risk of any side timing out > the other if the AVP side is using the default 5 s minimum interval. >=20 > Based on this one could in fact have the RTCWEB nodes always use AVPF > for RTP/RTCP Behavior. The AVPF feedback messages are explicitly > negotiated and will only be used when agreed on. >=20 > This leaves us with any signaling incompatibilities when talking to a > legacy device. If one don't want to use cap-neg I see two directions to g= o: >=20 > 1) RTCWEB end-point will always signal AVPF or SAVPF. I signalling > gateway to legacy will change that by removing the F to AVP or SAVP. >=20 > 2) RTCWEB end-point will always use AVPF but signal it as AVP. It will > detect the AVPF capabilities of the other end-point based on the > signaling of the feedback events intended to be used. >=20 > I think 1) is cleaner for the future. 2) might be more pragmatic. >=20 > In both cases I believe there are methods for negotiating a lower > trr-int than some AVP fallback value to preserve interoperability. >=20 >=20 > However, this still don't resolve the question if the "S" should be in > front of the RTP profile indicator or not. But it might help by removing > the F or not in the profile. >=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 Ranjit.Avasarala@Polycom.com Wed Sep 14 21:50: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 3D1B721F8785 for ; Wed, 14 Sep 2011 21:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.355 X-Spam-Level: X-Spam-Status: No, score=-6.355 tagged_above=-999 required=5 tests=[AWL=-0.056, 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 8mI6gOZy83nN for ; Wed, 14 Sep 2011 21:50:50 -0700 (PDT) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9730221F8781 for ; Wed, 14 Sep 2011 21:50:49 -0700 (PDT) Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Thu, 15 Sep 2011 12:52:58 +0800 From: "Avasarala, Ranjit" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "rtcweb@ietf.org" Date: Thu, 15 Sep 2011 12:52:54 +0800 Thread-Topic: [rtcweb] About defining a signaling protocol for WebRTC (or not) Thread-Index: Acxy7pNBYo7Pgq8tQgagPJvFqCjvagAdLsUA Message-ID: <1F2A2C70609D9E41844A2126145FC09802D95CB6@HKGMBOXPRD22.polycom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 04:50:51 -0000 QWdyZWUgd2l0aCB5b3UgSW5ha2kNCg0KUmVnYXJkcw0KUmFuaml0DQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cnRj d2ViLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJw7Fha2kgQmF6IENhc3RpbGxvDQpT ZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxNCwgMjAxMSA4OjI3IFBNDQpUbzogcnRjd2ViQGll dGYub3JnDQpTdWJqZWN0OiBbcnRjd2ViXSBBYm91dCBkZWZpbmluZyBhIHNpZ25hbGluZyBwcm90 b2NvbCBmb3IgV2ViUlRDIChvciBub3QpDQoNCkhpIGFsbCwNCg0KVGhlcmUgYXJlIHNvbWUgdGhy ZWFkcyBhYm91dCB0aGUgbmVlZCAob3Igbm90KSBmb3IgYSB3ZWxsIGRlZmluZWQNCnNpZ25hbGlu ZyBwcm90b2NvbCB3aXRoaW4gV2ViUlRDLiBJIHdvdWxkIGxpa2UgdG8gY29tbWVudCBhYm91dCBp dC4NCg0KV2ViUlRDIGRlZmluZXMgbXVsdGltZWRpYSBjYXBhYmlsaXRpZXMgZm9yIHdlYi1icm93 c2VycyBhbmQgbWFuZGF0ZXMNCnByb3RvY29scyBhcyBSVFAsIFNUVU4sIElDRSwgYW5kIHVuZGVy c3RhbmRpbmcgb2YgU0RQIChSRkMgNDU2NikuIFRoZQ0KYWltIG9mIHRoZXNlIHByb3RvY29scyBp cyB0byBlbmFibGUgbXVsdGltZWRpYSBzdHJlYW1zIGJldHdlZW4gYQ0Kd2ViLWJyb3dzZXIgYW5k IG90aGVyIGVuZHBvaW50ICh3aGljaCBjb3VsZCBhbHNvIGJlIGEgd2ViLWJyb3dzZXIpLg0KDQpC dXQgaGF2aW5nIHRoZSBhYm92ZSBpcyBub3QgZW5vdWdoIHNpbmNlIGEgc2lnbmFsaW5nDQpwcm90 b2NvbC9tZWNoYW5pc20gZm9yIG1hbmFnaW5nIHRoZSBtZWRpYSBzZXNzaW9ucyBpcyByZXF1aXJl ZCAoZm9yDQpyZXF1ZXN0aW5nIGEgbXVsdGltZWRpYSBzZXNzaW9uIHRvIHRoZSBlbmRwb2ludCwg Zm9yIHRlcm1pbmF0aW5nIGl0LA0KZm9yIHB1dHRpbmcgaXQgaW4gaG9sZC4uLikuDQoNCkJvdGgg U0lQIGFuZCBYTVBQICh3aXRoIEppbmdsZSkgYmVoYXZlIGFzIGEgc2lnbmFsaW5nIHByb3RvY29s IGFuZA0KbWFuYWdlIG11bHRpbWVkaWEgc2Vzc2lvbnMgYmFzZWQgb24gU0RQIGRlc2NyaXB0aW9u cyAoU0lQIHVzZXMgcGxhaW4NClNEUCBncmFtbWFyIGFzIGRlZmluZWQgaW4gUkZDIDQ1NjYgd2hp bGUgWE1QUCB1c2VzIGEgWE1MIHZlcnNpb24gb2YNCnRoZSBTRFAgZm9ybWF0KS4gU28gYm90aCBT SVAgYW5kIFhNUFAgY291bGQgYmUgYSBnb29kIGNob2ljZS4gQnV0IGFsc28NCmFueSBjdXN0b20g c2lnbmFsaW5nIHByb3RvY29sIGNhcnJ5aW5nIGxpa2UtU0RQIGluZm9ybWF0aW9uLg0KDQpJZiBX ZWJSVEMgbWFuZGF0ZXMgYSBzcGVjaWZpYyBzaWduYWxpbmcgcHJvdG9jb2wgdGhlbiBhbGwgdGhl IHdlYg0KcHJvdmlkZXJzIHNob3VsZCBpbmNvcnBvcmF0ZSBzdWNoIGEgcHJvdG9jb2wgd2l0aGlu IHRoZWlyDQppbmZyYXN0cnVjdHVyZSwgd2hpY2ggc2VlbXMgbm90IGZlYXNpYmxlIGZvciBtZSAo bGV0J3Mgc2F5IHdlYiBwYWdlcw0Kc2VydmVkIGJ5IGhvc3RpbmcgZGF0YWNlbnRlcnMgd2hpY2gg anVzdCBwcm92aWRlIGFuIEFwYWNoZSBzZXJ2ZXIgZm9yDQp0aGUgd2ViIGRldmVsb3BlciwgZm9y IGV4YW1wbGUpLg0KDQpTbyBJIHdvbmRlcjogd2h5IGlzIGEgc3BlY2lmaWMgc2lnbmFsaW5nIHBy b3RvY29sIG5lZWRlZCBhdCBhbGw/IEFGQUlLDQp0aGUgb25seSB3ZSBuZWVkIGlzIGFuIEFQSSAo d2l0aGluIFdlYlJUQykgdG8gbWFuYWdlIG11bHRpbWVkaWENCnNlc3Npb25zIChzdGFydCBpdCwg dGVybWluYXRlIGl0LCB1c2UgY29kZWMgWFhYWCwgcHV0IG9uIGhvbGQuLi4pLiBIb3cNCnRoZSBj bGllbnQgYXBwbGljYXRpb24gKGxldCdzIGFzc3VtZSB0aGUgSmF2YVNjcmlwdCBjb2RlKSBvYnRh aW5zIHN1Y2gNCmluZm9ybWF0aW9uIHNob3VsZCBiZSBvdXQgb2YgdGhlIHNjb3BlIG9mIFdlYlJU Qy4gVGhlIGNsaWVudA0KYXBwbGljYXRpb24gKEphdmFTY3JpcHQpIGp1c3QgbmVlZHMgdG8gcmV0 cmlldmUgKHZpYSBIVFRQLCBXZWJTb2NrZXQNCm9yIHdoYXRldmVyKSB0aGUgIlNEUCIgaW5mb3Jt YXRpb24gcHJvdmlkZWQgYnkgdGhlIGVuZHBvaW50IGFuZCB1c2UNCnN1Y2ggZGF0YSBmb3IgbWFr aW5nIEFQSSBjYWxscyB0byB0aGUgV2ViUlRDIHN0YWNrIGJ5IHBhc3NpbmcgYXMNCmFyZ3VtZW50 cyB0aGUgcmVtb3RlIHBlZXIgSVAsIHBvcnQsIHR5cGUgb2Ygc2Vzc2lvbiwgY29kZWMgdG8gdXNl LCBhbmQNCnNvIG9uLg0KDQpGb3IgZXhhbXBsZSwgaWYgYSB3ZWIgcGFnZSBtYWtlcyB1c2FnZSBv ZiBTSVAgb3ZlciBXZWJTb2NrZXQgb3IgWE1QUA0Kb3ZlciBXZWJTb2NrZXQsIHRoZSBzaWduYWxp bmcgKGFsc28gY29udGFpbmluZyBTRFAgaW5mb3JtYXRpb24pIHdvdWxkDQpiZSBjYXJyaWVkIHdp dGhpbiBTSVAgb3IgWE1QUCBtZXNzYWdlcy4gVGhlIG9ubHkgcmVxaXJlbWVudGUgd291bGQgYmUN CmZvciB0aGUgV2ViU29ja2V0IHNlcnZlciB0byBiZSBpbnRlZ3JhdGVkIHdpdGhpbiBhIFNJUCBw cm94eS9zZXJ2ZXINCmltcGxlbWVudGluZyBkcmFmdC1pYmMtcnRjd2ViLXNpcC13ZWJzb2NrZXQg b3IgYSBYTVBQIHNlcnZlcg0KaW1wbGVtZW50aW5nIGRyYWZ0LW1vZmZpdHQteG1wcC1vdmVyLXdl YnNvY2tldC4gVGhlIGNsaWVudCBhcHBsaWNhdGlvbg0KKEphdmFTY3JpcHQgaW4gdGhlIHdlYiBw YWdlKSBzaG91bGQgcGFyc2UgdGhlIFNEUCBib2RpZXMgYW5kIG1ha2UNCldlYlJUQyBjYWxscyB3 aGVuIGFwcHJvcHJpYXRlIHRvIGluaXRpYXRlIG9yIGFuc3dlciBtdWx0aW1lZGlhDQpzZXNzaW9u cy4gQW5kIHRoZW4gd2UgZ2V0IGZ1bGwgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIFNJUC9YTVBQIHdv cmxkDQpvdXQgdGhlcmUgKHdpdGhvdXQgcmVxdWlyaW5nIGEgc2VydmVyL2dhdGV3YXkgcGVyZm9y bWluZyBjb252ZXJzaW9uIG9mDQphcHBsaWNhdGlvbiBsZXZlbCBwcm90b2NvbHMpLg0KDQpJbiB0 aGUgc2FtZSB3YXksIG90aGVyIHdlYiBwYWdlIHdoaWNoIGp1c3QgcmVxdWlyZXMgbXVsdGltZWRp YQ0Kc2Vzc2lvbnMgYmV0d2VlbiB3ZWItYnJvd3NlcnMsIGNvdWxkIHByZWZlciB0byBpbXBsZW1l bnQgYSBzaW1wbGUgYW5kDQpjdXN0b20gSlNPTiBmb3JtYXQgYXMgYSBzaWduYWxpbmcgbWVjaGFu aXNtIG9uIHRvcCBvZiBXZWJTb2NrZXQgKG9yDQp1c2UgSFRUUCBDb21ldCwgbG9uZy1wb2xsaW5n LCBldGMpLiBJdCBjb3VsZCBtYXAgdGhlIFNEUCBkZWZpbml0aW9uDQppbnRvIGEgSlNPTiBzdHJ1 Y3QuIEFnYWluIHRoZSBKYXZhU2NyaXB0IGNvZGUgcGFyc2VzIHRoZSBTRFANCmluZm9ybWF0aW9u IGFuZCBjYWxscyBXZWJSVEMgQVBJIGZ1bmN0aW9ucyB0byBtYW5hZ2UgbXVsdGltZWRpYQ0Kc2Vz c2lvbnMuIFRoZSBvbmx5IHJlcXVpcmVtZW50IHdvdWxkIGJlIGZvciB0aGUgSFRUUCBzZXJ2ZXIg dG8NCmltcGxlbWVudCBXZWJTb2NrZXQgb3IgSFRUUCBDb21ldCAob3Igbm90aGluZyBpZiBIVFRQ IGxvbmcgcG9sbGluZyBpcw0KdXNlZCkuDQoNClNvIG15IHByb3Bvc2FsIGlzIHRoYXQgV2ViUlRD IHNob3VsZCBub3QgbWFuZGF0ZSBhIHNpZ25hbGluZyBwcm90b2NvbA0KaW4gdGhlIHdlYi1icm93 c2VyLCBidXQganVzdCBkZWZpbmUgYSByZXF1ZXJpbWVudCBmb3IgbWFuYWdpbmcNCm11bHRpbWVk aWEgc2Vzc2lvbnMgZnJvbSB0aGUgSmF2YVNjcmlwdCBjb2RlIGdpdmVuIGEgd2VsbCBkZWZpbmVk IEFQSS4NCklNSE8gdGhpcyBpcyB0aGUgd2F5IHRoYXQgZml0cyB3ZWxsIHdpdGggdGhlIGZsZXhp YmlsaXR5IG9mIHRoZSB3ZWINCmFuZCBsZXRzIGVhY2ggd2ViIHByb3ZpZGVyIHRvIGRlY2lkZSB3 aGljaCB0ZWNobm9sb2d5IHRvIHVzZSBhcw0Kc2lnbmFsaW5nIHByb3RvY29sLCByYXRoZXIgdGhh biBmb3JjaW5nIGhpbSB0byBpbXBsZW1lbnQNClNJUC9YTVBQL290aGVyLXByb3RvY29sIGluIHNl cnZlciBzaWRlLg0KDQoNCkJlc3QgcmVnYXJkcy4NCg0KLS0gDQpJw7Fha2kgQmF6IENhc3RpbGxv DQo8aWJjQGFsaWF4Lm5ldD4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo= From matthew.kaufman@skype.net Wed Sep 14 22:49: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 13E2721F856B for ; Wed, 14 Sep 2011 22:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, 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 Ml34YS1CWQaR for ; Wed, 14 Sep 2011 22:49:45 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 45ECC21F854F for ; Wed, 14 Sep 2011 22:49:45 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 492287FD; Thu, 15 Sep 2011 07:51:55 +0200 (CEST) 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=f4YmqJMk0HSnii yCE2tU9TPsTzY=; b=kAuZsRHUhqDlgWdlZJb01jTvrKY9p9Jq0vUaXEKx+0AJ8z QFsswZhGeDCq9BJeFuOnqPpE2W91R8ZuVGFIKpjcv4kQYi13ZiUMrbw0ITsWRAfk BiEVid8qk1YN2UZ3ysWQb7AJOFrGUb+CNpfxY4+fmoHn6oBZTrZMHjXfGJ/yM= 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=cjMp+t2Lf0L5FMWGJyHKDa oOXpr2pdbQZjmhfn0ipQpHud8CqqAVXqRDgidOec33H0478nCMEl4uVKUqAAqwYh qu2uSt1jKWSBo6qgRVyv/+IdfZYpmEr8uFOXgNyx0NXvQBW9Y/nD0+voldYkz3Uv rBsfWRW/Dh6WHlqvDVoiM= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 459137F8; Thu, 15 Sep 2011 07:51:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 2BE5F3506F77; Thu, 15 Sep 2011 07:51:55 +0200 (CEST) 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 rPThY9v117VQ; Thu, 15 Sep 2011 07:51:54 +0200 (CEST) Received: from Matthew-Kaufman-Air.local (gw2.rival.se [83.241.158.140]) by zimbra.skype.net (Postfix) with ESMTPSA id 65D5A3506F54; Thu, 15 Sep 2011 07:51:54 +0200 (CEST) Message-ID: <4E71927C.1090606@skype.net> Date: Thu, 15 Sep 2011 07:51:56 +0200 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 05:49:46 -0000 On 9/14/11 4:56 PM, I=C3=B1aki Baz Castillo wrote: > So my proposal is that WebRTC should not mandate a signaling protocol > in the web-browser, but just define a requeriment for managing > multimedia sessions from the JavaScript code given a well defined API. I think this is exactly what I've been advocating, so I agree as well. I'd go one step further to say that the "well defined API" shouldn't be=20 "SDP offer/answer via events" for negotiating codec parameters, but=20 should instead be a way to manage the codec settings, with offer/answer=20 or capneg or whatever you want implemented in the Javascript (or up at=20 the server, your choice). Matthew Kaufman From pravindran@sonusnet.com Wed Sep 14 23:50: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 416E121F854E for ; Wed, 14 Sep 2011 23:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, J_CHICKENPOX_32=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 jb1NuxEQqoNH for ; Wed, 14 Sep 2011 23:50:04 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 69E1D21F8549 for ; Wed, 14 Sep 2011 23:50:04 -0700 (PDT) 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 p8F6qgFb020508; Thu, 15 Sep 2011 02:52:42 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Sep 2011 02:45:59 -0400 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, 15 Sep 2011 12:15:55 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] About defining a signaling protocol for WebRTC (or not) Thread-Index: Acxy7pIeBYJ0+xh5Sme1Gc4ouRPeigAf4cWw References: From: "Ravindran Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , X-OriginalArrivalTime: 15 Sep 2011 06:45:59.0553 (UTC) FILETIME=[20CB4F10:01CC7373] Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 06:50:05 -0000 SGkgSW5ha2ksDQoNCkFzIHlvdXIgZHJhZnQgZHJhZnQtaWJjLXJ0Y3dlYi1zaXAtdnMtd2Vic29j a2V0IGluZGljYXRlcywgaXQgaXMgcG9zc2libGUgZm9yIEphdmFzY3JpcHQgYXBwbGljYXRpb24g dG8gd3JpdGUgYW55IHNpZ25hbGluZyBwcm90b2NvbCBhbmQgc28sIHRoZXJlIGlzIG5vIGJsb2Nr aW5nIGZhY3RvciBmb3IgaW5ub3ZhdGlvbiBpbiBicm93c2VyIHBsYXRmb3JtLiBJJ20gc2VlaW5n IHRoZSBjdXJyZW50IGluZnJhc3RydWN0dXJlIGluIFJUQ1dlYiBhcyAicmF3IHNvY2tldCIgaW4g U29ja2V0IGxpYnJhcnkuIFRoZSByYXcgc29ja2V0IHByb3ZpZGVzIHRoZSBmbGV4aWJpbGl0eSBh bmQgbm8gZG91YnQgYWJvdXQgaXQuIEFsc28sIFJUQ1dlYiBzdXBwb3J0cyBmb3IgU0lQLCBYTVBQ LCBvciBzb21lIDxjb250ZW50PiBYTUwgdXNpbmcgU0RQLG9yIHNvbWUgb3RoZXIgVExWIHByb3Rv Y29sLiANCg0KTXkgcG9pbnQgaXMgdGhhdCB0aGUgZGVmYXVsdCBzaWduYWxpbmcgcHJvdG9jb2wg aGFzIHRvIGJlIHN1cHBvcnRlZCBpbiBSVENXZWIgY2xpZW50IHdoaWNoIHNob3VsZCBub3QgYmUg ZG93bmxvYWRlZCBpbiBydW50aW1lIHRvIG1ha2UgdGhlIGRpYWxvZyBiZXR3ZWVuIHR3byBSVENX ZWIgY2xpZW50LiBJIGFza2VkIGZvciBTSVAgaW5pdGlhbGx5IGFzIFNJUCBpcyB0aGUgZGUtZmFj dG8gcHJvdG9jb2wgYW5kIG1vc3RseSBkZXBsb3ltZW50LiBJIGFncmVlIHdpdGggUGV0ZXIgJiBv dGhlcnMgdGhhdCB3ZWJzb2NrZXQgY291bGQgYmUgYW5vdGhlciBhbHRlcm5hdGl2ZSBpbiB0aGUg d2ViIGRlcGxveW1lbnQuIEluIGNhc2UgcmVxdWlyZWQsIEknbGwgY29tZSB1cCB0aGUgd3JpdGUg dXAgdG8gc2hvdyB0aGUgbmVlZHMgb2YgZGVmYXVsdCBzaWduYWxpbmcgcHJvdG9jb2wgZm9yIG1h a2luZyBkaWFsb2cgYmV0d2VlbiBicm93c2VyIHRvIGJyb3dzZXIuDQoNClBsZWFzZSByZWFkIGlu bGluZS4NCg0KVGhhbmtzDQpQYXJ0aGENCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ RnJvbTogcnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmDQo+T2YgScOxYWtpIEJheiBDYXN0aWxsbw0KPlNlbnQ6IFdlZG5lc2Rh eSwgU2VwdGVtYmVyIDE0LCAyMDExIDg6MjcgUE0NCj5UbzogcnRjd2ViQGlldGYub3JnDQo+U3Vi amVjdDogW3J0Y3dlYl0gQWJvdXQgZGVmaW5pbmcgYSBzaWduYWxpbmcgcHJvdG9jb2wgZm9yIFdl YlJUQyAob3INCj5ub3QpDQo+DQo+SGkgYWxsLA0KPg0KPlRoZXJlIGFyZSBzb21lIHRocmVhZHMg YWJvdXQgdGhlIG5lZWQgKG9yIG5vdCkgZm9yIGEgd2VsbCBkZWZpbmVkDQo+c2lnbmFsaW5nIHBy b3RvY29sIHdpdGhpbiBXZWJSVEMuIEkgd291bGQgbGlrZSB0byBjb21tZW50IGFib3V0IGl0Lg0K Pg0KPldlYlJUQyBkZWZpbmVzIG11bHRpbWVkaWEgY2FwYWJpbGl0aWVzIGZvciB3ZWItYnJvd3Nl cnMgYW5kIG1hbmRhdGVzDQo+cHJvdG9jb2xzIGFzIFJUUCwgU1RVTiwgSUNFLCBhbmQgdW5kZXJz dGFuZGluZyBvZiBTRFAgKFJGQyA0NTY2KS4gVGhlDQo+YWltIG9mIHRoZXNlIHByb3RvY29scyBp cyB0byBlbmFibGUgbXVsdGltZWRpYSBzdHJlYW1zIGJldHdlZW4gYQ0KPndlYi1icm93c2VyIGFu ZCBvdGhlciBlbmRwb2ludCAod2hpY2ggY291bGQgYWxzbyBiZSBhIHdlYi1icm93c2VyKS4NCj4N CjxwYXJ0aGE+IEkgaG9wZSB0aGF0IHRoZSBhaW0gb2YgdGhlIHByb3RvY29scyBpcyB0byBlbmFi bGUgbXVsdGltZWRpYSBzdHJlYW0gYmV0d2VlbiBicm93c2VyIHRvIGJyb3dzZXIgb25seS4gSW4g Y2FzZSBicm93c2VyIHRvIG90aGVyIGVuZC1wb2ludCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiBS VENXRWIuIDwvcGFydGhhPiANCg0KPkJ1dCBoYXZpbmcgdGhlIGFib3ZlIGlzIG5vdCBlbm91Z2gg c2luY2UgYSBzaWduYWxpbmcNCj5wcm90b2NvbC9tZWNoYW5pc20gZm9yIG1hbmFnaW5nIHRoZSBt ZWRpYSBzZXNzaW9ucyBpcyByZXF1aXJlZCAoZm9yDQo+cmVxdWVzdGluZyBhIG11bHRpbWVkaWEg c2Vzc2lvbiB0byB0aGUgZW5kcG9pbnQsIGZvciB0ZXJtaW5hdGluZyBpdCwNCj5mb3IgcHV0dGlu ZyBpdCBpbiBob2xkLi4uKS4NCj4NCj5Cb3RoIFNJUCBhbmQgWE1QUCAod2l0aCBKaW5nbGUpIGJl aGF2ZSBhcyBhIHNpZ25hbGluZyBwcm90b2NvbCBhbmQNCj5tYW5hZ2UgbXVsdGltZWRpYSBzZXNz aW9ucyBiYXNlZCBvbiBTRFAgZGVzY3JpcHRpb25zIChTSVAgdXNlcyBwbGFpbg0KPlNEUCBncmFt bWFyIGFzIGRlZmluZWQgaW4gUkZDIDQ1NjYgd2hpbGUgWE1QUCB1c2VzIGEgWE1MIHZlcnNpb24g b2YNCj50aGUgU0RQIGZvcm1hdCkuIFNvIGJvdGggU0lQIGFuZCBYTVBQIGNvdWxkIGJlIGEgZ29v ZCBjaG9pY2UuIEJ1dCBhbHNvDQo+YW55IGN1c3RvbSBzaWduYWxpbmcgcHJvdG9jb2wgY2Fycnlp bmcgbGlrZS1TRFAgaW5mb3JtYXRpb24uDQo+DQo8cGFydGhhPiBJIGFncmVlIHdpdGggQ3VsbGVu IGZvciBoaXMgcHJvcG9zYWwgb24gU0RQIGJ1dCBJJ20gbm90IHN1cmUgd2hldGhlciB3ZSB3aWxs IGVuZC11cCB0aGVyZSA8L3BhcnRoYT4NCg0KPklmIFdlYlJUQyBtYW5kYXRlcyBhIHNwZWNpZmlj IHNpZ25hbGluZyBwcm90b2NvbCB0aGVuIGFsbCB0aGUgd2ViDQo+cHJvdmlkZXJzIHNob3VsZCBp bmNvcnBvcmF0ZSBzdWNoIGEgcHJvdG9jb2wgd2l0aGluIHRoZWlyDQo+aW5mcmFzdHJ1Y3R1cmUs IHdoaWNoIHNlZW1zIG5vdCBmZWFzaWJsZSBmb3IgbWUgKGxldCdzIHNheSB3ZWIgcGFnZXMNCj5z ZXJ2ZWQgYnkgaG9zdGluZyBkYXRhY2VudGVycyB3aGljaCBqdXN0IHByb3ZpZGUgYW4gQXBhY2hl IHNlcnZlciBmb3INCj50aGUgd2ViIGRldmVsb3BlciwgZm9yIGV4YW1wbGUpLg0KPg0KPHBhcnRo YT4gUGxlYXNlIHNlZSB0aGUgdXNlY2FzZSwgSSBoYXZlIG1lbnRpb25lZCBpbiBodHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNnMDA4NDUuaHRtbC4g VGhlIGlzc3VlIGluIHlvdXIgYXJndW1lbnQgaXMgdGhhdCB5b3UgYXNzdW1lIHdlYiBzZXJ2ZXIg YXMgUlRDV0ViIHNlcnZlci4gSSBhZ3JlZSB0aGF0IGl0IG1heSBiZSBwcmVmZXJyZWQgYnV0IG5v dCBhIE1VU1QgaXRlbS4gPC9wYXJ0aGE+DQoNCj5TbyBJIHdvbmRlcjogd2h5IGlzIGEgc3BlY2lm aWMgc2lnbmFsaW5nIHByb3RvY29sIG5lZWRlZCBhdCBhbGw/IEFGQUlLDQo+dGhlIG9ubHkgd2Ug bmVlZCBpcyBhbiBBUEkgKHdpdGhpbiBXZWJSVEMpIHRvIG1hbmFnZSBtdWx0aW1lZGlhDQo+c2Vz c2lvbnMgKHN0YXJ0IGl0LCB0ZXJtaW5hdGUgaXQsIHVzZSBjb2RlYyBYWFhYLCBwdXQgb24gaG9s ZC4uLikuIEhvdw0KPnRoZSBjbGllbnQgYXBwbGljYXRpb24gKGxldCdzIGFzc3VtZSB0aGUgSmF2 YVNjcmlwdCBjb2RlKSBvYnRhaW5zIHN1Y2gNCj5pbmZvcm1hdGlvbiBzaG91bGQgYmUgb3V0IG9m IHRoZSBzY29wZSBvZiBXZWJSVEMuIFRoZSBjbGllbnQNCj5hcHBsaWNhdGlvbiAoSmF2YVNjcmlw dCkganVzdCBuZWVkcyB0byByZXRyaWV2ZSAodmlhIEhUVFAsIFdlYlNvY2tldA0KPm9yIHdoYXRl dmVyKSB0aGUgIlNEUCIgaW5mb3JtYXRpb24gcHJvdmlkZWQgYnkgdGhlIGVuZHBvaW50IGFuZCB1 c2UNCj5zdWNoIGRhdGEgZm9yIG1ha2luZyBBUEkgY2FsbHMgdG8gdGhlIFdlYlJUQyBzdGFjayBi eSBwYXNzaW5nIGFzDQo+YXJndW1lbnRzIHRoZSByZW1vdGUgcGVlciBJUCwgcG9ydCwgdHlwZSBv ZiBzZXNzaW9uLCBjb2RlYyB0byB1c2UsIGFuZA0KPnNvIG9uLg0KPg0KPkZvciBleGFtcGxlLCBp ZiBhIHdlYiBwYWdlIG1ha2VzIHVzYWdlIG9mIFNJUCBvdmVyIFdlYlNvY2tldCBvciBYTVBQDQo+ b3ZlciBXZWJTb2NrZXQsIHRoZSBzaWduYWxpbmcgKGFsc28gY29udGFpbmluZyBTRFAgaW5mb3Jt YXRpb24pIHdvdWxkDQo+YmUgY2FycmllZCB3aXRoaW4gU0lQIG9yIFhNUFAgbWVzc2FnZXMuIFRo ZSBvbmx5IHJlcWlyZW1lbnRlIHdvdWxkIGJlDQo+Zm9yIHRoZSBXZWJTb2NrZXQgc2VydmVyIHRv IGJlIGludGVncmF0ZWQgd2l0aGluIGEgU0lQIHByb3h5L3NlcnZlcg0KPmltcGxlbWVudGluZyBk cmFmdC1pYmMtcnRjd2ViLXNpcC13ZWJzb2NrZXQgb3IgYSBYTVBQIHNlcnZlcg0KPmltcGxlbWVu dGluZyBkcmFmdC1tb2ZmaXR0LXhtcHAtb3Zlci13ZWJzb2NrZXQuIFRoZSBjbGllbnQgYXBwbGlj YXRpb24NCj4oSmF2YVNjcmlwdCBpbiB0aGUgd2ViIHBhZ2UpIHNob3VsZCBwYXJzZSB0aGUgU0RQ IGJvZGllcyBhbmQgbWFrZQ0KPldlYlJUQyBjYWxscyB3aGVuIGFwcHJvcHJpYXRlIHRvIGluaXRp YXRlIG9yIGFuc3dlciBtdWx0aW1lZGlhDQo+c2Vzc2lvbnMuIEFuZCB0aGVuIHdlIGdldCBmdWxs IGludGVyb3BlcmFiaWxpdHkgd2l0aCBTSVAvWE1QUCB3b3JsZA0KPm91dCB0aGVyZSAod2l0aG91 dCByZXF1aXJpbmcgYSBzZXJ2ZXIvZ2F0ZXdheSBwZXJmb3JtaW5nIGNvbnZlcnNpb24gb2YNCj5h cHBsaWNhdGlvbiBsZXZlbCBwcm90b2NvbHMpLg0KPg0KPkluIHRoZSBzYW1lIHdheSwgb3RoZXIg d2ViIHBhZ2Ugd2hpY2gganVzdCByZXF1aXJlcyBtdWx0aW1lZGlhDQo+c2Vzc2lvbnMgYmV0d2Vl biB3ZWItYnJvd3NlcnMsIGNvdWxkIHByZWZlciB0byBpbXBsZW1lbnQgYSBzaW1wbGUgYW5kDQo+ Y3VzdG9tIEpTT04gZm9ybWF0IGFzIGEgc2lnbmFsaW5nIG1lY2hhbmlzbSBvbiB0b3Agb2YgV2Vi U29ja2V0IChvcg0KPnVzZSBIVFRQIENvbWV0LCBsb25nLXBvbGxpbmcsIGV0YykuIEl0IGNvdWxk IG1hcCB0aGUgU0RQIGRlZmluaXRpb24NCj5pbnRvIGEgSlNPTiBzdHJ1Y3QuIEFnYWluIHRoZSBK YXZhU2NyaXB0IGNvZGUgcGFyc2VzIHRoZSBTRFANCj5pbmZvcm1hdGlvbiBhbmQgY2FsbHMgV2Vi UlRDIEFQSSBmdW5jdGlvbnMgdG8gbWFuYWdlIG11bHRpbWVkaWENCj5zZXNzaW9ucy4gVGhlIG9u bHkgcmVxdWlyZW1lbnQgd291bGQgYmUgZm9yIHRoZSBIVFRQIHNlcnZlciB0bw0KPmltcGxlbWVu dCBXZWJTb2NrZXQgb3IgSFRUUCBDb21ldCAob3Igbm90aGluZyBpZiBIVFRQIGxvbmcgcG9sbGlu ZyBpcw0KPnVzZWQpLg0KPg0KPlNvIG15IHByb3Bvc2FsIGlzIHRoYXQgV2ViUlRDIHNob3VsZCBu b3QgbWFuZGF0ZSBhIHNpZ25hbGluZyBwcm90b2NvbA0KPmluIHRoZSB3ZWItYnJvd3NlciwgYnV0 IGp1c3QgZGVmaW5lIGEgcmVxdWVyaW1lbnQgZm9yIG1hbmFnaW5nDQo+bXVsdGltZWRpYSBzZXNz aW9ucyBmcm9tIHRoZSBKYXZhU2NyaXB0IGNvZGUgZ2l2ZW4gYSB3ZWxsIGRlZmluZWQgQVBJLg0K PklNSE8gdGhpcyBpcyB0aGUgd2F5IHRoYXQgZml0cyB3ZWxsIHdpdGggdGhlIGZsZXhpYmlsaXR5 IG9mIHRoZSB3ZWINCj5hbmQgbGV0cyBlYWNoIHdlYiBwcm92aWRlciB0byBkZWNpZGUgd2hpY2gg dGVjaG5vbG9neSB0byB1c2UgYXMNCj5zaWduYWxpbmcgcHJvdG9jb2wsIHJhdGhlciB0aGFuIGZv cmNpbmcgaGltIHRvIGltcGxlbWVudA0KPlNJUC9YTVBQL290aGVyLXByb3RvY29sIGluIHNlcnZl ciBzaWRlLg0KPg0KPg0KPkJlc3QgcmVnYXJkcy4NCj4NCj4tLQ0KPknDsWFraSBCYXogQ2FzdGls bG8NCj48aWJjQGFsaWF4Lm5ldD4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPnJ0Y3dlYiBtYWlsaW5nIGxpc3QNCj5ydGN3ZWJAaWV0Zi5vcmcNCj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0K From s.choi@daemon.or.kr Thu Sep 15 00:28: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 9A58021F8508 for ; Thu, 15 Sep 2011 00:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7N-Uy4rD+iay for ; Thu, 15 Sep 2011 00:28:01 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 46B1721F84DC for ; Thu, 15 Sep 2011 00:28:01 -0700 (PDT) Received: by bkaq10 with SMTP id q10so2449815bka.31 for ; Thu, 15 Sep 2011 00:30:10 -0700 (PDT) Received: by 10.204.156.11 with SMTP id u11mr442952bkw.143.1316071810101; Thu, 15 Sep 2011 00:30:10 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by mx.google.com with ESMTPS id t18sm2100583bkb.9.2011.09.15.00.30.08 (version=SSLv3 cipher=OTHER); Thu, 15 Sep 2011 00:30:09 -0700 (PDT) Received: by bkaq10 with SMTP id q10so2449777bka.31 for ; Thu, 15 Sep 2011 00:30:08 -0700 (PDT) Received: by 10.204.9.197 with SMTP id m5mr427008bkm.171.1316071808202; Thu, 15 Sep 2011 00:30:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.205.81.10 with HTTP; Thu, 15 Sep 2011 00:29:48 -0700 (PDT) In-Reply-To: References: From: Soo-Hyun Choi Date: Thu, 15 Sep 2011 16:29:48 +0900 Message-ID: To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=0015175cd84ea079d304acf5d841 Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 07:28:02 -0000 --0015175cd84ea079d304acf5d841 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 On Wed, Sep 14, 2011 at 23:56, I=F1aki Baz Castillo wrote: > Hi all, > > There are some threads about the need (or not) for a well defined > signaling protocol within WebRTC. I would like to comment about it. > > WebRTC defines multimedia capabilities for web-browsers and mandates > protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566). The > aim of these protocols is to enable multimedia streams between a > web-browser and other endpoint (which could also be a web-browser). > > But having the above is not enough since a signaling > protocol/mechanism for managing the media sessions is required (for > requesting a multimedia session to the endpoint, for terminating it, > for putting it in hold...). > > Both SIP and XMPP (with Jingle) behave as a signaling protocol and > manage multimedia sessions based on SDP descriptions (SIP uses plain > SDP grammar as defined in RFC 4566 while XMPP uses a XML version of > the SDP format). So both SIP and XMPP could be a good choice. But also > any custom signaling protocol carrying like-SDP information. > > If WebRTC mandates a specific signaling protocol then all the web > providers should incorporate such a protocol within their > infrastructure, which seems not feasible for me (let's say web pages > served by hosting datacenters which just provide an Apache server for > the web developer, for example). > > So I wonder: why is a specific signaling protocol needed at all? AFAIK > the only we need is an API (within WebRTC) to manage multimedia > sessions (start it, terminate it, use codec XXXX, put on hold...). How > the client application (let's assume the JavaScript code) obtains such > information should be out of the scope of WebRTC. The client > application (JavaScript) just needs to retrieve (via HTTP, WebSocket > or whatever) the "SDP" information provided by the endpoint and use > such data for making API calls to the WebRTC stack by passing as > arguments the remote peer IP, port, type of session, codec to use, and > so on. > > For example, if a web page makes usage of SIP over WebSocket or XMPP > over WebSocket, the signaling (also containing SDP information) would > be carried within SIP or XMPP messages. The only reqiremente would be > for the WebSocket server to be integrated within a SIP proxy/server > implementing draft-ibc-rtcweb-sip-websocket or a XMPP server > implementing draft-moffitt-xmpp-over-websocket. The client application > (JavaScript in the web page) should parse the SDP bodies and make > WebRTC calls when appropriate to initiate or answer multimedia > sessions. And then we get full interoperability with SIP/XMPP world > out there (without requiring a server/gateway performing conversion of > application level protocols). > > In the same way, other web page which just requires multimedia > sessions between web-browsers, could prefer to implement a simple and > custom JSON format as a signaling mechanism on top of WebSocket (or > use HTTP Comet, long-polling, etc). It could map the SDP definition > into a JSON struct. Again the JavaScript code parses the SDP > information and calls WebRTC API functions to manage multimedia > sessions. The only requirement would be for the HTTP server to > implement WebSocket or HTTP Comet (or nothing if HTTP long polling is > used). > > So my proposal is that WebRTC should not mandate a signaling protocol > in the web-browser, but just define a requeriment for managing > multimedia sessions from the JavaScript code given a well defined API. > IMHO this is the way that fits well with the flexibility of the web > and lets each web provider to decide which technology to use as > signaling protocol, rather than forcing him to implement > SIP/XMPP/other-protocol in server side. > > > Best regards. > > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0015175cd84ea079d304acf5d841 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1



On Wed, Sep 14, 2011 at 23:56, I=F1aki B= az Castillo <ibc@alia= x.net> wrote:
Hi all,

There are some threads about the need (or not) for a well defined
signaling protocol within WebRTC. I would like to comment about it.

WebRTC defines multimedia capabilities for web-browsers and mandates
protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566). The
aim of these protocols is to enable multimedia streams between a
web-browser and other endpoint (which could also be a web-browser).

But having the above is not enough since a signaling
protocol/mechanism for managing the media sessions is required (for
requesting a multimedia session to the endpoint, for terminating it,
for putting it in hold...).

Both SIP and XMPP (with Jingle) behave as a signaling protocol and
manage multimedia sessions based on SDP descriptions (SIP uses plain
SDP grammar as defined in RFC 4566 while XMPP uses a XML version of
the SDP format). So both SIP and XMPP could be a good choice. But also
any custom signaling protocol carrying like-SDP information.

If WebRTC mandates a specific signaling protocol then all the web
providers should incorporate such a protocol within their
infrastructure, which seems not feasible for me (let's say web pages served by hosting datacenters which just provide an Apache server for
the web developer, for example).

So I wonder: why is a specific signaling protocol needed at all? AFAIK
the only we need is an API (within WebRTC) to manage multimedia
sessions (start it, terminate it, use codec XXXX, put on hold...). How
the client application (let's assume the JavaScript code) obtains such<= br> information should be out of the scope of WebRTC. The client
application (JavaScript) just needs to retrieve (via HTTP, WebSocket
or whatever) the "SDP" information provided by the endpoint and u= se
such data for making API calls to the WebRTC stack by passing as
arguments the remote peer IP, port, type of session, codec to use, and
so on.

For example, if a web page makes usage of SIP over WebSocket or XMPP
over WebSocket, the signaling (also containing SDP information) would
be carried within SIP or XMPP messages. The only reqiremente would be
for the WebSocket server to be integrated within a SIP proxy/server
implementing draft-ibc-rtcweb-sip-websocket or a XMPP server
implementing draft-moffitt-xmpp-over-websocket. The client application
(JavaScript in the web page) should parse the SDP bodies and make
WebRTC calls when appropriate to initiate or answer multimedia
sessions. And then we get full interoperability with SIP/XMPP world
out there (without requiring a server/gateway performing conversion of
application level protocols).

In the same way, other web page which just requires multimedia
sessions between web-browsers, could prefer to implement a simple and
custom JSON format as a signaling mechanism on top of WebSocket (or
use HTTP Comet, long-polling, etc). It could map the SDP definition
into a JSON struct. Again the JavaScript code parses the SDP
information and calls WebRTC API functions to manage multimedia
sessions. The only requirement would be for the HTTP server to
implement WebSocket or HTTP Comet (or nothing if HTTP long polling is
used).

So my proposal is that WebRTC should not mandate a signaling protocol
in the web-browser, but just define a requeriment for managing
multimedia sessions from the JavaScript code given a well defined API.
IMHO this is the way that fits well with the flexibility of the web
and lets each web provider to decide which technology to use as
signaling protocol, rather than forcing him to implement
SIP/XMPP/other-protocol in server side.


Best regards.

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

--0015175cd84ea079d304acf5d841-- From jmillan@aliax.net Thu Sep 15 00: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 BCF9221F84F5 for ; Thu, 15 Sep 2011 00:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.026, 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 iELa7yTQUuMb for ; Thu, 15 Sep 2011 00:48:11 -0700 (PDT) Received: from mail-iy0-f194.google.com (mail-iy0-f194.google.com [209.85.210.194]) by ietfa.amsl.com (Postfix) with ESMTP id 6473D21F84DC for ; Thu, 15 Sep 2011 00:48:08 -0700 (PDT) Received: by iadj38 with SMTP id j38so297226iad.1 for ; Thu, 15 Sep 2011 00:50:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.134.4 with SMTP id j4mr678217ict.135.1316073017827; Thu, 15 Sep 2011 00:50:17 -0700 (PDT) Received: by 10.231.36.201 with HTTP; Thu, 15 Sep 2011 00:50:17 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Sep 2011 09:50:17 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: Soo-Hyun Choi Content-Type: multipart/alternative; boundary=90e6ba613858b9e0e804acf62007 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 07:48:12 -0000 --90e6ba613858b9e0e804acf62007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Totally agree, I=F1aki +1 2011/9/15 Soo-Hyun Choi > +1 > > > > > On Wed, Sep 14, 2011 at 23:56, I=F1aki Baz Castillo wrote= : > >> Hi all, >> >> There are some threads about the need (or not) for a well defined >> signaling protocol within WebRTC. I would like to comment about it. >> >> WebRTC defines multimedia capabilities for web-browsers and mandates >> protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566). The >> aim of these protocols is to enable multimedia streams between a >> web-browser and other endpoint (which could also be a web-browser). >> >> But having the above is not enough since a signaling >> protocol/mechanism for managing the media sessions is required (for >> requesting a multimedia session to the endpoint, for terminating it, >> for putting it in hold...). >> >> Both SIP and XMPP (with Jingle) behave as a signaling protocol and >> manage multimedia sessions based on SDP descriptions (SIP uses plain >> SDP grammar as defined in RFC 4566 while XMPP uses a XML version of >> the SDP format). So both SIP and XMPP could be a good choice. But also >> any custom signaling protocol carrying like-SDP information. >> >> If WebRTC mandates a specific signaling protocol then all the web >> providers should incorporate such a protocol within their >> infrastructure, which seems not feasible for me (let's say web pages >> served by hosting datacenters which just provide an Apache server for >> the web developer, for example). >> >> So I wonder: why is a specific signaling protocol needed at all? AFAIK >> the only we need is an API (within WebRTC) to manage multimedia >> sessions (start it, terminate it, use codec XXXX, put on hold...). How >> the client application (let's assume the JavaScript code) obtains such >> information should be out of the scope of WebRTC. The client >> application (JavaScript) just needs to retrieve (via HTTP, WebSocket >> or whatever) the "SDP" information provided by the endpoint and use >> such data for making API calls to the WebRTC stack by passing as >> arguments the remote peer IP, port, type of session, codec to use, and >> so on. >> >> For example, if a web page makes usage of SIP over WebSocket or XMPP >> over WebSocket, the signaling (also containing SDP information) would >> be carried within SIP or XMPP messages. The only reqiremente would be >> for the WebSocket server to be integrated within a SIP proxy/server >> implementing draft-ibc-rtcweb-sip-websocket or a XMPP server >> implementing draft-moffitt-xmpp-over-websocket. The client application >> (JavaScript in the web page) should parse the SDP bodies and make >> WebRTC calls when appropriate to initiate or answer multimedia >> sessions. And then we get full interoperability with SIP/XMPP world >> out there (without requiring a server/gateway performing conversion of >> application level protocols). >> >> In the same way, other web page which just requires multimedia >> sessions between web-browsers, could prefer to implement a simple and >> custom JSON format as a signaling mechanism on top of WebSocket (or >> use HTTP Comet, long-polling, etc). It could map the SDP definition >> into a JSON struct. Again the JavaScript code parses the SDP >> information and calls WebRTC API functions to manage multimedia >> sessions. The only requirement would be for the HTTP server to >> implement WebSocket or HTTP Comet (or nothing if HTTP long polling is >> used). >> >> So my proposal is that WebRTC should not mandate a signaling protocol >> in the web-browser, but just define a requeriment for managing >> multimedia sessions from the JavaScript code given a well defined API. >> IMHO this is the way that fits well with the flexibility of the web >> and lets each web provider to decide which technology to use as >> signaling protocol, rather than forcing him to implement >> SIP/XMPP/other-protocol in server side. >> >> >> Best regards. >> >> -- >> I=F1aki Baz Castillo >> >> _______________________________________________ >> 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 > > --90e6ba613858b9e0e804acf62007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Totally agree, I=F1aki

+1


2011/9/15 Soo-Hyun Choi <soohyun.choi@cl.cam.ac= .uk>
+1



On Wed, Sep 14, 2011 at 23:56, I=F1aki B= az Castillo <ibc@aliax.net> wrote:
Hi all,

There are some threads about the need (or not) for a well defined
signaling protocol within WebRTC. I would like to comment about it.

WebRTC defines multimedia capabilities for web-browsers and mandates
protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566). The
aim of these protocols is to enable multimedia streams between a
web-browser and other endpoint (which could also be a web-browser).

But having the above is not enough since a signaling
protocol/mechanism for managing the media sessions is required (for
requesting a multimedia session to the endpoint, for terminating it,
for putting it in hold...).

Both SIP and XMPP (with Jingle) behave as a signaling protocol and
manage multimedia sessions based on SDP descriptions (SIP uses plain
SDP grammar as defined in RFC 4566 while XMPP uses a XML version of
the SDP format). So both SIP and XMPP could be a good choice. But also
any custom signaling protocol carrying like-SDP information.

If WebRTC mandates a specific signaling protocol then all the web
providers should incorporate such a protocol within their
infrastructure, which seems not feasible for me (let's say web pages served by hosting datacenters which just provide an Apache server for
the web developer, for example).

So I wonder: why is a specific signaling protocol needed at all? AFAIK
the only we need is an API (within WebRTC) to manage multimedia
sessions (start it, terminate it, use codec XXXX, put on hold...). How
the client application (let's assume the JavaScript code) obtains such<= br> information should be out of the scope of WebRTC. The client
application (JavaScript) just needs to retrieve (via HTTP, WebSocket
or whatever) the "SDP" information provided by the endpoint and u= se
such data for making API calls to the WebRTC stack by passing as
arguments the remote peer IP, port, type of session, codec to use, and
so on.

For example, if a web page makes usage of SIP over WebSocket or XMPP
over WebSocket, the signaling (also containing SDP information) would
be carried within SIP or XMPP messages. The only reqiremente would be
for the WebSocket server to be integrated within a SIP proxy/server
implementing draft-ibc-rtcweb-sip-websocket or a XMPP server
implementing draft-moffitt-xmpp-over-websocket. The client application
(JavaScript in the web page) should parse the SDP bodies and make
WebRTC calls when appropriate to initiate or answer multimedia
sessions. And then we get full interoperability with SIP/XMPP world
out there (without requiring a server/gateway performing conversion of
application level protocols).

In the same way, other web page which just requires multimedia
sessions between web-browsers, could prefer to implement a simple and
custom JSON format as a signaling mechanism on top of WebSocket (or
use HTTP Comet, long-polling, etc). It could map the SDP definition
into a JSON struct. Again the JavaScript code parses the SDP
information and calls WebRTC API functions to manage multimedia
sessions. The only requirement would be for the HTTP server to
implement WebSocket or HTTP Comet (or nothing if HTTP long polling is
used).

So my proposal is that WebRTC should not mandate a signaling protocol
in the web-browser, but just define a requeriment for managing
multimedia sessions from the JavaScript code given a well defined API.
IMHO this is the way that fits well with the flexibility of the web
and lets each web provider to decide which technology to use as
signaling protocol, rather than forcing him to implement
SIP/XMPP/other-protocol in server side.


Best regards.

--
I=F1aki Baz Castillo
<ibc@aliax.net>= ;
_______________________________________________
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


--90e6ba613858b9e0e804acf62007-- From saul@ag-projects.com Thu Sep 15 00:51: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 8A0DD21F853E for ; Thu, 15 Sep 2011 00:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9du74x6Q4JgJ for ; Thu, 15 Sep 2011 00:51:07 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id D169521F8532 for ; Thu, 15 Sep 2011 00:51:06 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 57095B01BB; Thu, 15 Sep 2011 09:53:14 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 94C0FB01A2; Thu, 15 Sep 2011 09:53:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> Date: Thu, 15 Sep 2011 09:53:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> To: Ravindran Parthasarathi X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 07:51:07 -0000 Hi, [snip] > My point is that the default signaling protocol has to be supported in = RTCWeb client which should not be downloaded in runtime to make the = dialog between two RTCWeb client. I asked for SIP initially as SIP is = the de-facto protocol and mostly deployment. I agree with Peter & others = that websocket could be another alternative in the web deployment. In = case required, I'll come up the write up to show the needs of default = signaling protocol for making dialog between browser to browser. >=20 Do you mean there should be a 'default signaling protocol' on every = browser? I'm not sure I'd like that. I (personally) see RTCWeb as a = framework on top of which we can build RTC applications. The fact that = one would use SIP and someone else uses something else is not crucial, = IMHO. Now if some new simplified protocol is chosen for = browser-to-browser communication we'd have yet another island of devices = (browsers in this case) to which we'd need to gateway somehow. [snip] >>=20 >> WebRTC defines multimedia capabilities for web-browsers and mandates >> protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566). The >> aim of these protocols is to enable multimedia streams between a >> web-browser and other endpoint (which could also be a web-browser). >>=20 > I hope that the aim of the protocols is to enable multimedia = stream between browser to browser only. In case browser to other = end-point is outside the scope of RTCWEb. =20 >=20 Well, why build a parallel universe just for the browsers? If RTCWeb = would only define the media plane and developers themselves can choose = the signaling protocol, the integration with existing communication = systems (using SIP or XMPP for example since they are the most used = ones) would be pretty straight-forward. My 2 cents. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From tim@phonefromhere.com Thu Sep 15 02:46: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 23B3121F849D for ; Thu, 15 Sep 2011 02:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 R-oZbR8IV10p for ; Thu, 15 Sep 2011 02:46:29 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 6835421F8497 for ; Thu, 15 Sep 2011 02:46:29 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id EC09437A902; Thu, 15 Sep 2011 11:01:29 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0B8A@sonusinmail02.sonusnet.com> Date: Thu, 15 Sep 2011 10:48:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4E4270DE-5CC3-4089-874A-FDFFB12156E7@phonefromhere.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F0B39@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F0B8A@sonusinmail02.sonusnet.com> To: Ravindran Parthasarathi X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 09:46:30 -0000 It is worth pointing out that even with a signalling protocol agnostic = webRTC you=20 wouldn't _have_ to implement your signalling protocol in javascript. Browsers support other plugin languages - specifically it would be = possible to implement a classic full UDP SIP stack as a java applet and delegate the media = handling to the webRTC layer. Chrome is moving towards support for native plugins, but it isn't clear = that they would be suitable for this use. Tim. (speaking for himself) On 14 Sep 2011, at 11:03, Ravindran Parthasarathi wrote: > Hi Inaki, >=20 > =20 >=20 > The fact that there are other alternatives for signaling in the web = does not mean that using SIP is invalid. > If I want to build a SIP phone in a web, why should I use libjingle = rather than SIP protocol? Why should I code a complex server behaving as = a gateway between Jingle and SIP protocols? >=20 > Any protocol conversion (i.e. from Jingle to SIP) means loss of = features. Our draft proposes the contrary: no protocol conversion (just = SIP), and just transport protocol conversion (as already exists in SIP = when bridging UDP/TCP/TLS-TCP/SCTP...). > =20 >=20 > I agree with your problem statement. I have raised the same concern in = http://www.ietf.org/mail-archive/web/rtcweb/current/msg00845.html. IMO, = your solution is a workaround and we will end-up with your solution in = case signaling protocol is not standardized as part of RTCWeb. >=20 > Thanks > Partha >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From stefan.lk.hakansson@ericsson.com Thu Sep 15 02:50: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 D4FD621F84D1 for ; Thu, 15 Sep 2011 02:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.313 X-Spam-Level: X-Spam-Status: No, score=-7.313 tagged_above=-999 required=5 tests=[AWL=0.986, BAYES_00=-2.599, GB_I_LETTER=-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 micyMz1ML3q6 for ; Thu, 15 Sep 2011 02:50:55 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C523121F84C1 for ; Thu, 15 Sep 2011 02:50:54 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-51-4e71cb01f4f4 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1F.57.20773.10BC17E4; Thu, 15 Sep 2011 11:53:05 +0200 (CEST) Received: from [150.132.141.36] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 11:53:04 +0200 Message-ID: <4E71CB00.8040702@ericsson.com> Date: Thu, 15 Sep 2011 11:53:04 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <0D3E4B73-39A0-41C6-93E6-88E46E9416FF@voxeo.com> In-Reply-To: <0D3E4B73-39A0-41C6-93E6-88E46E9416FF@voxeo.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-use-cases-and-requirements-04.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 09:50:56 -0000 Dan, many thanks for great input! I've updated the document, and will shortly announce a new version (-05). I have not incorporated all your proposals, see inline for details. Thanks, Stefan On 2011-09-08 11:18, Dan Burnett wrote: > A while ago I promised a full read-through review of the use cases and requirements document [1], primarily from the API perspective, but I have included other comments as well. > The comments follow the order of the document. Some are editorial, and some are more substantive. > > > Section 4: As a general comment, the use cases occasionally stray more into implementation rather than just being worded in terms of user needs. This has driven some of my wording change suggestions below. > > > 4.2.1.1: The wording is a bit unclear as to whether this use case is for only a single peer-to-peer connection or for multiple connections. In particular, it points out that for a session there is a self-view and a remote view, but it's not clear at that point whether there might be *multiple* remote views simultaneously in the session. However, later on in this use case it states that "Any session participant can end the session at any time." Then there are what appear to be examples of different users, but it is not clear whether it only needs to be possible for each of these kinds of users to be supported (singly), or whether it must be possible to support communication with all simultaneously. > > Since there is a separate use case for multiparty video communication (4.2.7), I believe this use case should be cleaned up a bit. I suggest the following text for this use case: > > ****** > Two or more users have loaded a video communication web application into their browsers, provided by the same service provider, and logged into the service it provides. The web service publishes information about user login status by pushing updates to the web application in the browsers. When one online user selects a peer online user, a 1-1 video communication session between the browsers of the two peers is initiated. The invited user might accept or reject the session. > > During session establishment a self-view is displayed, and once the session has been established the video sent from the remote peer is displayed in addition to the self-view. During the session, each user can select to remove and re-insert the self-view as often as desired. Each user can also change the sizes of his/her two video displays during the session. Each user can also pause sending of media (audio, video, or both) and mute incoming media. > > It is essential that the communication cannot be eavesdropped. > > Either session participant can end the session at any time. > > The two users may be using communication devices of different makes, with different operating systems and browsers from different vendors. > > One user has an unreliable Internet connection that sometimes loses packets and sometimes goes down completely. > > One user is located behind a Network Address Translator (NAT). > ****** I updated according to your proposal. > > > 4.2.3.1: I recommend some minor editorial changes, so that the second paragraph reads > > ****** > The communication device used by one of the users has several network adapters (Ethernet, WiFi, Cellular). The communication device is accessing the Internet using Ethernet, but the user has to start a trip during the session. The communication device automatically changes to use WiFi when the Ethernet cable is removed and then moves to cellular access to the Internet when moving out of WiFi coverage. The session continues even though the access method changes. > ****** I updated accordingly. > > > 4.2.4.1: "previos" -> "previous". Also, the first use of "QoS" should define the term, as in "Quality of Service (QoS)". Fixed. > Actually, QoS is more a derived functional requirement than a use case, especially when that specific term is used anywhere near IETF folks. If what the user wants is that the call continues at best available quality (to the possible detriment of other users of the same cell/dsl/whatever), we should say so. It may be the best way to do this lies in the codec or protocol and not using existing QoS methods. I tend to agree. Maybe this part should be removed. It was originally added after input from Cullen (who wanted to be able to use QoS support in residential GWs. > > > 4.2.5.1: We should clarify that *in this use case*, the service providers are choosing to exchange no more information about the users than what can be carried using SIP. In other words, this is not suggesting that all RTCWeb/WebRTC web application service providers must restrict themselves only to exchanging information that can be carried via SIP (whatever SIP means in this situation). For example, in general the interoperability of sites could be done though any IM protocol, e.g., combined with, say, oauth for identity. We should not be mandating or preferring (even by implication) any specific protocol. If websites choose to export presence and identity to support interoperability that is up to them and does not necessarily require that the RTCWeb API provide such a mechanism. I agree fully to the above. However, I did not have the energy to update the wording in the document (now it basically says that more work is needed to define). > I almost think that this implies a new, more precise requirement that the Web API MUST NOT prevent two webapps that happen to choose to peer with SIP from peering. That makes clearer what our baseline minimum is without restricting the peering mechanisms of all webapps. I say "clearer" rather than "clear" because "peer with SIP" is itself not very precise, but I still think it's better than what we have now. Do you mean a new requirement, or should F24 be re-phrased? Also, for clarity, my view is that what can be exchanged using SIP is not limited to the signaling messages PeerConnection produces/consumes. Only certain messages (related to establishing streams and setting up connections) make sense to PeerConnection object, others can be webapp-webapp messages (in this case carried by SIP) that doesn't originate from, and are never fed into, the PeerConnection. > > I suggest a minor rewording of > "Each web service publishes information about user login status for users that have a relationship with the other user; how this is established is out of scope." > to something more concrete, e.g., > "For each user Alice who has authorized another user Bob to receive login status information, Alice's service publishes Alice's login status information to Bob. How this authorization is defined and established is out of scope." This part I've updated. > > > 4.2.6.1: "thumbnail ot" -> "thumbnail of". "can not" -> "cannot" Updated. > > > 4.2.7.1: "simple video communication service" needs to reference 4.2.1. Right. Updated. > > > 4.2.8.1: The description should begin with "This use case is based on the previous one." Also, "can not" -> "cannot" and "sound of the tank, that file" -> "sound of the tank; that file". I updated accordingly. > More substantially, the note in this section strongly suggests that the WebRTC/RTCWeb groups must be responsible for the mixing of sound objects with streams before rendering. It might be clearer to state that our group's work MUST NOT prevent this and in fact should work with other groups' definitions of HTML5 audio rendering. Yes it does. And the previous section suggests that webrtc is responsible for making sure that audio streams can be spatialized. I am not sure these are our tasks; the reason for putting these requirements into the document in the first place was to make sure that audio processing functions developed by other groups (e.g. the W3C Audio WG) can be applied also to the MediaStreams defined by WebRTC. > > > 4.3.1.1: "mobile phone used" -> "mobile phone is used". "can not" -> "cannot". > This use case is underspecified. What does it mean for a user to "place and receive calls in the same way as when using a normal mobile phone"? My mobile phone vibrates when I receive a call, and I can dial it by pressing and holding a digit on the keypad. I don't even have a SIP softphone on my desktop that can do either one. The login must also allow the user to manage their account, pay bills, add services, etc. More interestingly, it should be possible to write a portal web app that, once the user is logged in, does not require the user to submit an additional set of credentials to access the phone functionality. I agree. I added some clarification of what was meant as a note. What do you think? > > > 4.3.2.1: I don't believe this use case goes far enough. The phone experience should be sufficiently embedded in the page that the user's context can be passed with the call, possibly resulting in a deep dial into an IVR tree or a customer service representative not having to ask questions that the user has already answered at the website level. The key here is that we should be aspiring to a user experience that is *better* than that of a PSTN call, not just equivalent. Could you help produce more text to this one? > > > 4.3.3.1: "can not" -> "cannot". "All participant are authenticated" -> "All participants are authenticated". "There exists several" -> "There exist several". "one low resolution stream, the" -> "one low resolution stream, and the". "c) each browser" -> "or c) each browser". "just an high" -> "just a high". "reslution" -> "resolution". Fixed. > Also, we should probably note in this use case that the spatialization could not only happen as part of the server-side mixing but also by having the server tag the stream with spatialization info and having the browser render it. As the use-case is now written (only one audio stream from server to browser), it seems that the spatialization must be done in the server. Then it is a question if the use-case should be changed to allow for client side mixing/spatialization. > > > F2: "in presence of" -> "in the presence of" Fixed > > > F5: ditto Fixed > > > F8: "any more" -> "anymore" Fixed. > > > F15: I think this is venturing out of scope. Perhaps a better phrasing is "The webrtc browser component MUST interoperate with other HTML5 methods for processing and mixing sound objects (media that is retrieved from another source than the established media stream(s) with the peer(s) with audio streams)." I agree it is venturing out of scope for these WGs, as is the panning part of F13. But as phrased it is a requirement on the Browser, and then I think it is correctly phrased. > > > F18: While support for a minimum common codec is important, requiring it to be commonly supported by existing legacy telephony services is technically only a nice-to-have feature. One might consider gsm610 as an alternative, for example. I guess the codecs will be discussed a lot in the coming months. You can go either way, from saying that "a minimum common codec is a nice to have feature" (you could always transcode) to requiring codecs and even certain profiles (AVP/AVPF/SAVPF discussion) so that interop can be accomplished without any GW at all. I left it as is for the time being. > > > F19: The first letter needs to be capitalized. Done > > > F24: "carried in SIP" is not sufficiently precise. More clarity here might improve some of the discussions we are currently having. I agree. Harald supplied this requirement, and it would be good if he could supply a more precise requirement (along with text for 4.2.5). > > > F26: "in presence of" -> "in the presence of" Done. > > > General comment about all of the API requirements in section 5.3: they are not written as API requirements, but as *web application* requirements. Since many of the requirements on the web application could be met through means other than the WebRTC API, it is easy for people to agree with the requirement but strongly disagree on whether the API needs to be the *mechanism* by which the requirement is satisfied. Although I have not reworded all of the requirements below, I think it would be much clearer if we only wrote the requirements that the Web API itself must satisfy as "The Web API MUST ...". For example, "The Web API MUST inform a web application when a stream from a peer is no longer received." I think this makes sense. I tried to update the document accordingly. However, I did not update A18 since that requirement to me is partly on the API, but can partly be solved without API involvement. I don't want to forego this discussion by changing the requirement. > I suspect that this will help make clear where we disagree on which requirements must be addressed by the Web API itself and which must merely not be prevented by the Web API (and thus could be satisfied external to the WebRTC API). > > > > A8 and A10: It would be good to clarify here somewhere what the difference is between pause/resume and cease/start for a stream. I think, given the current API that it would perhaps be better to put it like "it must be possible to mute streams locally. The mute/unmute state must be preserved when a stream is sent to a peer" and remove pause/resume. I've changed along these lines in the document now. It also means that A8 is removed. > > > A14: As written this is not entirely in scope. Perhaps the following phrasing would be more accurate? > > "The Web API MUST NOT prevent panning, mixing, and other processing for individual streams." I did nothing to this at this time. I think it must be sorted out whether what parts of it that is in scope. > > > A15: This requirement is too specific in terms of how identifiers are shared. Would the following perhaps be more accurate? > > "For each stream, the Web API MUST provide to both parties of the communication an identifier for the stream that is a) the same at both ends, b) serializable, and c) unique relative to all other stream identifiers in use by either party." I re-wrote this requirement, what do you think? > > The word "serializable" is not exactly correct, but the idea I'm trying to convey is that the identifier can safely be passed from one party to the other and back again, via WebRTC calls or otherwise. > > > A16: A minor nit here -- we probably should not use the word "datagram" at this stage because of its implementation implications. What about "In addition to the streams listed elsewhere, the Web API MUST provide a mechanism for sending and receiving isolated discrete chunks of data." Correct. > > > A17: Another minor nit -- presumably this only applies when the signal is audio. Maybe we could reword as "For streams of type audio, it MUST be possible for the web application author to indicate, via the Web API, when the stream is speech." At some other place I used stream component. I used it here again. > > > 7.2: All but the last paragraph here should be written as requirements in section 5.2, not in the security considerations section. They need to be not security afterthoughts but primary requirements for implementations. > Additionally, I think we should be more explicit about consent revision to include revocation, i.e., "The browser is expected to provide mechanisms for users to revise and even completely revoke consent to use device resources such as cameras and microphones." > Along the same lines, I believe we also discussed at the WebRTC meeting in Quebec that the browser should provide a user-visible security indicator (such as a padlock) indicating the encryption level of the session. Maybe this should be a requirement? > Also, "browser is needs" -> "browser needs". I left this for further discussion (except for adding the revocation part) as it seems the security study has not gotten that far yet. I think at a later stage we will move this into section 5.2. > > > 7.3: This should be a requirement in section 5.3. I don't agree; this is currently a requirement (of sorts) on the _application_, not on the browser or API. > > > Thanks, Many thanks for useful input. > > -- dan > > [1] http://www.ietf.org/id/draft-ietf-rtcweb-use-cases-and-requirements-04.txt > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From tim@phonefromhere.com Thu Sep 15 02:51: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 58D7821F84C1 for ; Thu, 15 Sep 2011 02:51:09 -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 ScQbP65SJuE4 for ; Thu, 15 Sep 2011 02:51:08 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id C453021F862F for ; Thu, 15 Sep 2011 02:51:02 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 56B5137A902; Thu, 15 Sep 2011 11:06:09 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: <09b501cc726d$66655360$332ffa20$@com> Date: Thu, 15 Sep 2011 10:53:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <52B1B3C9-A5D2-473A-9A7F-FC7EE6EAD259@phonefromhere.com> References: <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org>, <4E6AE22A.2070106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se>, <4E6C16FF.1000706@jesup.org> <4E6CB9F7.2060208@mozilla.com> <4E6DB7F4.3090404@skype.net> <09b501c c726d$66655360$332ffa20$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 09:51:11 -0000 On 14 Sep 2011, at 00:32, Dan Wing wrote: >>=20 >=20 > SDES is also not as secure as DTLS-SRTP, reference RFC5479. >=20 > -d I had my mind rather forcibly changed on this by reading this: https://www.owasp.org/index.php/File:SSL_paved_with_good_intentions.pdf and http://www.slate.com/id/2265204/ Basically any key exchange that depends for it's security on https: is = worthless. Tim (as usual speaking for himself) P.S. I particularly enjoyed the idea of embedding logos in X509 certs = (seems this is valid).= From tim@phonefromhere.com Thu Sep 15 02: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 A71B021F862F for ; Thu, 15 Sep 2011 02:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHoKXY5uusGA for ; Thu, 15 Sep 2011 02:59:54 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 83FBB21F85CE for ; Thu, 15 Sep 2011 02:59:54 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 6D7A137A902; Thu, 15 Sep 2011 11:15:00 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4-618791845 From: Tim Panton In-Reply-To: Date: Thu, 15 Sep 2011 11:02:04 +0100 Message-Id: <6F469757-6B5C-4DC9-BC34-026F34C7E508@phonefromhere.com> References: To: =?iso-8859-1?Q?Jos=E9_Luis_Mill=E1n?= X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Thu, 15 Sep 2011 09:59:55 -0000 --Apple-Mail-4-618791845 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 13 Sep 2011, at 21:50, Jos=E9 Luis Mill=E1n wrote: > On Tue, Sep 13, 2011 at 9:25 PM, wrote: > > Hi Inaki, > > > > Fully agree about everything you say below. >=20 > Hi, >=20 > Sorry if this mail arrives out of the original mail thread. >=20 > > > > It would be interesting to understand the performance differences of = the native vs. Javascript SIP stack, if there is anything we should be = worried about. This is my only concern when (perhaps one day) applying = RTCWeb in devices like smartphones. If the JS stack works in (any of) = today's high end smartphones without problems, we should be fine. >=20 > The are no meaningful performance penalties at all using the = JavaScript SIP stack in our prototype. In fact, multiple SIP stack = instances can run in a single Web browser freshly. BTW, is there any = WebSocket capable web browser for smartphones? As an additional datapoint, The Phono.com javascript XMPP stack performs = fine on android and iOS within a Phonegap app. Native browser javascript engines tend to be slightly better optimized = than the ones available to mobile apps, so I doubt that performance would be an issue. Tim. --Apple-Mail-4-618791845 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Tue, Sep 13, 2011 at 9:25 PM,  <Markus.Isomaki@nokia.com> = wrote:
> Hi Inaki,
>
> Fully = agree about everything you say below.

Hi,

Sorry if this mail = arrives out of the original mail = thread.

>
> It would be = interesting to understand the performance differences of the native vs. = Javascript SIP stack, if there is anything we should be worried about. = This is my only concern when (perhaps one day) applying RTCWeb in = devices like smartphones. If the JS stack works in (any of) today's high = end smartphones without problems, we should be fine.

The are no meaningful performance penalties at all = using the JavaScript SIP stack in our prototype. In fact, multiple SIP = stack instances can run in a single Web browser freshly.  BTW, is = there any WebSocket capable web browser for smartphones?

As an additional datapoint, The Phono.com javascript XMPP stack = performs fine on android and iOS within a Phonegap app.
Native = browser javascript engines tend to be slightly better optimized than the = ones available to mobile apps,
so I doubt that performance would be = an issue.

Tim.

= --Apple-Mail-4-618791845-- From ibc@aliax.net Thu Sep 15 03:47: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 28EE121F84DC for ; Thu, 15 Sep 2011 03:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qPrZC-vhDwk for ; Thu, 15 Sep 2011 03:47:17 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEA821F84D9 for ; Thu, 15 Sep 2011 03:47:17 -0700 (PDT) Received: by qyk32 with SMTP id 32so4862896qyk.10 for ; Thu, 15 Sep 2011 03:49:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.148 with SMTP id r20mr791209qci.64.1316083768677; Thu, 15 Sep 2011 03:49:28 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Thu, 15 Sep 2011 03:49:28 -0700 (PDT) In-Reply-To: <4E71927C.1090606@skype.net> References: <4E71927C.1090606@skype.net> Date: Thu, 15 Sep 2011 12:49:28 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Matthew Kaufman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 10:47:18 -0000 2011/9/15 Matthew Kaufman : > On 9/14/11 4:56 PM, I=C3=B1aki Baz Castillo wrote: >> >> So my proposal is that WebRTC should not mandate a signaling protocol >> in the web-browser, but just define a requeriment for managing >> multimedia sessions from the JavaScript code given a well defined API. > > I think this is exactly what I've been advocating, so I agree as well. > > I'd go one step further to say that the "well defined API" shouldn't be "= SDP > offer/answer via events" for negotiating codec parameters, but should > instead be a way to manage the codec settings, with offer/answer or capne= g > or whatever you want implemented in the Javascript (or up at the server, > your choice). Hi Matthew, You mean a way to simplify the "SDP management" from the JavaScript code, am I right? The web-browser JavaScript stack could include a native library to parse a SDP body (maybe plain SDP as defined in RFC 4566 and also the XML version used in XMPP/Jingle) so it returns some kind of JS struct/object describing the peer-requested streams (something easier than full understanding of SDP). An also another native JS function to generate a SDP (plain or XML) given some arguments (enable-audio, enable-video, and so on) to be included in a custom signaling message (which could also be SIP or XMPP). Also functions for adding/modifying/deleting a stream, and callbacks for the case in which the remote puts on hold a specific stream, adds/modifies/deletes a stream... This is: make an API that exposes SDP capabilities without requiring understanding of the complex RFC 4566 (SDP). Regards. --=20 I=C3=B1aki Baz Castillo From internet-drafts@ietf.org Thu Sep 15 04:19: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 1D73121F8997; Thu, 15 Sep 2011 04:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.242 X-Spam-Level: X-Spam-Status: No, score=-102.242 tagged_above=-999 required=5 tests=[AWL=0.357, 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 xNReIYFekmDP; Thu, 15 Sep 2011 04:19:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88C221F88A0; Thu, 15 Sep 2011 04:19:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110915111912.7609.11334.idtracker@ietfa.amsl.com> Date: Thu, 15 Sep 2011 04:19:12 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-use-cases-and-requirements-05.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, 15 Sep 2011 11:19:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : Web Real-Time Communication Use-cases and Requirements Author(s) : Christer Holmberg Stefan Hakansson Goran AP Eriksson Filename : draft-ietf-rtcweb-use-cases-and-requirements-05.txt Pages : 20 Date : 2011-09-15 This document describes web based real-time communication use-cases. Based on the use-cases, the document also derives requirements related to the browser, and the API used by web applications to request and control media stream services provided by the browser. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-require= ments-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-requirem= ents-05.txt From stefan.lk.hakansson@ericsson.com Thu Sep 15 04:22: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 8182321F8783 for ; Thu, 15 Sep 2011 04:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.337 X-Spam-Level: X-Spam-Status: No, score=-6.337 tagged_above=-999 required=5 tests=[AWL=-0.038, 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 a+3IHVzclfYY for ; Thu, 15 Sep 2011 04:22:36 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2127B21F86EC for ; Thu, 15 Sep 2011 04:22:35 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-eb-4e71e07eb6c0 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E7.53.02839.E70E17E4; Thu, 15 Sep 2011 13:24:46 +0200 (CEST) Received: from [150.132.141.36] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 13:24:46 +0200 Message-ID: <4E71E07D.6030003@ericsson.com> Date: Thu, 15 Sep 2011 13:24:45 +0200 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" References: <20110915111912.7609.72127.idtracker@ietfa.amsl.com> In-Reply-To: <20110915111912.7609.72127.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20110915111912.7609.72127.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Fwd: New Version Notification for draft-ietf-rtcweb-use-cases-and-requirements-05.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, 15 Sep 2011 11:22:38 -0000 An updated version of the use case document has been uploaded. The changes are made based on the input from Dan Burnett (), responded to today (). Stefan -------- Original Message -------- Subject: New Version Notification for draft-ietf-rtcweb-use-cases-and-requirements-05.txt Date: Thu, 15 Sep 2011 13:19:12 +0200 From: internet-drafts@ietf.org To: Stefan Håkansson LK CC: Stefan Håkansson LK , Göran Eriksson AP , Christer Holmberg A new version of I-D, draft-ietf-rtcweb-use-cases-and-requirements-05.txt has been successfully submitted by Stefan Hakansson and posted to the IETF repository. Filename: draft-ietf-rtcweb-use-cases-and-requirements Revision: 05 Title: Web Real-Time Communication Use-cases and Requirements Creation date: 2011-09-15 WG ID: rtcweb Number of pages: 20 Abstract: This document describes web based real-time communication use-cases. Based on the use-cases, the document also derives requirements related to the browser, and the API used by web applications to request and control media stream services provided by the browser. The IETF Secretariat From tim@phonefromhere.com Thu Sep 15 04:47: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 43BDC21F8A66 for ; Thu, 15 Sep 2011 04:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=-0.118, 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 rI6r8e5Fnxe8 for ; Thu, 15 Sep 2011 04:47:42 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 95BD821F8A35 for ; Thu, 15 Sep 2011 04:47:42 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 481A837A902; Thu, 15 Sep 2011 13:02:44 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: Date: Thu, 15 Sep 2011 12:49:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com> References: <4E71927C.1090606@skype.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 11:47:43 -0000 On 15 Sep 2011, at 11:49, I=F1aki Baz Castillo wrote: > 2011/9/15 Matthew Kaufman : >> On 9/14/11 4:56 PM, I=F1aki Baz Castillo wrote: >>>=20 >>> So my proposal is that WebRTC should not mandate a signaling = protocol >>> in the web-browser, but just define a requeriment for managing >>> multimedia sessions from the JavaScript code given a well defined = API. >>=20 >> I think this is exactly what I've been advocating, so I agree as = well. >>=20 >> I'd go one step further to say that the "well defined API" shouldn't = be "SDP >> offer/answer via events" for negotiating codec parameters, but should >> instead be a way to manage the codec settings, with offer/answer or = capneg >> or whatever you want implemented in the Javascript (or up at the = server, >> your choice). >=20 > Hi Matthew, >=20 > You mean a way to simplify the "SDP management" from the JavaScript > code, am I right? >=20 > The web-browser JavaScript stack could include a native library to > parse a SDP body (maybe plain SDP as defined in RFC 4566 and also the > XML version used in XMPP/Jingle) so it returns some kind of JS > struct/object describing the peer-requested streams (something easier > than full understanding of SDP). >=20 > An also another native JS function to generate a SDP (plain or XML) > given some arguments (enable-audio, enable-video, and so on) to be > included in a custom signaling message (which could also be SIP or > XMPP). >=20 > Also functions for adding/modifying/deleting a stream, and callbacks > for the case in which the remote puts on hold a specific stream, > adds/modifies/deletes a stream... >=20 > This is: make an API that exposes SDP capabilities without requiring > understanding of the complex RFC 4566 (SDP). >=20 > Regards. >=20 Are we saying that SDP is so impossible to parse that the only way to do = it=20 is with a pre-existing native library ?!? If not I think we can do that = transformation=20 (when needed) in JavaScript. Tim. From ibc@aliax.net Thu Sep 15 04:50: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 2E74521F8A95 for ; Thu, 15 Sep 2011 04:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRxOX3VINx09 for ; Thu, 15 Sep 2011 04:50:28 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3738421F8A6C for ; Thu, 15 Sep 2011 04:50:27 -0700 (PDT) Received: by qyk32 with SMTP id 32so4926763qyk.10 for ; Thu, 15 Sep 2011 04:52:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.105 with SMTP id q41mr786335qci.216.1316087558648; Thu, 15 Sep 2011 04:52:38 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Thu, 15 Sep 2011 04:52:38 -0700 (PDT) In-Reply-To: <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com> References: <4E71927C.1090606@skype.net> <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com> Date: Thu, 15 Sep 2011 13:52:38 +0200 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] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 11:50:32 -0000 2011/9/15 Tim Panton : > Are we saying that SDP is so impossible to parse that the only way to do = it > is with a pre-existing native library ?!? If not I think we can do that t= ransformation > (when needed) in JavaScript. No, I just said that _maybe_ it wouldl be useful to provide such parsing functions natively (given the fact that various protocol use SDP bodies, as SIP and XMPP). I'm fine with parsing SDP bodies in custom JavaScript code however :) --=20 I=C3=B1aki Baz Castillo From magnus.westerlund@ericsson.com Thu Sep 15 05:03: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 5B7B121F8A70 for ; Thu, 15 Sep 2011 05:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.5 X-Spam-Level: X-Spam-Status: No, score=-106.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 TVP0q8UAqT6W for ; Thu, 15 Sep 2011 05:03:36 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8063E21F8997 for ; Thu, 15 Sep 2011 05:03:36 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-4f-4e71ea1b808c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DE.FD.20773.B1AE17E4; Thu, 15 Sep 2011 14:05:47 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 14:05:47 +0200 Message-ID: <4E71EA1A.5020407@ericsson.com> Date: Thu, 15 Sep 2011 14:05:46 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <4E70C387.1070707@ericsson.com> <4E710155.8080409@alvestrand.no> In-Reply-To: <4E710155.8080409@alvestrand.no> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 12:03:37 -0000 On 2011-09-14 21:32, Harald Alvestrand wrote: > On 09/14/11 17:08, Magnus Westerlund wrote: >> Hi, >> >> There has been this long thread with the subject partially containing >> "AVPF". I want to clarify something in this context around AVPF. Rather >> than the SRTP question. >> >> An end-point that is AVPF compliant is in fact interoperable with an AVP >> one as long as the trr-int parameter is set reasonably large. A >> parameter value of 1.5-5 seconds (I would recommend 3s) will ensure that >> they are in fact compatible. This avoids the risk of any side timing out >> the other if the AVP side is using the default 5 s minimum interval. >> >> Based on this one could in fact have the RTCWEB nodes always use AVPF >> for RTP/RTCP Behavior. The AVPF feedback messages are explicitly >> negotiated and will only be used when agreed on. >> >> This leaves us with any signaling incompatibilities when talking to a >> legacy device. If one don't want to use cap-neg I see two directions to go: >> >> 1) RTCWEB end-point will always signal AVPF or SAVPF. I signalling >> gateway to legacy will change that by removing the F to AVP or SAVP. >> >> 2) RTCWEB end-point will always use AVPF but signal it as AVP. It will >> detect the AVPF capabilities of the other end-point based on the >> signaling of the feedback events intended to be used. >> >> I think 1) is cleaner for the future. 2) might be more pragmatic. > If 2) is more pragmatic, the IETF should update the definition of AVP to > allow use of AVPF functionality. No, Harald that I think is a bad idea. The core of AVPF is the timing rule. From my perspective the important aspect is that one do implement the timing rules. Thus it is important we have the label of AVPF to indicate these rules. Thus my proposal is really to say that an RTCWEB end-point SHALL implement and always use the AVPF timing rules. It might send feedback messages if those have been negotiated with a=rtcp-fb attribute. > The responses seem to indicate that in practice, this is already being > done (and this is a clear indication that the concept of "profile" in > RTP has failed to achieve its purpose). It works fine on the RTP level. But the signalling aspects has clearly been botched. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From lorenzo@meetecho.com Thu Sep 15 05:05: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 97EDD21F8AAA for ; Thu, 15 Sep 2011 05:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.569 X-Spam-Level: X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 1CZrAxU2DO9R for ; Thu, 15 Sep 2011 05:05:15 -0700 (PDT) Received: from smtplq02.aruba.it (smtplq-out18.aruba.it [62.149.158.38]) by ietfa.amsl.com (Postfix) with SMTP id 4407721F8A70 for ; Thu, 15 Sep 2011 05:05:14 -0700 (PDT) Received: (qmail 2056 invoked by uid 89); 15 Sep 2011 12:07:19 -0000 Received: from unknown (HELO smtp3.aruba.it) (62.149.158.223) by smtplq02.aruba.it with SMTP; 15 Sep 2011 12:07:19 -0000 Received: (qmail 31719 invoked by uid 89); 15 Sep 2011 12:07:19 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.166) by smtp3.ad.aruba.it with SMTP; 15 Sep 2011 12:07:19 -0000 Date: Thu, 15 Sep 2011 14:02:48 +0200 From: Lorenzo Miniero To: =?ISO-8859-1?B?SfFha2k=?= Baz Castillo Message-ID: <20110915140248.4cc17977@lminiero-acer> In-Reply-To: References: <4E71927C.1090606@skype.net> <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com> Organization: Meetecho X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Rating: smtp3.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Cc: rtcweb@ietf.org Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 12:05:16 -0000 Il giorno Thu, 15 Sep 2011 13:52:38 +0200 I=F1aki Baz Castillo ha scritto: > 2011/9/15 Tim Panton : > > Are we saying that SDP is so impossible to parse that the only way > > to do it is with a pre-existing native library ?!? If not I think > > we can do that transformation (when needed) in JavaScript. >=20 > No, I just said that _maybe_ it wouldl be useful to provide such > parsing functions natively (given the fact that various protocol use > SDP bodies, as SIP and XMPP). >=20 > I'm fine with parsing SDP bodies in custom JavaScript code however :) >=20 I don't understand the need for it to be SDP actually: Javascript already has native and efficient ways to describe information (JSON, XML), if SDP is what everybody wants then it would be easier to just map SDP over them. L. --=20 Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From magnus.westerlund@ericsson.com Thu Sep 15 05:07: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 2368621F852E for ; Thu, 15 Sep 2011 05:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.501 X-Spam-Level: X-Spam-Status: No, score=-106.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 j0f5uWDhZDMD for ; Thu, 15 Sep 2011 05:07: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 5AA1F21F8514 for ; Thu, 15 Sep 2011 05:07:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-c5-4e71eb07b506 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id FC.DA.02839.70BE17E4; Thu, 15 Sep 2011 14:09:43 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 14:09:43 +0200 Message-ID: <4E71EB06.9010006@ericsson.com> Date: Thu, 15 Sep 2011 14:09:42 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E70C387.1070707@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 12:07:33 -0000 On 2011-09-15 05:21, Hadriel Kaplan wrote: > > I am shocked, Shocked!, to see you suggest that we disregard RFC 4585 > and SDP rules, when we have an IETF specified means of indicating > multiple profile support using RFC 5939 SDP Capability Negotiation. > ;) Yes, sometimes I do surprise myself ;-). But, I am not really arguing for disregarding RFC 4585. I definintely want all the functions of the AVPF spec. But it is clear that the "RTP/AVPF" on m= lines is the issue that people have. But on a serious note. If all the energy spent discussing CAPNEG had instead been put into implementing it. It would be universally deployed by now. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ibc@aliax.net Thu Sep 15 05:10: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 803A921F893C for ; Thu, 15 Sep 2011 05:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seM-F+M9O12i for ; Thu, 15 Sep 2011 05:10:23 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3384621F85BB for ; Thu, 15 Sep 2011 05:10:23 -0700 (PDT) Received: by qyk32 with SMTP id 32so4947712qyk.10 for ; Thu, 15 Sep 2011 05:12:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.66.144 with SMTP id n16mr409539qci.178.1316088734929; Thu, 15 Sep 2011 05:12:14 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Thu, 15 Sep 2011 05:12:14 -0700 (PDT) In-Reply-To: <20110915140248.4cc17977@lminiero-acer> References: <4E71927C.1090606@skype.net> <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com> <20110915140248.4cc17977@lminiero-acer> Date: Thu, 15 Sep 2011 14:12:14 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Lorenzo Miniero Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 12:10:24 -0000 2011/9/15 Lorenzo Miniero : > I don't understand the need for it to be SDP actually: Javascript > already has native and efficient ways to describe information (JSON, > XML), if SDP is what everybody wants then it would be easier to just > map SDP over them. Assuming that the signaling protocol is custom, my JavaScript code could receive pure SIP messages or XMPP messages, so the SDP comes in plain or XML format. I can parse it manually in my JS code (or use some native JS function to parse them if they are provided) and convert it to JSON prior to use it for WebRTC function calls. Other web application could prefer to create its own signaling protocol and carry SDP directly in JSON format, of course. Freedom for all. Best regards. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Thu Sep 15 05:16: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 5C05021F8AAC for ; Thu, 15 Sep 2011 05:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.459 X-Spam-Level: X-Spam-Status: No, score=-108.459 tagged_above=-999 required=5 tests=[AWL=2.140, 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 sDFUzH-jcH6V for ; Thu, 15 Sep 2011 05:16:13 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB3421F8AA9 for ; Thu, 15 Sep 2011 05:16:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 06AD739E0CD; Thu, 15 Sep 2011 14:18:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIdpZjUtbX+S; Thu, 15 Sep 2011 14:18:21 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 75EB639E072; Thu, 15 Sep 2011 14:18:21 +0200 (CEST) Message-ID: <4E71ED0D.7060505@alvestrand.no> Date: Thu, 15 Sep 2011 14:18:21 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Magnus Westerlund References: <4E70C387.1070707@ericsson.com> <4E710155.8080409@alvestrand.no> <4E71EA1A.5020407@ericsson.com> In-Reply-To: <4E71EA1A.5020407@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 12:16:14 -0000 On 09/15/11 14:05, Magnus Westerlund wrote: > On 2011-09-14 21:32, Harald Alvestrand wrote: >> On 09/14/11 17:08, Magnus Westerlund wrote: >>> Hi, >>> >>> There has been this long thread with the subject partially containing >>> "AVPF". I want to clarify something in this context around AVPF. Rather >>> than the SRTP question. >>> >>> An end-point that is AVPF compliant is in fact interoperable with an AVP >>> one as long as the trr-int parameter is set reasonably large. A >>> parameter value of 1.5-5 seconds (I would recommend 3s) will ensure that >>> they are in fact compatible. This avoids the risk of any side timing out >>> the other if the AVP side is using the default 5 s minimum interval. >>> >>> Based on this one could in fact have the RTCWEB nodes always use AVPF >>> for RTP/RTCP Behavior. The AVPF feedback messages are explicitly >>> negotiated and will only be used when agreed on. >>> >>> This leaves us with any signaling incompatibilities when talking to a >>> legacy device. If one don't want to use cap-neg I see two directions to go: >>> >>> 1) RTCWEB end-point will always signal AVPF or SAVPF. I signalling >>> gateway to legacy will change that by removing the F to AVP or SAVP. >>> >>> 2) RTCWEB end-point will always use AVPF but signal it as AVP. It will >>> detect the AVPF capabilities of the other end-point based on the >>> signaling of the feedback events intended to be used. >>> >>> I think 1) is cleaner for the future. 2) might be more pragmatic. >> If 2) is more pragmatic, the IETF should update the definition of AVP to >> allow use of AVPF functionality. > No, Harald that I think is a bad idea. The core of AVPF is the timing > rule. From my perspective the important aspect is that one do implement > the timing rules. Thus it is important we have the label of AVPF to > indicate these rules. But how do you "have" the label if you signal it as AVP?????? Is it a label that occurs in the spec only, and is undetectable on the wire? That's the place where you lost me. > Thus my proposal is really to say that an RTCWEB end-point SHALL > implement and always use the AVPF timing rules. It might send feedback > messages if those have been negotiated with a=rtcp-fb attribute. > >> The responses seem to indicate that in practice, this is already being >> done (and this is a clear indication that the concept of "profile" in >> RTP has failed to achieve its purpose). > It works fine on the RTP level. But the signalling aspects has clearly > been botched. > > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Frgatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > From harald@alvestrand.no Thu Sep 15 06:07: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 22B9821F8A95 for ; Thu, 15 Sep 2011 06:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.496 X-Spam-Level: X-Spam-Status: No, score=-108.496 tagged_above=-999 required=5 tests=[AWL=2.103, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8YC24rrSfg5 for ; Thu, 15 Sep 2011 06:07:23 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8429121F8A80 for ; Thu, 15 Sep 2011 06:07:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E9D4C39E0CD; Thu, 15 Sep 2011 15:09:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYqBwzRxq-Ki; Thu, 15 Sep 2011 15:09:34 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 388CF39E072; Thu, 15 Sep 2011 15:09:34 +0200 (CEST) Message-ID: <4E71F90D.8030302@alvestrand.no> Date: Thu, 15 Sep 2011 15:09:33 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Lorenzo Miniero References: <4E71927C.1090606@skype.net> <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com> <20110915140248.4cc17977@lminiero-acer> In-Reply-To: <20110915140248.4cc17977@lminiero-acer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 13:07:24 -0000 On 09/15/11 14:02, Lorenzo Miniero wrote: > Il giorno Thu, 15 Sep 2011 13:52:38 +0200 > Iaki Baz Castillo ha scritto: > >> 2011/9/15 Tim Panton: >>> Are we saying that SDP is so impossible to parse that the only way >>> to do it is with a pre-existing native library ?!? If not I think >>> we can do that transformation (when needed) in JavaScript. >> No, I just said that _maybe_ it wouldl be useful to provide such >> parsing functions natively (given the fact that various protocol use >> SDP bodies, as SIP and XMPP). >> >> I'm fine with parsing SDP bodies in custom JavaScript code however :) >> > > I don't understand the need for it to be SDP actually: Javascript > already has native and efficient ways to describe information (JSON, > XML), if SDP is what everybody wants then it would be easier to just > map SDP over them. The disadvantage of parsing to another structure (I am fond of JSON myself) is that one has to maintain a data definition for the format being parsed to, a defined transform between that and the "canonical SDP structure" has to be implemented in user space when one does SDP interoperability, both of those have to be updated for every SDP extension that someone defines somewhere, and one is still not free to define extensions on the non-SDP side if one still requires the ability to map them into SDP. If one uses the "native" SDP format, which is the format in which every extension to the format gets documented, the browsers are the ones who *have* to parse it (although others are likely to). Harald From ron.even.tlv@gmail.com Thu Sep 15 07:00: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 5822921F8A95 for ; Thu, 15 Sep 2011 07:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJxniEipW+6f for ; Thu, 15 Sep 2011 07:00:58 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6FC21F8696 for ; Thu, 15 Sep 2011 07:00:58 -0700 (PDT) Received: by yie12 with SMTP id 12so2509884yie.31 for ; Thu, 15 Sep 2011 07:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=hVP/pzBnlizyAtTeRZgkQIU46icmwY5n7Aysa569wEs=; b=bzjOp8+1u2fgsUflddvWm3ouUSC40A8sFw3ygvO+1G10hOSyvhoBSogfl/ZCLB5dp7 LCEh299JWPZits2XKLRrqUSxG6oHFc0bNPBlMRPHhKN4twSYFiLSqwg5M4+CttvVHBJB XAJfXK49GRazDf1PJk37EJRFMoDAtNZXgToyc= Received: by 10.68.25.138 with SMTP id c10mr474075pbg.459.1316095389987; Thu, 15 Sep 2011 07:03:09 -0700 (PDT) Received: from windows8d787f9 ([59.37.10.82]) by mx.google.com with ESMTPS id i8sm1768151pbl.2.2011.09.15.07.03.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 07:03:08 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , References: <4E70C387.1070707@ericsson.com> In-Reply-To: <4E70C387.1070707@ericsson.com> Date: Thu, 15 Sep 2011 17:01:44 +0300 Message-ID: <4e72059c.e829440a.4094.ffffb025@mx.google.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: Acxy8IefSwNpefInRDiRlAjJbviBHwAvLJWQ Content-Language: en-us Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 14:00:59 -0000 Magnus, I noticed that you claim that all AVPF feedback messages are explicitly negotiated, is this a requirement. At least RTCP-SR-REQ is not = negotiated in SDP. As for using AVPF while signaling AVP that will confuse endpoint that so = not understand this convention and can support AVPF. They will see an offer = with AVP but with parameters that are not part of AVP. They can respond with = AVP without the AVPF parameter and behave like AVP endpoints even though = they support AVPF. This will prevent them from sending AVPF feedback = messages. This may be a problem for what you call "legacy" video conferencing endpoint. (I do not like the term legacy here since these are not legacy endpoint but AVP/AVPF compliant EPs=20 I think that if we are not going to use cap-neg we should make it historical.=20 Roni Even > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Magnus Westerlund > Sent: Wednesday, September 14, 2011 6:09 PM > To: rtcweb@ietf.org > Subject: [rtcweb] AVPF vs AVP >=20 > Hi, >=20 > There has been this long thread with the subject partially containing > "AVPF". I want to clarify something in this context around AVPF. = Rather > than the SRTP question. >=20 > An end-point that is AVPF compliant is in fact interoperable with an > AVP > one as long as the trr-int parameter is set reasonably large. A > parameter value of 1.5-5 seconds (I would recommend 3s) will ensure > that > they are in fact compatible. This avoids the risk of any side timing > out > the other if the AVP side is using the default 5 s minimum interval. >=20 > Based on this one could in fact have the RTCWEB nodes always use AVPF > for RTP/RTCP Behavior. The AVPF feedback messages are explicitly > negotiated and will only be used when agreed on. >=20 > This leaves us with any signaling incompatibilities when talking to a > legacy device. If one don't want to use cap-neg I see two directions = to > go: >=20 > 1) RTCWEB end-point will always signal AVPF or SAVPF. I signalling > gateway to legacy will change that by removing the F to AVP or SAVP. >=20 > 2) RTCWEB end-point will always use AVPF but signal it as AVP. It will > detect the AVPF capabilities of the other end-point based on the > signaling of the feedback events intended to be used. >=20 > I think 1) is cleaner for the future. 2) might be more pragmatic. >=20 > In both cases I believe there are methods for negotiating a lower > trr-int than some AVP fallback value to preserve interoperability. >=20 >=20 > However, this still don't resolve the question if the "S" should be in > front of the RTP profile indicator or not. But it might help by > removing > the F or not in the profile. >=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 ron.even.tlv@gmail.com Thu Sep 15 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 3980221F8B19 for ; Thu, 15 Sep 2011 07:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzRA1p-ilDWc for ; Thu, 15 Sep 2011 07:05:33 -0700 (PDT) Received: from mail-gx0-f170.google.com (mail-gx0-f170.google.com [209.85.161.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7F86B21F8B17 for ; Thu, 15 Sep 2011 07:05:33 -0700 (PDT) Received: by gxk27 with SMTP id 27so4031804gxk.15 for ; Thu, 15 Sep 2011 07:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=TaiM1gBMRMYvvQZrjVmTw3Q1zLVzWUh18d2XxomvooE=; b=Xf1AxBzfPt8J6TAntEYALUNaRFg3O2kXek3/JRL66kQDL1Ze0I80pgcnwiqFeKl4+/ ub/sywxBWwsxb7TfrqkmeL6jNzR9zt3jImx4tbmIPAC4WfJoSumUeAhAOGJytHtxu2T2 Gy7JAcRADfUBui3FzkpL+nCvtUktlSdPIOJDQ= Received: by 10.68.28.199 with SMTP id d7mr631386pbh.142.1316095664960; Thu, 15 Sep 2011 07:07:44 -0700 (PDT) Received: from windows8d787f9 ([59.37.10.82]) by mx.google.com with ESMTPS id 4sm23283485pbk.5.2011.09.15.07.07.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 07:07:44 -0700 (PDT) From: "Roni Even" To: "'Harald Alvestrand'" , References: <4E70C387.1070707@ericsson.com> <4E710155.8080409@alvestrand.no> In-Reply-To: <4E710155.8080409@alvestrand.no> Date: Thu, 15 Sep 2011 17:06:21 +0300 Message-ID: <4e7206b0.4401440a.4bc3.ffff8813@mx.google.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: AcxzFRdXG+WhkHpQSYCWaGcYcsdeIgAmzUjg Content-Language: en-us Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 14:05:34 -0000 Hi, RFC4585 talks about coexistence of AVP and AVPF systems in a multicast = group in section 5. Example 3 in section 4.4 of RFC 4585 talks about signaling = but claims to be incomplete and suggests using grouping for the alternatives offers. The MMUSIC group did cap-neg for the alternatives. Roni Even > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: Wednesday, September 14, 2011 10:33 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] AVPF vs AVP >=20 > On 09/14/11 17:08, Magnus Westerlund wrote: > > Hi, > > > > There has been this long thread with the subject partially = containing > > "AVPF". I want to clarify something in this context around AVPF. > Rather > > than the SRTP question. > > > > An end-point that is AVPF compliant is in fact interoperable with an > AVP > > one as long as the trr-int parameter is set reasonably large. A > > parameter value of 1.5-5 seconds (I would recommend 3s) will ensure > that > > they are in fact compatible. This avoids the risk of any side timing > out > > the other if the AVP side is using the default 5 s minimum interval. > > > > Based on this one could in fact have the RTCWEB nodes always use = AVPF > > for RTP/RTCP Behavior. The AVPF feedback messages are explicitly > > negotiated and will only be used when agreed on. > > > > This leaves us with any signaling incompatibilities when talking to = a > > legacy device. If one don't want to use cap-neg I see two directions > to go: > > > > 1) RTCWEB end-point will always signal AVPF or SAVPF. I signalling > > gateway to legacy will change that by removing the F to AVP or SAVP. > > > > 2) RTCWEB end-point will always use AVPF but signal it as AVP. It > will > > detect the AVPF capabilities of the other end-point based on the > > signaling of the feedback events intended to be used. > > > > I think 1) is cleaner for the future. 2) might be more pragmatic. > If 2) is more pragmatic, the IETF should update the definition of AVP > to > allow use of AVPF functionality. > The responses seem to indicate that in practice, this is already being > done (and this is a clear indication that the concept of "profile" in > RTP has failed to achieve its purpose). >=20 > *shudder* > > In both cases I believe there are methods for negotiating a lower > > trr-int than some AVP fallback value to preserve interoperability. > > > > > > However, this still don't resolve the question if the "S" should be > in > > front of the RTP profile indicator or not. But it might help by > removing > > the F or not in the profile. > > > > 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 > > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From john.elwell@siemens-enterprise.com Thu Sep 15 08:25: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 1BB2F21F8AA9 for ; Thu, 15 Sep 2011 08:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.028 X-Spam-Level: X-Spam-Status: No, score=-103.028 tagged_above=-999 required=5 tests=[AWL=-0.429, 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 tc5fQ7tm2NIt for ; Thu, 15 Sep 2011 08:25:42 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 11E1121F8A7A for ; Thu, 15 Sep 2011 08:25:42 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id D36CC23F04D9; Thu, 15 Sep 2011 17:27:53 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 15 Sep 2011 17:27:53 +0200 From: "Elwell, John" To: Ravindran Parthasarathi , Hadriel Kaplan Date: Thu, 15 Sep 2011 17:27:52 +0200 Thread-Topic: [rtcweb] Proposed text - remote recording use case Thread-Index: AQHMciK7XwUojQUk70aUevXP868dwpVMX0wwgAABGYCAAjHtsA== Message-ID: References: <2E239D6FCD033C4BAF15F386A979BF510F09ED@sonusinmail02.sonusnet.com> <8357A942-21EA-4209-82DB-ADFCEB5F32EF@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF510F0B4E@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0B4E@sonusinmail02.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] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 15:25:43 -0000 Partha,=20 > -----Original Message----- > From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com]=20 > Sent: 14 September 2011 06:57 > To: Elwell, John; Hadriel Kaplan > Cc: rtcweb@ietf.org > Subject: RE: [rtcweb] Proposed text - remote recording use case >=20 > John, >=20 > I'm fine with Hadriel proposal of "remote peer" instead=20 > "remote browser > or SRS" but not the original wordings. >=20 > At this moment, I'm not convinced whether SIPREC SRS will interop with > RTCWeb browser because the signaling protocol is an open item=20 > in RTCWeb. > The recording could be done by two websocket from browser wherein one > websocket towards webserver and other towards recorder. How these > entities interact with each other has to be discussed &=20 > defined. Please > let me know the reason why this approach may not be followed=20 > in RTCWeb. [JRE] I am not saying it will not work, but I consider this to be outside s= cope of RTC-Web. John >=20 > Thanks > Partha=20 >=20 >=20 > >-----Original Message----- > >From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >Sent: Wednesday, September 14, 2011 11:21 AM > >To: Hadriel Kaplan; Ravindran Parthasarathi > >Cc: > >Subject: RE: [rtcweb] Proposed text - remote recording use case > > > > > > > >> -----Original Message----- > >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > >> Sent: 13 September 2011 15:38 > >> To: Ravindran Parthasarathi > >> Cc: Elwell, John; > >> Subject: Re: [rtcweb] Proposed text - remote recording use case > >> > >> inline... > >> > >> On Sep 11, 2011, at 4:29 PM, Ravindran Parthasarathi wrote: > >> > >> > New requirements: > >> > Fyy1: The browser MUST be able to send in real-time to an another > >> > browser/session recording server(SRS) that are being > >> transmitted to and > >> > received from remote browser. > >> > >> That doesn't make sense in English - *what* needs to be sent > >> in real-time? Removing the word "media" broke the meaning. > >> Also, the media it needs to replicate/fork may not be to/from > >> another "remote browser" - it could be to/from a remote > >> gateway, SIP UA, whatever. Really what you want to say is > >> to/from a "remote peer". > >> Same issues/comments go for the next requirement. > >[JRE] I agree the modified words don't make sense and would like to > >stick to the words I proposed at the start of this thread. > > > >> > >> > > >> > Ayy1: The web application MUST be able to ask the browser > >> to transmit in > >> > real-time to another browser/session recording=20 > server(SRS) that are > >> > being transmitted to and received from remote browser. > >> > >> Same as above. > >> > >> > As I asked in the meeting (but couldn't discuss due to time > >> constraint), > >> > it is possible for browser to do the signaling directly=20 > to the SRS > >> > without going through original webserver. The signaling towards > >> > recording is not required to be SIP but it shall be=20 > websocket (let > >> > discuss separately). Here, the advantageous in this model > >> is that the > >> > recording signaling hop is reduced to 1 hop (browser to=20 > SRS) from > 2 > >> > hops (browser to webserver, webserver to SRS). > >> > > >> > >> Actually, I don't think it is possible for the rtcweb browser > >> to properly do SIPREC, even if it had a SIP stack to do it > >> with. The reason is the browser doesn't know the full call > >> metadata. The browser doesn't know the calling/called party > >> info, for example. Even the javascript itself may not know > >> it, depending on how the application provider does their > >> logic. They could decide to have some state/logic be handled > >> by the web server, rather than all in the javascript. For > >> example the javascript may just display a list of friends > >> using aliases or icons, and the web server may be the only > >> one who knows what the friend's AoR/URI actually is for that alias. > >[JRE] Quite so. Metadata would come from the application, but whether > >this is server-side or client-side is out of scope for RTC-Web. The > >important thing is that an application that is able to do the SIP and > >Metadata part of SIPREC can ask the browser to do the media part. > > > >John > > > > > >> > >> -hadriel > >> > >> > = From harald@alvestrand.no Thu Sep 15 08:36: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 9645721F8B1B for ; Thu, 15 Sep 2011 08:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.566 X-Spam-Level: X-Spam-Status: No, score=-108.566 tagged_above=-999 required=5 tests=[AWL=2.033, 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 cKQHYWuB1gf4 for ; Thu, 15 Sep 2011 08:36:17 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 01E2F21F8B17 for ; Thu, 15 Sep 2011 08:36:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B2C4739E0CD for ; Thu, 15 Sep 2011 17:38:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84SBKa86Wwzc for ; Thu, 15 Sep 2011 17:38:28 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 5A60139E072 for ; Thu, 15 Sep 2011 17:38:28 +0200 (CEST) Message-ID: <4E721BF3.10505@alvestrand.no> Date: Thu, 15 Sep 2011 17:38:27 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F09ED@sonusinmail02.sonusnet.com> <8357A942-21EA-4209-82DB-ADFCEB5F32EF@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF510F0B4E@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0B4E@sonusinmail02.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 15:36:17 -0000 On 09/14/11 07:57, Ravindran Parthasarathi wrote: > John, > > I'm fine with Hadriel proposal of "remote peer" instead "remote browser > or SRS" but not the original wordings. > > At this moment, I'm not convinced whether SIPREC SRS will interop with > RTCWeb browser because the signaling protocol is an open item in RTCWeb. > The recording could be done by two websocket from browser wherein one > websocket towards webserver and other towards recorder. How these > entities interact with each other has to be discussed& defined. Please > let me know the reason why this approach may not be followed in RTCWeb. My opinion: If this can be built in JS using the APIs and protocols defined by RTCWEB/WEBRTC, there is no need for anything more within these groups. If it cannot be built using these APIs and protocols, we need to consider whether these APIs and protocols need to be extended in order to cover this use case. The detailed building of the application is, in my opinion, out of scope for RTCWEB. From magnus.westerlund@ericsson.com Thu Sep 15 09:03: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 4A6CD21F86EE for ; Thu, 15 Sep 2011 09:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.502 X-Spam-Level: X-Spam-Status: No, score=-106.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 IRrmHHeBBtKf for ; Thu, 15 Sep 2011 09:03:53 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 79F6021F8AFB for ; Thu, 15 Sep 2011 09:03:53 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-cf-4e72226b9d57 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DC.5D.02839.B62227E4; Thu, 15 Sep 2011 18:06:04 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 15 Sep 2011 18:06:03 +0200 Message-ID: <4E722269.30304@ericsson.com> Date: Thu, 15 Sep 2011 18:06:01 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Roni Even References: <4E70C387.1070707@ericsson.com> <4e72059c.e829440a.4094.ffffb025@mx.google.com> In-Reply-To: <4e72059c.e829440a.4094.ffffb025@mx.google.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 16:03:54 -0000 On 2011-09-15 16:01, Roni Even wrote: > Magnus, > I noticed that you claim that all AVPF feedback messages are explicitly > negotiated, is this a requirement. At least RTCP-SR-REQ is not negotiated in > SDP. You are correct, had not actually noticed that. Fortunately that isn't an real issue. First of all the support of AVPF can still be negotiated with the a=rtcp-fb. Simply the trr-int configuration lets both side show support of AVPF. Secondly, for the RTCP-SR-REQ if one uses the header extension to deliver the synch data then that is explicitly indicated. And if you ignore or don't understand the request then you simple fall back to normal synchronization procedures with more delay before completing it. > > As for using AVPF while signaling AVP that will confuse endpoint that so not > understand this convention and can support AVPF. They will see an offer with > AVP but with parameters that are not part of AVP. They can respond with AVP > without the AVPF parameter and behave like AVP endpoints even though they > support AVPF. This will prevent them from sending AVPF feedback messages. They can still use AVPF timing rules, even if the other end-point is AVP only. They only need to restrict themselves from sending feedback messages. > This may be a problem for what you call "legacy" video conferencing > endpoint. (I do not like the term legacy here since these are not legacy > endpoint but AVP/AVPF compliant EPs Yes, I agree it is not without issues in that regard. I would also like to note that if you require AVPF and don't think talking to AVP only end-points then one really should include the AVPF in the m= line to prevent fallback. > > I think that if we are not going to use cap-neg we should make it > historical. I kind of agree with that also. But if it constantly fails in the market I think we have to recognize that and do something else that works better. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From roman@telurix.com Thu Sep 15 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 AB7C911E8073 for ; Thu, 15 Sep 2011 10:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.735 X-Spam-Level: X-Spam-Status: No, score=-2.735 tagged_above=-999 required=5 tests=[AWL=0.241, 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 Z4tUCR1OVCKm for ; Thu, 15 Sep 2011 10:31:54 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 594CC21F8B65 for ; Thu, 15 Sep 2011 10:31:53 -0700 (PDT) Received: by gxk9 with SMTP id 9so3312836gxk.40 for ; Thu, 15 Sep 2011 10:34:06 -0700 (PDT) Received: by 10.68.118.229 with SMTP id kp5mr1005922pbb.303.1316108045758; Thu, 15 Sep 2011 10:34:05 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx.google.com with ESMTPS id p7sm24763060pbe.0.2011.09.15.10.34.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 10:34:03 -0700 (PDT) Received: by pzk33 with SMTP id 33so1582806pzk.18 for ; Thu, 15 Sep 2011 10:34:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.39.229 with SMTP id s5mr2283054pbk.107.1316108041757; Thu, 15 Sep 2011 10:34:01 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Thu, 15 Sep 2011 10:34:01 -0700 (PDT) In-Reply-To: <6F469757-6B5C-4DC9-BC34-026F34C7E508@phonefromhere.com> References: <6F469757-6B5C-4DC9-BC34-026F34C7E508@phonefromhere.com> Date: Thu, 15 Sep 2011 13:34:01 -0400 Message-ID: From: Roman Shpount To: Tim Panton Content-Type: multipart/alternative; boundary=bcaec520f3fb50a5bd04acfe4870 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Thu, 15 Sep 2011 17:31:55 -0000 --bcaec520f3fb50a5bd04acfe4870 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The only potential problem with mobile applications and javascript based signaling code is the effect of maintaining registrations for long periods of time while waiting for a call on battery life and network utilization. A regular SIP library can be designed is such a way that the device will go into sleep mode and will wake up when a SIP packet is received. JavaScript will need to open a connection to a server and send ping messages at regular, fairly short, intervals, that will cause device to wake up every time ping message needs to be sent and to consume both power and network capacity. Such applications, running for the long periods of time can seriously decrease battery lifetime. On the other hand, doing this during a= n active call has a negligible effect on both power consumption or network utilization, since device is already running and sending media. _____________ Roman Shpount On Thu, Sep 15, 2011 at 6:02 AM, Tim Panton wrote: > > On 13 Sep 2011, at 21:50, Jos=E9 Luis Mill=E1n wrote: > > On Tue, Sep 13, 2011 at 9:25 PM, wrote: > > Hi Inaki, > > > > Fully agree about everything you say below. > > Hi, > > Sorry if this mail arrives out of the original mail thread. > > > > > It would be interesting to understand the performance differences of th= e > native vs. Javascript SIP stack, if there is anything we should be worrie= d > about. This is my only concern when (perhaps one day) applying RTCWeb in > devices like smartphones. If the JS stack works in (any of) today's high = end > smartphones without problems, we should be fine. > > The are no meaningful performance penalties at all using the JavaScript S= IP > stack in our prototype. In fact, multiple SIP stack instances can run in = a > single Web browser freshly. BTW, is there any WebSocket capable web brow= ser > for smartphones? > > > As an additional datapoint, The Phono.com javascript XMPP stack performs > fine on android and iOS within a Phonegap app. > Native browser javascript engines tend to be slightly better optimized th= an > the ones available to mobile apps, > so I doubt that performance would be an issue. > > Tim. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --bcaec520f3fb50a5bd04acfe4870 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The only potential problem with mobile applications and javascript based si= gnaling code is the effect of maintaining registrations for long periods of= time while waiting for a call on battery life and network utilization. A r= egular SIP library can be designed is such a way that the device will go in= to sleep mode and will wake up when a SIP packet is received. JavaScript wi= ll need to open a connection to a server and send ping messages at regular,= fairly short, intervals, that will cause device to wake up every time ping= message needs to be sent and to consume both power and network capacity. S= uch applications, running for the long periods of time can seriously decrea= se battery lifetime. On the other hand, doing this during an active call ha= s a negligible effect on both power consumption or network utilization, sin= ce device is already running and sending media.
_____________
Roman Shpount


On Thu, Sep 15, 2011 at 6:02 AM, Tim Pan= ton <tim@phon= efromhere.com> wrote:

On 13 Sep 2011, at 21:50,= Jos=E9 Luis Mill=E1n wrote:

On Tue= , Sep 13, 2011 at 9:25 PM, =A0<Markus.Isomaki@nokia.com> wrote:
> Hi Inaki,
>
> Fully agree about everyth= ing you say below.

Hi,

Sorry if this mail arrives= out of the original mail thread.

>
&= gt; It would be interesting to understand the performance differences of th= e native vs. Javascript SIP stack, if there is anything we should be worrie= d about. This is my only concern when (perhaps one day) applying RTCWeb in = devices like smartphones. If the JS stack works in (any of) today's hig= h end smartphones without problems, we should be fine.

The are no meaningful performance penalties at all usin= g the JavaScript SIP stack in our prototype. In fact, multiple SIP stack in= stances can run in a single Web browser freshly. =A0BTW, is there any WebSo= cket capable web browser for smartphones?

As an additional datapoint, The=A0Phono.com=A0javascript XMPP stack pe= rforms fine on android and iOS within a Phonegap app.
Native browser jav= ascript engines tend to be slightly better optimized than the ones availabl= e to mobile apps,
so I doubt that performance would be an issue.
<= br>Tim.


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


--bcaec520f3fb50a5bd04acfe4870-- From randell-ietf@jesup.org Thu Sep 15 10: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 D97A211E807F for ; Thu, 15 Sep 2011 10:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qZzLy7RUs7f for ; Thu, 15 Sep 2011 10:37:18 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 66FB211E8073 for ; Thu, 15 Sep 2011 10:37:18 -0700 (PDT) Received: from [216.1.177.180] (helo=[172.16.169.201]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R4FuM-0004fl-1p for rtcweb@ietf.org; Thu, 15 Sep 2011 12:39:30 -0500 Message-ID: <4E72384F.3080202@jesup.org> Date: Thu, 15 Sep 2011 10:39:27 -0700 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <6F469757-6B5C-4DC9-BC34-026F34C7E508@phonefromhere.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] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Thu, 15 Sep 2011 17:37:19 -0000 On 9/15/2011 10:34 AM, Roman Shpount wrote: > The only potential problem with mobile applications and javascript > based signaling code is the effect of maintaining registrations for > long periods of time while waiting for a call on battery life and > network utilization. A regular SIP library can be designed is such a > way that the device will go into sleep mode and will wake up when a > SIP packet is received. JavaScript will need to open a connection to a > server and send ping messages at regular, fairly short, intervals, > that will cause device to wake up every time ping message needs to be > sent and to consume both power and network capacity. Such > applications, running for the long periods of time can seriously > decrease battery lifetime. On the other hand, doing this during an > active call has a negligible effect on both power consumption or > network utilization, since device is already running and sending media. +1 Any suggested solutions, other than "require (native) SIP"? (Since SIP-in-JS would I assume fall into the case above.) -- Randell Jesup randell-ietf@jesup.org From roman@telurix.com Thu Sep 15 10: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 26B4B21F8AF5 for ; Thu, 15 Sep 2011 10:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nB7xrm5ubTKi for ; Thu, 15 Sep 2011 10:50:07 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3359C21F8A57 for ; Thu, 15 Sep 2011 10:50:07 -0700 (PDT) Received: by gwb17 with SMTP id 17so3259532gwb.15 for ; Thu, 15 Sep 2011 10:52:19 -0700 (PDT) Received: by 10.150.210.16 with SMTP id i16mr1534294ybg.137.1316109139305; Thu, 15 Sep 2011 10:52:19 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id m4sm16853437ang.4.2011.09.15.10.52.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 10:52:18 -0700 (PDT) Received: by ywa6 with SMTP id 6so2727332ywa.31 for ; Thu, 15 Sep 2011 10:52:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.24.135 with SMTP id u7mr2435020pbf.442.1316109137673; Thu, 15 Sep 2011 10:52:17 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Thu, 15 Sep 2011 10:52:17 -0700 (PDT) In-Reply-To: <4E72384F.3080202@jesup.org> References: <6F469757-6B5C-4DC9-BC34-026F34C7E508@phonefromhere.com> <4E72384F.3080202@jesup.org> Date: Thu, 15 Sep 2011 13:52:17 -0400 Message-ID: From: Roman Shpount To: Randell Jesup Content-Type: multipart/alternative; boundary=bcaec520e493a2feb204acfe8905 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Thu, 15 Sep 2011 17:50:08 -0000 --bcaec520e493a2feb204acfe8905 Content-Type: text/plain; charset=ISO-8859-1 I don't think this is a problem for RTC web to resolve. This is the same problem that someone building an IM or email client for a web browser will need to deal with. Some type of push notification framework is needed to implement this and it might be something for W3C to standardize as a solution for this problem. _____________ Roman Shpount On Thu, Sep 15, 2011 at 1:39 PM, Randell Jesup wrote: > On 9/15/2011 10:34 AM, Roman Shpount wrote: > >> The only potential problem with mobile applications and javascript based >> signaling code is the effect of maintaining registrations for long periods >> of time while waiting for a call on battery life and network utilization. A >> regular SIP library can be designed is such a way that the device will go >> into sleep mode and will wake up when a SIP packet is received. JavaScript >> will need to open a connection to a server and send ping messages at >> regular, fairly short, intervals, that will cause device to wake up every >> time ping message needs to be sent and to consume both power and network >> capacity. Such applications, running for the long periods of time can >> seriously decrease battery lifetime. On the other hand, doing this during an >> active call has a negligible effect on both power consumption or network >> utilization, since device is already running and sending media. >> > > +1 > > Any suggested solutions, other than "require (native) SIP"? (Since > SIP-in-JS would I assume fall into the case above.) > > -- > Randell Jesup > randell-ietf@jesup.org > > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --bcaec520e493a2feb204acfe8905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't think this is a problem for RTC web to resolve. This is the sam= e problem that someone building an IM or email client for a web browser wil= l need to deal with. Some type of push notification framework is needed to = implement this and it might be something for W3C to standardize as a soluti= on for this problem.
_____________
Roman Shpount


On Thu, Sep 15, 2011 at 1:39 PM, Randell= Jesup <rand= ell-ietf@jesup.org> wrote:
On 9/15/2011 10:34 AM, Roman Shpount wrote:
The only potential problem with mobile applications and javascript based si= gnaling code is the effect of maintaining registrations for long periods of= time while waiting for a call on battery life and network utilization. A r= egular SIP library can be designed is such a way that the device will go in= to sleep mode and will wake up when a SIP packet is received. JavaScript wi= ll need to open a connection to a server and send ping messages at regular,= fairly short, intervals, that will cause device to wake up every time ping= message needs to be sent and to consume both power and network capacity. S= uch applications, running for the long periods of time can seriously decrea= se battery lifetime. On the other hand, doing this during an active call ha= s a negligible effect on both power consumption or network utilization, sin= ce device is already running and sending media.

+1

Any suggested solutions, other than "require (native) SIP"? =A0 (= Since SIP-in-JS would I assume fall into the case above.)

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


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

--bcaec520e493a2feb204acfe8905-- From Markus.Isomaki@nokia.com Thu Sep 15 11:47: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 6569A21F8AFE for ; Thu, 15 Sep 2011 11:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 f9O47HCdY+eq for ; Thu, 15 Sep 2011 11:46:59 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAA121F8AFD for ; Thu, 15 Sep 2011 11:46:58 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8FIn9oN004902; Thu, 15 Sep 2011 21:49:09 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Sep 2011 21:49:04 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 15 Sep 2011 20:49:03 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.204]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0323.007; Thu, 15 Sep 2011 20:49:03 +0200 From: To: , Thread-Topic: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP) Thread-Index: AQHMclbXOUIKXflnkES/7qO+qcO8OJVOFtUAgAB+RoCAADJxMA== Date: Thu, 15 Sep 2011 18:49:02 +0000 Message-ID: References: <6F469757-6B5C-4DC9-BC34-026F34C7E508@phonefromhere.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 15 Sep 2011 18:49:04.0387 (UTC) FILETIME=[242B9D30:01CC73D8] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Thu, 15 Sep 2011 18:47:01 -0000 Hi, This is an important point. But why do you think it is necessary for a Java= script based implementation, using HTTP or websockets, to send keepalives m= ore often than a regular SIP UA would? If both are running on TCP, the NAT = and firewall and such timers will be the same for both, and this gives an u= pper bound to the keepalive interval. (SIP over UDP is out of the question = due to too short timers.) RTCWeb HTTP or websocket servers should be designed so that they do not req= uire some kind of hearbeat or pingpong or keepalive too often by themselves= , and especially they should not interfere but let the clients do them.=20 The trend has been that a lot of asynchronous communication is nowadays agr= egated to apps via some kind of "notification service" (several companies r= un them), so that not all apps need to do keepalives by themselves. It woul= d be useful if the browser/web environment could also make use of these ser= vices. Unfortunately they are all proprietary and bound to a particular OS = or vendor. Markus From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= ext Roman Shpount Sent: 15 September, 2011 20:34 To: Tim Panton Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport= for Session Initiation Protocol (SIP) The only potential problem with mobile applications and javascript based si= gnaling code is the effect of maintaining registrations for long periods of= time while waiting for a call on battery life and network utilization. A r= egular SIP library can be designed is such a way that the device will go in= to sleep mode and will wake up when a SIP packet is received. JavaScript wi= ll need to open a connection to a server and send ping messages at regular,= fairly short, intervals, that will cause device to wake up every time ping= message needs to be sent and to consume both power and network capacity. S= uch applications, running for the long periods of time can seriously decrea= se battery lifetime. On the other hand, doing this during an active call ha= s a negligible effect on both power consumption or network utilization, sin= ce device is already running and sending media.=20 _____________ Roman Shpount On Thu, Sep 15, 2011 at 6:02 AM, Tim Panton wrote: On 13 Sep 2011, at 21:50, Jos=E9 Luis Mill=E1n wrote: On Tue, Sep 13, 2011 at 9:25 PM, =A0 wrote: > Hi Inaki, > > Fully agree about everything you say below. Hi, Sorry if this mail arrives out of the original mail thread. > > It would be interesting to understand the performance differences of the = native vs. Javascript SIP stack, if there is anything we should be worried = about. This is my only concern when (perhaps one day) applying RTCWeb in de= vices like smartphones. If the JS stack works in (any of) today's high end = smartphones without problems, we should be fine. The are no meaningful performance penalties at all using the JavaScript SIP= stack in our prototype. In fact, multiple SIP stack instances can run in a= single Web browser freshly. =A0BTW, is there any WebSocket capable web bro= wser for smartphones? As an additional datapoint, The=A0Phono.com=A0javascript XMPP stack perform= s fine on android and iOS within a Phonegap app. Native browser javascript engines tend to be slightly better optimized than= the ones available to mobile apps, so I doubt that performance would be an issue. Tim. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From roman@telurix.com Thu Sep 15 11:55: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 57ABE11E80B5 for ; Thu, 15 Sep 2011 11:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=0.266, 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 YEv70HGJZ+gM for ; Thu, 15 Sep 2011 11:54:59 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 40E7E11E80A5 for ; Thu, 15 Sep 2011 11:54:59 -0700 (PDT) Received: by gxk9 with SMTP id 9so3403733gxk.40 for ; Thu, 15 Sep 2011 11:57:11 -0700 (PDT) Received: by 10.68.62.105 with SMTP id x9mr423963pbr.287.1316113030439; Thu, 15 Sep 2011 11:57:10 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx.google.com with ESMTPS id i8sm3813631pbl.2.2011.09.15.11.57.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 11:57:09 -0700 (PDT) Received: by pzk33 with SMTP id 33so1697609pzk.18 for ; Thu, 15 Sep 2011 11:57:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.29.66 with SMTP id i2mr445719pbh.375.1316113028911; Thu, 15 Sep 2011 11:57:08 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Thu, 15 Sep 2011 11:57:08 -0700 (PDT) In-Reply-To: References: <6F469757-6B5C-4DC9-BC34-026F34C7E508@phonefromhere.com> Date: Thu, 15 Sep 2011 14:57:08 -0400 Message-ID: From: Roman Shpount To: Markus.Isomaki@nokia.com Content-Type: multipart/alternative; boundary=bcaec520e88b92909004acff7191 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Thu, 15 Sep 2011 18:55:01 -0000 --bcaec520e88b92909004acff7191 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Actually SIP over UDP is what is typically used for mobile apps now. If you are doing SIP from the public IP, you do not need to maintain the connectio= n even if TCP/TLS is used. If SIP over TCP/TLS from behind NAT is used, there are no benefits of using SIP over a long poll HTTP connection or websockets= . Btw, sometime with SIP a combination technique is used, where a notificatio= n is pushed to a SIP client using a mobile service specific push mechanism, SIP client processes this notification, re-registers, and that connection i= s used to place a call. Something similar can be used for a web app, but such implementation would be specific to each mobile platform. _____________ Roman Shpount On Thu, Sep 15, 2011 at 2:49 PM, wrote: > Hi, > > This is an important point. But why do you think it is necessary for a > Javascript based implementation, using HTTP or websockets, to send > keepalives more often than a regular SIP UA would? If both are running on > TCP, the NAT and firewall and such timers will be the same for both, and > this gives an upper bound to the keepalive interval. (SIP over UDP is out= of > the question due to too short timers.) > > RTCWeb HTTP or websocket servers should be designed so that they do not > require some kind of hearbeat or pingpong or keepalive too often by > themselves, and especially they should not interfere but let the clients = do > them. > > The trend has been that a lot of asynchronous communication is nowadays > agregated to apps via some kind of "notification service" (several compan= ies > run them), so that not all apps need to do keepalives by themselves. It > would be useful if the browser/web environment could also make use of the= se > services. Unfortunately they are all proprietary and bound to a particula= r > OS or vendor. > > Markus > > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > Of ext Roman Shpount > Sent: 15 September, 2011 20:34 > To: Tim Panton > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transpo= rt > for Session Initiation Protocol (SIP) > > The only potential problem with mobile applications and javascript based > signaling code is the effect of maintaining registrations for long period= s > of time while waiting for a call on battery life and network utilization.= A > regular SIP library can be designed is such a way that the device will go > into sleep mode and will wake up when a SIP packet is received. JavaScrip= t > will need to open a connection to a server and send ping messages at > regular, fairly short, intervals, that will cause device to wake up every > time ping message needs to be sent and to consume both power and network > capacity. Such applications, running for the long periods of time can > seriously decrease battery lifetime. On the other hand, doing this during= an > active call has a negligible effect on both power consumption or network > utilization, since device is already running and sending media. > _____________ > Roman Shpount > > On Thu, Sep 15, 2011 at 6:02 AM, Tim Panton wrote= : > > On 13 Sep 2011, at 21:50, Jos=E9 Luis Mill=E1n wrote: > > > On Tue, Sep 13, 2011 at 9:25 PM, wrote: > > Hi Inaki, > > > > Fully agree about everything you say below. > > Hi, > > Sorry if this mail arrives out of the original mail thread. > > > > > It would be interesting to understand the performance differences of th= e > native vs. Javascript SIP stack, if there is anything we should be worrie= d > about. This is my only concern when (perhaps one day) applying RTCWeb in > devices like smartphones. If the JS stack works in (any of) today's high = end > smartphones without problems, we should be fine. > > The are no meaningful performance penalties at all using the JavaScript S= IP > stack in our prototype. In fact, multiple SIP stack instances can run in = a > single Web browser freshly. BTW, is there any WebSocket capable web brow= ser > for smartphones? > > As an additional datapoint, The Phono.com javascript XMPP stack performs > fine on android and iOS within a Phonegap app. > Native browser javascript engines tend to be slightly better optimized th= an > the ones available to mobile apps, > so I doubt that performance would be an issue. > > Tim. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --bcaec520e88b92909004acff7191 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Actually SIP over UDP is what is typically used for mobile apps now. If you= are doing SIP from the public IP, you do not need to maintain the connecti= on even if TCP/TLS is used. If SIP over TCP/TLS from behind NAT is used, th= ere are no benefits of using SIP over a long poll HTTP connection or websoc= kets. Btw, sometime with SIP a combination technique is used, where a notif= ication is pushed to a SIP client using a mobile service specific push mech= anism, SIP client processes this notification, re-registers, and that conne= ction is used to place a call. Something similar can be used for a web app,= but such implementation would be specific to each mobile platform.
_____________
Roman Shpount


On Thu, Sep 15, 2011 at 2:49 PM, <Markus.Isomaki@= nokia.com> wrote:
Hi,

This is an important point. But why do you think it is necessary for a Java= script based implementation, using HTTP or websockets, to send keepalives m= ore often than a regular SIP UA would? If both are running on TCP, the NAT = and firewall and such timers will be the same for both, and this gives an u= pper bound to the keepalive interval. (SIP over UDP is out of the question = due to too short timers.)

RTCWeb HTTP or websocket servers should be designed so that they do not req= uire some kind of hearbeat or pingpong or keepalive too often by themselves= , and especially they should not interfere but let the clients do them.

The trend has been that a lot of asynchronous communication is nowadays agr= egated to apps via some kind of "notification service" (several c= ompanies run them), so that not all apps need to do keepalives by themselve= s. It would be useful if the browser/web environment could also make use of= these services. Unfortunately they are all proprietary and bound to a part= icular OS or vendor.

Markus


From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.or= g] On Behalf Of ext Roman Shpount
Sent: 15 September, 2011 20:34
To: Tim Panton
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport= for Session Initiation Protocol (SIP)

The only potential problem with mobile applications and javascript based si= gnaling code is the effect of maintaining registrations for long periods of= time while waiting for a call on battery life and network utilization. A r= egular SIP library can be designed is such a way that the device will go in= to sleep mode and will wake up when a SIP packet is received. JavaScript wi= ll need to open a connection to a server and send ping messages at regular,= fairly short, intervals, that will cause device to wake up every time ping= message needs to be sent and to consume both power and network capacity. S= uch applications, running for the long periods of time can seriously decrea= se battery lifetime. On the other hand, doing this during an active call ha= s a negligible effect on both power consumption or network utilization, sin= ce device is already running and sending media.
_____________
Roman Shpount

On Thu, Sep 15, 2011 at 6:02 AM, Tim Panton <tim@phonefromhere.com> wrote:

On 13 Sep 2011, at 21:50, Jos=E9 Luis Mill=E1n wrote:


On Tue, Sep 13, 2011 at 9:25 PM, =A0<Markus.Isomaki@nokia.com> wrote:
> Hi Inaki,
>
> Fully agree about everything you say below.

Hi,

Sorry if this mail arrives out of the original mail thread.

>
> It would be interesting to understand the performance differences of t= he native vs. Javascript SIP stack, if there is anything we should be worri= ed about. This is my only concern when (perhaps one day) applying RTCWeb in= devices like smartphones. If the JS stack works in (any of) today's hi= gh end smartphones without problems, we should be fine.

The are no meaningful performance penalties at all using the JavaScript SIP= stack in our prototype. In fact, multiple SIP stack instances can run in a= single Web browser freshly. =A0BTW, is there any WebSocket capable web bro= wser for smartphones?

As an additional datapoint, The=A0Phono.com=A0javascript XMPP stack perform= s fine on android and iOS within a Phonegap app.
Native browser javascript engines tend to be slightly better optimized than= the ones available to mobile apps,
so I doubt that performance would be an issue.

Tim.


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


--bcaec520e88b92909004acff7191-- From igor.faynberg@alcatel-lucent.com Thu Sep 15 12:04: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 69C5411E80C2 for ; Thu, 15 Sep 2011 12:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 uyUR3VlvyMTG for ; Thu, 15 Sep 2011 12:04:31 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D359F11E80BF for ; Thu, 15 Sep 2011 12:04:30 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p8FJ6eVH024153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 15 Sep 2011 14:06:40 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8FJ6e7X022335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Sep 2011 14:06:40 -0500 Received: from [135.222.134.166] (USMUYN0L055118.mh.lucent.com [135.222.134.166]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p8FJ6dxF006867; Thu, 15 Sep 2011 14:06:40 -0500 (CDT) Message-ID: <4E724CBF.8030201@alcatel-lucent.com> Date: Thu, 15 Sep 2011 15:06:39 -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: <6F469757-6B5C-4DC9-BC34-026F34C7E508@phonefromhere.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 19:04:31 -0000 With that, I think it would be best to leave the timers configurable, with an agreed default, of course. (I would imagine that sooner or later there will be an application that may demand faster heartbeat.) Igor On 9/15/2011 2:49 PM, Markus.Isomaki@nokia.com wrote: > ... > RTCWeb HTTP or websocket servers should be designed so that they do not require some kind of hearbeat or pingpong or keepalive too often by themselves, and especially they should not interfere but let the clients do them. > > ... > > . From dzonatas@gmail.com Thu Sep 15 12:05: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 99D4E11E80C2 for ; Thu, 15 Sep 2011 12:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.871 X-Spam-Level: X-Spam-Status: No, score=-3.871 tagged_above=-999 required=5 tests=[AWL=-0.272, 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 KKtdGKkNykYg for ; Thu, 15 Sep 2011 12:05:46 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A1B9E11E80BF for ; Thu, 15 Sep 2011 12:05:46 -0700 (PDT) Received: by iaby26 with SMTP id y26so1795780iab.31 for ; Thu, 15 Sep 2011 12:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Oc2jyRXQJcJrYywfeaAcUyRe1gHBTqVDpnlwWb50ems=; b=hHD9qjbEVjAzO695dd2KI7F8pgze8KoUzC2ti7UGEqxsSPqbSsoQxK7z5c2Sa6w9FM +uuKanfKLie0f0SWmoHNG9gQ6cJf+L4w9iUqlIrHJ9OJvKh/7RzsaSgBEnAQK0T2nqOb PVCJnyr95mhoFHUPcGZ9hA+kpC4Qxu3fLbAH0= Received: by 10.231.65.139 with SMTP id j11mr2422436ibi.33.1316113678985; Thu, 15 Sep 2011 12:07:58 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id a11sm5894996ibg.3.2011.09.15.12.07.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 12:07:56 -0700 (PDT) Message-ID: <4E724D8D.7020603@gmail.com> Date: Thu, 15 Sep 2011 12:10:05 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <6F469757-6B5C-4DC9-BC34-026F34C7E508@phonefromhere.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Thu, 15 Sep 2011 19:05:47 -0000 On 09/15/2011 11:49 AM, Markus.Isomaki@nokia.com wrote: > Hi, > > This is an important point. But why do you think it is necessary for a Javascript based implementation, using HTTP or websockets, to send keepalives more often than a regular SIP UA would? If both are running on TCP, the NAT and firewall and such timers will be the same for both, and this gives an upper bound to the keepalive interval. (SIP over UDP is out of the question due to too short timers.) > > RTCWeb HTTP or websocket servers should be designed so that they do not require some kind of hearbeat or pingpong or keepalive too often by themselves, and especially they should not interfere but let the clients do them. > In crowds of more than 10,000 people all with "mobiles" the heart-beat signal/server is liken to QoS for proximal optimization for them. They have the option to tune-out and still have expected bandwidth which is known to get worse without QoS in such scenarios. With "50mi wi-fi" out now, this is now liken to the clock towers at universities and not just some reminder of the Olympic bandwidth requirements. We can think of that as basic federation before we evolve security states; also, that help clear-up the situation of a stateful transfer between get-opts and SCTP such that schema moves up on the lexical stack. I see why Bruce Perens wants "The Covenant" now. > The trend has been that a lot of asynchronous communication is nowadays agregated to apps via some kind of "notification service" (several companies run them), so that not all apps need to do keepalives by themselves. It would be useful if the browser/web environment could also make use of these services. Unfortunately they are all proprietary and bound to a particular OS or vendor. > > Markus > > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of ext Roman Shpount > Sent: 15 September, 2011 20:34 > To: Tim Panton > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP) > > The only potential problem with mobile applications and javascript based signaling code is the effect of maintaining registrations for long periods of time while waiting for a call on battery life and network utilization. A regular SIP library can be designed is such a way that the device will go into sleep mode and will wake up when a SIP packet is received. JavaScript will need to open a connection to a server and send ping messages at regular, fairly short, intervals, that will cause device to wake up every time ping message needs to be sent and to consume both power and network capacity. Such applications, running for the long periods of time can seriously decrease battery lifetime. On the other hand, doing this during an active call has a negligible effect on both power consumption or network utilization, since device is already running and sending media. > _____________ > Roman Shpount > > On Thu, Sep 15, 2011 at 6:02 AM, Tim Panton wrote: > > On 13 Sep 2011, at 21:50, Jos� Luis Mill�n wrote: > > > On Tue, Sep 13, 2011 at 9:25 PM, � wrote: > >> Hi Inaki, >> >> Fully agree about everything you say below. >> > Hi, > > Sorry if this mail arrives out of the original mail thread. > > >> It would be interesting to understand the performance differences of the native vs. Javascript SIP stack, if there is anything we should be worried about. This is my only concern when (perhaps one day) applying RTCWeb in devices like smartphones. If the JS stack works in (any of) today's high end smartphones without problems, we should be fine. >> > The are no meaningful performance penalties at all using the JavaScript SIP stack in our prototype. In fact, multiple SIP stack instances can run in a single Web browser freshly. �BTW, is there any WebSocket capable web browser for smartphones? > > As an additional datapoint, The�Phono.com�javascript XMPP stack performs fine on android and iOS within a Phonegap app. > Native browser javascript engines tend to be slightly better optimized than the ones available to mobile apps, > so I doubt that performance would be an issue. > > Tim. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- --- The wheel. From randell-ietf@jesup.org Thu Sep 15 12:10: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 885CE21F8B50 for ; Thu, 15 Sep 2011 12:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWvWvjUglKEl for ; Thu, 15 Sep 2011 12:10:33 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 6643521F8B33 for ; Thu, 15 Sep 2011 12:10:31 -0700 (PDT) Received: from [216.1.177.180] (helo=[172.16.169.201]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R4HMV-00020l-M0 for rtcweb@ietf.org; Thu, 15 Sep 2011 14:12:40 -0500 Message-ID: <4E724E25.1000204@jesup.org> Date: Thu, 15 Sep 2011 12:12:37 -0700 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <6F469757-6B5C-4DC9-BC34-026F34C7E508@phonefromhere.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] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Thu, 15 Sep 2011 19:10:33 -0000 On 9/15/2011 11:57 AM, Roman Shpount wrote: > Actually SIP over UDP is what is typically used for mobile apps now. > If you are doing SIP from the public IP, you do not need to maintain > the connection even if TCP/TLS is used. Markus had a point: SIP over UDP requires keepalives if it's behind a NAT as well. So maybe it's not such a big difference, depending on the keepalive rates needed (and for UDP circa 30 sec is typical). -- Randell Jesup randell-ietf@jesup.org From Markus.Isomaki@nokia.com Thu Sep 15 12:22: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 7DB6721F8BFE for ; Thu, 15 Sep 2011 12:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 XAz0PLals10T for ; Thu, 15 Sep 2011 12:22:49 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id C6B0921F8BF9 for ; Thu, 15 Sep 2011 12:22:48 -0700 (PDT) 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.3) with ESMTP id p8FJOxEq008175; Thu, 15 Sep 2011 22:25:00 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Sep 2011 22:24:55 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 15 Sep 2011 21:24:54 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.204]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0323.007; Thu, 15 Sep 2011 21:24:53 +0200 From: To: , Thread-Topic: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP) Thread-Index: AQHMclbXOUIKXflnkES/7qO+qcO8OJVOFtUAgAB+RoCAADJxMP//5MgAgAAEU4CAACIG8A== Date: Thu, 15 Sep 2011 19:24:53 +0000 Message-ID: References: <6F469757-6B5C-4DC9-BC34-026F34C7E508@phonefromhere.com> <4E724E25.1000204@jesup.org> In-Reply-To: <4E724E25.1000204@jesup.org> 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: 15 Sep 2011 19:24:55.0110 (UTC) FILETIME=[2619E660:01CC73DD] X-Nokia-AV: Clean Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Thu, 15 Sep 2011 19:22:49 -0000 SIP over UDP is used by mobile operators themselves, as they are in control= of the access infrastructure, and can make special provisions for their ow= n services. But if you try to run SIP over UDP over mobile networks to any = independent ("OTT") Internet service, it is likely to not work that well, d= ue to battery consumption. Even with public addresses, in many mobile netwo= rks firewalls drop UDP flow state after 30 seconds. TCP usually survives longer, in most networks actually more than 15 minutes= . Unfortunately a small percentage of networks breaks even TCP in less than= 5 minutes. (Several companies, including Nokia, have concrete stats from a= ll over the globe.) So all in all I'm not sure that HTTP or websockets are in a worse position = than pure SIP. The main differences are that the Javascript app may not hav= e access to some helpers the more native mobile platform may offer. Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of ext Randell Jesup >Sent: 15 September, 2011 22:13 >To: rtcweb@ietf.org >Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transpor= t >for Session Initiation Protocol (SIP) > >On 9/15/2011 11:57 AM, Roman Shpount wrote: >> Actually SIP over UDP is what is typically used for mobile apps now. >> If you are doing SIP from the public IP, you do not need to maintain >> the connection even if TCP/TLS is used. > >Markus had a point: SIP over UDP requires keepalives if it's behind a NAT = as >well. So maybe it's not such a big difference, depending on the keepalive >rates needed (and for UDP circa 30 sec is typical). > >-- >Randell Jesup >randell-ietf@jesup.org > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From dzonatas@gmail.com Thu Sep 15 12:44: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 E55DC21F8BAC for ; Thu, 15 Sep 2011 12:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[AWL=-0.268, 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 2oqdZ76JRiUt for ; Thu, 15 Sep 2011 12:44:48 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB6C21F8B53 for ; Thu, 15 Sep 2011 12:44:48 -0700 (PDT) Received: by iaby26 with SMTP id y26so1830398iab.31 for ; Thu, 15 Sep 2011 12:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=RUp6JQThUUe2dQv4pJcJR5DrrgmQFOew3Q0DCGqXnw0=; b=BTdFROyYQ2voRxKUSGkKYbci2QmTjxiya/7eMUsTJlsGHvGv102W3xXAObXdb7zfF4 4xYVdg1Nbmz8hxFWsldpMFjVpHvF+YxP5ZMVw8fAH8E29UaRWTWbQugq3VHE1skxZykm ALE/l7TFy4ugRp7j2P2B+R6daIRRu8xyeblIA= Received: by 10.42.72.132 with SMTP id o4mr756623icj.97.1316116020699; Thu, 15 Sep 2011 12:47:00 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id a11sm6015670ibg.3.2011.09.15.12.46.59 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 12:46:59 -0700 (PDT) Message-ID: <4E7256B6.4010001@gmail.com> Date: Thu, 15 Sep 2011 12:49:10 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <6F469757-6B5C-4DC9-BC34-026F34C7E508@phonefromhere.com> <4E724E25.1000204@jesup.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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: Thu, 15 Sep 2011 19:44:49 -0000 On 09/15/2011 12:24 PM, Markus.Isomaki@nokia.com wrote: > SIP over UDP is used by mobile operators themselves, as they are in control of the access infrastructure, and can make special provisions for their own services. But if you try to run SIP over UDP over mobile networks to any independent ("OTT") Internet service, it is likely to not work that well, due to battery consumption. Even with public addresses, in many mobile networks firewalls drop UDP flow state after 30 seconds. > If the concern is the battery, then with ICE, SIP over UDP is something we want can reserve in stateful progressions. People don't like that stateful discussion when it comes to buffer size and transient mix, as they defaulted to cache under IPv4. E911 traffic would be transient to corporate cache, for example. There are more options as we garbage collect, resolve, and reserve those allocations after clean from either cache or transient states. Behind corporate firewalls, cache items could be datestamp'd, which simply releases them from the transient state. Under SMTP, that was normal. UDP is BSD friendly, and I like how rtcweb fits right in the UDP header with extended Content-Length:. If the SSRC is touched, then expand or deliver. > TCP usually survives longer, in most networks actually more than 15 minutes. Unfortunately a small percentage of networks breaks even TCP in less than 5 minutes. (Several companies, including Nokia, have concrete stats from all over the globe.) > > So all in all I'm not sure that HTTP or websockets are in a worse position than pure SIP. The main differences are that the Javascript app may not have access to some helpers the more native mobile platform may offer. > > Markus > > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >> Of ext Randell Jesup >> Sent: 15 September, 2011 22:13 >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport >> for Session Initiation Protocol (SIP) >> >> On 9/15/2011 11:57 AM, Roman Shpount wrote: >> >>> Actually SIP over UDP is what is typically used for mobile apps now. >>> If you are doing SIP from the public IP, you do not need to maintain >>> the connection even if TCP/TLS is used. >>> >> Markus had a point: SIP over UDP requires keepalives if it's behind a NAT as >> well. So maybe it's not such a big difference, depending on the keepalive >> rates needed (and for UDP circa 30 sec is typical). >> >> -- >> Randell Jesup >> randell-ietf@jesup.org >> >> _______________________________________________ >> 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 > > -- --- The wheel. From henry.sinnreich@gmail.com Thu Sep 15 14:18: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 D607311E8088 for ; Thu, 15 Sep 2011 14:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsN-88tkfkC2 for ; Thu, 15 Sep 2011 14:18:43 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 570CE11E807F for ; Thu, 15 Sep 2011 14:18:43 -0700 (PDT) Received: by gwb17 with SMTP id 17so3531105gwb.15 for ; Thu, 15 Sep 2011 14:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=ia4BWxwszsYmTp3ohF6fbRPEGOwZB1PNYEUaIcwodiE=; b=cW5rDXpFbTc4+5qtWPxsh52fxGziO5BMMSWk0/j5fv9phMiacZdttHI3lXYLl3mICH TdygqVUSWBGKYatZ5RVw3AxIm9dTB9BrFZbx198aT+zUHGwGt43bnrRCBoJFKl1O2XjN 7EtjKlZdIfRpT3n/rDPPazYZiTOtyOEJ9gDa0= Received: by 10.236.177.72 with SMTP id c48mr10022395yhm.79.1316121655995; Thu, 15 Sep 2011 14:20:55 -0700 (PDT) Received: from [192.168.15.2] (cpe-76-184-249-163.tx.res.rr.com. [76.184.249.163]) by mx.google.com with ESMTPS id z24sm5277542yhj.5.2011.09.15.14.20.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 14:20:54 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 15 Sep 2011 16:20:50 -0500 From: Henry Sinnreich To: Lorenzo Miniero , =?ISO-8859-1?B?SfFha2k=?= Baz Castillo Message-ID: Thread-Topic: [rtcweb] About defining a signaling protocol for WebRTC (or not) Thread-Index: Acxz7VeJHV0yHktK0kiiDaqPs7bydA== In-Reply-To: <20110915140248.4cc17977@lminiero-acer> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 21:18:44 -0000 +1 Thanks, Henry On 9/15/11 7:02 AM, "Lorenzo Miniero" wrote: > Il giorno Thu, 15 Sep 2011 13:52:38 +0200 > I=F1aki Baz Castillo ha scritto: >=20 >> 2011/9/15 Tim Panton : >>> Are we saying that SDP is so impossible to parse that the only way >>> to do it is with a pre-existing native library ?!? If not I think >>> we can do that transformation (when needed) in JavaScript. >>=20 >> No, I just said that _maybe_ it wouldl be useful to provide such >> parsing functions natively (given the fact that various protocol use >> SDP bodies, as SIP and XMPP). >>=20 >> I'm fine with parsing SDP bodies in custom JavaScript code however :) >>=20 >=20 >=20 > I don't understand the need for it to be SDP actually: Javascript > already has native and efficient ways to describe information (JSON, > XML), if SDP is what everybody wants then it would be easier to just > map SDP over them. >=20 > L. From pravindran@sonusnet.com Thu Sep 15 14: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 A7CFF11E80A0 for ; Thu, 15 Sep 2011 14:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 ZKZ+qlXLekom for ; Thu, 15 Sep 2011 14:59:04 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id D016611E8097 for ; Thu, 15 Sep 2011 14:59:03 -0700 (PDT) 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 p8FM1kwN030934; Thu, 15 Sep 2011 18:01:46 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Sep 2011 18:01:01 -0400 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: Fri, 16 Sep 2011 03:30:59 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0C8A@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Proposed text - remote recording use case Thread-Index: AQHMciK7XwUojQUk70aUevXP868dwpVMX0wwgAABGYCAAjHtsIAAbdhA References: <2E239D6FCD033C4BAF15F386A979BF510F09ED@sonusinmail02.sonusnet.com> <8357A942-21EA-4209-82DB-ADFCEB5F32EF@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF510F0B4E@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: "Elwell, John" , "Hadriel Kaplan" X-OriginalArrivalTime: 15 Sep 2011 22:01:01.0659 (UTC) FILETIME=[F4FFDAB0:01CC73F2] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 21:59:04 -0000 John, Could you please explain in detail about the reason for two websocket from browser wherein one towards webserver and another towards recorder (another webserver) is outside the scope of RTCWeb. Also, I guess that it would have covered in one of usecase of RTCWeb document already. AFAIK, there is no restriction on number of websockets from browser. Thanks Partha >-----Original Message----- >From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >Sent: Thursday, September 15, 2011 8:58 PM >To: Ravindran Parthasarathi; Hadriel Kaplan >Cc: rtcweb@ietf.org >Subject: RE: [rtcweb] Proposed text - remote recording use case > >Partha, > >> -----Original Message----- >> From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com] >> Sent: 14 September 2011 06:57 >> To: Elwell, John; Hadriel Kaplan >> Cc: rtcweb@ietf.org >> Subject: RE: [rtcweb] Proposed text - remote recording use case >> >> John, >> >> I'm fine with Hadriel proposal of "remote peer" instead >> "remote browser >> or SRS" but not the original wordings. >> >> At this moment, I'm not convinced whether SIPREC SRS will interop with >> RTCWeb browser because the signaling protocol is an open item >> in RTCWeb. >> The recording could be done by two websocket from browser wherein one >> websocket towards webserver and other towards recorder. How these >> entities interact with each other has to be discussed & >> defined. Please >> let me know the reason why this approach may not be followed >> in RTCWeb. >[JRE] I am not saying it will not work, but I consider this to be >outside scope of RTC-Web. > >John > > >> >> Thanks >> Partha >> >> >> >-----Original Message----- >> >From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> >Sent: Wednesday, September 14, 2011 11:21 AM >> >To: Hadriel Kaplan; Ravindran Parthasarathi >> >Cc: >> >Subject: RE: [rtcweb] Proposed text - remote recording use case >> > >> > >> > >> >> -----Original Message----- >> >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> >> Sent: 13 September 2011 15:38 >> >> To: Ravindran Parthasarathi >> >> Cc: Elwell, John; >> >> Subject: Re: [rtcweb] Proposed text - remote recording use case >> >> >> >> inline... >> >> >> >> On Sep 11, 2011, at 4:29 PM, Ravindran Parthasarathi wrote: >> >> >> >> > New requirements: >> >> > Fyy1: The browser MUST be able to send in real-time to an another >> >> > browser/session recording server(SRS) that are being >> >> transmitted to and >> >> > received from remote browser. >> >> >> >> That doesn't make sense in English - *what* needs to be sent >> >> in real-time? Removing the word "media" broke the meaning. >> >> Also, the media it needs to replicate/fork may not be to/from >> >> another "remote browser" - it could be to/from a remote >> >> gateway, SIP UA, whatever. Really what you want to say is >> >> to/from a "remote peer". >> >> Same issues/comments go for the next requirement. >> >[JRE] I agree the modified words don't make sense and would like to >> >stick to the words I proposed at the start of this thread. >> > >> >> >> >> > >> >> > Ayy1: The web application MUST be able to ask the browser >> >> to transmit in >> >> > real-time to another browser/session recording >> server(SRS) that are >> >> > being transmitted to and received from remote browser. >> >> >> >> Same as above. >> >> >> >> > As I asked in the meeting (but couldn't discuss due to time >> >> constraint), >> >> > it is possible for browser to do the signaling directly >> to the SRS >> >> > without going through original webserver. The signaling towards >> >> > recording is not required to be SIP but it shall be >> websocket (let >> >> > discuss separately). Here, the advantageous in this model >> >> is that the >> >> > recording signaling hop is reduced to 1 hop (browser to >> SRS) from >> 2 >> >> > hops (browser to webserver, webserver to SRS). >> >> > >> >> >> >> Actually, I don't think it is possible for the rtcweb browser >> >> to properly do SIPREC, even if it had a SIP stack to do it >> >> with. The reason is the browser doesn't know the full call >> >> metadata. The browser doesn't know the calling/called party >> >> info, for example. Even the javascript itself may not know >> >> it, depending on how the application provider does their >> >> logic. They could decide to have some state/logic be handled >> >> by the web server, rather than all in the javascript. For >> >> example the javascript may just display a list of friends >> >> using aliases or icons, and the web server may be the only >> >> one who knows what the friend's AoR/URI actually is for that alias. >> >[JRE] Quite so. Metadata would come from the application, but whether >> >this is server-side or client-side is out of scope for RTC-Web. The >> >important thing is that an application that is able to do the SIP and >> >Metadata part of SIPREC can ask the browser to do the media part. >> > >> >John >> > >> > >> >> >> >> -hadriel >> >> >> >> >> From pravindran@sonusnet.com Thu Sep 15 15:17: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 DA8A021F84B1 for ; Thu, 15 Sep 2011 15:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 SBL+qC4Mml7n for ; Thu, 15 Sep 2011 15:17:06 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2F221F84AF for ; Thu, 15 Sep 2011 15:17:06 -0700 (PDT) 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 p8FMJlEC009599; Thu, 15 Sep 2011 18:19:47 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Sep 2011 18:18:55 -0400 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: Fri, 16 Sep 2011 03:48:53 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0C8C@sonusinmail02.sonusnet.com> In-Reply-To: <4E721BF3.10505@alvestrand.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Proposed text - remote recording use case Thread-Index: AcxzvYkgfUcWa7MUSWONOeb17M/tnQANdlrA References: <2E239D6FCD033C4BAF15F386A979BF510F09ED@sonusinmail02.sonusnet.com> <8357A942-21EA-4209-82DB-ADFCEB5F32EF@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF510F0B4E@sonusinmail02.sonusnet.com> <4E721BF3.10505@alvestrand.no> From: "Ravindran Parthasarathi" To: "Harald Alvestrand" , X-OriginalArrivalTime: 15 Sep 2011 22:18:55.0153 (UTC) FILETIME=[74DA0A10:01CC73F5] Subject: Re: [rtcweb] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 22:17:07 -0000 Hi Harlad, I agree with you in case it is just two socket from JS (app environment).=20 But in this usecase, The websocket towards recorder needs metadata which is similar to SIPREC metadata (http://tools.ietf.org/html/draft-ietf-siprec-metadata-04) and also, it will have the impact on RTP model (RTP translator or mixer) of the browser (http://tools.ietf.org/id/draft-eckel-siprec-rtp-rec-01.txt). So, I'm thinking that it is inside the scope of RTCWeb.=20 Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Harald Alvestrand >Sent: Thursday, September 15, 2011 9:08 PM >To: rtcweb@ietf.org >Subject: Re: [rtcweb] Proposed text - remote recording use case > >On 09/14/11 07:57, Ravindran Parthasarathi wrote: >> John, >> >> I'm fine with Hadriel proposal of "remote peer" instead "remote >browser >> or SRS" but not the original wordings. >> >> At this moment, I'm not convinced whether SIPREC SRS will interop with >> RTCWeb browser because the signaling protocol is an open item in >RTCWeb. >> The recording could be done by two websocket from browser wherein one >> websocket towards webserver and other towards recorder. How these >> entities interact with each other has to be discussed& defined. >Please >> let me know the reason why this approach may not be followed in >RTCWeb. >My opinion: > >If this can be built in JS using the APIs and protocols defined by >RTCWEB/WEBRTC, there is no need for anything more within these groups. > >If it cannot be built using these APIs and protocols, we need to >consider whether these APIs and protocols need to be extended in order >to cover this use case. > >The detailed building of the application is, in my opinion, out of scope >for RTCWEB. > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Thu Sep 15 16:44: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 4DFF821F8B51 for ; Thu, 15 Sep 2011 16:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 Z4wY9I4POmi4 for ; Thu, 15 Sep 2011 16:44:15 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB1621F8B4D for ; Thu, 15 Sep 2011 16:44:09 -0700 (PDT) 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 p8FNkndC001645; Thu, 15 Sep 2011 19:46:49 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Sep 2011 19:38:26 -0400 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: Fri, 16 Sep 2011 05:08:25 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0C92@sonusinmail02.sonusnet.com> In-Reply-To: <4E4270DE-5CC3-4089-874A-FDFFB12156E7@phonefromhere.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for Default signaling protocol for RTCWeb [was RE: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket] Thread-Index: AcxzjZj8wPl5zH0RShqnmFaCezvjkAAcYYZA References: <2E239D6FCD033C4BAF15F386A979BF510F0B37@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F0B39@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F0B8A@sonusinmail02.sonusnet.com> <4E4270DE-5CC3-4089-874A-FDFFB12156E7@phonefromhere.com> From: "Ravindran Parthasarathi" To: "Tim Panton" X-OriginalArrivalTime: 15 Sep 2011 23:38:26.0622 (UTC) FILETIME=[90DE6DE0:01CC7400] Cc: rtcweb@ietf.org Subject: [rtcweb] Need for Default signaling protocol for RTCWeb [was RE: draft-ibc-rtcweb-sip-vs-websocket] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 23:44:16 -0000 Hi Tim, I agree with you that it is possible to implement using plugins and it = is highlighted in RTCWeb charter = (http://tools.ietf.org/wg/rtcweb/charters) as "These are not = interoperable, as they require non-standard extensions or plugins to = work.". And also, the aim of this WG is to "There is a desire to = standardize the basis for such communication so that interoperable = communication can be established between any compatible browsers". Now, = I don't the reason for implementing signaling in JavaScript or plugin or = applet. Also, I don't know about native plugin but I guess that those plugin are = installed as part of the browser installation. Please correct me if I'm = wrong. Thanks Partha >-----Original Message----- >From: Tim Panton [mailto:tim@phonefromhere.com] >Sent: Thursday, September 15, 2011 3:19 PM >To: Ravindran Parthasarathi >Cc: I=F1aki Baz Castillo; rtcweb@ietf.org >Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-vs-websocket > >It is worth pointing out that even with a signalling protocol agnostic >webRTC you >wouldn't _have_ to implement your signalling protocol in javascript. > >Browsers support other plugin languages - specifically it would be >possible to implement >a classic full UDP SIP stack as a java applet and delegate the media >handling to the webRTC layer. > >Chrome is moving towards support for native plugins, but it isn't clear >that they >would be suitable for this use. > >Tim. (speaking for himself) > > >On 14 Sep 2011, at 11:03, Ravindran Parthasarathi wrote: > >> Hi Inaki, >> >> >> >> The fact that there are other alternatives for signaling in the web >does not mean that using SIP is invalid. >> If I want to build a SIP phone in a web, why should I use libjingle >rather than SIP protocol? Why should I code a complex server behaving = as >a gateway between Jingle and SIP protocols? >> >> Any protocol conversion (i.e. from Jingle to SIP) means loss of >features. Our draft proposes the contrary: no protocol conversion (just >SIP), and just transport protocol conversion (as already exists in SIP >when bridging UDP/TCP/TLS-TCP/SCTP...). >> >> >> I agree with your problem statement. I have raised the same concern = in >http://www.ietf.org/mail-archive/web/rtcweb/current/msg00845.html. IMO, >your solution is a workaround and we will end-up with your solution in >case signaling protocol is not standardized as part of RTCWeb. >> >> Thanks >> Partha >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Thu Sep 15 16:59: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 F13E31F0C3C for ; Thu, 15 Sep 2011 16:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=-0.043, 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 KQo6hb8XwHEO for ; Thu, 15 Sep 2011 16:59:57 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF6D1F0C3B for ; Thu, 15 Sep 2011 16:59:57 -0700 (PDT) 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 p8G02aCR011719; Thu, 15 Sep 2011 20:02:36 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Sep 2011 19:56:46 -0400 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: Fri, 16 Sep 2011 05:26:45 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> In-Reply-To: <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RTCWeb default signaling protocol [was RE: [rtcweb] About defining a signaling protocol for WebRTC (or not)] Thread-Index: AcxzfIlTZtq9ST3YRzeqHdWEUmGLFAAhHZdw References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> From: "Ravindran Parthasarathi" To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-OriginalArrivalTime: 15 Sep 2011 23:56:46.0105 (UTC) FILETIME=[20363890:01CC7403] Cc: rtcweb@ietf.org Subject: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 15 Sep 2011 23:59:58 -0000 Hi Saul, I really didn't get your argument fully because in case there is no = default signaling protocol, it is unavoidable to have island of devices = without gateways but you argue other way around.=20 I specifically asked for the scope of your opinion on RTCWeb work is = between browser-to-browser or browser-to-other end-point to know whether = parallel universe has to be build or not. In case there is no default = signaling protocol, it is impossible to communicate between = browser-to-endpoint without gateways. Let us assume that the intention = of RTCWeb is to create island of browser devices even then the native = signaling protocol for RTCWeb has advantage over Jquery library and = plugin is not the solution. Having said that, I agree that it is possible to implement RTP or STUN = or SIP stack or codec using Javascript or plugins but interop and better = performance is not guaranteed. Thanks Partha >-----Original Message----- >From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] >Sent: Thursday, September 15, 2011 1:23 PM >To: Ravindran Parthasarathi >Cc: I=F1aki Baz Castillo; rtcweb@ietf.org >Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC = (or >not) > >Hi, > >[snip] > >> My point is that the default signaling protocol has to be supported = in >RTCWeb client which should not be downloaded in runtime to make the >dialog between two RTCWeb client. I asked for SIP initially as SIP is >the de-facto protocol and mostly deployment. I agree with Peter & = others >that websocket could be another alternative in the web deployment. In >case required, I'll come up the write up to show the needs of default >signaling protocol for making dialog between browser to browser. >> > >Do you mean there should be a 'default signaling protocol' on every >browser? I'm not sure I'd like that. I (personally) see RTCWeb as a >framework on top of which we can build RTC applications. The fact that >one would use SIP and someone else uses something else is not crucial, >IMHO. Now if some new simplified protocol is chosen for browser-to- >browser communication we'd have yet another island of devices (browsers >in this case) to which we'd need to gateway somehow. > >[snip] > >>> >>> WebRTC defines multimedia capabilities for web-browsers and mandates >>> protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566). = The >>> aim of these protocols is to enable multimedia streams between a >>> web-browser and other endpoint (which could also be a web-browser). >>> >> I hope that the aim of the protocols is to enable multimedia >stream between browser to browser only. In case browser to other end- >point is outside the scope of RTCWEb. >> > >Well, why build a parallel universe just for the browsers? If RTCWeb >would only define the media plane and developers themselves can choose >the signaling protocol, the integration with existing communication >systems (using SIP or XMPP for example since they are the most used >ones) would be pretty straight-forward. > >My 2 cents. > > >Regards, > >-- >Sa=FAl Ibarra Corretg=E9 >AG Projects > > From roman@telurix.com Thu Sep 15 17:49: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 E1E731F0C3D for ; Thu, 15 Sep 2011 17:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.728 X-Spam-Level: X-Spam-Status: No, score=-2.728 tagged_above=-999 required=5 tests=[AWL=0.248, 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 fU9QaYpizp0e for ; Thu, 15 Sep 2011 17:49:55 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id C91D31F0C3C for ; Thu, 15 Sep 2011 17:49:54 -0700 (PDT) Received: by gxk9 with SMTP id 9so3684527gxk.40 for ; Thu, 15 Sep 2011 17:52:07 -0700 (PDT) Received: by 10.147.19.1 with SMTP id w1mr1494836yai.9.1316134325988; Thu, 15 Sep 2011 17:52:05 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by mx.google.com with ESMTPS id s15sm19249722ank.8.2011.09.15.17.52.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 17:52:05 -0700 (PDT) Received: by gxk9 with SMTP id 9so3684495gxk.40 for ; Thu, 15 Sep 2011 17:52:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.34.34 with SMTP id w2mr1561818pbi.174.1316134323885; Thu, 15 Sep 2011 17:52:03 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Thu, 15 Sep 2011 17:52:03 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> Date: Thu, 15 Sep 2011 20:52:03 -0400 Message-ID: From: Roman Shpount To: Ravindran Parthasarathi Content-Type: multipart/alternative; boundary=bcaec52163dfda185304ad046632 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 00:49:56 -0000 --bcaec52163dfda185304ad046632 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Partha, It is not possible to implement browser to browser calls unless both browsers are on public IPs or on the same network. As far as signaling is concerned, it is always going to be browser to server to browser call. Sinc= e there is always a server on the signaling path and since implementing a signaling gateway from long poll HTTP or websocket signaling interface to SIP (as shown by a number of projects mentioned in this thread) is straight forward enough to implement, there is no desire to create a standard signaling protocol to be used in the browser. There is no benefit for the application developer in following this standard, since it provides neither more functionality no better performance then a custom protocol implemented in JavaScript. Interop and fragmentation arguments do not apply to this either, since it is the same as complaining that HotMail and GMail use different protocols when implementing web mail. It does not affect anything since this stays within the same application and is no more then an implementation detail. _____________ Roman Shpount On Thu, Sep 15, 2011 at 7:56 PM, Ravindran Parthasarathi < pravindran@sonusnet.com> wrote: > Hi Saul, > > I really didn't get your argument fully because in case there is no defau= lt > signaling protocol, it is unavoidable to have island of devices without > gateways but you argue other way around. > > I specifically asked for the scope of your opinion on RTCWeb work is > between browser-to-browser or browser-to-other end-point to know whether > parallel universe has to be build or not. In case there is no default > signaling protocol, it is impossible to communicate between > browser-to-endpoint without gateways. Let us assume that the intention of > RTCWeb is to create island of browser devices even then the native signal= ing > protocol for RTCWeb has advantage over Jquery library and plugin is not t= he > solution. > > Having said that, I agree that it is possible to implement RTP or STUN or > SIP stack or codec using Javascript or plugins but interop and better > performance is not guaranteed. > > Thanks > Partha > > >-----Original Message----- > >From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] > >Sent: Thursday, September 15, 2011 1:23 PM > >To: Ravindran Parthasarathi > >Cc: I=F1aki Baz Castillo; rtcweb@ietf.org > >Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or > >not) > > > >Hi, > > > >[snip] > > > >> My point is that the default signaling protocol has to be supported in > >RTCWeb client which should not be downloaded in runtime to make the > >dialog between two RTCWeb client. I asked for SIP initially as SIP is > >the de-facto protocol and mostly deployment. I agree with Peter & others > >that websocket could be another alternative in the web deployment. In > >case required, I'll come up the write up to show the needs of default > >signaling protocol for making dialog between browser to browser. > >> > > > >Do you mean there should be a 'default signaling protocol' on every > >browser? I'm not sure I'd like that. I (personally) see RTCWeb as a > >framework on top of which we can build RTC applications. The fact that > >one would use SIP and someone else uses something else is not crucial, > >IMHO. Now if some new simplified protocol is chosen for browser-to- > >browser communication we'd have yet another island of devices (browsers > >in this case) to which we'd need to gateway somehow. > > > >[snip] > > > >>> > >>> WebRTC defines multimedia capabilities for web-browsers and mandates > >>> protocols as RTP, STUN, ICE, and understanding of SDP (RFC 4566). The > >>> aim of these protocols is to enable multimedia streams between a > >>> web-browser and other endpoint (which could also be a web-browser). > >>> > >> I hope that the aim of the protocols is to enable multimedia > >stream between browser to browser only. In case browser to other end- > >point is outside the scope of RTCWEb. > >> > > > >Well, why build a parallel universe just for the browsers? If RTCWeb > >would only define the media plane and developers themselves can choose > >the signaling protocol, the integration with existing communication > >systems (using SIP or XMPP for example since they are the most used > >ones) would be pretty straight-forward. > > > >My 2 cents. > > > > > >Regards, > > > >-- > >Sa=FAl Ibarra Corretg=E9 > >AG Projects > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec52163dfda185304ad046632 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Partha,

It is not possible to implement browser to browser calls unl= ess both browsers are on public IPs or on the same network. As far as signa= ling is concerned, it is always going to be browser to server to browser ca= ll. Since there is always a server on the signaling path and since implemen= ting a signaling gateway from long poll HTTP or websocket signaling interfa= ce to SIP (as shown by a number of projects mentioned in this thread) is st= raight forward enough to implement, there is no desire to create a standard= signaling protocol to be used in the browser. There is no benefit for the = application developer in following this standard, since it provides neither= more functionality no better performance then a custom protocol implemente= d in JavaScript. Interop and fragmentation arguments do not apply to this e= ither, since it is the same as complaining that HotMail and GMail use diffe= rent protocols when implementing web mail. It does not affect anything sinc= e this stays within the same application and is no more then an implementat= ion detail.
_____________
Roman Shpount


On Thu, Sep 15, 2011 at 7:56 PM, Ravindr= an Parthasarathi <pravindran@sonusnet.com> wrote:
Hi Saul,

I really didn't get your argument fully because in case there is no def= ault signaling protocol, it is unavoidable to have island of devices withou= t gateways but you argue other way around.

I specifically asked for the scope of your opinion on RTCWeb work is betwee= n browser-to-browser or browser-to-other end-point to know whether parallel= universe has to be build or not. In case there is no default signaling pro= tocol, it is impossible to communicate between browser-to-endpoint without = gateways. Let us assume that the intention of RTCWeb is to create island of= browser devices even then the native signaling protocol for RTCWeb has adv= antage over Jquery library and plugin is not the solution.

Having said that, I agree that it is possible to implement RTP or STUN or S= IP stack or codec using Javascript or plugins but interop and better perfor= mance is not guaranteed.

Thanks
Partha

>-----Original Message-----
>From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com]
>Sent: Thursday, September 15, 2011 1:23 PM
>To: Ravindran Parthasarathi
>Cc: I=F1aki Baz Castillo; rtcweb@iet= f.org
>Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (o= r
>not)
>
>Hi,
>
>[snip]
>
>> My point is that the default signaling protocol has to be supporte= d in
>RTCWeb client which should not be downloaded in runtime to make the
>dialog between two RTCWeb client. I asked for SIP initially as SIP is >the de-facto protocol and mostly deployment. I agree with Peter & o= thers
>that websocket could be another alternative in the web deployment. In >case required, I'll come up the write up to show the needs of defau= lt
>signaling protocol for making dialog between browser to browser.
>>
>
>Do you mean there should be a 'default signaling protocol' on e= very
>browser? I'm not sure I'd like that. I (personally) see RTCWeb = as a
>framework on top of which we can build RTC applications. The fact that<= br> >one would use SIP and someone else uses something else is not crucial,<= br> >IMHO. Now if some new simplified protocol is chosen for browser-to-
>browser communication we'd have yet another island of devices (brow= sers
>in this case) to which we'd need to gateway somehow.
>
>[snip]
>
>>>
>>> WebRTC defines multimedia capabilities for web-browsers and ma= ndates
>>> protocols as RTP, STUN, ICE, and understanding of SDP (RFC 456= 6). The
>>> aim of these protocols is to enable multimedia streams between= a
>>> web-browser and other endpoint (which could also be a web-brow= ser).
>>>
>> <partha> I hope that the aim of the protocols is to enable m= ultimedia
>stream between browser to browser only. In case browser to other end- >point is outside the scope of RTCWEb. </partha>
>>
>
>Well, why build a parallel universe just for the browsers? If RTCWeb >would only define the media plane and developers themselves can choose<= br> >the signaling protocol, the integration with existing communication
>systems (using SIP or XMPP for example since they are the most used
>ones) would be pretty straight-forward.
>
>My 2 cents.
>
>
>Regards,
>
>--
>Sa=FAl Ibarra Corretg=E9
>AG Projects
>
>

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

--bcaec52163dfda185304ad046632-- From HKaplan@acmepacket.com Thu Sep 15 19:22: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 E87C221F84ED for ; Thu, 15 Sep 2011 19:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 oLpIHCLn26wm for ; Thu, 15 Sep 2011 19:22:20 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2E86421F84DD for ; Thu, 15 Sep 2011 19:22:19 -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, 15 Sep 2011 22:24:32 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 15 Sep 2011 22:24:31 -0400 From: Hadriel Kaplan To: Ravindran Parthasarathi Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: AQHMdBfEi7FefEQ3sUO4/j8bw5yK0g== Date: Fri, 16 Sep 2011 02:24:31 +0000 Message-ID: <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.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: <2F2C947AA2A3834BA428305E34B1A51E@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 02:22:21 -0000 There is no need for a "default signaling protocol", because the "signaling= " is between the browser's Javascript and its web server. And as for the s= ignaling protocol the web server has to support in order to speak to other = servers or non-RTCweb endpoints, even if we specified to use SIP we'd just = be summarily ignored by those who don't want to, because they actually don'= t *need* to. It doesn't hurt interoperability of rtcweb if they don't impl= ement SIP - it just means they can't talk to other SIP devices/servers. Bu= t it's not like we need an RFC to say "if you don't implement X then you ca= n't talk to people who do X". Think of this RTCWEB concept as Skinny/SCCP. The Web Server is Call Manage= r, and the browser is the Skinny phone, but in this case instead of needing= a 7960 phone, the Skinny protocol was written in javascript and uses a bro= wser's user interface for its GUI and the built-in RTP library for media. (= in fact one could probably write a javascript to do just that, if Call Mana= ger handled SCCP over websocket) =20 Clearly the IETF does not need to define for Cisco a standardized replaceme= nt for the SCCP protocol for this to work, because one isn't needed since t= he client javascript and server are built by the same developers and they k= now how their proprietary signaling works. So how about for the signaling = Call Manager would use to other VoIP devices, like gateways or VoIP service= providers? Does the IETF need to tell Cisco what peer-to-peer protocol(s)= to implement on Call Manager? No, and we never have. Cisco's product man= agers decide that. They decide if Call Manager needs to be able to communi= cate a standard protocol at all, such as SIP or H.323, and which one/any of= those. They decide based on their use-cases/need. Some rtcweb developers may not do any standard signaling protocol, ever. F= or example many Instant Messaging providers still have closed environments = to this day. (e.g., AIM, YIM, MSN, etc.) Some may choose to only use H.323= , or XMPP, or IAX, or even BICC. Some may choose to only support SIP with = 3GPP extensions. Obviously most of us think/hope people do SIP, but really= the market makes those types of decisions, not the IETF. Just like the IE= TF standardized MGCP but didn't specify what the MGCP Call Agent had to sup= port to speak to other Call Agents. SIP was given as an example in MGCP, b= ut not mandated. The only thing we need to do for rtcweb is make sure the RTP library built = into the browser supports media in such a way that it can communicate with = other RTP peers at a media plane, regardless of what signaling protocol tho= se peers might be using, preferably without going through media gateways. = And obviously since SIP is a very common protocol and defined by the IETF w= e need to make sure it's possible to use SIP on the rtcweb server, but we c= an't *mandate* that it be used or supported, and if we did it wouldn't chan= ge anything.=20 -hadriel On Sep 15, 2011, at 7:56 PM, Ravindran Parthasarathi wrote: > I really didn't get your argument fully because in case there is no defau= lt signaling protocol, it is unavoidable to have island of devices without = gateways but you argue other way around.=20 >=20 > I specifically asked for the scope of your opinion on RTCWeb work is betw= een browser-to-browser or browser-to-other end-point to know whether parall= el universe has to be build or not. In case there is no default signaling p= rotocol, it is impossible to communicate between browser-to-endpoint withou= t gateways. Let us assume that the intention of RTCWeb is to create island = of browser devices even then the native signaling protocol for RTCWeb has a= dvantage over Jquery library and plugin is not the solution. >=20 > Having said that, I agree that it is possible to implement RTP or STUN or= SIP stack or codec using Javascript or plugins but interop and better perf= ormance is not guaranteed. >=20 > Thanks > Partha From jim.mceachern@genband.com Thu Sep 15 20:22: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 941AD11E8086 for ; Thu, 15 Sep 2011 20:22:08 -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 aoG5H4+oestW for ; Thu, 15 Sep 2011 20:22:07 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id CC9D121F85BB for ; Thu, 15 Sep 2011 20:22:05 -0700 (PDT) Received: from mail.genband.com ([63.149.188.88]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTnLBWzuyPgwaMI1UQlD4+8jDP0k9R0tq@postini.com; Thu, 15 Sep 2011 20:24:21 PDT Received: from owa.genband.com ([172.16.21.97]) by mail.genband.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Sep 2011 22:23:59 -0500 Received: from GBPLMAIL03.genband.com ([fe80::81ee:2d58:ca01:fb9a]) by GBEX01.genband.com ([fe80::a0a8:7818:e701:2f58%13]) with mapi id 14.01.0289.001; Thu, 15 Sep 2011 22:23:53 -0500 From: Jim McEachern To: Hadriel Kaplan , Ravindran Parthasarathi Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: AcxzfIlTZtq9ST3YRzeqHdWEUmGLFAAhHZdwABArUIAACKQ7AA== Date: Fri, 16 Sep 2011 03:23:54 +0000 Message-ID: <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> In-Reply-To: <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [99.242.72.70] Content-Type: multipart/mixed; boundary="_002_8584590C8D7DD141AA96D01920FC6C698C896B71gbplmail03genba_" MIME-Version: 1.0 X-OriginalArrivalTime: 16 Sep 2011 03:23:59.0592 (UTC) FILETIME=[1325C680:01CC7420] X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.500.1024-18388.004 X-TM-AS-Result: No--32.914900-5.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 03:22:08 -0000 --_002_8584590C8D7DD141AA96D01920FC6C698C896B71gbplmail03genba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hadriel, Well said. =20 Your closing paragraph sums it up nicely in my mind. The only thing we need to do for rtcweb is make sure the RTP library built = into the browser supports media in such a way that it can communicate with = other RTP peers at a media plane, regardless of what signaling protocol tho= se peers might be using, preferably without going through media gateways. = And ... we need to make sure it's possible to use SIP on the rtcweb server.= ... Jim -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Hadriel Kaplan Sent: Thursday, September 15, 2011 10:25 PM To: Ravindran Parthasarathi Cc: Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defi= ning a signaling protocol for WebRTC (or not)] There is no need for a "default signaling protocol", because the "signaling= " is between the browser's Javascript and its web server. And as for the s= ignaling protocol the web server has to support in order to speak to other = servers or non-RTCweb endpoints, even if we specified to use SIP we'd just = be summarily ignored by those who don't want to, because they actually don'= t *need* to. It doesn't hurt interoperability of rtcweb if they don't impl= ement SIP - it just means they can't talk to other SIP devices/servers. Bu= t it's not like we need an RFC to say "if you don't implement X then you ca= n't talk to people who do X". Think of this RTCWEB concept as Skinny/SCCP. The Web Server is Call Manage= r, and the browser is the Skinny phone, but in this case instead of needing= a 7960 phone, the Skinny protocol was written in javascript and uses a bro= wser's user interface for its GUI and the built-in RTP library for media. (= in fact one could probably write a javascript to do just that, if Call Mana= ger handled SCCP over websocket) =20 Clearly the IETF does not need to define for Cisco a standardized replaceme= nt for the SCCP protocol for this to work, because one isn't needed since t= he client javascript and server are built by the same developers and they k= now how their proprietary signaling works. So how about for the signaling = Call Manager would use to other VoIP devices, like gateways or VoIP service= providers? Does the IETF need to tell Cisco what peer-to-peer protocol(s)= to implement on Call Manager? No, and we never have. Cisco's product man= agers decide that. They decide if Call Manager needs to be able to communi= cate a standard protocol at all, such as SIP or H.323, and which one/any of= those. They decide based on their use-cases/need. Some rtcweb developers may not do any standard signaling protocol, ever. F= or example many Instant Messaging providers still have closed environments = to this day. (e.g., AIM, YIM, MSN, etc.) Some may choose to only use H.323= , or XMPP, or IAX, or even BICC. Some may choose to only support SIP with = 3GPP extensions. Obviously most of us think/hope people do SIP, but really= the market makes those types of decisions, not the IETF. Just like the IE= TF standardized MGCP but didn't specify what the MGCP Call Agent had to sup= port to speak to other Call Agents. SIP was given as an example in MGCP, b= ut not mandated. The only thing we need to do for rtcweb is make sure the RTP library built = into the browser supports media in such a way that it can communicate with = other RTP peers at a media plane, regardless of what signaling protocol tho= se peers might be using, preferably without going through media gateways. = And obviously since SIP is a very common protocol and defined by the IETF w= e need to make sure it's possible to use SIP on the rtcweb server, but we c= an't *mandate* that it be used or supported, and if we did it wouldn't chan= ge anything.=20 -hadriel On Sep 15, 2011, at 7:56 PM, Ravindran Parthasarathi wrote: > I really didn't get your argument fully because in case there is no defau= lt signaling protocol, it is unavoidable to have island of devices without = gateways but you argue other way around.=20 >=20 > I specifically asked for the scope of your opinion on RTCWeb work is betw= een browser-to-browser or browser-to-other end-point to know whether parall= el universe has to be build or not. In case there is no default signaling p= rotocol, it is impossible to communicate between browser-to-endpoint withou= t gateways. Let us assume that the intention of RTCWeb is to create island = of browser devices even then the native signaling protocol for RTCWeb has a= dvantage over Jquery library and plugin is not the solution. >=20 > Having said that, I agree that it is possible to implement RTP or STUN or= SIP stack or codec using Javascript or plugins but interop and better perf= ormance is not guaranteed. >=20 > Thanks > Partha _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_002_8584590C8D7DD141AA96D01920FC6C698C896B71gbplmail03genba_ Content-Type: text/x-vcard; name="Jim McEachern.vcf" Content-Description: Jim McEachern.vcf Content-Disposition: attachment; filename="Jim McEachern.vcf"; size=6149; creation-date="Fri, 16 Sep 2011 03:23:53 GMT"; modification-date="Fri, 16 Sep 2011 03:23:53 GMT" Content-Transfer-Encoding: base64 QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpYLU1TLVNJR05BVFVSRTpZRVMNCk47TEFOR1VBR0U9 ZW4tdXM6TWNFYWNoZXJuO0ppbQ0KRk46SmltIE1jRWFjaGVybg0KT1JHOkdFTkJBTkQNClRJVExF Ok5BIFN0YW5kYXJkcyBEaXJlY3Rvcg0KVEVMO1dPUks7Vk9JQ0U6KzEgMzQzLjg4My4yNTI1IDw9 PSBORVcNClRFTDtDRUxMO1ZPSUNFOisxIDYxMy44NTMuMDE3Ng0KQURSO1dPUks7UFJFRjo7OzM1 MDAgQ2FybGluZyBBdmVudWU7T3R0YXdhLDtPTjtLMkggOEU5O0NhbmFkYQ0KTEFCRUw7V09SSztQ UkVGO0VOQ09ESU5HPVFVT1RFRC1QUklOVEFCTEU6MzUwMCBDYXJsaW5nIEF2ZW51ZT0wRD0wQT0N Ck90dGF3YSwgT04sIEsySCA4RTkgQ2FuYWRhDQpYLU1TLU9MLURFRkFVTFQtUE9TVEFMLUFERFJF U1M6Mg0KRU1BSUw7UFJFRjtJTlRFUk5FVDpqaW0ubWNlYWNoZXJuQGdlbmJhbmQuY29tDQpYLU1T LVRFWFQ7Q1VTVE9NMTpPZmZpY2Ugb2YgdGhlIENUTw0KUEhPVE87VFlQRT1KUEVHO0VOQ09ESU5H PUJBU0U2NDoNCiAvOWovNEFBUVNrWkpSZ0FCQVFFQVlBQmdBQUQvMndCREFBWUVCUVlGQkFZR0JR WUhCd1lJQ2hBS0Nna0pDaFFPRHd3UUZ4UVkNCiBHQmNVRmhZYUhTVWZHaHNqSEJZV0lDd2dJeVlu S1NvcEdSOHRNQzBvTUNVb0tTai8yd0JEQVFjSEJ3b0lDaE1LQ2hNb0doWWENCiBLQ2dvS0Nnb0tD Z29LQ2dvS0Nnb0tDZ29LQ2dvS0Nnb0tDZ29LQ2dvS0Nnb0tDZ29LQ2dvS0Nnb0tDZ29LQ2dvS0Nq L3dBQVINCiBDQUJZQUVnREFTSUFBaEVCQXhFQi84UUFId0FBQVFVQkFRRUJBUUVBQUFBQUFBQUFB QUVDQXdRRkJnY0lDUW9MLzhRQXRSQUENCiBBZ0VEQXdJRUF3VUZCQVFBQUFGOUFRSURBQVFSQlJJ aE1VRUdFMUZoQnlKeEZES0JrYUVJSTBLeHdSVlMwZkFrTTJKeWdna0sNCiBGaGNZR1JvbEppY29L U28wTlRZM09EazZRMFJGUmtkSVNVcFRWRlZXVjFoWldtTmtaV1puYUdscWMzUjFkbmQ0ZVhxRGhJ V0cNCiBoNGlKaXBLVGxKV1dsNWlabXFLanBLV21wNmlwcXJLenRMVzJ0N2k1dXNMRHhNWEd4OGpK eXRMVDFOWFcxOWpaMnVIaTQrVGwNCiA1dWZvNmVyeDh2UDA5ZmIzK1BuNi84UUFId0VBQXdFQkFR RUJBUUVCQVFBQUFBQUFBQUVDQXdRRkJnY0lDUW9MLzhRQXRSRUENCiBBZ0VDQkFRREJBY0ZCQVFB QVFKM0FBRUNBeEVFQlNFeEJoSkJVUWRoY1JNaU1vRUlGRUtSb2JIQkNTTXpVdkFWWW5MUkNoWWsN CiBOT0VsOFJjWUdSb21KeWdwS2pVMk56ZzVPa05FUlVaSFNFbEtVMVJWVmxkWVdWcGpaR1ZtWjJo cGFuTjBkWFozZUhsNmdvT0UNCiBoWWFIaUltS2twT1VsWmFYbUptYW9xT2twYWFucUttcXNyTzB0 YmEzdUxtNndzUEV4Y2JIeU1uSzB0UFUxZGJYMk5uYTR1UGsNCiA1ZWJuNk9ucTh2UDA5ZmIzK1Bu Ni85b0FEQU1CQUFJUkF4RUFQd0Q2cHF2cU45YTZiWnlYVjlQSEJieGpMTzV3QlJxTjdiNmINCiBZ ejNsNUlJcmVGUzd1ZXdyNXI4YWVLdFM4YmEwa051a3YyWGZzdGJST1NmUWtEcXgvU3ViRTRsVVYz YlBZeWpLSjVqTnR2bGcNCiB0MytpOC95T3k4V2ZHS1ZuZUR3MWJxcURqN1RPdVNmZFY3ZmorVmVj WC9pTFg5WmxJdXRSdmJndC9Bcm5IL2ZJNHIxTHdaOEkNCiBvVWpqdXZFN21TVThpMGpiQ3Ivdk1P djBINjE2bHB1bGFmcGNRajA2eXQ3WkIyaWpDL25qclhJc1BYcjYxSldYWTkyV2E1WmwNCiBuN3ZD VXVkcnIvd1hkL2RvZktYOWo2dGp6ZjdPdjhkZC9rUC9BRHhWblQvRWV2YU5LUHN1bzN0dVYvZ1p6 ai92azhWOVkxUzENCiBQU2RQMVNJeDZqWlc5eWgvNTZ4aHNmUTlxUDdPY2RZVDFKWEZrS251MTZD Y2ZXLzROSGtYaFQ0eFNxNlFlSmJkV2pQSDJtQmMNCiBFZTdMMy9EOHE5aDA2K3RkU3M0N3F3bmpu dDVCbFhRNUJyeWZ4cDhJb21qa3V2RERsSkFNbTBrYkliL2RZOVBvZnpyZy9CWGkNCiByVWZCV3N0 Rk1rdjJYZnN1clI4Z2pIQklCNk1LY01SVnc4dVN2cXU0cStWNExOS1RyNWE3VFc4ZitCMCtXaDlP MFZXMDIrdDkNCiBTc0lMeXlrRXR2TW9kR0hjVVY2YWQ5VWZIU2k0dHhlNlBIdmoxNGpacmkzMEMy Y2hGQW11TWR5ZnVxZnAxL0VWMG53aThGUjYNCiBKcHNlcVg4UU9wM0tCbEREL1VvZWdIdWUvd0NW ZWVhQmEvOEFDWWZGdWFTNEcrMiswdk8rZVJzVDdvK25DaXZaZkhQaXUwOEoNCiA2U2JtY0NTNWt5 dHZBRGd1MzlBTzVyemFQTE9jc1JVMld4OWZtSHRNUGg2T1ZZWmU5SlhsYnEzMC93QS9KTG9iR3E2 blphVGENCiBOYzZsZFJXMEEvaWtiR2ZZZXA5aFhuR3NmR1hTcmQyVFM3SzR2Q1A0M0lqVS9UcWYw RmVVM1Z4ci9qdlhjN1pyMjZiN3NhY0oNCiBFdnQyVWU1cjBEUXZndTd4ckpybXBlV3g2eFd5NXgv d0kvNFVuaWExZC91VnAzS2prK1haZEZQTWFsNVBvdjhBZ2EvUFJFUC8NCiBBQXV5OTM1L3NhMzIr bm5Objg4VnQ2UDhadExuZFUxU3d1TFRQOGNaRWlqNjlEK2hxNy93cDN3M3MyK2RxT2Y3M25Mbi93 QkINCiBybjljK0M1V05uMFRVaXpEcEZjcmpQOEF3SWY0VVd4a05iMys0RkxoK3Y3bG5EejEvd0Ez K0o2MXBHcTJPc1dndWRNdW9ybUUNCiAvd0FTSE9ENkVkUWZyWEIvRi93VkhyR215YXZwOFFHcFd5 RnBBby8xeURxUHFPMzVlbGVQd3lhLzRFMXdFck5aWGE5VmJsSlYNCiAva3dyNkM4QitMYlR4YnBQ blJnUjNjV0Z1SU01Mm4xSHFwN1ZwQ3RIRlJkS29yTTVjVGw5Ykpxa2NiaFpjMVB2NWRuNVB1ZWQN CiAvQVh4R3kzRnhvRnkrWTNCbXQ4OW1IM2xIMTYvZ2FLNTNYTFgvaER2aXpHOEEyVzYzS1R4NDZl Vy9VZlRsaCtGRkxDMWxDTHANCiAxSHFtVm5lWHl4TmFPS3dzYnhxSlA1LzErSnQvQUNOUnJHdFhN MkEwVUNxU2UyV0pQL29OYzFyMTFmZkVMeDRZclBMSkpKNVYNCiB1RDkyT0lIN3gvRGsxMUZuWlNl R2RKK0lzNHlqSTYyMGYrNjdjSDhuRmFQN1AraklsamY2eEl1WkpIK3p4RTlsSExmbVNQeXINCiBt akJ6VUtEODIvdlBXclltRkNlSXpOYXUwWXg5WEZQOWZ6UFEvQ1hocXc4TWFXbHBZUmpmak1zeEh6 U3Q2ay8wN1Z0MXcveEMNCiArSUZwNFZYN05icXQxcWpESWl6OHNZN0Z6L1RyWGowbDc0eThjenY1 UnZicVBPTmtQeVFyN2RoK2RkdFRFd28vdTRLNzdJK2YNCiB3dVRZbk1FOFZpSnFFWHJ6UzYvMTh2 SStrL3RWdnYyZWZGdi9BTHU4WnFhdm0wL0M3eGI1ZS83RW03Kzc5b1RQODZnaDFIeGoNCiA0SHVF RXh2TFdQT0JIT044VGV3Nmo4aldmMTJVZGFrR2tkWCtybEdycGhjVEdVdTMvRE4va2ZRSGlydzdZ ZUpkTGV6MUNNSGoNCiBNY29IelJ0NmcvNXpYei9wVTkvOE8vSGdTNnp0aWZaTUIwbGhKKzhQdzVI dUs5aitIM2orejhWUi9aNWxXMTFSQmxvYy9LNDcNCiBsRC9UclhPZkg3UmttMHF5MWVOUUpZSDht UWp1amRNL1FqL3g2bGlZeHFRVmVudWlzb3FWY0ppSGxtTVh1ejBzKzc2cjFNSDQNCiArb2o2M285 MUFRZk90dUdYdUEyUWYvSHFLbWtzRzhTK0h2aDdNUVdrODlyU1EvN0t0My80REdUUlhQUER5cnpj NDdPMzVIclUNCiBNMm81Wmg0WWVycTF6TDdwTkhkZkZqVDAvd0NFRjE2YUJNU3lpRjVNZDlraTgv bC9Lc1B3YnJjWGhyNE5SNmpoVEl2bWlOVC8NCiBBQlNGMkFIK2V3cjBmV0xGTlQwcThzWmZ1WEVU Um4yeU1acnhQNGoyVTJqZUJmQ2VodUJISTdTUEtPZzNqSFg4WE5kZUlUcFMNCiBkVmRyZk8vL0FB VHdzcWNNWlJoZ3FqM3FKL0pSZC95SWZodDRNbDhZYWhQcm12dEk5a1pDVGs4M0Q1NTUvdWovQU90 WHZOcmINCiBRV2x1a0ZyRkhEQ2d3cVJxRlVEMkFxcDRmMCtIU3RFc3JHMUE4cUdKVkJIZmprL2lj bjhhMEsydzlCVW8rZlU4N05jeW5qcXoNCiBlMEZwRmRFdjh3cUc5dExlK3RudDd5R09lQnhobzVG M0EvaFUxRmRGcm5tSnVMdWo1OCtJbmhDZndUcXR2ck9oUEl0a1pBVWINCiBPVEEvOTBudUQyL0t1 MzhYYTFENGsrRGsrb2dBTklrZTlSL0RJSFVFZm5YYitLdE1oMWp3N3FGamNiZGtzTFlMZEZZY2cv Z1ENCiBEWGpQdyt0cHRaK0hIaWpSNDFNa2lTUnlSS1A3eC84QXJwWG16cCt5bktFTnBKNmVaOWZo OFY5ZXc5UEVWMzc5R2NidnZGdnINCiAvWDVub1B3Z3NVLzRRTFI1Wmt6SWp6U3g1L2h5N0RQNVov T2l1czBIVDAwblJiS3dqKzdid3JIbjFJSEovT2l1NmxEa2dvK1INCiA4emphL3dCWXhFNnEyYmJY emR5OVhsdngzdFZObm9lb1RSbVMydHJvcEtvN3EyMGtmanN4WHFWWlhpblJvZkVHZzNtbXo4Q1oN CiBNSzJNN0dIS3QrQnhTcjAvYVUzRkdtVzRsWVhGUXJTMlQxOUhvL3daeTJoV2wvWmFmRGUrQzcr TFVkR2xHNWJHOGM1ajlRa24NCiBVWTlHclhUeGZGYi9BQzYxcG1wNmE0Nmw0RExIK0R4NUdLNUx3 UnA5N2J4elJhVk9tbjY3WkVSMzJuekFtQzV4OTJRQWNydUcNCiBQbUhldXpqOFNTVzQyNjFwVjla U0RxOGNadUl2d2RBY2ZpQldOS1Q1VTcyL0wvZ2VoNkdNcEoxWEZybjgwN1M4dktWOTdwTy8NCiBY c04vNFRqdzVqL2tLUjU5Tmo1L0xHYWlmeGZIY2ZMb3VsNm5xVWgrNlZnTU1mNHZKZ1lxNS93bGVo NHovYUVXZlRhMjc4c1oNCiBxS1R4STA0MjZOcFYvZlNIb3p4bUNMOFhjRDlBYTBjMy9Ndmt2K0N6 a1ZDSzE5akwvdDUyWHowaithTUhXN0RVZFFzWnJ6eHANCiBxRVduYU5FTjdXTm81K2NkaEpKMVAw V3N6NEMyWWowblY3MUVLdzNOeUZqSCt5b1Avd0FWVUhqNnd2NzhXOWxxZHdsNXJkODINCiB5MDAr M3lJTFpmNHBXN3NRTS9NY2ZUaXZSdkRPanc2RG9WbnB0dnlzQ0FGc1kzTjFadnhPVFdNSWMxYm10 dDkrcDZHSnJxamwNCiA3cGN5dk5yUkt5U1hWZFhycGQ3MjYydWFkRkZGZHA4NEZGRkZBR0xydWdS NmpjUlgxcE0xbHFzQXhGZFJqSngvZGNkR1gyUDQNCiBWRkRxOS9aZ1I2M3BzdTRmOHZOa3BtaWIz d1BuWDZZUDFvb3JLYTVieVIyNGVick9OR3BxdW5kZWovUjNRLzhBNFNyUmZOMmYNCiBhLzMyTStY NUw3LysrZHVham4xZlVyNEdMUTlObFVuL0FKZXI1VEZHdnVGKyszMHdCNzBVVmpUcXlxUGxlaDM0 dkEwc0pCVkkNCiArOTY3ZmhZbDhQOEFoK0xTNXByeTRtZTkxVzQvMTEzS01NUi9kVWRGVWVncmJv b3JxakZSVmtlUFZxenF5NXB1N0NpaWltWm4NCiAvOWs9DQoNClgtTVMtT0wtREVTSUdOO0NIQVJT RVQ9dXRmLTg6PGNhcmQgeG1sbnM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNl L291dGxvb2svMTIvZWxlY3Ryb25pY2J1c2luZXNzY2FyZHMiIHZlcj0iMS4wIiBsYXlvdXQ9Imxl ZnQiIGJnY29sb3I9ImZmZmZmZiI+PGltZyB4bWxucz0iIiBhbGlnbj0idGxlZnQiIGFyZWE9IjE1 IiB1c2U9InBob3RvIi8+PGZsZCB4bWxucz0iIiBwcm9wPSJuYW1lIiBhbGlnbj0ibGVmdCIgZGly PSJsdHIiIGNvbG9yPSIwMDAwMDAiIHNpemU9IjEwIi8+PGZsZCB4bWxucz0iIiBwcm9wPSJ0aXRs ZSIgYWxpZ249ImxlZnQiIGRpcj0ibHRyIiBjb2xvcj0iMDAwMDAwIiBzaXplPSI4Ii8+PGZsZCB4 bWxucz0iIiBwcm9wPSJ0ZXh0MSIgYWxpZ249ImxlZnQiIGRpcj0ibHRyIiBjb2xvcj0iMDAwMDAw IiBzaXplPSI4Ii8+PGZsZCB4bWxucz0iIiBwcm9wPSJibGFuayIgc2l6ZT0iOCIvPjxmbGQgeG1s bnM9IiIgcHJvcD0ib3JnIiBhbGlnbj0ibGVmdCIgZGlyPSJsdHIiIHN0eWxlPSJiIiBjb2xvcj0i MDAwMDAwIiBzaXplPSI4Ii8+PGZsZCB4bWxucz0iIiBwcm9wPSJhZGRyd29yayIgYWxpZ249Imxl ZnQiIGRpcj0ibHRyIiBjb2xvcj0iMDAwMDAwIiBzaXplPSI4Ii8+PGZsZCB4bWxucz0iIiBwcm9w PSJ0ZWx3b3JrIiBhbGlnbj0ibGVmdCIgZGlyPSJsdHIiIGNvbG9yPSIwMDAwMDAiIHNpemU9Ijgi PjxsYWJlbCBhbGlnbj0ibGVmdCIgY29sb3I9IjAwMDAwMCI+T2ZmaWNlPC9sYWJlbD48L2ZsZD48 ZmxkIHhtbG5zPSIiIHByb3A9InRlbGNlbGwiIGFsaWduPSJsZWZ0IiBkaXI9Imx0ciIgY29sb3I9 IjAwMDAwMCIgc2l6ZT0iOCI+PGxhYmVsIGFsaWduPSJsZWZ0IiBjb2xvcj0iMDAwMDAwIj5Nb2Jp bGU8L2xhYmVsPjwvZmxkPjxmbGQgeG1sbnM9IiIgcHJvcD0iZW1haWwiIGFsaWduPSJsZWZ0IiBk aXI9Imx0ciIgY29sb3I9IjAwMDAwMCIgc2l6ZT0iOCIvPjxmbGQgeG1sbnM9IiIgcHJvcD0iYmxh bmsiIHNpemU9IjgiLz48ZmxkIHhtbG5zPSIiIHByb3A9ImJsYW5rIiBzaXplPSI4Ii8+PGZsZCB4 bWxucz0iIiBwcm9wPSJibGFuayIgc2l6ZT0iOCIvPjxmbGQgeG1sbnM9IiIgcHJvcD0iYmxhbmsi IHNpemU9IjgiLz48ZmxkIHhtbG5zPSIiIHByb3A9ImJsYW5rIiBzaXplPSI4Ii8+PGZsZCB4bWxu cz0iIiBwcm9wPSJibGFuayIgc2l6ZT0iOCIvPjxmbGQgeG1sbnM9IiIgcHJvcD0iYmxhbmsiIHNp emU9IjgiLz48L2NhcmQ+DQpSRVY6MjAxMTA0MTRUMTQwNzIzWg0KRU5EOlZDQVJEDQo= --_002_8584590C8D7DD141AA96D01920FC6C698C896B71gbplmail03genba_-- From christer.holmberg@ericsson.com Thu Sep 15 22:32: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 E555A21F8AB0 for ; Thu, 15 Sep 2011 22:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 P8v8bDGK+Tid for ; Thu, 15 Sep 2011 22:32:08 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9E53821F8AAF for ; Thu, 15 Sep 2011 22:32:07 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f5-4e72dfdb5049 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C2.84.20773.BDFD27E4; Fri, 16 Sep 2011 07:34:19 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 16 Sep 2011 07:34:19 +0200 From: Christer Holmberg To: Roni Even , Magnus Westerlund , "rtcweb@ietf.org" Date: Fri, 16 Sep 2011 07:34:18 +0200 Thread-Topic: [rtcweb] AVPF vs AVP Thread-Index: Acxy8IefSwNpefInRDiRlAjJbviBHwAvLJWQACE6AAA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233F1E3F6@ESESSCMS0356.eemea.ericsson.se> References: <4E70C387.1070707@ericsson.com> <4e72059c.e829440a.4094.ffffb025@mx.google.com> In-Reply-To: <4e72059c.e829440a.4094.ffffb025@mx.google.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] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 05:32:09 -0000 Hi Roni,=20 >As for using AVPF while signaling AVP that will confuse=20 >endpoint that so not understand this convention and can=20 >support AVPF. They will see an offer with AVP but with=20 >parameters that are not part of AVP. They can respond with=20 >AVP without the AVPF parameter and behave like AVP endpoints=20 >even though they support AVPF. This will prevent them from=20 >sending AVPF feedback messages. > >This may be a problem for what you call "legacy" video=20 >conferencing endpoint. (I do not like the term legacy here=20 >since these are not legacy endpoint but AVP/AVPF compliant EPs=20 Do those devices support CapNeg? Regards, Christer > > -----Original Message----- > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On=20 > > Behalf Of Magnus Westerlund > > Sent: Wednesday, September 14, 2011 6:09 PM > > To: rtcweb@ietf.org > > Subject: [rtcweb] AVPF vs AVP > >=20 > > Hi, > >=20 > > There has been this long thread with the subject partially=20 > containing=20 > > "AVPF". I want to clarify something in this context around AVPF.=20 > > Rather than the SRTP question. > >=20 > > An end-point that is AVPF compliant is in fact=20 > interoperable with an=20 > > AVP one as long as the trr-int parameter is set reasonably large. A=20 > > parameter value of 1.5-5 seconds (I would recommend 3s) will ensure=20 > > that they are in fact compatible. This avoids the risk of any side=20 > > timing out the other if the AVP side is using the default 5=20 > s minimum=20 > > interval. > >=20 > > Based on this one could in fact have the RTCWEB nodes=20 > always use AVPF=20 > > for RTP/RTCP Behavior. The AVPF feedback messages are explicitly=20 > > negotiated and will only be used when agreed on. > >=20 > > This leaves us with any signaling incompatibilities when=20 > talking to a=20 > > legacy device. If one don't want to use cap-neg I see two=20 > directions=20 > > to > > go: > >=20 > > 1) RTCWEB end-point will always signal AVPF or SAVPF. I signalling=20 > > gateway to legacy will change that by removing the F to AVP or SAVP. > >=20 > > 2) RTCWEB end-point will always use AVPF but signal it as=20 > AVP. It will=20 > > detect the AVPF capabilities of the other end-point based on the=20 > > signaling of the feedback events intended to be used. > >=20 > > I think 1) is cleaner for the future. 2) might be more pragmatic. > >=20 > > In both cases I believe there are methods for negotiating a lower=20 > > trr-int than some AVP fallback value to preserve interoperability. > >=20 > >=20 > > However, this still don't resolve the question if the "S"=20 > should be in=20 > > front of the RTP profile indicator or not. But it might help by=20 > > removing the F or not in the profile. > >=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 ron.even.tlv@gmail.com Thu Sep 15 22:42: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 099F021F8B8F for ; Thu, 15 Sep 2011 22:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AU+xxJ7J54+Z for ; Thu, 15 Sep 2011 22:42:45 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 692FF21F8B4C for ; Thu, 15 Sep 2011 22:42:45 -0700 (PDT) Received: by pzk33 with SMTP id 33so350099pzk.4 for ; Thu, 15 Sep 2011 22:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=F7SKDa91ApS+1yy+zFY4NL2a+xlvsIwUgXQznEWYAow=; b=d0LDlTb8plWy5XKJ4xiKjBH5E4aX436dvXeqoEhS4lRUNsCxK9S/eCjeD+UuDv1o4H kSa5Oirz3ukjs+IVI4iYLrgGAGyKodwx6s5b3b8irETtYsjejwNeb0eDFZI2uzFdZGAR Z+33nVeYvxWn8QjypeeCoJ7mzAPYC71FLPOdY= Received: by 10.68.44.129 with SMTP id e1mr3082033pbm.113.1316151898518; Thu, 15 Sep 2011 22:44:58 -0700 (PDT) Received: from windows8d787f9 ([59.37.10.82]) by mx.google.com with ESMTPS id 4sm29912064pbk.5.2011.09.15.22.44.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 22:44:57 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" References: <4E70C387.1070707@ericsson.com> <4e72059c.e829440a.4094.ffffb025@mx.google.com> <4E722269.30304@ericsson.com> In-Reply-To: <4E722269.30304@ericsson.com> Date: Fri, 16 Sep 2011 08:43:31 +0300 Message-ID: <4e72e259.4401440a.4bc3.ffffd7d2@mx.google.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: AcxzwV8zx0ZJbyF8Sausjk/9knnSngAccuog Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 05:42:46 -0000 Magnus, I can agree that if you are doing video call you must send AVPF = regardless if you are talking with this type of systems that you call "not legacy" = or systems that you call "legacy". This must be a MUST in the text = otherwise the so called "legacy" end point will think it is AVP and will not send feedback messages which will break video conferencing applications.=20 Roni > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, September 15, 2011 7:06 PM > To: Roni Even > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] AVPF vs AVP >=20 > On 2011-09-15 16:01, Roni Even wrote: > > Magnus, > > I noticed that you claim that all AVPF feedback messages are > explicitly > > negotiated, is this a requirement. At least RTCP-SR-REQ is not > negotiated in > > SDP. >=20 > You are correct, had not actually noticed that. Fortunately that isn't > an real issue. >=20 > First of all the support of AVPF can still be negotiated with the > a=3Drtcp-fb. Simply the trr-int configuration lets both side show = support > of AVPF. >=20 > Secondly, for the RTCP-SR-REQ if one uses the header extension to > deliver the synch data then that is explicitly indicated. And if you > ignore or don't understand the request then you simple fall back to > normal synchronization procedures with more delay before completing = it. >=20 > > > > As for using AVPF while signaling AVP that will confuse endpoint = that > so not > > understand this convention and can support AVPF. They will see an > offer with > > AVP but with parameters that are not part of AVP. They can respond > with AVP > > without the AVPF parameter and behave like AVP endpoints even though > they > > support AVPF. This will prevent them from sending AVPF feedback > messages. >=20 > They can still use AVPF timing rules, even if the other end-point is > AVP > only. They only need to restrict themselves from sending feedback > messages. >=20 > > This may be a problem for what you call "legacy" video conferencing > > endpoint. (I do not like the term legacy here since these are not > legacy > > endpoint but AVP/AVPF compliant EPs >=20 > Yes, I agree it is not without issues in that regard. >=20 > I would also like to note that if you require AVPF and don't think > talking to AVP only end-points then one really should include the AVPF > in the m=3D line to prevent fallback. >=20 > > > > I think that if we are not going to use cap-neg we should make it > > historical. >=20 > I kind of agree with that also. But if it constantly fails in the > market > I think we have to recognize that and do something else that works > better. >=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 > ---------------------------------------------------------------------- From ron.even.tlv@gmail.com Thu Sep 15 22:48: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 05A3C21F8BA7 for ; Thu, 15 Sep 2011 22:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uke1A3Wa7dNx for ; Thu, 15 Sep 2011 22:48:12 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7B321F8BA6 for ; Thu, 15 Sep 2011 22:48:12 -0700 (PDT) Received: by yie12 with SMTP id 12so3144855yie.31 for ; Thu, 15 Sep 2011 22:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=tCAq7YGSdM3CzULpurdC3IBegP0rSqMZ5bQmShtFQA4=; b=cdpgOSgZMCwkmwNFLtMR+mbmiPmohh5kOqH3ovSeMVoAUbXMGFz1DZidIh12Uw7kTV 2HwRVwhU0kFtVzKC0Qt5l0HzEQ/ZLRvixxEAFcsRmEkFsQugZ1IU9yqscPbjsN5ePalL 1VLmSvoEai8qoRUgAH9gRfEDRpKJm44TPG1VQ= Received: by 10.68.16.196 with SMTP id i4mr1680957pbd.512.1316152225109; Thu, 15 Sep 2011 22:50:25 -0700 (PDT) Received: from windows8d787f9 ([59.37.10.82]) by mx.google.com with ESMTPS id i8sm8466833pbl.2.2011.09.15.22.50.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 22:50:24 -0700 (PDT) From: "Roni Even" To: "'Christer Holmberg'" , "'Magnus Westerlund'" , References: <4E70C387.1070707@ericsson.com> <4e72059c.e829440a.4094.ffffb025@mx.google.com> <7F2072F1E0DE894DA4B517B93C6A05852233F1E3F6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F1E3F6@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 16 Sep 2011 08:49:00 +0300 Message-ID: <4e72e3a0.e829440a.4094.0760@mx.google.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: Acxy8IefSwNpefInRDiRlAjJbviBHwAvLJWQACE6AAAAAGah0A== Content-Language: en-us Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 05:48:13 -0000 Christer, This is not the issue, since the capneg talks about how to address the systems that do not support it. In the current proposal it will work as long as it will have a = distinction when to send AVP or AVPF and for video calls it must say that you MUST = send AVPF regardless of what is the system on the other side otherwise it = will fail to achieve a reasonable video call. What I object is to always sending AVP with AVPF information. This usage should be based on the type of media that is being used (video MUST = always use AVPF!!!!) Roni > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, September 16, 2011 8:34 AM > To: Roni Even; Magnus Westerlund; rtcweb@ietf.org > Subject: RE: [rtcweb] AVPF vs AVP >=20 >=20 > Hi Roni, >=20 > >As for using AVPF while signaling AVP that will confuse > >endpoint that so not understand this convention and can > >support AVPF. They will see an offer with AVP but with > >parameters that are not part of AVP. They can respond with > >AVP without the AVPF parameter and behave like AVP endpoints > >even though they support AVPF. This will prevent them from > >sending AVPF feedback messages. > > > >This may be a problem for what you call "legacy" video > >conferencing endpoint. (I do not like the term legacy here > >since these are not legacy endpoint but AVP/AVPF compliant EPs >=20 > Do those devices support CapNeg? >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > > -----Original Message----- > > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > > Behalf Of Magnus Westerlund > > > Sent: Wednesday, September 14, 2011 6:09 PM > > > To: rtcweb@ietf.org > > > Subject: [rtcweb] AVPF vs AVP > > > > > > Hi, > > > > > > There has been this long thread with the subject partially > > containing > > > "AVPF". I want to clarify something in this context around AVPF. > > > Rather than the SRTP question. > > > > > > An end-point that is AVPF compliant is in fact > > interoperable with an > > > AVP one as long as the trr-int parameter is set reasonably large. = A > > > parameter value of 1.5-5 seconds (I would recommend 3s) will = ensure > > > that they are in fact compatible. This avoids the risk of any side > > > timing out the other if the AVP side is using the default 5 > > s minimum > > > interval. > > > > > > Based on this one could in fact have the RTCWEB nodes > > always use AVPF > > > for RTP/RTCP Behavior. The AVPF feedback messages are explicitly > > > negotiated and will only be used when agreed on. > > > > > > This leaves us with any signaling incompatibilities when > > talking to a > > > legacy device. If one don't want to use cap-neg I see two > > directions > > > to > > > go: > > > > > > 1) RTCWEB end-point will always signal AVPF or SAVPF. I signalling > > > gateway to legacy will change that by removing the F to AVP or > SAVP. > > > > > > 2) RTCWEB end-point will always use AVPF but signal it as > > AVP. It will > > > detect the AVPF capabilities of the other end-point based on the > > > signaling of the feedback events intended to be used. > > > > > > I think 1) is cleaner for the future. 2) might be more pragmatic. > > > > > > In both cases I believe there are methods for negotiating a lower > > > trr-int than some AVP fallback value to preserve interoperability. > > > > > > > > > However, this still don't resolve the question if the "S" > > should be in > > > front of the RTP profile indicator or not. But it might help by > > > removing the F or not in the profile. > > > > > > 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 > > =3D From christer.holmberg@ericsson.com Thu Sep 15 22:48: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 7256721F8BAB for ; Thu, 15 Sep 2011 22:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 NwcB6ijT1Blf for ; Thu, 15 Sep 2011 22:48:21 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 51F5521F8BAA for ; Thu, 15 Sep 2011 22:48:21 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-16-4e72e3a90735 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E9.16.20773.9A3E27E4; Fri, 16 Sep 2011 07:50:33 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 16 Sep 2011 07:50:33 +0200 From: Christer Holmberg To: Roni Even , Magnus Westerlund Date: Fri, 16 Sep 2011 07:50:31 +0200 Thread-Topic: [rtcweb] AVPF vs AVP Thread-Index: AcxzwV8zx0ZJbyF8Sausjk/9knnSngAccuogAABA7PA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233F1E40A@ESESSCMS0356.eemea.ericsson.se> References: <4E70C387.1070707@ericsson.com> <4e72059c.e829440a.4094.ffffb025@mx.google.com> <4E722269.30304@ericsson.com> <4e72e259.4401440a.4bc3.ffffd7d2@mx.google.com> In-Reply-To: <4e72e259.4401440a.4bc3.ffffd7d2@mx.google.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] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 05:48:22 -0000 Hi,=20 >I can agree that if you are doing video call you must send=20 >AVPF regardless if you are talking with this type of systems=20 >that you call "not legacy" or systems that you call "legacy".=20 >This must be a MUST in the text otherwise the so called=20 >"legacy" end point will think it is AVP and will not send=20 >feedback messages which will break video conferencing applications.=20 If the video conf app *requires* AVPF, you should include AVPF in the m=3D = line. The AVP+a=3Drtcp-fb proposal is an alternative to CapNeg, where there is "b= uilt-in" fallback to AVP in case the answerer does not support AVPF. And, IF we choose to go forward with this proposal, it should also be adopt= ed by CLUE. Regards, Christer > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Thursday, September 15, 2011 7:06 PM > > To: Roni Even > > Cc: rtcweb@ietf.org > > Subject: Re: [rtcweb] AVPF vs AVP > >=20 > > On 2011-09-15 16:01, Roni Even wrote: > > > Magnus, > > > I noticed that you claim that all AVPF feedback messages are > > explicitly > > > negotiated, is this a requirement. At least RTCP-SR-REQ is not > > negotiated in > > > SDP. > >=20 > > You are correct, had not actually noticed that. Fortunately=20 > that isn't=20 > > an real issue. > >=20 > > First of all the support of AVPF can still be negotiated with the=20 > > a=3Drtcp-fb. Simply the trr-int configuration lets both side show=20 > > support of AVPF. > >=20 > > Secondly, for the RTCP-SR-REQ if one uses the header extension to=20 > > deliver the synch data then that is explicitly indicated.=20 > And if you=20 > > ignore or don't understand the request then you simple fall back to=20 > > normal synchronization procedures with more delay before=20 > completing it. > >=20 > > > > > > As for using AVPF while signaling AVP that will confuse endpoint=20 > > > that > > so not > > > understand this convention and can support AVPF. They will see an > > offer with > > > AVP but with parameters that are not part of AVP. They can respond > > with AVP > > > without the AVPF parameter and behave like AVP endpoints=20 > even though > > they > > > support AVPF. This will prevent them from sending AVPF feedback > > messages. > >=20 > > They can still use AVPF timing rules, even if the other=20 > end-point is=20 > > AVP only. They only need to restrict themselves from=20 > sending feedback=20 > > messages. > >=20 > > > This may be a problem for what you call "legacy" video=20 > conferencing=20 > > > endpoint. (I do not like the term legacy here since these are not > > legacy > > > endpoint but AVP/AVPF compliant EPs > >=20 > > Yes, I agree it is not without issues in that regard. > >=20 > > I would also like to note that if you require AVPF and don't think=20 > > talking to AVP only end-points then one really should=20 > include the AVPF=20 > > in the m=3D line to prevent fallback. > >=20 > > > > > > I think that if we are not going to use cap-neg we should make it=20 > > > historical. > >=20 > > I kind of agree with that also. But if it constantly fails in the=20 > > market I think we have to recognize that and do something else that=20 > > works better. > >=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 > = From christer.holmberg@ericsson.com Thu Sep 15 22:51: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 4E87121F8B5F for ; Thu, 15 Sep 2011 22:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 NzBvIMXxksOd for ; Thu, 15 Sep 2011 22:51:38 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2574A21F8B72 for ; Thu, 15 Sep 2011 22:51:37 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-14-4e72e46f9a06 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A3.66.20773.F64E27E4; Fri, 16 Sep 2011 07:53:51 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 16 Sep 2011 07:53:50 +0200 From: Christer Holmberg To: Roni Even , Magnus Westerlund , "rtcweb@ietf.org" Date: Fri, 16 Sep 2011 07:53:49 +0200 Thread-Topic: [rtcweb] AVPF vs AVP Thread-Index: Acxy8IefSwNpefInRDiRlAjJbviBHwAvLJWQACE6AAAAAGah0AAAOS3w Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233F1E40F@ESESSCMS0356.eemea.ericsson.se> References: <4E70C387.1070707@ericsson.com> <4e72059c.e829440a.4094.ffffb025@mx.google.com> <7F2072F1E0DE894DA4B517B93C6A05852233F1E3F6@ESESSCMS0356.eemea.ericsson.se> <4e72e3a0.e829440a.4094.0760@mx.google.com> In-Reply-To: <4e72e3a0.e829440a.4094.0760@mx.google.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] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 05:51:39 -0000 Hi,=20 >This is not the issue, since the capneg talks about how to=20 >address the systems that do not support it. I think it is. Because, if they don't support CapNeg, they will still end u= p using AVP - even if they support AVPF - because that is the only thing th= ey will understand in the offer. >In the current proposal it will work as long as it will have=20 >a distinction when to send AVP or AVPF and for video calls it=20 >must say that you MUST send AVPF regardless of what is the=20 >system on the other side otherwise it will fail to achieve a=20 >reasonable video call. >What I object is to always sending AVP with AVPF information.=20 >This usage should be based on the type of media that is being=20 >used (video MUST always use AVPF!!!!) Roni I don't anyone has suggested that you are not allowed to mandate AVPF for v= ideo. You can do that by including AVPF in the video m=3D line. Regards, Christer > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Friday, September 16, 2011 8:34 AM > > To: Roni Even; Magnus Westerlund; rtcweb@ietf.org > > Subject: RE: [rtcweb] AVPF vs AVP > >=20 > >=20 > > Hi Roni, > >=20 > > >As for using AVPF while signaling AVP that will confuse=20 > endpoint that=20 > > >so not understand this convention and can support AVPF.=20 > They will see=20 > > >an offer with AVP but with parameters that are not part of=20 > AVP. They=20 > > >can respond with AVP without the AVPF parameter and behave=20 > like AVP=20 > > >endpoints even though they support AVPF. This will prevent=20 > them from=20 > > >sending AVPF feedback messages. > > > > > >This may be a problem for what you call "legacy" video=20 > conferencing=20 > > >endpoint. (I do not like the term legacy here since these are not=20 > > >legacy endpoint but AVP/AVPF compliant EPs > >=20 > > Do those devices support CapNeg? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > > > > -----Original Message----- > > > > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On=20 > > > > Behalf Of Magnus Westerlund > > > > Sent: Wednesday, September 14, 2011 6:09 PM > > > > To: rtcweb@ietf.org > > > > Subject: [rtcweb] AVPF vs AVP > > > > > > > > Hi, > > > > > > > > There has been this long thread with the subject partially > > > containing > > > > "AVPF". I want to clarify something in this context around AVPF. > > > > Rather than the SRTP question. > > > > > > > > An end-point that is AVPF compliant is in fact > > > interoperable with an > > > > AVP one as long as the trr-int parameter is set=20 > reasonably large.=20 > > > > A parameter value of 1.5-5 seconds (I would recommend 3s) will=20 > > > > ensure that they are in fact compatible. This avoids=20 > the risk of=20 > > > > any side timing out the other if the AVP side is using=20 > the default=20 > > > > 5 > > > s minimum > > > > interval. > > > > > > > > Based on this one could in fact have the RTCWEB nodes > > > always use AVPF > > > > for RTP/RTCP Behavior. The AVPF feedback messages are=20 > explicitly=20 > > > > negotiated and will only be used when agreed on. > > > > > > > > This leaves us with any signaling incompatibilities when > > > talking to a > > > > legacy device. If one don't want to use cap-neg I see two > > > directions > > > > to > > > > go: > > > > > > > > 1) RTCWEB end-point will always signal AVPF or SAVPF. I=20 > signalling=20 > > > > gateway to legacy will change that by removing the F to AVP or > > SAVP. > > > > > > > > 2) RTCWEB end-point will always use AVPF but signal it as > > > AVP. It will > > > > detect the AVPF capabilities of the other end-point=20 > based on the=20 > > > > signaling of the feedback events intended to be used. > > > > > > > > I think 1) is cleaner for the future. 2) might be more=20 > pragmatic. > > > > > > > > In both cases I believe there are methods for=20 > negotiating a lower=20 > > > > trr-int than some AVP fallback value to preserve=20 > interoperability. > > > > > > > > > > > > However, this still don't resolve the question if the "S" > > > should be in > > > > front of the RTP profile indicator or not. But it might help by=20 > > > > removing the F or not in the profile. > > > > > > > > Cheers > > > > > > > > Magnus Westerlund > > > > > > > > > > >=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:=20 > > > > magnus.westerlund@ericsson.com > > > > > > >=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 > > > =3D >=20 > = From ron.even.tlv@gmail.com Thu Sep 15 23:19: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 1FA9E21F8BBA for ; Thu, 15 Sep 2011 23:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4ClTPcpT8yX for ; Thu, 15 Sep 2011 23:19:31 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 35E1B21F8BB8 for ; Thu, 15 Sep 2011 23:19:31 -0700 (PDT) Received: by gwb17 with SMTP id 17so4065479gwb.15 for ; Thu, 15 Sep 2011 23:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=DgBWUCCont50sc7MK/OfGzvT0Y5V4HBcH4x+zzDgjVg=; b=oi4bt3A/PSEiY/Gck2JcW5YadUwQ2t4SDZVhMKu/ydl5a4H5rbFi+RIwzwHxoY+mwI ij3WzfqytzEftauafL7XLbwaI2olQGEQoDxLrlY+1BNV+Vd92yQ0DwtF+Qep2TKu4tqm WPeSqmY/HGb2kDi5nxO+U1Kd0jMcEbwvtzdl4= Received: by 10.68.36.35 with SMTP id n3mr798046pbj.112.1316154103159; Thu, 15 Sep 2011 23:21:43 -0700 (PDT) Received: from windows8d787f9 ([59.37.10.82]) by mx.google.com with ESMTPS id e3sm30140519pbi.7.2011.09.15.23.21.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 23:21:42 -0700 (PDT) From: "Roni Even" To: "'Christer Holmberg'" , "'Magnus Westerlund'" , References: <4E70C387.1070707@ericsson.com> <4e72059c.e829440a.4094.ffffb025@mx.google.com> <7F2072F1E0DE894DA4B517B93C6A05852233F1E3F6@ESESSCMS0356.eemea.ericsson.se> <4e72e3a0.e829440a.4094.0760@mx.google.com> <7F2072F1E0DE894DA4B517B93C6A05852233F1E40F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F1E40F@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 16 Sep 2011 09:20:15 +0300 Message-ID: <4e72eaf6.0320440a.4697.ffffe053@mx.google.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: Acxy8IefSwNpefInRDiRlAjJbviBHwAvLJWQACE6AAAAAGah0AAAOS3wAADQGyA= Content-Language: en-us Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 06:19:32 -0000 Christer, You can start with avpf asin the offer in capneg and not AVP depending = on the media type. Typically for audio you will have avp and video avpf As for the current proposal what I said is that if you are offering = video I think that the text should mandate offering AVPF if and not AVP with the AVPF parameters. Otherwise it will break with what is called "legacy" = that support AVPF and the important feedback messages like (FIR, PLI, TMBBR, etc.) will not be sent form the "legacy" answerer and may be ignored = when received from by the answerer since the offer was for AVP. Roni > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, September 16, 2011 8:54 AM > To: Roni Even; Magnus Westerlund; rtcweb@ietf.org > Subject: RE: [rtcweb] AVPF vs AVP >=20 >=20 > Hi, >=20 > >This is not the issue, since the capneg talks about how to > >address the systems that do not support it. >=20 > I think it is. Because, if they don't support CapNeg, they will still > end up using AVP - even if they support AVPF - because that is the = only > thing they will understand in the offer. >=20 > >In the current proposal it will work as long as it will have > >a distinction when to send AVP or AVPF and for video calls it > >must say that you MUST send AVPF regardless of what is the > >system on the other side otherwise it will fail to achieve a > >reasonable video call. > >What I object is to always sending AVP with AVPF information. > >This usage should be based on the type of media that is being > >used (video MUST always use AVPF!!!!) Roni >=20 > I don't anyone has suggested that you are not allowed to mandate AVPF > for video. You can do that by including AVPF in the video m=3D line. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Friday, September 16, 2011 8:34 AM > > > To: Roni Even; Magnus Westerlund; rtcweb@ietf.org > > > Subject: RE: [rtcweb] AVPF vs AVP > > > > > > > > > Hi Roni, > > > > > > >As for using AVPF while signaling AVP that will confuse > > endpoint that > > > >so not understand this convention and can support AVPF. > > They will see > > > >an offer with AVP but with parameters that are not part of > > AVP. They > > > >can respond with AVP without the AVPF parameter and behave > > like AVP > > > >endpoints even though they support AVPF. This will prevent > > them from > > > >sending AVPF feedback messages. > > > > > > > >This may be a problem for what you call "legacy" video > > conferencing > > > >endpoint. (I do not like the term legacy here since these are not > > > >legacy endpoint but AVP/AVPF compliant EPs > > > > > > Do those devices support CapNeg? > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > -----Original Message----- > > > > > From: rtcweb-bounces@ietf.org > > [mailto:rtcweb-bounces@ietf.org] On > > > > > Behalf Of Magnus Westerlund > > > > > Sent: Wednesday, September 14, 2011 6:09 PM > > > > > To: rtcweb@ietf.org > > > > > Subject: [rtcweb] AVPF vs AVP > > > > > > > > > > Hi, > > > > > > > > > > There has been this long thread with the subject partially > > > > containing > > > > > "AVPF". I want to clarify something in this context around > AVPF. > > > > > Rather than the SRTP question. > > > > > > > > > > An end-point that is AVPF compliant is in fact > > > > interoperable with an > > > > > AVP one as long as the trr-int parameter is set > > reasonably large. > > > > > A parameter value of 1.5-5 seconds (I would recommend 3s) will > > > > > ensure that they are in fact compatible. This avoids > > the risk of > > > > > any side timing out the other if the AVP side is using > > the default > > > > > 5 > > > > s minimum > > > > > interval. > > > > > > > > > > Based on this one could in fact have the RTCWEB nodes > > > > always use AVPF > > > > > for RTP/RTCP Behavior. The AVPF feedback messages are > > explicitly > > > > > negotiated and will only be used when agreed on. > > > > > > > > > > This leaves us with any signaling incompatibilities when > > > > talking to a > > > > > legacy device. If one don't want to use cap-neg I see two > > > > directions > > > > > to > > > > > go: > > > > > > > > > > 1) RTCWEB end-point will always signal AVPF or SAVPF. I > > signalling > > > > > gateway to legacy will change that by removing the F to AVP or > > > SAVP. > > > > > > > > > > 2) RTCWEB end-point will always use AVPF but signal it as > > > > AVP. It will > > > > > detect the AVPF capabilities of the other end-point > > based on the > > > > > signaling of the feedback events intended to be used. > > > > > > > > > > I think 1) is cleaner for the future. 2) might be more > > pragmatic. > > > > > > > > > > In both cases I believe there are methods for > > negotiating a lower > > > > > trr-int than some AVP fallback value to preserve > > interoperability. > > > > > > > > > > > > > > > However, this still don't resolve the question if the "S" > > > > should be in > > > > > front of the RTP profile indicator or not. But it might help = by > > > > > removing the F or not in the profile. > > > > > > > > > > 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 > > > > =3D > > > > =3D From ron.even.tlv@gmail.com Thu Sep 15 23:24: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 C398A21F8BA4 for ; Thu, 15 Sep 2011 23:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 UMjnMoU8uC5Y for ; Thu, 15 Sep 2011 23:24:51 -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 ECF4221F8B90 for ; Thu, 15 Sep 2011 23:24:50 -0700 (PDT) Received: by ywa6 with SMTP id 6so3154082ywa.31 for ; Thu, 15 Sep 2011 23:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=BCaouhi3lkwDTLwoatCkR3c4bQsrma3ih0EBqRfOq+g=; b=SBg/BwM8GB1LAvJjYkl0iyN+la16JRG/8/prixgixFyq3uSk4zM1d980hfSikKhTpB 4Z9uZmCcdt2Imey/Mh9AO2H7BBnYSroi8ZOEFyoBmxjrQegQdEIs568vjV70IryUBUCW NpQFkwLNYWcqlNa7wvcKc4u/Dk2eBqsLRdVq0= Received: by 10.68.35.8 with SMTP id d8mr1091683pbj.415.1316154424237; Thu, 15 Sep 2011 23:27:04 -0700 (PDT) Received: from windows8d787f9 ([59.37.10.82]) by mx.google.com with ESMTPS id i3sm30157615pbg.10.2011.09.15.23.27.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 23:27:03 -0700 (PDT) From: "Roni Even" To: "'Christer Holmberg'" , "'Magnus Westerlund'" References: <4E70C387.1070707@ericsson.com> <4e72059c.e829440a.4094.ffffb025@mx.google.com> <4E722269.30304@ericsson.com> <4e72e259.4401440a.4bc3.ffffd7d2@mx.google.com> <7F2072F1E0DE894DA4B517B93C6A05852233F1E40A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F1E40A@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 16 Sep 2011 09:25:39 +0300 Message-ID: <4e72ec37.231a440a.0179.ffffe41b@mx.google.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: AcxzwV8zx0ZJbyF8Sausjk/9knnSngAccuogAABA7PAAAScegA== Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 06:24:51 -0000 Hi Christer, Again, the word is MUST for video. I think that systems that will = interwork with RTCWEB systems will support AVPF since they will need to support current video codecs. I do not see RTCWEB systems interwork with systems that support only H.261 or even H.263, so I assume that the interworking will be with systems that also use AVPF for video. As for CLUE, we can discuss it in CLUE if relevant at all. It may be relevant only for the video capture that should be used for interworking with non CLUE systems. =20 Roni > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, September 16, 2011 8:51 AM > To: Roni Even; Magnus Westerlund > Cc: rtcweb@ietf.org > Subject: RE: [rtcweb] AVPF vs AVP >=20 >=20 > Hi, >=20 > >I can agree that if you are doing video call you must send > >AVPF regardless if you are talking with this type of systems > >that you call "not legacy" or systems that you call "legacy". > >This must be a MUST in the text otherwise the so called > >"legacy" end point will think it is AVP and will not send > >feedback messages which will break video conferencing applications. >=20 > If the video conf app *requires* AVPF, you should include AVPF in the > m=3D line. >=20 > The AVP+a=3Drtcp-fb proposal is an alternative to CapNeg, where there = is > "built-in" fallback to AVP in case the answerer does not support AVPF. >=20 > And, IF we choose to go forward with this proposal, it should also be > adopted by CLUE. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Sent: Thursday, September 15, 2011 7:06 PM > > > To: Roni Even > > > Cc: rtcweb@ietf.org > > > Subject: Re: [rtcweb] AVPF vs AVP > > > > > > On 2011-09-15 16:01, Roni Even wrote: > > > > Magnus, > > > > I noticed that you claim that all AVPF feedback messages are > > > explicitly > > > > negotiated, is this a requirement. At least RTCP-SR-REQ is not > > > negotiated in > > > > SDP. > > > > > > You are correct, had not actually noticed that. Fortunately > > that isn't > > > an real issue. > > > > > > First of all the support of AVPF can still be negotiated with the > > > a=3Drtcp-fb. Simply the trr-int configuration lets both side show > > > support of AVPF. > > > > > > Secondly, for the RTCP-SR-REQ if one uses the header extension to > > > deliver the synch data then that is explicitly indicated. > > And if you > > > ignore or don't understand the request then you simple fall back = to > > > normal synchronization procedures with more delay before > > completing it. > > > > > > > > > > > As for using AVPF while signaling AVP that will confuse endpoint > > > > that > > > so not > > > > understand this convention and can support AVPF. They will see = an > > > offer with > > > > AVP but with parameters that are not part of AVP. They can > respond > > > with AVP > > > > without the AVPF parameter and behave like AVP endpoints > > even though > > > they > > > > support AVPF. This will prevent them from sending AVPF feedback > > > messages. > > > > > > They can still use AVPF timing rules, even if the other > > end-point is > > > AVP only. They only need to restrict themselves from > > sending feedback > > > messages. > > > > > > > This may be a problem for what you call "legacy" video > > conferencing > > > > endpoint. (I do not like the term legacy here since these are = not > > > legacy > > > > endpoint but AVP/AVPF compliant EPs > > > > > > Yes, I agree it is not without issues in that regard. > > > > > > I would also like to note that if you require AVPF and don't think > > > talking to AVP only end-points then one really should > > include the AVPF > > > in the m=3D line to prevent fallback. > > > > > > > > > > > I think that if we are not going to use cap-neg we should make = it > > > > historical. > > > > > > I kind of agree with that also. But if it constantly fails in the > > > market I think we have to recognize that and do something else = that > > > works better. > > > > > > 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 > > =3D From christer.holmberg@ericsson.com Thu Sep 15 23:27: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 57E8821F8B90 for ; Thu, 15 Sep 2011 23:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 zmLt8baTjJlz for ; Thu, 15 Sep 2011 23:27:37 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B424721F8B8C for ; Thu, 15 Sep 2011 23:27:36 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-f0-4e72ecdddd01 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 61.A7.02839.DDCE27E4; Fri, 16 Sep 2011 08:29:49 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 16 Sep 2011 08:29:49 +0200 From: Christer Holmberg To: Roni Even , Magnus Westerlund Date: Fri, 16 Sep 2011 08:29:47 +0200 Thread-Topic: [rtcweb] AVPF vs AVP Thread-Index: AcxzwV8zx0ZJbyF8Sausjk/9knnSngAccuogAABA7PAAAScegAAAP16w Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233F1E44A@ESESSCMS0356.eemea.ericsson.se> References: <4E70C387.1070707@ericsson.com> <4e72059c.e829440a.4094.ffffb025@mx.google.com> <4E722269.30304@ericsson.com> <4e72e259.4401440a.4bc3.ffffd7d2@mx.google.com> <7F2072F1E0DE894DA4B517B93C6A05852233F1E40A@ESESSCMS0356.eemea.ericsson.se> <4e72ec37.231a440a.0179.ffffe41b@mx.google.com> In-Reply-To: <4e72ec37.231a440a.0179.ffffe41b@mx.google.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] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 06:27:38 -0000 Hi,=20 >Again, the word is MUST for video. I think that systems that=20 >will interwork with RTCWEB systems will support AVPF since=20 >they will need to support current video codecs. I do not see=20 >RTCWEB systems interwork with systems that support only H.261=20 >or even H.263, so I assume that the interworking will be with=20 >systems that also use AVPF for video. > =20 >As for CLUE, we can discuss it in CLUE if relevant at all. It=20 >may be relevant only for the video capture that should be=20 >used for interworking with non CLUE systems. Correct.=20 Again, if we *mandate* the anyone involved in a session (CLUE session or so= mething else) supports AVPF, we can use AVPF in the m=3D line. Regards, Christer > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Friday, September 16, 2011 8:51 AM > > To: Roni Even; Magnus Westerlund > > Cc: rtcweb@ietf.org > > Subject: RE: [rtcweb] AVPF vs AVP > >=20 > >=20 > > Hi, > >=20 > > >I can agree that if you are doing video call you must send AVPF=20 > > >regardless if you are talking with this type of systems=20 > that you call=20 > > >"not legacy" or systems that you call "legacy". > > >This must be a MUST in the text otherwise the so called=20 > "legacy" end=20 > > >point will think it is AVP and will not send feedback=20 > messages which=20 > > >will break video conferencing applications. > >=20 > > If the video conf app *requires* AVPF, you should include=20 > AVPF in the=20 > > m=3D line. > >=20 > > The AVP+a=3Drtcp-fb proposal is an alternative to CapNeg,=20 > where there is=20 > > "built-in" fallback to AVP in case the answerer does not=20 > support AVPF. > >=20 > > And, IF we choose to go forward with this proposal, it=20 > should also be=20 > > adopted by CLUE. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > > > > -----Original Message----- > > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > > Sent: Thursday, September 15, 2011 7:06 PM > > > > To: Roni Even > > > > Cc: rtcweb@ietf.org > > > > Subject: Re: [rtcweb] AVPF vs AVP > > > > > > > > On 2011-09-15 16:01, Roni Even wrote: > > > > > Magnus, > > > > > I noticed that you claim that all AVPF feedback messages are > > > > explicitly > > > > > negotiated, is this a requirement. At least RTCP-SR-REQ is not > > > > negotiated in > > > > > SDP. > > > > > > > > You are correct, had not actually noticed that. Fortunately > > > that isn't > > > > an real issue. > > > > > > > > First of all the support of AVPF can still be=20 > negotiated with the=20 > > > > a=3Drtcp-fb. Simply the trr-int configuration lets both side show=20 > > > > support of AVPF. > > > > > > > > Secondly, for the RTCP-SR-REQ if one uses the header=20 > extension to=20 > > > > deliver the synch data then that is explicitly indicated. > > > And if you > > > > ignore or don't understand the request then you simple=20 > fall back=20 > > > > to normal synchronization procedures with more delay before > > > completing it. > > > > > > > > > > > > > > As for using AVPF while signaling AVP that will=20 > confuse endpoint=20 > > > > > that > > > > so not > > > > > understand this convention and can support AVPF. They=20 > will see=20 > > > > > an > > > > offer with > > > > > AVP but with parameters that are not part of AVP. They can > > respond > > > > with AVP > > > > > without the AVPF parameter and behave like AVP endpoints > > > even though > > > > they > > > > > support AVPF. This will prevent them from sending=20 > AVPF feedback > > > > messages. > > > > > > > > They can still use AVPF timing rules, even if the other > > > end-point is > > > > AVP only. They only need to restrict themselves from > > > sending feedback > > > > messages. > > > > > > > > > This may be a problem for what you call "legacy" video > > > conferencing > > > > > endpoint. (I do not like the term legacy here since these are=20 > > > > > not > > > > legacy > > > > > endpoint but AVP/AVPF compliant EPs > > > > > > > > Yes, I agree it is not without issues in that regard. > > > > > > > > I would also like to note that if you require AVPF and=20 > don't think=20 > > > > talking to AVP only end-points then one really should > > > include the AVPF > > > > in the m=3D line to prevent fallback. > > > > > > > > > > > > > > I think that if we are not going to use cap-neg we=20 > should make=20 > > > > > it historical. > > > > > > > > I kind of agree with that also. But if it constantly=20 > fails in the=20 > > > > market I think we have to recognize that and do something else=20 > > > > that works better. > > > > > > > > Cheers > > > > > > > > Magnus Westerlund > > > > > > > > > > >=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:=20 > > > > magnus.westerlund@ericsson.com > > > > > > >=20 > -------------------------------------------------------------------- > > > - > > - > > > > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > =3D >=20 > = From oej@edvina.net Thu Sep 15 23:29: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 BFADB21F8B90 for ; Thu, 15 Sep 2011 23:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwSjLUNr++vG for ; Thu, 15 Sep 2011 23:29:46 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC3221F8B8C for ; Thu, 15 Sep 2011 23:29:46 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id D1C1F754BCE4 for ; Fri, 16 Sep 2011 06:31:56 +0000 (UTC) From: "Olle E. Johansson" Content-Type: multipart/alternative; boundary="Apple-Mail=_475369E4-7522-45D2-AF56-03AC7BB64406" Date: Fri, 16 Sep 2011 08:32:34 +0200 Message-Id: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [rtcweb] Data transfer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 06:29:46 -0000 --Apple-Mail=_475369E4-7522-45D2-AF56-03AC7BB64406 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A comment on the list made me go back and re-read the charter. One thing = I had missed is the data transfer part of rtcweb. "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." Most of the discussions on the list has been about the media. What are = the ideas for data transfer? Applications? To me, this seems like an interesting feature. If it's a plain data = transfer session, a bidirectional session, it's a way to open a session = from Javascript to any server, acting as an rtcweb client, which is = different from the current sandbox model. I could have missed this = discussion, but if not, I think this is an interesting topic to bring = up. Another note, which I think is purely a mistake, is to forget realtime = text - T.140 and just state audio and video. The T.140 users are natural = early adoptor users of rtcweb. /O= --Apple-Mail=_475369E4-7522-45D2-AF56-03AC7BB64406 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii A = comment on the list made me go back and re-read the charter. One thing I = had missed is the data transfer part of rtcweb.

"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."
Most of the discussions on = the list has been about the media. What are the ideas for data transfer? = Applications?

To me, this = seems like an interesting feature. If it's a plain data transfer = session, a bidirectional session, it's a way to open a session from = Javascript to any server, acting as an rtcweb client, which is different = from the current sandbox model. I could have missed this discussion, but = if not, I think this is an interesting topic to bring = up.

Another note, which I think is purely a = mistake, is to forget realtime text - T.140 and just state audio and = video. The T.140 users are natural early adoptor users of = rtcweb.

/O
= --Apple-Mail=_475369E4-7522-45D2-AF56-03AC7BB64406-- From Ranjit.Avasarala@Polycom.com Thu Sep 15 23:30: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 4971D21F8B8C for ; Thu, 15 Sep 2011 23:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 ABHfSIoCYecz for ; Thu, 15 Sep 2011 23:30:56 -0700 (PDT) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 182CC21F8B90 for ; Thu, 15 Sep 2011 23:30:55 -0700 (PDT) Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Fri, 16 Sep 2011 14:33:08 +0800 From: "Avasarala, Ranjit" To: Hadriel Kaplan , Ravindran Parthasarathi Date: Fri, 16 Sep 2011 14:33:06 +0800 Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: AQHMdBfEi7FefEQ3sUO4/j8bw5yK0pVPjMTw Message-ID: <1F2A2C70609D9E41844A2126145FC09802D95E85@HKGMBOXPRD22.polycom.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> In-Reply-To: <16880306-5B3A-4EFD-ADE4-1201138D9182@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 06:30:57 -0000 Agree. Regards Ranjit -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Hadriel Kaplan Sent: Friday, September 16, 2011 7:55 AM To: Ravindran Parthasarathi Cc: Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defi= ning a signaling protocol for WebRTC (or not)] There is no need for a "default signaling protocol", because the "signaling= " is between the browser's Javascript and its web server. And as for the s= ignaling protocol the web server has to support in order to speak to other = servers or non-RTCweb endpoints, even if we specified to use SIP we'd just = be summarily ignored by those who don't want to, because they actually don'= t *need* to. It doesn't hurt interoperability of rtcweb if they don't impl= ement SIP - it just means they can't talk to other SIP devices/servers. Bu= t it's not like we need an RFC to say "if you don't implement X then you ca= n't talk to people who do X". Think of this RTCWEB concept as Skinny/SCCP. The Web Server is Call Manage= r, and the browser is the Skinny phone, but in this case instead of needing= a 7960 phone, the Skinny protocol was written in javascript and uses a bro= wser's user interface for its GUI and the built-in RTP library for media. (= in fact one could probably write a javascript to do just that, if Call Mana= ger handled SCCP over websocket) =20 Clearly the IETF does not need to define for Cisco a standardized replaceme= nt for the SCCP protocol for this to work, because one isn't needed since t= he client javascript and server are built by the same developers and they k= now how their proprietary signaling works. So how about for the signaling = Call Manager would use to other VoIP devices, like gateways or VoIP service= providers? Does the IETF need to tell Cisco what peer-to-peer protocol(s)= to implement on Call Manager? No, and we never have. Cisco's product man= agers decide that. They decide if Call Manager needs to be able to communi= cate a standard protocol at all, such as SIP or H.323, and which one/any of= those. They decide based on their use-cases/need. Some rtcweb developers may not do any standard signaling protocol, ever. F= or example many Instant Messaging providers still have closed environments = to this day. (e.g., AIM, YIM, MSN, etc.) Some may choose to only use H.323= , or XMPP, or IAX, or even BICC. Some may choose to only support SIP with = 3GPP extensions. Obviously most of us think/hope people do SIP, but really= the market makes those types of decisions, not the IETF. Just like the IE= TF standardized MGCP but didn't specify what the MGCP Call Agent had to sup= port to speak to other Call Agents. SIP was given as an example in MGCP, b= ut not mandated. The only thing we need to do for rtcweb is make sure the RTP library built = into the browser supports media in such a way that it can communicate with = other RTP peers at a media plane, regardless of what signaling protocol tho= se peers might be using, preferably without going through media gateways. = And obviously since SIP is a very common protocol and defined by the IETF w= e need to make sure it's possible to use SIP on the rtcweb server, but we c= an't *mandate* that it be used or supported, and if we did it wouldn't chan= ge anything.=20 -hadriel On Sep 15, 2011, at 7:56 PM, Ravindran Parthasarathi wrote: > I really didn't get your argument fully because in case there is no defau= lt signaling protocol, it is unavoidable to have island of devices without = gateways but you argue other way around.=20 >=20 > I specifically asked for the scope of your opinion on RTCWeb work is betw= een browser-to-browser or browser-to-other end-point to know whether parall= el universe has to be build or not. In case there is no default signaling p= rotocol, it is impossible to communicate between browser-to-endpoint withou= t gateways. Let us assume that the intention of RTCWeb is to create island = of browser devices even then the native signaling protocol for RTCWeb has a= dvantage over Jquery library and plugin is not the solution. >=20 > Having said that, I agree that it is possible to implement RTP or STUN or= SIP stack or codec using Javascript or plugins but interop and better perf= ormance is not guaranteed. >=20 > Thanks > Partha _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From saul@ag-projects.com Thu Sep 15 23:48: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 4807921F8BBC for ; Thu, 15 Sep 2011 23:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMeSqcbg8zwb for ; Thu, 15 Sep 2011 23:48:51 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id B6E7A21F8BAA for ; Thu, 15 Sep 2011 23:48:51 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 96C0DB01B8; Fri, 16 Sep 2011 08:51:04 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 01ABFB019A; Fri, 16 Sep 2011 08:51:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Fri, 16 Sep 2011 08:51:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6A37608C-95E1-4BDA-8F66-55E4785ABC2E@ag-projects.com> References: <6F469757-6B5C-4DC9-BC34-026F34C7E508@phonefromhere.com> <4E72384F.3080202@jesup.org> To: Roman Shpount X-Mailer: Apple Mail (2.1084) Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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, 16 Sep 2011 06:48:52 -0000 Hi, On Sep 15, 2011, at 7:52 PM, Roman Shpount wrote: > I don't think this is a problem for RTC web to resolve. This is the = same problem that someone building an IM or email client for a web = browser will need to deal with. Some type of push notification framework = is needed to implement this and it might be something for W3C to = standardize as a solution for this problem.=20 I fully agree here. AFAIK this group is not about getting applications = to run smoothly on mobile platforms, it's about realtime communications = within a browser. Having a JS SIP client on a browser might be OK for a = desktop, but mobiles will always need native apps because they can be = optimized for specific hardware and give a better user experience IMHO. = That being said, I don't think mobile battery consumption is important = in any way when discussing SIP over WebSocket. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Thu Sep 15 23:52: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 9E73621F8B3F for ; Thu, 15 Sep 2011 23:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EN55zUVRpZ9F for ; Thu, 15 Sep 2011 23:52:19 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD4121F8B3D for ; Thu, 15 Sep 2011 23:52:19 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id BA75BB01BB; Fri, 16 Sep 2011 08:54:32 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 1803FB019A; Fri, 16 Sep 2011 08:54:32 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Fri, 16 Sep 2011 08:54:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> To: Roman Shpount X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 06:52:19 -0000 Roman, On Sep 16, 2011, at 2:52 AM, Roman Shpount wrote: > Partha, >=20 > It is not possible to implement browser to browser calls unless both = browsers are on public IPs or on the same network. As far as signaling = is concerned, it is always going to be browser to server to browser = call. Since there is always a server on the signaling path and since = implementing a signaling gateway from long poll HTTP or websocket = signaling interface to SIP (as shown by a number of projects mentioned = in this thread) is straight forward enough to implement, there is no = desire to create a standard signaling protocol to be used in the = browser. There is no benefit for the application developer in following = this standard, since it provides neither more functionality no better = performance then a custom protocol implemented in JavaScript. Interop = and fragmentation arguments do not apply to this either, since it is the = same as complaining that HotMail and GMail use different protocols when = implementing web mail. It does not affect anything since this stays = within the same application and is no more then an implementation = detail. I couldn't have said it better :-) -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Thu Sep 15 23:54: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 C982921F8BB1 for ; Thu, 15 Sep 2011 23:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id At7z1toAOgQJ for ; Thu, 15 Sep 2011 23:54:30 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id CC07121F8B45 for ; Thu, 15 Sep 2011 23:54:29 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 67080B01BB; Fri, 16 Sep 2011 08:56:42 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 50204B019A; Fri, 16 Sep 2011 08:56:42 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> Date: Fri, 16 Sep 2011 08:56:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5AB3D485-BFA1-41D2-9D2A-F437A6551F98@ag-projects.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 06:54:30 -0000 +1 On Sep 16, 2011, at 4:24 AM, Hadriel Kaplan wrote: >=20 > There is no need for a "default signaling protocol", because the = "signaling" is between the browser's Javascript and its web server. And = as for the signaling protocol the web server has to support in order to = speak to other servers or non-RTCweb endpoints, even if we specified to = use SIP we'd just be summarily ignored by those who don't want to, = because they actually don't *need* to. It doesn't hurt interoperability = of rtcweb if they don't implement SIP - it just means they can't talk to = other SIP devices/servers. But it's not like we need an RFC to say "if = you don't implement X then you can't talk to people who do X". >=20 > Think of this RTCWEB concept as Skinny/SCCP. The Web Server is Call = Manager, and the browser is the Skinny phone, but in this case instead = of needing a 7960 phone, the Skinny protocol was written in javascript = and uses a browser's user interface for its GUI and the built-in RTP = library for media. (in fact one could probably write a javascript to do = just that, if Call Manager handled SCCP over websocket) =20 >=20 > Clearly the IETF does not need to define for Cisco a standardized = replacement for the SCCP protocol for this to work, because one isn't = needed since the client javascript and server are built by the same = developers and they know how their proprietary signaling works. So how = about for the signaling Call Manager would use to other VoIP devices, = like gateways or VoIP service providers? Does the IETF need to tell = Cisco what peer-to-peer protocol(s) to implement on Call Manager? No, = and we never have. Cisco's product managers decide that. They decide = if Call Manager needs to be able to communicate a standard protocol at = all, such as SIP or H.323, and which one/any of those. They decide = based on their use-cases/need. >=20 > Some rtcweb developers may not do any standard signaling protocol, = ever. For example many Instant Messaging providers still have closed = environments to this day. (e.g., AIM, YIM, MSN, etc.) Some may choose = to only use H.323, or XMPP, or IAX, or even BICC. Some may choose to = only support SIP with 3GPP extensions. Obviously most of us think/hope = people do SIP, but really the market makes those types of decisions, not = the IETF. Just like the IETF standardized MGCP but didn't specify what = the MGCP Call Agent had to support to speak to other Call Agents. SIP = was given as an example in MGCP, but not mandated. >=20 > The only thing we need to do for rtcweb is make sure the RTP library = built into the browser supports media in such a way that it can = communicate with other RTP peers at a media plane, regardless of what = signaling protocol those peers might be using, preferably without going = through media gateways. And obviously since SIP is a very common = protocol and defined by the IETF we need to make sure it's possible to = use SIP on the rtcweb server, but we can't *mandate* that it be used or = supported, and if we did it wouldn't change anything.=20 >=20 > -hadriel >=20 >=20 > On Sep 15, 2011, at 7:56 PM, Ravindran Parthasarathi wrote: >=20 >> I really didn't get your argument fully because in case there is no = default signaling protocol, it is unavoidable to have island of devices = without gateways but you argue other way around.=20 >>=20 >> I specifically asked for the scope of your opinion on RTCWeb work is = between browser-to-browser or browser-to-other end-point to know whether = parallel universe has to be build or not. In case there is no default = signaling protocol, it is impossible to communicate between = browser-to-endpoint without gateways. Let us assume that the intention = of RTCWeb is to create island of browser devices even then the native = signaling protocol for RTCWeb has advantage over Jquery library and = plugin is not the solution. >>=20 >> Having said that, I agree that it is possible to implement RTP or = STUN or SIP stack or codec using Javascript or plugins but interop and = better performance is not guaranteed. >>=20 >> Thanks >> Partha >=20 -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Fri Sep 16 00: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 AC60F21F8BC5 for ; Fri, 16 Sep 2011 00:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pa6+KQNZvfTo for ; Fri, 16 Sep 2011 00:00:32 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 338A421F8B3F for ; Fri, 16 Sep 2011 00:00:32 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id AD2EAB019A; Fri, 16 Sep 2011 09:02:45 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id D07CDB019A; Fri, 16 Sep 2011 09:02:32 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> Date: Fri, 16 Sep 2011 09:02:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> To: Olle E. Johansson X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Data transfer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 07:00:32 -0000 Hi Olle, On Sep 16, 2011, at 8:32 AM, Olle E. Johansson wrote: > A comment on the list made me go back and re-read the charter. One = thing I had missed is the data transfer part of rtcweb. >=20 > "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 > Most of the discussions on the list has been about the media. What are = the ideas for data transfer? Applications? >=20 Maybe I arrived a bit late to the party ;-) but so far I've seen = discussions mainly around RTP (and related) media. > To me, this seems like an interesting feature. If it's a plain data = transfer session, a bidirectional session, it's a way to open a session = from Javascript to any server, acting as an rtcweb client, which is = different from the current sandbox model. I could have missed this = discussion, but if not, I think this is an interesting topic to bring = up. >=20 > Another note, which I think is purely a mistake, is to forget realtime = text - T.140 and just state audio and video. The T.140 users are natural = early adoptor users of rtcweb. >=20 I can think of another use case for "data transfer": MSRP. A browser = looks looks like a good place for having IM sessions over MSRP. = Supporting file transfers would also be awesome, and MSRP is just a TCP = pipe where data flows, so maybe this "data transfer" layer is the right = place to do this? Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From Markus.Isomaki@nokia.com Fri Sep 16 00:27: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 B3CFA21F8BE5 for ; Fri, 16 Sep 2011 00:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 9z3rURmeNQ+1 for ; Fri, 16 Sep 2011 00:27:27 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id B378C21F8BDC for ; Fri, 16 Sep 2011 00:27:26 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8G7TScd017814; Fri, 16 Sep 2011 10:29:38 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Sep 2011 10:29:35 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 16 Sep 2011 09:29:35 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.204]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0323.007; Fri, 16 Sep 2011 09:29:12 +0200 From: To: , Thread-Topic: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (SIP) Thread-Index: AQHMclbXOUIKXflnkES/7qO+qcO8OJVOFtUAgAB+RoCAADJxMP//5MgAgAAEU4CAACIG8P//6DAAgADfzzA= Date: Fri, 16 Sep 2011 07:29:11 +0000 Message-ID: References: <6F469757-6B5C-4DC9-BC34-026F34C7E508@phonefromhere.com> <4E724E25.1000204@jesup.org> <4E7256B6.4010001@gmail.com> In-Reply-To: <4E7256B6.4010001@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.75.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Sep 2011 07:29:35.0562 (UTC) FILETIME=[62785AA0:01CC7442] X-Nokia-AV: Clean Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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, 16 Sep 2011 07:27:27 -0000 Hi, The real-time media traffic should definitely go over UDP. And even if in t= hat case there is also a question about keepalives, that is not so critical= as typically the real-time sessions are not that long. And when they are o= n, users do understand that the battery can run out after a while if they d= on't charge. This is the so called "talk time" in legacy mobile phone terms= . But all "signaling" needs to be on TCP, as that connectivity is in many c= ases needed all the time, to be able to receive calls, messages and other e= vents. And users don't accept that the phone/tablet runs out of battery, ev= en if it is "unused" from their perspective. This is the "stand-by time" in= legacy terms. Now, these may be quite specific issues to battery powered devices using ce= llular/wide-are type of radios for their Internet access. But I think that = will be an important segment of devices for RTCWeb too.=20 Markus=20 >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of ext Dzonatas Sol >Sent: 15 September, 2011 22:49 >To: rtcweb@ietf.org >Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transpor= t >for Session Initiation Protocol (SIP) > >On 09/15/2011 12:24 PM, Markus.Isomaki@nokia.com wrote: >> SIP over UDP is used by mobile operators themselves, as they are in cont= rol >of the access infrastructure, and can make special provisions for their ow= n >services. But if you try to run SIP over UDP over mobile networks to any >independent ("OTT") Internet service, it is likely to not work that well, = due to >battery consumption. Even with public addresses, in many mobile networks >firewalls drop UDP flow state after 30 seconds. >> > >If the concern is the battery, then with ICE, SIP over UDP is something we >want can reserve in stateful progressions. People don't like that stateful >discussion when it comes to buffer size and transient mix, as they default= ed >to cache under IPv4. > >E911 traffic would be transient to corporate cache, for example. There are >more options as we garbage collect, resolve, and reserve those allocations >after clean from either cache or transient states. Behind corporate firewa= lls, >cache items could be datestamp'd, which simply releases them from the >transient state. Under SMTP, that was normal. > >UDP is BSD friendly, and I like how rtcweb fits right in the UDP header wi= th >extended Content-Length:. If the SSRC is touched, then expand or deliver. > > > >> TCP usually survives longer, in most networks actually more than 15 >> minutes. Unfortunately a small percentage of networks breaks even TCP >> in less than 5 minutes. (Several companies, including Nokia, have >> concrete stats from all over the globe.) >> >> So all in all I'm not sure that HTTP or websockets are in a worse positi= on than >pure SIP. The main differences are that the Javascript app may not have >access to some helpers the more native mobile platform may offer. >> >> Markus >> >> >> >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>> Behalf Of ext Randell Jesup >>> Sent: 15 September, 2011 22:13 >>> To: rtcweb@ietf.org >>> Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket >>> Transport for Session Initiation Protocol (SIP) >>> >>> On 9/15/2011 11:57 AM, Roman Shpount wrote: >>> >>>> Actually SIP over UDP is what is typically used for mobile apps now. >>>> If you are doing SIP from the public IP, you do not need to maintain >>>> the connection even if TCP/TLS is used. >>>> >>> Markus had a point: SIP over UDP requires keepalives if it's behind a >>> NAT as well. So maybe it's not such a big difference, depending on >>> the keepalive rates needed (and for UDP circa 30 sec is typical). >>> >>> -- >>> Randell Jesup >>> randell-ietf@jesup.org >>> >>> _______________________________________________ >>> 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 >> >> > > >-- > >--- >The wheel. > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From mperumal@cisco.com Fri Sep 16 00:28: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 7D8C921F8BDC for ; Fri, 16 Sep 2011 00:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQejNfvsMa0D for ; Fri, 16 Sep 2011 00:28:33 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E040A21F84D9 for ; Fri, 16 Sep 2011 00:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=5246; q=dns/txt; s=iport; t=1316158247; x=1317367847; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=X12yf4nMhIe5C/TgQztpw78y+bq4B7XNSUydRyQNZ0Y=; b=Twbj3Y4eCBgAB/veU97qa1wa38xvUHMwYuyV0GRXr4Qs79PnJKZBGy4Y n8HBBa0il5QSm3/cm7VShqwwxbo+iEwKmywiXyDLpO1TSQjtMrmaApoXs 0BRUYzPCGX4d4xFO6+9XbH8OaJ5YYLvCTQLI53VpRbbmInAmBuwfUgoSg k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgAAGj6ck5Io8UT/2dsb2JhbABBmFaPBHeBTAcBAQEBAwEBAQ8BHQo0CwwEAgEIDgMEAQELBhMEAQYBJh8JCAIEAQoICBMHh1mWPAGeEIYYYASHbZECjA4 X-IronPort-AV: E=Sophos;i="4.68,392,1312156800"; d="scan'208";a="115719957" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 16 Sep 2011 07:30:42 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8G7Uf2t019446; Fri, 16 Sep 2011 07:30:41 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); Fri, 16 Sep 2011 13:00:41 +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: Fri, 16 Sep 2011 13:00:42 +0530 Message-ID: <1D062974A4845E4D8A343C653804920206649221@XMB-BGL-414.cisco.com> In-Reply-To: <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: AQHMdBfEi7FefEQ3sUO4/j8bw5yK0pVPmxUA References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com><05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Hadriel Kaplan" , "Ravindran Parthasarathi" X-OriginalArrivalTime: 16 Sep 2011 07:30:41.0680 (UTC) FILETIME=[89E12900:01CC7442] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 07:28:34 -0000 |The only thing we need to do for rtcweb is make sure the=20 |RTP library built into the browser supports media in such |a way that it can communicate with other RTP peers at a=20 |media plane, regardless of what signaling protocol those=20 |peers might be using, preferably without going through=20 |media gateways. And obviously since SIP is a very common=20 |protocol and defined by the IETF we need to make sure it's |possible to use SIP on the rtcweb server, but we can't=20 |*mandate* that it be used or supported, and if we did it=20 |wouldn't change anything. +1.=20 We may also want to make sure that it is possible use SDP, but shouldn't mandate that it be used. Muthu |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hadriel Kaplan |Sent: Friday, September 16, 2011 7:55 AM |To: Ravindran Parthasarathi |Cc: |Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol |for WebRTC (or not)] | | |There is no need for a "default signaling protocol", because the "signaling" is between the browser's |Javascript and its web server. And as for the signaling protocol the web server has to support in |order to speak to other servers or non-RTCweb endpoints, even if we specified to use SIP we'd just be |summarily ignored by those who don't want to, because they actually don't *need* to. It doesn't hurt |interoperability of rtcweb if they don't implement SIP - it just means they can't talk to other SIP |devices/servers. But it's not like we need an RFC to say "if you don't implement X then you can't |talk to people who do X". | |Think of this RTCWEB concept as Skinny/SCCP. The Web Server is Call Manager, and the browser is the |Skinny phone, but in this case instead of needing a 7960 phone, the Skinny protocol was written in |javascript and uses a browser's user interface for its GUI and the built-in RTP library for media. (in |fact one could probably write a javascript to do just that, if Call Manager handled SCCP over |websocket) | |Clearly the IETF does not need to define for Cisco a standardized replacement for the SCCP protocol |for this to work, because one isn't needed since the client javascript and server are built by the |same developers and they know how their proprietary signaling works. So how about for the signaling |Call Manager would use to other VoIP devices, like gateways or VoIP service providers? Does the IETF |need to tell Cisco what peer-to-peer protocol(s) to implement on Call Manager? No, and we never have. |Cisco's product managers decide that. They decide if Call Manager needs to be able to communicate a |standard protocol at all, such as SIP or H.323, and which one/any of those. They decide based on |their use-cases/need. | |Some rtcweb developers may not do any standard signaling protocol, ever. For example many Instant |Messaging providers still have closed environments to this day. (e.g., AIM, YIM, MSN, etc.) Some may |choose to only use H.323, or XMPP, or IAX, or even BICC. Some may choose to only support SIP with |3GPP extensions. Obviously most of us think/hope people do SIP, but really the market makes those |types of decisions, not the IETF. Just like the IETF standardized MGCP but didn't specify what the |MGCP Call Agent had to support to speak to other Call Agents. SIP was given as an example in MGCP, |but not mandated. | |The only thing we need to do for rtcweb is make sure the RTP library built into the browser supports |media in such a way that it can communicate with other RTP peers at a media plane, regardless of what |signaling protocol those peers might be using, preferably without going through media gateways. And |obviously since SIP is a very common protocol and defined by the IETF we need to make sure it's |possible to use SIP on the rtcweb server, but we can't *mandate* that it be used or supported, and if |we did it wouldn't change anything. | |-hadriel | | |On Sep 15, 2011, at 7:56 PM, Ravindran Parthasarathi wrote: | |> I really didn't get your argument fully because in case there is no default signaling protocol, it |is unavoidable to have island of devices without gateways but you argue other way around. |> |> I specifically asked for the scope of your opinion on RTCWeb work is between browser-to-browser or |browser-to-other end-point to know whether parallel universe has to be build or not. In case there is |no default signaling protocol, it is impossible to communicate between browser-to-endpoint without |gateways. Let us assume that the intention of RTCWeb is to create island of browser devices even then |the native signaling protocol for RTCWeb has advantage over Jquery library and plugin is not the |solution. |> |> Having said that, I agree that it is possible to implement RTP or STUN or SIP stack or codec using |Javascript or plugins but interop and better performance is not guaranteed. |> |> Thanks |> Partha | |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From ibc@aliax.net Fri Sep 16 01:31: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 AC50021F8AEA for ; Fri, 16 Sep 2011 01:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_46=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 rDUUNb2QA8Fs for ; Fri, 16 Sep 2011 01:31:50 -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 EE7F221F8557 for ; Fri, 16 Sep 2011 01:31:49 -0700 (PDT) Received: by qyk33 with SMTP id 33so3657962qyk.10 for ; Fri, 16 Sep 2011 01:34:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.105 with SMTP id q41mr1671708qci.216.1316162043602; Fri, 16 Sep 2011 01:34:03 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Fri, 16 Sep 2011 01:34:03 -0700 (PDT) In-Reply-To: <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> Date: Fri, 16 Sep 2011 10:34:03 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 08:31:50 -0000 2011/9/16 Hadriel Kaplan : > The only thing we need to do for rtcweb is make sure the RTP library buil= t into the browser supports media in such a way that it can communicate wit= h other RTP peers at a media plane, regardless of what signaling protocol t= hose peers might be using, preferably without going through media gateways.= =C2=A0And obviously since SIP is a very common protocol and defined by the= IETF we need to make sure it's possible to use SIP on the rtcweb server, b= ut we can't *mandate* that it be used or supported, and if we did it wouldn= 't change anything. +1 The only I expect is that a WebRTC web-browser can establish a RTP session with a remote SIP or XMPP+Jingle endpoint (without requiring media gateways !!). How the signaling (SIP or XMPP) is carried between the real SIP/XMPP endpoint and the browser should be out of the scope of rtcweb (IMHO). Having said that, we have already shown a working solution for carrying SIP between web-browsers and real SIP entities out there (SIP over WebSocket). The same can be done for any other protocol (it's already specified also for XMPP). Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Sep 16 01:59: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 6351621F8BB9 for ; Fri, 16 Sep 2011 01:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, 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 wOiKeYXxpY2B for ; Fri, 16 Sep 2011 01:59:47 -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 CA48C21F8A7A for ; Fri, 16 Sep 2011 01:59:47 -0700 (PDT) Received: by qyk33 with SMTP id 33so3680471qyk.10 for ; Fri, 16 Sep 2011 02:02:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.66.144 with SMTP id n16mr1336600qci.178.1316163721491; Fri, 16 Sep 2011 02:02:01 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Fri, 16 Sep 2011 02:02:01 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> Date: Fri, 16 Sep 2011 11:02:01 +0200 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] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 08:59:48 -0000 2011/9/16 Ravindran Parthasarathi : > I really didn't get your argument fully because in case there is no defau= lt signaling protocol, it is unavoidable to have island of devices without = gateways but you argue other way around. A centralized signaling point is required (think about NAT). Signaling is just supposed to be present between web-browsers visiting the same web site, so the signaling can be perfectly carried within HTTP or WebSocket protocol and be centralized in that server. Otherwise, are you proposing the existence of a global/unique SIP proxy in the world for all the web-browsers to intercommunicate? WebRTC is not about communication between web-browsers as if they were generic SIP phones contacting directly one to other. > I specifically asked for the scope of your opinion on RTCWeb work is betw= een browser-to-browser or browser-to-other end-point to know whether parall= el universe has to be build or not. In case there is no default signaling p= rotocol, it is impossible to communicate between browser-to-endpoint withou= t gateways Why is it impossible? If WebSocket is used as a new transport for SIP and XMPP then web-browsers can establish a pure SIP or XMPP session with a SIP/XMPP server implementing WebSocket transport. And for sure that works. Best regards. --=20 I=C3=B1aki Baz Castillo From mperumal@cisco.com Fri Sep 16 04:24: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 D56D021F8B81; Fri, 16 Sep 2011 04:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NV3Qj7CCO0qq; Fri, 16 Sep 2011 04:24:29 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id EED5A21F8B4D; Fri, 16 Sep 2011 04:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3315; q=dns/txt; s=iport; t=1316172403; x=1317382003; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=0LEqdS1J8jxOEweXyIeNU4n+uLep56vbBpaVH8NsXEc=; b=guX9VW4+k3GhFe4FJbypz1MMTzzAe6okSaxvHCmf/61H7ve0uFrYxOXJ dHTqmIZDTbAC/f3oraltydLCij7kG03Vb6x2qVo1Sy5zF3FASOodPhIjm n5fpZ8cXZkgP0cK6ZUKyKCug7wK2T2eU5G9iHldRFPxJUh/dq6hansCwQ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgAALIxc05Io8US/2dsb2JhbABBmF6PBXeBUwEBAQEDAQEBDwEdCjQJDgQCAQgRBAEBCwYTBAEGASYfCAEIAQEEAQoICBqHWZYdAZ4dhhhgBIdtkQKMDg X-IronPort-AV: E=Sophos;i="4.68,393,1312156800"; d="scan'208";a="54886364" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 16 Sep 2011 11:26:41 +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 p8GBQeV6013064; Fri, 16 Sep 2011 11:26:40 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); Fri, 16 Sep 2011 16:55:59 +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: Fri, 16 Sep 2011 16:55:58 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202066492D5@XMB-BGL-414.cisco.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233EDB29F@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] FW: New Version Notification for draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt Thread-Index: Acxyyd6aOvfK+MMFTn6XQAfby+UjdAAASajQAGLLwtA= References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB29F@ESESSCMS0356.eemea.ericsson.se> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Christer Holmberg" , , "IETF - MMUSIC" X-OriginalArrivalTime: 16 Sep 2011 11:25:59.0685 (UTC) FILETIME=[68DDC350:01CC7463] Subject: Re: [rtcweb] FW: New Version Notification for draft-holmberg-mmusic-sdp-multiplex-negotiation-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: Fri, 16 Sep 2011 11:24:31 -0000 The approach looks good overall. A quick comment on section 5. SDP Offer/Answer Procedures: |When an SDP offerer wants to offer multiplexed media, it inserts the |same port number value for each "m=3D" line that is part of the offered |multiplex. In addition, the SDP offerer inserts an SDP session-level |"a=3Dgroup" attribute, with a "MULTIPLEX" value, and assigns an SDP |media-level "a=3Dmid" attribute value for each "m=3D" line that is part |of the offered multiplex. Suggestion: An entity generating an SDP offer or answer describing multiplexed=20 media does the following: 1. Inserts the same port number for each "m=3D" line that is part of=20 the multiplex. 2. Uses the same connection data ("c=3D" line) values for each media=20 stream that is part of the multiplex. 3. Inserts the same RTCP port number in the "a=3Drtcp" attribute for each media stream that is part of the multiplex, when the RTCP=20 port is not the next higher (odd) port number following the RTP=20 port described in the "m=3D" line. 4. Inserts an "a=3Drtcp-mux" attribute for each media stream that is part of the multiplex, when RTCP is multiplexed with RTP on the=20 same port. 5. Inserts an SDP session-level "a=3Dgroup" attribute, with a = "MULTIPLEX"=20 value, and assigns an SDP media-level "a=3Dmid" attribute value for=20 each "m=3D" line that is part of the multiplex. Muthu |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg |Sent: Wednesday, September 14, 2011 4:17 PM |To: rtcweb@ietf.org |Subject: [rtcweb] FW: New Version Notification for draft-holmberg-mmusic-sdp-multiplex-negotiation- |00.txt | | | |Hi, | |I've submitted a draft in MMUSIC, which defines a mechanism and grouping framework extension in order |to negotiate multiplexing of media associated with multiple m=3D lines. | |The main difference from Harald's previous proposal is that it defines the usage of the same port |number value for multiple m=3D lines, and every m=3D line is used to describe media even in the case of |multiplex. | |Comments are welcome :) | |Regards, | |Christer | | | | |> -----Original Message----- |> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] |> Sent: 14. syyskuuta 2011 13:32 |> To: Christer Holmberg |> Cc: Christer Holmberg |> Subject: New Version Notification for |> draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt |> |> A new version of I-D, |> draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt has |> been successfully submitted by Christer Holmberg and posted |> to the IETF repository. |> |> Filename: draft-holmberg-mmusic-sdp-multiplex-negotiation |> Revision: 00 |> Title: Multiplexing Negotiation Using Session |> Description Protocol (SDP) Port Numbers |> Creation date: 2011-09-14 |> WG ID: Individual Submission |> Number of pages: 9 |> |> Abstract: |> This document defines how to use the Session Description Protocol |> (SDP) in order to negotiate the usage of multiplexed media. |> |> |> |> |> |> The IETF Secretariat |> |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From christer.holmberg@ericsson.com Fri Sep 16 04: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 F0C7021F8BEE; Fri, 16 Sep 2011 04:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 GvD3uSEAeNyy; Fri, 16 Sep 2011 04:33:23 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id BF73221F8BE7; Fri, 16 Sep 2011 04:33:21 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-e4-4e733487563e Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 18.5D.02839.784337E4; Fri, 16 Sep 2011 13:35:35 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 16 Sep 2011 13:35:34 +0200 From: Christer Holmberg To: "Muthu Arul Mozhi Perumal (mperumal)" , "rtcweb@ietf.org" , IETF - MMUSIC Date: Fri, 16 Sep 2011 13:35:34 +0200 Thread-Topic: [rtcweb] FW: New Version Notification for draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt Thread-Index: Acxyyd6aOvfK+MMFTn6XQAfby+UjdAAASajQAGLLwtAAA5ebUA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233F1E768@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB29F@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C6538049202066492D5@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C6538049202066492D5@XMB-BGL-414.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== Subject: Re: [rtcweb] FW: New Version Notification for draft-holmberg-mmusic-sdp-multiplex-negotiation-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: Fri, 16 Sep 2011 11:33:24 -0000 Hi Muthu, You suggestion looks good, and I'll implement it in the next version of the= draft. Thanks! Regards, Christer=20 > -----Original Message----- > From: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20 > Sent: 16. syyskuuta 2011 14:26 > To: Christer Holmberg; rtcweb@ietf.org; IETF - MMUSIC > Subject: RE: [rtcweb] FW: New Version Notification for=20 > draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt >=20 > The approach looks good overall. A quick comment on section=20 > 5. SDP Offer/Answer Procedures: >=20 > |When an SDP offerer wants to offer multiplexed media, it inserts the=20 > |same port number value for each "m=3D" line that is part of=20 > the offered=20 > |multiplex. In addition, the SDP offerer inserts an SDP=20 > session-level=20 > |"a=3Dgroup" attribute, with a "MULTIPLEX" value, and assigns an SDP=20 > |media-level "a=3Dmid" attribute value for each "m=3D" line that=20 > is part of=20 > |the offered multiplex. >=20 > Suggestion: >=20 > An entity generating an SDP offer or answer describing=20 > multiplexed media does the following: > 1. Inserts the same port number for each "m=3D" line that is part of=20 > the multiplex. > 2. Uses the same connection data ("c=3D" line) values for each media=20 > stream that is part of the multiplex. > 3. Inserts the same RTCP port number in the "a=3Drtcp" attribute for > each media stream that is part of the multiplex, when the RTCP=20 > port is not the next higher (odd) port number following the RTP=20 > port described in the "m=3D" line. > 4. Inserts an "a=3Drtcp-mux" attribute for each media stream that is > part of the multiplex, when RTCP is multiplexed with RTP on the=20 > same port. > 5. Inserts an SDP session-level "a=3Dgroup" attribute, with a=20 > "MULTIPLEX"=20 > value, and assigns an SDP media-level "a=3Dmid" attribute value for=20 > each "m=3D" line that is part of the multiplex. >=20 > Muthu >=20 > |-----Original Message----- > |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Christer Holmberg > |Sent: Wednesday, September 14, 2011 4:17 PM > |To: rtcweb@ietf.org > |Subject: [rtcweb] FW: New Version Notification for > draft-holmberg-mmusic-sdp-multiplex-negotiation- > |00.txt > | > | > | > |Hi, > | > |I've submitted a draft in MMUSIC, which defines a mechanism and > grouping framework extension in order > |to negotiate multiplexing of media associated with multiple m=3D lines. > | > |The main difference from Harald's previous proposal is that=20 > it defines > the usage of the same port > |number value for multiple m=3D lines, and every m=3D line is used to > describe media even in the case of > |multiplex. > | > |Comments are welcome :) > | > |Regards, > | > |Christer > | > | > | > | > |> -----Original Message----- > |> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > |> Sent: 14. syyskuuta 2011 13:32 > |> To: Christer Holmberg > |> Cc: Christer Holmberg > |> Subject: New Version Notification for=20 > |> draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt > |> > |> A new version of I-D, > |> draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt has been=20 > |> successfully submitted by Christer Holmberg and posted to the IETF=20 > |> repository. > |> > |> Filename: draft-holmberg-mmusic-sdp-multiplex-negotiation > |> Revision: 00 > |> Title: Multiplexing Negotiation Using Session > |> Description Protocol (SDP) Port Numbers > |> Creation date: 2011-09-14 > |> WG ID: Individual Submission > |> Number of pages: 9 > |> > |> Abstract: > |> This document defines how to use the Session=20 > Description Protocol > |> (SDP) in order to negotiate the usage of multiplexed media. > |> > |> > |> > |> > |> > |> The IETF Secretariat > |> > |_______________________________________________ > |rtcweb mailing list > |rtcweb@ietf.org > |https://www.ietf.org/mailman/listinfo/rtcweb > = From ron.even.tlv@gmail.com Fri Sep 16 05:52: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 12F0D21F8B8E; Fri, 16 Sep 2011 05:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wvo5jHeK0h77; Fri, 16 Sep 2011 05:52:27 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E032D21F8AF1; Fri, 16 Sep 2011 05:52:26 -0700 (PDT) Received: by yxt33 with SMTP id 33so3378207yxt.31 for ; Fri, 16 Sep 2011 05:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=tzLC0RUNtF+Pd3NIvQAij5YFcFaFr34vVi+d4lxR+kM=; b=kulHoCT/KfYVdB5UwF6D9babXSBBukfXVfTc89V4h/IIze74E3bhgWFMQxNVJf75sJ OLn02+4+Hm+JIgwzmwwGLxZkHtW99TsBGq8W28qbX64qQuGTkr4EamseYI2+uKe5hJcf KQxoUR+vjzV1VECJAQHWQMcNqAmq7rCjQ3Pno= Received: by 10.68.7.69 with SMTP id h5mr1264815pba.527.1316177680850; Fri, 16 Sep 2011 05:54:40 -0700 (PDT) Received: from windows8d787f9 ([59.37.10.82]) by mx.google.com with ESMTPS id i1sm32939009pbe.1.2011.09.16.05.54.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Sep 2011 05:54:39 -0700 (PDT) From: "Roni Even" To: "'Christer Holmberg'" , "'Muthu Arul Mozhi Perumal \(mperumal\)'" , , "'IETF - MMUSIC'" References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB29F@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C6538049202066492D5@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233F1E768@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F1E768@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 16 Sep 2011 15:53:15 +0300 Message-ID: <4e73470f.e113440a.6fe3.ffffa2bb@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acxyyd6aOvfK+MMFTn6XQAfby+UjdAAASajQAGLLwtAAA5ebUAAClWrg Content-Language: en-us Subject: Re: [rtcweb] [MMUSIC] FW: New Version Notification for draft-holmberg-mmusic-sdp-multiplex-negotiation-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: Fri, 16 Sep 2011 12:52:28 -0000 Hi, I think that you MUST have unique payload type numbers in all m-lines. As for parameters I am not sure what will be the outcome of the bandwidth if they appear in both m-lines. Or for encryption parameters if you offer SAVP/SAVPF. BTW: This solution is not limited to RTCWEB, at least it does not say it is. Regards Roni Even > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Friday, September 16, 2011 2:36 PM > To: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org; IETF - MMUSIC > Subject: Re: [MMUSIC] [rtcweb] FW: New Version Notification for draft- > holmberg-mmusic-sdp-multiplex-negotiation-00.txt > > > Hi Muthu, > > You suggestion looks good, and I'll implement it in the next version of > the draft. > > Thanks! > > Regards, > > Christer > > > > -----Original Message----- > > From: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > > Sent: 16. syyskuuta 2011 14:26 > > To: Christer Holmberg; rtcweb@ietf.org; IETF - MMUSIC > > Subject: RE: [rtcweb] FW: New Version Notification for > > draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt > > > > The approach looks good overall. A quick comment on section > > 5. SDP Offer/Answer Procedures: > > > > |When an SDP offerer wants to offer multiplexed media, it inserts the > > |same port number value for each "m=" line that is part of > > the offered > > |multiplex. In addition, the SDP offerer inserts an SDP > > session-level > > |"a=group" attribute, with a "MULTIPLEX" value, and assigns an SDP > > |media-level "a=mid" attribute value for each "m=" line that > > is part of > > |the offered multiplex. > > > > Suggestion: > > > > An entity generating an SDP offer or answer describing > > multiplexed media does the following: > > 1. Inserts the same port number for each "m=" line that is part of > > the multiplex. > > 2. Uses the same connection data ("c=" line) values for each media > > stream that is part of the multiplex. > > 3. Inserts the same RTCP port number in the "a=rtcp" attribute for > > each media stream that is part of the multiplex, when the RTCP > > port is not the next higher (odd) port number following the RTP > > port described in the "m=" line. > > 4. Inserts an "a=rtcp-mux" attribute for each media stream that is > > part of the multiplex, when RTCP is multiplexed with RTP on the > > same port. > > 5. Inserts an SDP session-level "a=group" attribute, with a > > "MULTIPLEX" > > value, and assigns an SDP media-level "a=mid" attribute value for > > each "m=" line that is part of the multiplex. > > > > Muthu > > > > |-----Original Message----- > > |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > Behalf Of Christer Holmberg > > |Sent: Wednesday, September 14, 2011 4:17 PM > > |To: rtcweb@ietf.org > > |Subject: [rtcweb] FW: New Version Notification for > > draft-holmberg-mmusic-sdp-multiplex-negotiation- > > |00.txt > > | > > | > > | > > |Hi, > > | > > |I've submitted a draft in MMUSIC, which defines a mechanism and > > grouping framework extension in order > > |to negotiate multiplexing of media associated with multiple m= > lines. > > | > > |The main difference from Harald's previous proposal is that > > it defines > > the usage of the same port > > |number value for multiple m= lines, and every m= line is used to > > describe media even in the case of > > |multiplex. > > | > > |Comments are welcome :) > > | > > |Regards, > > | > > |Christer > > | > > | > > | > > | > > |> -----Original Message----- > > |> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > |> Sent: 14. syyskuuta 2011 13:32 > > |> To: Christer Holmberg > > |> Cc: Christer Holmberg > > |> Subject: New Version Notification for > > |> draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt > > |> > > |> A new version of I-D, > > |> draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt has been > > |> successfully submitted by Christer Holmberg and posted to the IETF > > |> repository. > > |> > > |> Filename: draft-holmberg-mmusic-sdp-multiplex-negotiation > > |> Revision: 00 > > |> Title: Multiplexing Negotiation Using Session > > |> Description Protocol (SDP) Port Numbers > > |> Creation date: 2011-09-14 > > |> WG ID: Individual Submission > > |> Number of pages: 9 > > |> > > |> Abstract: > > |> This document defines how to use the Session > > Description Protocol > > |> (SDP) in order to negotiate the usage of multiplexed media. > > |> > > |> > > |> > > |> > > |> > > |> The IETF Secretariat > > |> > > |_______________________________________________ > > |rtcweb mailing list > > |rtcweb@ietf.org > > |https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From christer.holmberg@ericsson.com Fri Sep 16 05:54: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 82CC221F8B9B; Fri, 16 Sep 2011 05:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 xbnryFxfhwc6; Fri, 16 Sep 2011 05:54:18 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 373EF21F8AF1; Fri, 16 Sep 2011 05:54:18 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-bd-4e73478078bf Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B3.5A.02839.087437E4; Fri, 16 Sep 2011 14:56:32 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 16 Sep 2011 14:56:31 +0200 From: Christer Holmberg To: Roni Even , "'Muthu Arul Mozhi Perumal (mperumal)'" , "rtcweb@ietf.org" , 'IETF - MMUSIC' Date: Fri, 16 Sep 2011 14:56:29 +0200 Thread-Topic: [MMUSIC] [rtcweb] FW: New Version Notification for draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt Thread-Index: Acxyyd6aOvfK+MMFTn6XQAfby+UjdAAASajQAGLLwtAAA5ebUAAClWrgAABEa6A= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233F1E831@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB29F@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C6538049202066492D5@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233F1E768@ESESSCMS0356.eemea.ericsson.se> <4e73470f.e113440a.6fe3.ffffa2bb@mx.google.com> In-Reply-To: <4e73470f.e113440a.6fe3.ffffa2bb@mx.google.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: Re: [rtcweb] [MMUSIC] FW: New Version Notification for draft-holmberg-mmusic-sdp-multiplex-negotiation-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: Fri, 16 Sep 2011 12:54:19 -0000 Hi,=20 >I think that you MUST have unique payload type numbers in all m-lines. >As for parameters I am not sure what will be the outcome of=20 >the bandwidth if they appear in both m-lines. Or for=20 >encryption parameters if you offer SAVP/SAVPF. >=20 >BTW: This solution is not limited to RTCWEB, at least it does=20 >not say it is. That is why I submitted it to MMUSIC :) Regards, Christer > > -----Original Message----- > > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On=20 > > Behalf Of Christer Holmberg > > Sent: Friday, September 16, 2011 2:36 PM > > To: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org; IETF -=20 > > MMUSIC > > Subject: Re: [MMUSIC] [rtcweb] FW: New Version Notification=20 > for draft-=20 > > holmberg-mmusic-sdp-multiplex-negotiation-00.txt > >=20 > >=20 > > Hi Muthu, > >=20 > > You suggestion looks good, and I'll implement it in the=20 > next version=20 > > of the draft. > >=20 > > Thanks! > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > > -----Original Message----- > > > From: Muthu Arul Mozhi Perumal (mperumal)=20 > > > [mailto:mperumal@cisco.com] > > > Sent: 16. syyskuuta 2011 14:26 > > > To: Christer Holmberg; rtcweb@ietf.org; IETF - MMUSIC > > > Subject: RE: [rtcweb] FW: New Version Notification for=20 > > > draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt > > > > > > The approach looks good overall. A quick comment on=20 > section 5. SDP=20 > > > Offer/Answer Procedures: > > > > > > |When an SDP offerer wants to offer multiplexed media, it inserts=20 > > > |the same port number value for each "m=3D" line that is part of > > > the offered > > > |multiplex. In addition, the SDP offerer inserts an SDP > > > session-level > > > |"a=3Dgroup" attribute, with a "MULTIPLEX" value, and=20 > assigns an SDP=20 > > > |media-level "a=3Dmid" attribute value for each "m=3D" line that > > > is part of > > > |the offered multiplex. > > > > > > Suggestion: > > > > > > An entity generating an SDP offer or answer describing=20 > multiplexed=20 > > > media does the following: > > > 1. Inserts the same port number for each "m=3D" line that is part of > > > the multiplex. > > > 2. Uses the same connection data ("c=3D" line) values for each media > > > stream that is part of the multiplex. > > > 3. Inserts the same RTCP port number in the "a=3Drtcp" attribute for > > > each media stream that is part of the multiplex, when the RTCP > > > port is not the next higher (odd) port number following the RTP > > > port described in the "m=3D" line. > > > 4. Inserts an "a=3Drtcp-mux" attribute for each media stream that is > > > part of the multiplex, when RTCP is multiplexed with RTP on the > > > same port. > > > 5. Inserts an SDP session-level "a=3Dgroup" attribute, with a=20 > > > "MULTIPLEX" > > > value, and assigns an SDP media-level "a=3Dmid"=20 > attribute value for > > > each "m=3D" line that is part of the multiplex. > > > > > > Muthu > > > > > > |-----Original Message----- > > > |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > > > Behalf Of Christer Holmberg > > > |Sent: Wednesday, September 14, 2011 4:17 PM > > > |To: rtcweb@ietf.org > > > |Subject: [rtcweb] FW: New Version Notification for > > > draft-holmberg-mmusic-sdp-multiplex-negotiation- > > > |00.txt > > > | > > > | > > > | > > > |Hi, > > > | > > > |I've submitted a draft in MMUSIC, which defines a mechanism and > > > grouping framework extension in order > > > |to negotiate multiplexing of media associated with multiple m=3D > > lines. > > > | > > > |The main difference from Harald's previous proposal is that > > > it defines > > > the usage of the same port > > > |number value for multiple m=3D lines, and every m=3D line is used to > > > describe media even in the case of > > > |multiplex. > > > | > > > |Comments are welcome :) > > > | > > > |Regards, > > > | > > > |Christer > > > | > > > | > > > | > > > | > > > |> -----Original Message----- > > > |> From: internet-drafts@ietf.org=20 > [mailto:internet-drafts@ietf.org] > > > |> Sent: 14. syyskuuta 2011 13:32 > > > |> To: Christer Holmberg > > > |> Cc: Christer Holmberg > > > |> Subject: New Version Notification for=20 > > > |> draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt > > > |> > > > |> A new version of I-D, > > > |> draft-holmberg-mmusic-sdp-multiplex-negotiation-00.txt=20 > has been=20 > > > |> successfully submitted by Christer Holmberg and posted to the=20 > > > |> IETF repository. > > > |> > > > |> Filename: draft-holmberg-mmusic-sdp-multiplex-negotiation > > > |> Revision: 00 > > > |> Title: Multiplexing Negotiation Using Session > > > |> Description Protocol (SDP) Port Numbers > > > |> Creation date: 2011-09-14 > > > |> WG ID: Individual Submission > > > |> Number of pages: 9 > > > |> > > > |> Abstract: > > > |> This document defines how to use the Session > > > Description Protocol > > > |> (SDP) in order to negotiate the usage of multiplexed media. > > > |> > > > |> > > > |> > > > |> > > > |> > > > |> The IETF Secretariat > > > |> > > > |_______________________________________________ > > > |rtcweb mailing list > > > |rtcweb@ietf.org > > > |https://www.ietf.org/mailman/listinfo/rtcweb > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic >=20 > = From ron.even.tlv@gmail.com Fri Sep 16 06:02: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 71B9321F8B13 for ; Fri, 16 Sep 2011 06:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csn0p9INHf-B for ; Fri, 16 Sep 2011 06:02:45 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id CAA9021F8B0B for ; Fri, 16 Sep 2011 06:02:45 -0700 (PDT) Received: by gxk19 with SMTP id 19so3460287gxk.31 for ; Fri, 16 Sep 2011 06:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=zVAEb+S5lsTO4XYqTLJDMDCCsVaJbaBzwprGzFrtjc0=; b=jD/wYULXVVwUSjmzd6GdRfpjjoN0uASuBpBx4vl5l1L7NKnoFv/vsXpbZPoPxmZd0M qBBLbwwzcjeBrzilY5hV8Fkp6gVf8uBhSjbKRgU6XL7gHmJnEi5vxvhC0ZmE9kqclGzn rfzlj5L4upMwtB8x0gggBzTZEY23acWW+zUyE= Received: by 10.68.58.100 with SMTP id p4mr1705983pbq.476.1316178300036; Fri, 16 Sep 2011 06:05:00 -0700 (PDT) Received: from windows8d787f9 ([59.37.10.82]) by mx.google.com with ESMTPS id e8sm32931867pbc.8.2011.09.16.06.04.55 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Sep 2011 06:04:58 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , References: <4E70C387.1070707@ericsson.com> In-Reply-To: <4E70C387.1070707@ericsson.com> Date: Fri, 16 Sep 2011 16:03:34 +0300 Message-ID: <4e73497a.280d440a.69d0.ffff9f98@mx.google.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: Acxy8IefSwNpefInRDiRlAjJbviBHwBgCWdw Content-Language: en-us Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 13:02:46 -0000 Magnus, Maybe we can take the approach from draft-holmberg-mmusic-sdp-multiplex-negotiation and offer the same = m-line with the same port number twice, one as AVP and one as AVPF and let the other side chose, he can answer with a port=3D0 for the profile it does = not want. If the multiplex proposal has backward interoperability than this proposal also does. Roni Even > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Magnus Westerlund > Sent: Wednesday, September 14, 2011 6:09 PM > To: rtcweb@ietf.org > Subject: [rtcweb] AVPF vs AVP >=20 > Hi, >=20 > There has been this long thread with the subject partially containing > "AVPF". I want to clarify something in this context around AVPF. = Rather > than the SRTP question. >=20 > An end-point that is AVPF compliant is in fact interoperable with an > AVP > one as long as the trr-int parameter is set reasonably large. A > parameter value of 1.5-5 seconds (I would recommend 3s) will ensure > that > they are in fact compatible. This avoids the risk of any side timing > out > the other if the AVP side is using the default 5 s minimum interval. >=20 > Based on this one could in fact have the RTCWEB nodes always use AVPF > for RTP/RTCP Behavior. The AVPF feedback messages are explicitly > negotiated and will only be used when agreed on. >=20 > This leaves us with any signaling incompatibilities when talking to a > legacy device. If one don't want to use cap-neg I see two directions = to > go: >=20 > 1) RTCWEB end-point will always signal AVPF or SAVPF. I signalling > gateway to legacy will change that by removing the F to AVP or SAVP. >=20 > 2) RTCWEB end-point will always use AVPF but signal it as AVP. It will > detect the AVPF capabilities of the other end-point based on the > signaling of the feedback events intended to be used. >=20 > I think 1) is cleaner for the future. 2) might be more pragmatic. >=20 > In both cases I believe there are methods for negotiating a lower > trr-int than some AVP fallback value to preserve interoperability. >=20 >=20 > However, this still don't resolve the question if the "S" should be in > front of the RTP profile indicator or not. But it might help by > removing > the F or not in the profile. >=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 magnus.westerlund@ericsson.com Fri Sep 16 06:24: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 F34F821F8C20 for ; Fri, 16 Sep 2011 06:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 j26kW1eRnzQb for ; Fri, 16 Sep 2011 06:24:25 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9100A21F8C1E for ; Fri, 16 Sep 2011 06:24:24 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-9c-4e734e8e03b5 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1C.B0.20773.E8E437E4; Fri, 16 Sep 2011 15:26:38 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 16 Sep 2011 15:26:37 +0200 Message-ID: <4E734E89.5010105@ericsson.com> Date: Fri, 16 Sep 2011 15:26:33 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <4E649FBD.1090001@alvestrand.no> In-Reply-To: <4E649FBD.1090001@alvestrand.no> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-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: Fri, 16 Sep 2011 13:24:26 -0000 Hi, As an Individual I do have a few comments and question on this document and its algorithm. 1. Section 3: As delay based congestion control has been tried a number of times and meet with less than stellar success I wonder if you have any understanding of how this relates to the issues previously encountered: - Stability (especially on short RTTs) - How it competes with TCP flows, which was a real issues for TCP Vegas but may be less of an issue here. 2. Section 3, I don't see any discussion of the startup issue. Is my assumption correct, that you will simply start at some rate and then adapt from that? 3. Section 3, I guess this mechanism would get significant issues with any sender side transmission filtering. Burst transmitting I-frames over a network, especially for high resolution video can easily result in packet loss in switch fabrics if there is any cross traffic in the switch fabric. Thus having a bit of send filtering for frame transmission is a good idea. Are I understanding it correctly that this could result in over-use indication if I has such mechanism which filters a packet to a slower transmission rate than what a single or small burst can achieve over the same path? 4. Section 4. "This algorithm is run every time a receive report arrives at the sender, which will happen [[how often do we expect? and why?]]. If no receive report is recieved within [[what timeout?]], the algorithm will take action as if all packets in the interval have been lost. [[does that make sense?]]" The transmission of receiver reports is highly dependent on RTP profile, the RTCP bandwidth, trr-int parameter and any feedback events. If I start with assuming AVPF which seems reasonable in most browser to browser case with our current proposals for RTP support. Then if there are no feedback events the transmission of receiver reports will occur as often as the bandwidth allows, but no more often than the value of trr-int parameter. Here is might be worth mentioning that I do expect trr-int to be set to avoid RTCP reporting to often due to the relatively high RTCP bandwidth values that will be set due to the multiplexing of audio and video in a single RTP session. Thus avoiding that RTCP rates are as high or larger than the audio streams they report in steady state. When feedback events occur the stack will have the choice of sending a RTCP RR, that is a choice provided due to the reduced size RTCP specification included. But if the loss cumulative count diff is non-zero it might be worth mandating that the RR/SR is included in any such feedback RTCP packet. For that reason causing a feedback event when there is losses and schedule them using the early algorithm may be a good choice to ensure timely reporting of any loss. If one uses AVP then the RTCP timing rules will give you when you transmit RTCP feeedback and thus the parameterization becomes central here. A clear issue is if people uses the minimal interval of 5 seconds or the 360/Session_BW(in kbps). I would note that 5 seconds is very long in adaptation situations. I think the timeout should be based on the RTT and possible reporting rate. But there clearly need to be some upper limit, either explicitly or mandating RTCP bandwidth rates. 5. Section 4: "We motivate the packet loss thresholds by noting that if we have small amount of packet losses due to over-use, that amount will soon increase if we don't adjust our bit rate. Therefore we will soon enough reach above the 10 % threshold and adjust As(i). However if the packet loss rate does not increase, the losses are probably not related to self-induced channel over-use and therefore we should not react on them." I am personally worried that a packet loss threshold of 10% is so high that it might push a lot of other traffic out of the way. Thus being quite aggressive towards other flows. TCP has this relation between the average packet loss rate and the highest sustainable rate which can be interpreted as TCP gets more sensitive to loss the higher the average data rate becomes. Thus in certain situation the sender side algorithm part will be extremely aggressive in pushing TCP out of the way. The receiver part may compensate for this pretty well in a number of situations. But, I do wonder why for example the A(i) isn't bounded to be between TFRC's rate and some multiple of TFRC rate, not unbounded by other than the receiver side algorithm. I do understand this document is to start a discussion. But I think we need to be sensitive to that it is difficult to get even something that is self-fair over the wide range of conditions the Internet has to provide. Thus I would appreciate what issues with for example TFRC that you attempt to fix with the various new components you add. 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 Sep 16 06:30: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 A862721F8C1B for ; Fri, 16 Sep 2011 06:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.504 X-Spam-Level: X-Spam-Status: No, score=-106.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 P-P6hW9j4xsq for ; Fri, 16 Sep 2011 06:30:06 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id DEF7421F8C07 for ; Fri, 16 Sep 2011 06:30:05 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-4b-4e734fe34f2a Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 06.60.02839.3EF437E4; Fri, 16 Sep 2011 15:32:19 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Fri, 16 Sep 2011 15:32:18 +0200 Message-ID: <4E734FE0.9030404@ericsson.com> Date: Fri, 16 Sep 2011 15:32:16 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Roni Even References: <4E70C387.1070707@ericsson.com> <4e73497a.280d440a.69d0.ffff9f98@mx.google.com> In-Reply-To: <4e73497a.280d440a.69d0.ffff9f98@mx.google.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 13:30:06 -0000 On 2011-09-16 15:03, Roni Even wrote: > Magnus, > Maybe we can take the approach from > draft-holmberg-mmusic-sdp-multiplex-negotiation and offer the same m-line > with the same port number twice, one as AVP and one as AVPF and let the > other side chose, he can answer with a port=0 for the profile it does not > want. If the multiplex proposal has backward interoperability than this > proposal also does. An idea with potential I would say. I have to think if it has any issues. We may still have missed some aspect when it comes to Christer's draft which breaks it. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Sep 16 06:43: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 63CDE21F8C1D for ; Fri, 16 Sep 2011 06:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.355 X-Spam-Level: X-Spam-Status: No, score=-106.355 tagged_above=-999 required=5 tests=[AWL=-0.056, 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 MbJspsK3pCuR for ; Fri, 16 Sep 2011 06:43:25 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8349121F8C1C for ; Fri, 16 Sep 2011 06:43:25 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a8-4e73530343d8 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 23.63.20773.303537E4; Fri, 16 Sep 2011 15:45:39 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Fri, 16 Sep 2011 15:45:39 +0200 Message-ID: <4E735302.6010805@ericsson.com> Date: Fri, 16 Sep 2011 15:45:38 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data transfer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 13:43:26 -0000 Hi, When it comes to the data transfer the discussion we have had back in the beginning of the summer made it clear that there was clear interest for an unreliable peer to peer datagram based channel. Use cases include game data, meta information in conferencing. But it is for whatever the the JS application have use for it. When it comes to reliable data the result of the discussion was a bit more unclear. Some interest existed, but no one was willing to be a driving proponent to both propose technology and use cases. When it comes to the unreliable data channel we are awaiting that draft-cbran-rtcweb-data-00 is updated to try to provide something at least worth discussing. As the WG has no consensus yet on the details for solving this channel, any contribution is most welcome. I agree that when it comes to T.140 it can easily be included as media format that shall be supported. We have had several suggesting that and no real objections. One can note that there goes 13 proposals for text transfer to the dozen. Maybe the simplest is to make a consensus call on this. Cheers Magnus On 2011-09-16 09:02, Sal Ibarra Corretg wrote: > Hi Olle, > > On Sep 16, 2011, at 8:32 AM, Olle E. Johansson wrote: > >> A comment on the list made me go back and re-read the charter. One >> thing I had missed is the data transfer part of rtcweb. >> >> "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." >> >> Most of the discussions on the list has been about the media. What >> are the ideas for data transfer? Applications? >> > > Maybe I arrived a bit late to the party ;-) but so far I've seen > discussions mainly around RTP (and related) media. > >> To me, this seems like an interesting feature. If it's a plain data >> transfer session, a bidirectional session, it's a way to open a >> session from Javascript to any server, acting as an rtcweb client, >> which is different from the current sandbox model. I could have >> missed this discussion, but if not, I think this is an interesting >> topic to bring up. >> >> Another note, which I think is purely a mistake, is to forget >> realtime text - T.140 and just state audio and video. The T.140 >> users are natural early adoptor users of rtcweb. >> > > I can think of another use case for "data transfer": MSRP. A browser > looks looks like a good place for having IM sessions over MSRP. > Supporting file transfers would also be awesome, and MSRP is just a > TCP pipe where data flows, so maybe this "data transfer" layer is the > right place to do this? > > > Regards, > > -- Sal Ibarra Corretg AG Projects > > > > _______________________________________________ rtcweb mailing list > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ibc@aliax.net Fri Sep 16 06:58: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 21B5721F8C0E for ; Fri, 16 Sep 2011 06:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, 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 5hVkzXEP+X5n for ; Fri, 16 Sep 2011 06:58:56 -0700 (PDT) Received: from mail-qw0-f45.google.com (mail-qw0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6964721F8ABD for ; Fri, 16 Sep 2011 06:58:56 -0700 (PDT) Received: by qwg2 with SMTP id 2so1385273qwg.4 for ; Fri, 16 Sep 2011 07:01:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.66.144 with SMTP id n16mr1569955qci.178.1316181670591; Fri, 16 Sep 2011 07:01:10 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Fri, 16 Sep 2011 07:01:10 -0700 (PDT) In-Reply-To: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> Date: Fri, 16 Sep 2011 16:01:10 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Data transfer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 13:58:57 -0000 2011/9/16 Olle E. Johansson : > "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." > > Most of the discussions on the list has been about the media. What are th= e > ideas for data transfer? Applications? Hi. Just my opinion: Having WebSocket protocol I don't see the need for a separate/specific data transfer protocol within WebRTC. WebSocket already allows bidirectional traffic for carrying long text or binary data (I means even GigaBytes of data). Also, HTML5 offers some cool features for "downloading" data received by the JavaScript code. See a demo: http://html5-demos.appspot.com/static/a.download.html --=20 I=C3=B1aki Baz Castillo From magnus.westerlund@ericsson.com Fri Sep 16 07:07: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 69F0521F8C29 for ; Fri, 16 Sep 2011 07:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.354 X-Spam-Level: X-Spam-Status: No, score=-106.354 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 uc1PweBOHRZO for ; Fri, 16 Sep 2011 07:07:36 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5459621F8C0C for ; Fri, 16 Sep 2011 07:07:36 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-0b-4e7358ad3045 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E1.C5.02839.DA8537E4; Fri, 16 Sep 2011 16:09:50 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Fri, 16 Sep 2011 16:09:49 +0200 Message-ID: <4E7358AC.8030509@ericsson.com> Date: Fri, 16 Sep 2011 16:09:48 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data transfer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 14:07:37 -0000 On 2011-09-16 16:01, Iñaki Baz Castillo wrote: > 2011/9/16 Olle E. Johansson : >> "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." >> >> Most of the discussions on the list has been about the media. What are the >> ideas for data transfer? Applications? > > Hi. Just my opinion: > > Having WebSocket protocol I don't see the need for a separate/specific > data transfer protocol within WebRTC. WebSocket already allows > bidirectional traffic for carrying long text or binary data (I means > even GigaBytes of data). > > Also, HTML5 offers some cool features for "downloading" data received > by the JavaScript code. See a demo: > > http://html5-demos.appspot.com/static/a.download.html > The argument for having a peer to peer unreliable datagram channel has been two: 1) Minimal delay by direct peer-to-peer connection instead of going through a central server. This as you can't normally establish a websocket connection to a browser behind a NAT/FW. 2) Scalability by not requiring a server or having to handle the data flows at all on the server side. As an individual I think these arguments are good, and assuming we can find a reasonable solution that fulfills the requirements we should specify 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 Fri Sep 16 07:11: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 E6B0521F84F9 for ; Fri, 16 Sep 2011 07:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.692 X-Spam-Level: X-Spam-Status: No, score=-107.692 tagged_above=-999 required=5 tests=[AWL=2.907, 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 x88OcAcyj2fs for ; Fri, 16 Sep 2011 07:11:29 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0B821F84ED for ; Fri, 16 Sep 2011 07:11:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2FAFF39E0BC for ; Fri, 16 Sep 2011 16:13:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugTgyHGcthVW for ; Fri, 16 Sep 2011 16:13:42 +0200 (CEST) Received: from [172.16.48.184] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id B542339E089 for ; Fri, 16 Sep 2011 16:13:41 +0200 (CEST) Message-ID: <4E735994.2090007@alvestrand.no> Date: Fri, 16 Sep 2011 16:13:40 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E70C387.1070707@ericsson.com> <4e73497a.280d440a.69d0.ffff9f98@mx.google.com> In-Reply-To: <4e73497a.280d440a.69d0.ffff9f98@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 14:11:31 -0000 On 09/16/2011 03:03 PM, Roni Even wrote: > Magnus, > Maybe we can take the approach from > draft-holmberg-mmusic-sdp-multiplex-negotiation and offer the same m-line > with the same port number twice, one as AVP and one as AVPF and let the > other side chose, he can answer with a port=0 for the profile it does not > want. If the multiplex proposal has backward interoperability than this > proposal also does. The backwards compatibility case for this one (grouping type = PICKONE?) would be that the responder establishes two RTP sessions, one with AVP and one with AVPF. Presumably, one has to do a second SDP O/A to get rid of the one the initiator doesn't want, and hope that the responder hasn't started using that one for media. In draft-holmberg, the backwards compatibility case is that the responder establishes two RTP sessions, and both are used - each for one media type. No second pass is needed (as far as I can tell from current discussion). A lot of things become simpler if 2-pass SDP O/A is an acceptable mechanism - first send a very rich offer in order to figure out what the other side is willing to do, then a very lean offer with only the mechanisms one prefers and knows that the responder is capable of supporting. But is this an acceptable strategy? It has costs both in time-to-setup and possibly a quite confusing intermediate state of the SDP session. > Roni Even > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Magnus Westerlund >> Sent: Wednesday, September 14, 2011 6:09 PM >> To: rtcweb@ietf.org >> Subject: [rtcweb] AVPF vs AVP >> >> Hi, >> >> There has been this long thread with the subject partially containing >> "AVPF". I want to clarify something in this context around AVPF. Rather >> than the SRTP question. >> >> An end-point that is AVPF compliant is in fact interoperable with an >> AVP >> one as long as the trr-int parameter is set reasonably large. A >> parameter value of 1.5-5 seconds (I would recommend 3s) will ensure >> that >> they are in fact compatible. This avoids the risk of any side timing >> out >> the other if the AVP side is using the default 5 s minimum interval. >> >> Based on this one could in fact have the RTCWEB nodes always use AVPF >> for RTP/RTCP Behavior. The AVPF feedback messages are explicitly >> negotiated and will only be used when agreed on. >> >> This leaves us with any signaling incompatibilities when talking to a >> legacy device. If one don't want to use cap-neg I see two directions to >> go: >> >> 1) RTCWEB end-point will always signal AVPF or SAVPF. I signalling >> gateway to legacy will change that by removing the F to AVP or SAVP. >> >> 2) RTCWEB end-point will always use AVPF but signal it as AVP. It will >> detect the AVPF capabilities of the other end-point based on the >> signaling of the feedback events intended to be used. >> >> I think 1) is cleaner for the future. 2) might be more pragmatic. >> >> In both cases I believe there are methods for negotiating a lower >> trr-int than some AVP fallback value to preserve interoperability. >> >> >> However, this still don't resolve the question if the "S" should be in >> front of the RTP profile indicator or not. But it might help by >> removing >> the F or not in the profile. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Frgatan 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 Fri Sep 16 07:14: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 CBA9221F8BEB for ; Fri, 16 Sep 2011 07:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 9hlnXLDo3dyB for ; Fri, 16 Sep 2011 07:14:30 -0700 (PDT) Received: from mail-qw0-f45.google.com (mail-qw0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4591121F8BA6 for ; Fri, 16 Sep 2011 07:14:30 -0700 (PDT) Received: by qwg2 with SMTP id 2so1421199qwg.4 for ; Fri, 16 Sep 2011 07:16:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.66.144 with SMTP id n16mr1587402qci.178.1316182604681; Fri, 16 Sep 2011 07:16:44 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Fri, 16 Sep 2011 07:16:44 -0700 (PDT) In-Reply-To: <4E7358AC.8030509@ericsson.com> References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> <4E7358AC.8030509@ericsson.com> Date: Fri, 16 Sep 2011 16:16:44 +0200 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] Data transfer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 14:14:30 -0000 2011/9/16 Magnus Westerlund : > The argument for having a peer to peer unreliable datagram channel has > been two: > > 1) Minimal delay by direct peer-to-peer connection instead of going > through a central server. This as you can't normally establish a > websocket connection to a browser behind a NAT/FW. > > 2) Scalability by not requiring a server or having to handle the data > flows at all on the server side. > > As an individual I think these arguments are good, and assuming we can > find a reasonable solution that fulfills the requirements we should > specify it. I'm not opposed to such mechanism if approved. But given the current WWW reality, web applications always use HTTP for carrying long-data/documents between client and server, or client-server-client. Also I don't think that data transfer can be achieved using an unreliable data channel (so UDP), is it? For example in SIP protocol MSRP has emerged for this purpose (data transfer) and it uses TCP/TLS as transport, so MSRP relay servers are required when both endpoints are behind NAT. Regards. --=20 I=C3=B1aki Baz Castillo From tim@phonefromhere.com Fri Sep 16 07:22: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 11ACE21F8C4E for ; Fri, 16 Sep 2011 07:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCngrG-YG76n for ; Fri, 16 Sep 2011 07:22: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 85D7121F8B0F for ; Fri, 16 Sep 2011 07:22:35 -0700 (PDT) Received: from [192.168.0.14] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 1681537A902; Fri, 16 Sep 2011 15:37:40 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-720951959 From: Tim Panton In-Reply-To: Date: Fri, 16 Sep 2011 15:24:44 +0100 Message-Id: References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 14:22:36 -0000 --Apple-Mail-2-720951959 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 16 Sep 2011, at 10:02, I=F1aki Baz Castillo wrote: >=20 > WebRTC is not about communication between web-browsers as if they were > generic SIP phones contacting directly one to other. >=20 +1 --Apple-Mail-2-720951959 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

WebRTC is not = about communication between web-browsers as if they were
generic SIP = phones contacting directly one to = other.


+1

= --Apple-Mail-2-720951959-- From magnus.westerlund@ericsson.com Fri Sep 16 07: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 A2CD921F8C28 for ; Fri, 16 Sep 2011 07:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.354 X-Spam-Level: X-Spam-Status: No, score=-106.354 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 rW+zgKA8UIhN for ; Fri, 16 Sep 2011 07:37: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 A78B421F8C29 for ; Fri, 16 Sep 2011 07:37:55 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-0d-4e735fc946d5 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B4.1B.20773.9CF537E4; Fri, 16 Sep 2011 16:40:09 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Fri, 16 Sep 2011 16:40:08 +0200 Message-ID: <4E735FC8.20906@ericsson.com> Date: Fri, 16 Sep 2011 16:40:08 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> <4E7358AC.8030509@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data transfer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 14:37:56 -0000 On 2011-09-16 16:16, Iñaki Baz Castillo wrote: > 2011/9/16 Magnus Westerlund : >> The argument for having a peer to peer unreliable datagram channel has >> been two: >> >> 1) Minimal delay by direct peer-to-peer connection instead of going >> through a central server. This as you can't normally establish a >> websocket connection to a browser behind a NAT/FW. >> >> 2) Scalability by not requiring a server or having to handle the data >> flows at all on the server side. >> >> As an individual I think these arguments are good, and assuming we can >> find a reasonable solution that fulfills the requirements we should >> specify it. > > I'm not opposed to such mechanism if approved. But given the current > WWW reality, web applications always use HTTP for carrying > long-data/documents between client and server, or > client-server-client. As I said in another email in this thread the WG have had discussion of also peer to peer reliable data transport that are capable of handling larger data object transfers between the peers. However, the discussion didn't result in a clear consensus for this case. Nor a proponent surfaced that has continued driving the case. > > Also I don't think that data transfer can be achieved using an > unreliable data channel (so UDP), is it? For example in SIP protocol > MSRP has emerged for this purpose (data transfer) and it uses TCP/TLS > as transport, so MSRP relay servers are required when both endpoints > are behind NAT. I think we all agree that for NAT traversal we are expecting it to be IP/UDP/FOO. And it is most likely IP/UDP/DTLS/FOO to have confidential, source authenticated and integrity protected transfers. Where FOO provides congestion control and possible some type of framing or stream concept. But the actual solution is still very early in the discussion. When it comes to data transfer, of course you can achieve reliable transport over an UDP. I think I can mention several different methods in how to achieve it. 1. In this context one option is to implement a reliability function in JS, that buffer and retransmit lost data. 2. Another one would be to use NORM (RFC5740) as the transport protocol inside DTLS. NORM provides both congestion control and reliability. Yes, it might have a few over designed features being intended for multicast. 3. Use TCP over UDP Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ibc@aliax.net Fri Sep 16 07:42: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 8F8B221F8B0A for ; Fri, 16 Sep 2011 07:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 dNsbtq+ZQien for ; Fri, 16 Sep 2011 07:42:08 -0700 (PDT) Received: from mail-qw0-f45.google.com (mail-qw0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id 22C0821F8A80 for ; Fri, 16 Sep 2011 07:42:08 -0700 (PDT) Received: by qwg2 with SMTP id 2so1483205qwg.4 for ; Fri, 16 Sep 2011 07:44:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.66.144 with SMTP id n16mr1617466qci.178.1316184262722; Fri, 16 Sep 2011 07:44:22 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Fri, 16 Sep 2011 07:44:22 -0700 (PDT) In-Reply-To: <4E735FC8.20906@ericsson.com> References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> <4E7358AC.8030509@ericsson.com> <4E735FC8.20906@ericsson.com> Date: Fri, 16 Sep 2011 16:44:22 +0200 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] Data transfer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 14:42:08 -0000 2011/9/16 Magnus Westerlund : > 3. Use TCP over UDP Does it mean implementing a TCP stack in JavaScript? :) --=20 I=C3=B1aki Baz Castillo From john.elwell@siemens-enterprise.com Fri Sep 16 07:49: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 86D0C21F8B36 for ; Fri, 16 Sep 2011 07:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.023 X-Spam-Level: X-Spam-Status: No, score=-103.023 tagged_above=-999 required=5 tests=[AWL=-0.424, 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 YiI-bGfJ0qq3 for ; Fri, 16 Sep 2011 07:49:03 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 903F821F8B28 for ; Fri, 16 Sep 2011 07:49:03 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 9211323F04CF; Fri, 16 Sep 2011 16:51:15 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 16 Sep 2011 16:51:15 +0200 From: "Elwell, John" To: Ravindran Parthasarathi , Hadriel Kaplan Date: Fri, 16 Sep 2011 16:51:14 +0200 Thread-Topic: [rtcweb] Proposed text - remote recording use case Thread-Index: AQHMciK7XwUojQUk70aUevXP868dwpVMX0wwgAABGYCAAjHtsIAAbdhAgAEa2EA= Message-ID: References: <2E239D6FCD033C4BAF15F386A979BF510F09ED@sonusinmail02.sonusnet.com> <8357A942-21EA-4209-82DB-ADFCEB5F32EF@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF510F0B4E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F0C8A@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0C8A@sonusinmail02.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] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 14:49:04 -0000 RTC-Web is specifying: - the browser API (W3C); and - protocols that the browser uses for browser-to-browser communication (IET= F). Any use of WebSockets for communication between JS and elsewhere is not wit= hin scope, as far as I understand. John > -----Original Message----- > From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com]=20 > Sent: 15 September 2011 23:01 > To: Elwell, John; Hadriel Kaplan > Cc: rtcweb@ietf.org > Subject: RE: [rtcweb] Proposed text - remote recording use case >=20 > John, >=20 > Could you please explain in detail about the reason for two websocket > from browser wherein one towards webserver and another=20 > towards recorder > (another webserver) is outside the scope of RTCWeb. Also, I guess that > it would have covered in one of usecase of RTCWeb document already. > AFAIK, there is no restriction on number of websockets from browser. >=20 > Thanks > Partha >=20 > >-----Original Message----- > >From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >Sent: Thursday, September 15, 2011 8:58 PM > >To: Ravindran Parthasarathi; Hadriel Kaplan > >Cc: rtcweb@ietf.org > >Subject: RE: [rtcweb] Proposed text - remote recording use case > > > >Partha, > > > >> -----Original Message----- > >> From: Ravindran Parthasarathi [mailto:pravindran@sonusnet.com] > >> Sent: 14 September 2011 06:57 > >> To: Elwell, John; Hadriel Kaplan > >> Cc: rtcweb@ietf.org > >> Subject: RE: [rtcweb] Proposed text - remote recording use case > >> > >> John, > >> > >> I'm fine with Hadriel proposal of "remote peer" instead > >> "remote browser > >> or SRS" but not the original wordings. > >> > >> At this moment, I'm not convinced whether SIPREC SRS will interop > with > >> RTCWeb browser because the signaling protocol is an open item > >> in RTCWeb. > >> The recording could be done by two websocket from browser=20 > wherein one > >> websocket towards webserver and other towards recorder. How these > >> entities interact with each other has to be discussed & > >> defined. Please > >> let me know the reason why this approach may not be followed > >> in RTCWeb. > >[JRE] I am not saying it will not work, but I consider this to be > >outside scope of RTC-Web. > > > >John > > > > > >> > >> Thanks > >> Partha > >> > >> > >> >-----Original Message----- > >> >From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > >> >Sent: Wednesday, September 14, 2011 11:21 AM > >> >To: Hadriel Kaplan; Ravindran Parthasarathi > >> >Cc: > >> >Subject: RE: [rtcweb] Proposed text - remote recording use case > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > >> >> Sent: 13 September 2011 15:38 > >> >> To: Ravindran Parthasarathi > >> >> Cc: Elwell, John; > >> >> Subject: Re: [rtcweb] Proposed text - remote recording use case > >> >> > >> >> inline... > >> >> > >> >> On Sep 11, 2011, at 4:29 PM, Ravindran Parthasarathi wrote: > >> >> > >> >> > New requirements: > >> >> > Fyy1: The browser MUST be able to send in real-time to an > another > >> >> > browser/session recording server(SRS) that are being > >> >> transmitted to and > >> >> > received from remote browser. > >> >> > >> >> That doesn't make sense in English - *what* needs to be sent > >> >> in real-time? Removing the word "media" broke the meaning. > >> >> Also, the media it needs to replicate/fork may not be to/from > >> >> another "remote browser" - it could be to/from a remote > >> >> gateway, SIP UA, whatever. Really what you want to say is > >> >> to/from a "remote peer". > >> >> Same issues/comments go for the next requirement. > >> >[JRE] I agree the modified words don't make sense and=20 > would like to > >> >stick to the words I proposed at the start of this thread. > >> > > >> >> > >> >> > > >> >> > Ayy1: The web application MUST be able to ask the browser > >> >> to transmit in > >> >> > real-time to another browser/session recording > >> server(SRS) that are > >> >> > being transmitted to and received from remote browser. > >> >> > >> >> Same as above. > >> >> > >> >> > As I asked in the meeting (but couldn't discuss due to time > >> >> constraint), > >> >> > it is possible for browser to do the signaling directly > >> to the SRS > >> >> > without going through original webserver. The=20 > signaling towards > >> >> > recording is not required to be SIP but it shall be > >> websocket (let > >> >> > discuss separately). Here, the advantageous in this model > >> >> is that the > >> >> > recording signaling hop is reduced to 1 hop (browser to > >> SRS) from > >> 2 > >> >> > hops (browser to webserver, webserver to SRS). > >> >> > > >> >> > >> >> Actually, I don't think it is possible for the rtcweb browser > >> >> to properly do SIPREC, even if it had a SIP stack to do it > >> >> with. The reason is the browser doesn't know the full call > >> >> metadata. The browser doesn't know the calling/called party > >> >> info, for example. Even the javascript itself may not know > >> >> it, depending on how the application provider does their > >> >> logic. They could decide to have some state/logic be handled > >> >> by the web server, rather than all in the javascript. For > >> >> example the javascript may just display a list of friends > >> >> using aliases or icons, and the web server may be the only > >> >> one who knows what the friend's AoR/URI actually is for that > alias. > >> >[JRE] Quite so. Metadata would come from the application, but > whether > >> >this is server-side or client-side is out of scope for=20 > RTC-Web. The > >> >important thing is that an application that is able to do the SIP > and > >> >Metadata part of SIPREC can ask the browser to do the media part. > >> > > >> >John > >> > > >> > > >> >> > >> >> -hadriel > >> >> > >> >> > >> > = From magnus.westerlund@ericsson.com Fri Sep 16 07:49: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 DC95321F8C28 for ; Fri, 16 Sep 2011 07:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.353 X-Spam-Level: X-Spam-Status: No, score=-106.353 tagged_above=-999 required=5 tests=[AWL=-0.054, 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 d6tGzVz+p-Iq for ; Fri, 16 Sep 2011 07:49:07 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1B621F8C12 for ; Fri, 16 Sep 2011 07:49:06 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-78-4e736269247b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 99.6C.20773.962637E4; Fri, 16 Sep 2011 16:51:21 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Fri, 16 Sep 2011 16:51:21 +0200 Message-ID: <4E736268.6090405@ericsson.com> Date: Fri, 16 Sep 2011 16:51:20 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> <4E7358AC.8030509@ericsson.com> <4E735FC8.20906@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data transfer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 14:49:08 -0000 On 2011-09-16 16:44, Iñaki Baz Castillo wrote: > 2011/9/16 Magnus Westerlund : >> 3. Use TCP over UDP > > Does it mean implementing a TCP stack in JavaScript? :) > No, I hope not. If this option would be chosen I think the functionality would reside in the browser. Either to try to cross wire the OS TCP stack so that the TCP packets (Checksum issues) are in fact sent over a UDP socket or implement the TCP stack in the browser. I don't want to leave the correctness of the congestion control algorithm in the hand of the web service implementor. All the above as individual Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ibc@aliax.net Fri Sep 16 08:22: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 0243C21F8C5C for ; Fri, 16 Sep 2011 08:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 6WQ6K91+gaNi for ; Fri, 16 Sep 2011 08:22:29 -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 4620D21F8C57 for ; Fri, 16 Sep 2011 08:22:29 -0700 (PDT) Received: by qyk33 with SMTP id 33so4017978qyk.10 for ; Fri, 16 Sep 2011 08:24:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.204.73 with SMTP id fl9mr2073774qab.328.1316186683688; Fri, 16 Sep 2011 08:24:43 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Fri, 16 Sep 2011 08:24:43 -0700 (PDT) In-Reply-To: References: <2E239D6FCD033C4BAF15F386A979BF510F09ED@sonusinmail02.sonusnet.com> <8357A942-21EA-4209-82DB-ADFCEB5F32EF@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF510F0B4E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F0C8A@sonusinmail02.sonusnet.com> Date: Fri, 16 Sep 2011 17:24:43 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Elwell, John" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Proposed text - remote recording use case X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 15:22:30 -0000 2011/9/16 Elwell, John : > RTC-Web is specifying: > - the browser API (W3C); and > - protocols that the browser uses for browser-to-browser communication (I= ETF). AFAIK those protocols just cover the media plane, but not the signaling pla= ne. > Any use of WebSockets for communication between JS and elsewhere is not w= ithin scope, as far as I understand. I agree. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Sep 16 08:39: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 DCA4021F8CA6 for ; Fri, 16 Sep 2011 08:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.472, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_43=1, 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 YN68Ep4FPbZQ for ; Fri, 16 Sep 2011 08:39:58 -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 624EA21F8C90 for ; Fri, 16 Sep 2011 08:39:58 -0700 (PDT) Received: by qyk33 with SMTP id 33so4034569qyk.10 for ; Fri, 16 Sep 2011 08:42:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.204.73 with SMTP id fl9mr2090988qab.328.1316187733117; Fri, 16 Sep 2011 08:42:13 -0700 (PDT) Received: by 10.229.79.207 with HTTP; Fri, 16 Sep 2011 08:42:13 -0700 (PDT) Date: Fri, 16 Sep 2011 17:42:13 +0200 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] Another consideration about signaling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 15:39:59 -0000 Hi all, Let's imagine that rtcweb defines a specific signaling protocol (i.e. SIP) so browsers MUST use it natively for signaling the media streams. Of course this would require a SIP proxy/server in server side (think about NAT) which IMHO seems a showstopper (how to deploy such a SIP proxy in shared web hostings? a "mod_sip" for Apache? should I make a XMPP<->SIP protocol gateway in order to intercommunicate web-browsers with pure XMPP clients?) But there is another important drawback with this assumption: A web site could be interested in drawing in the web the status of the different audio/video streams between users connected to the web. This could mean displaying in the web the active streams (audio/video), when a session is on hold, when it's resumed again, when a new stream is added to a multimedia session (i.e. offering video within an already established audio session). If the signaling uses a separate channel (i.e. SIP) then there is no way for the web server to know what happens during multimedia sessions (or it would be really difficult to achieve). So multimedia sessions would be completely separated from the web page itself. Is that what we want? In the other side, if the signaling is implemented within HTTP or WebSocket (by using any custom mechanism), it would be easy for the web server to know the active sessions status in detail, and it could use such a information for rendering it in the webpage (so others web visitors can see the status of my calls, for example). I just see advantages in *non* mandating a separate and specific signaling protocol within rtcweb, even more taking into account that this is supposed to be an added value for the web. This is: a web-browser MUST NOT be a native SIP phone (IMHO). I wouldn't like to see a competition between Firefox 12 and Chrome 17 in next SIPit (Session Initiation Protocol Interoperability Test). Best regards. --=20 I=C3=B1aki Baz Castillo From dwing@cisco.com Fri Sep 16 11:01: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 141E021F85AA for ; Fri, 16 Sep 2011 11:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=-0.592, 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 ZfLp6NN4J8G9 for ; Fri, 16 Sep 2011 11:01:47 -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 780DB21F8582 for ; Fri, 16 Sep 2011 11:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=876; q=dns/txt; s=iport; t=1316196243; x=1317405843; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=ZLceKa3cnssqTvnc8NyueZ8ngEC+7uIQpK1WL52z+Fs=; b=G7WGc9+eCBAkD6zfkztxWVkCQrXmfDqe9CUpVw8qiAFzbfT6uPmBWIv/ vOH5OWVV1HKvaiZJwoml7QiSKjyKXwrdScIKy3MolEMphOZONXWumTxHm aDmOrP0msf19k4fLccQDcciNckc4fOojkQY11nLzSANdomjnC5vT7QDmN g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwAAEKOc06rRDoJ/2dsb2JhbABCmGGBbI0Sd4FTAQEBAQMICgEXEEsBAwIJDwIEAQEBIwQHGSMKCQgBAQQBEgsXh1mWGQGeLoZ4BIdvnSc X-IronPort-AV: E=Sophos;i="4.68,394,1312156800"; d="scan'208";a="2604729" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 16 Sep 2011 18:04:02 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8GI429e020690; Fri, 16 Sep 2011 18:04:02 GMT From: "Dan Wing" To: "'Randell Jesup'" , References: <6F469757-6B5C-4DC9-BC34-026F34C7E508@phonefromhere.com> <4E724E25.1000204@jesup.org> In-Reply-To: <4E724E25.1000204@jesup.org> Date: Fri, 16 Sep 2011 11:04:02 -0700 Message-ID: <092201cc749b$0450aa50$0cf1fef0$@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: Acxz23Z/F/tohcldR+Sq5iOFh/8D3wAvzcJQ Content-Language: en-us Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket Transport for Session Initiation Protocol (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, 16 Sep 2011 18:01:48 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Randell Jesup > Sent: Thursday, September 15, 2011 12:13 PM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] draft-ibc-rtcweb-sip-websocket -- WebSocket > Transport for Session Initiation Protocol (SIP) > > On 9/15/2011 11:57 AM, Roman Shpount wrote: > > Actually SIP over UDP is what is typically used for mobile apps now. > > If you are doing SIP from the public IP, you do not need to maintain > > the connection even if TCP/TLS is used. > > Markus had a point: SIP over UDP requires keepalives if it's behind a > NAT as well. So maybe it's not such a big difference, depending on the > keepalive rates needed (and for UDP circa 30 sec is typical). PCP could help with that, http://tools.ietf.org/html/draft-ietf-pcp-base-13#section-7.3 -d From dwing@cisco.com Fri Sep 16 11:02: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 0831C21F8B79 for ; Fri, 16 Sep 2011 11:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.181 X-Spam-Level: X-Spam-Status: No, score=-103.181 tagged_above=-999 required=5 tests=[AWL=-0.582, 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 bJfx-fY-aAYN for ; Fri, 16 Sep 2011 11:02: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 32A9421F85F2 for ; Fri, 16 Sep 2011 11:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3792; q=dns/txt; s=iport; t=1316196299; x=1317405899; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=dJPkD6Sb1IgsBudcy0h9y9642uEGfZTeU21EZ0Zngi0=; b=di8aYcuO2dHzeOXGotgDSDLgxDXl7v0Jr/idTTM2qz9jJv3R+MVq14Dm yqhojE5rPZGm+ttbaC2vUoQdMp1aCpYeYa/IGOvmoZRCkuiFRE+do5vt2 0z0jHDNyEkpWu+uLhpIOK1E91BFvq1areltaXp3MYPhK3Aq5HMJ9YnBJL Q=; X-IronPort-AV: E=Sophos;i="4.68,394,1312156800"; d="scan'208";a="2604920" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 16 Sep 2011 18:04:59 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8GI4xBm020417; Fri, 16 Sep 2011 18:04:59 GMT From: "Dan Wing" To: "'Muthu Arul Mozhi Perumal \(mperumal\)'" , "'Christer Holmberg'" , References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> Date: Fri, 16 Sep 2011 11:04:59 -0700 Message-ID: <092301cc749b$26223270$72669750$@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: Acxyw30r82gF7xzoSe2t1rt6OG8s+wAA6iNwAABiKWAAAWch4ABzMI7g Content-Language: en-us Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 18:02:45 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Muthu Arul Mozhi Perumal (mperumal) > Sent: Wednesday, September 14, 2011 4:24 AM > To: Christer Holmberg; rtcweb@ietf.org > Subject: Re: [rtcweb] STUN for keep-alive > > |Well, it depends on the amount of outgoing media traffic, > |but in cases where you only receive media you would still > |need to send keep-alives. > > If you are not sending anything the NAT binding in that direction will > likely timeout. On the other hand, if you are operating in a controlled > environment ICE already allows you to set the STUN keepalive duration > to > the longest duration possible in your environment, so it is already > flexible. PCP can allow the client to know and control the NAT's UDP timeout, http://tools.ietf.org/html/draft-ietf-pcp-base-13#section-7.3. -d > However, it mandates STUN keepalives to be used when an agent is a full > ICE implementation and is communicating with a peer that supports ICE > (lite/full). Are you saying it should allow a different UDP keepalive > method because it can possible have a lesser performance impact? > > Muthu > > |-----Original Message----- > |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > |Sent: Wednesday, September 14, 2011 3:59 PM > |To: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org > |Subject: RE: [rtcweb] STUN for keep-alive > | > | > |Hi, > | > |>|Because, eventhough the keep-alives messages aren't authenticated, > and > |>|do not trigger responses, a gateway would still have to > |>|process them, and since a gateway typically would serve a large > number of browser > |>|clients, that could have quite big performance impact (the number of > |>|STUN keep-alives sent per session of course depend on how much other > |>|media traffic there is, but still). > |> > |>STUN keepalives are required by ICE only in the absence of > |>media traffic. > | > |Yes. That's what I meant with the: > | > | "(the number of STUN keep-alives sent per session of course > depend on how much other media > |traffic there is, but still)" > | > |...statement :) > | > |>Here are the snip from RFC 5245: > |> > |> > |>10. Keepalives > |> > |>If there has been no packet sent on the candidate pair ICE is > |>using for a media component for Tr seconds (where packets > |>include those defined for the component (RTP or RTCP) and > |>previous keepalives), an agent MUST generate a keepalive on > |>that pair. Tr SHOULD be configurable and SHOULD have a > |>default of 15 seconds. Tr MUST NOT be configured to less > |>than 15 seconds. > |> > |> > |> > |>20.2.3. Keepalives > |> > |>STUN keepalives (in the form of STUN Binding Indications) are > |>sent in the middle of a media session. However, they are > |>sent only in the absence of actual media traffic. In > |>deployments that are not utilizing Voice Activity Detection > |>(VAD), the keepalives are never used and there is no increase > |>in bandwidth usage. When VAD is being used, keepalives will > |>be sent during silence periods. This involves a single > |>packet every 15-20 seconds, far less than the packet every > |>20-30 ms that is sent when there is voice. Therefore, > |>keepalives don't have any real impact on capacity planning. > |> > |> > |>Do you think there is still a problem? > | > |Well, it depends on the amount of outgoing media traffic, but in cases > where you only receive media > |you would still need to send keep-alives. > | > |Regards, > | > |Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From HKaplan@acmepacket.com Fri Sep 16 11:03: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 0535E21F8B7B for ; Fri, 16 Sep 2011 11:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 NtKzl9SEmKHS for ; Fri, 16 Sep 2011 11:03:56 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6B89921F8582 for ; Fri, 16 Sep 2011 11:03:56 -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, 16 Sep 2011 14:06:09 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 16 Sep 2011 14:06:10 -0400 From: Hadriel Kaplan To: Roni Even Thread-Topic: [rtcweb] AVPF vs AVP Thread-Index: AQHMcvCC1935An+dNEG35IBBpAPmuQ== Date: Fri, 16 Sep 2011 18:06:10 +0000 Message-ID: <87AC7090-D372-4CC7-A20B-560B0598D7E5@acmepacket.com> References: <4E70C387.1070707@ericsson.com> <4e73497a.280d440a.69d0.ffff9f98@mx.google.com> In-Reply-To: <4e73497a.280d440a.69d0.ffff9f98@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <998C8E51AC956648A6130C9E3D287371@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 18:03:57 -0000 On Sep 16, 2011, at 9:03 AM, Roni Even wrote: > Magnus, > Maybe we can take the approach from > draft-holmberg-mmusic-sdp-multiplex-negotiation and offer the same m-line > with the same port number twice, one as AVP and one as AVPF and let the > other side chose, he can answer with a port=3D0 for the profile it does n= ot > want. If the multiplex proposal has backward interoperability than this > proposal also does. You can't do that. Not only is it not kosher in the sense that you're real= ly offering two media sessions, rather than alternatives for one, but it ac= tually won't work in practice: if the SDP offer crosses an SBC or App-Serve= r B2BUA, some of them will treat them as two media sessions and thus offer = 2 different port numbers on their UAC side and make it no longer distinguis= hable from a normal offer of two media sessions. (and I've tested this on an SBC) -hadriel From dwing@cisco.com Fri Sep 16 11:05: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 52A0321F8BA2 for ; Fri, 16 Sep 2011 11:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.171 X-Spam-Level: X-Spam-Status: No, score=-103.171 tagged_above=-999 required=5 tests=[AWL=-0.572, 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 wNKireCdHc6b for ; Fri, 16 Sep 2011 11:05:41 -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 E288021F8B7B for ; Fri, 16 Sep 2011 11:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1300; q=dns/txt; s=iport; t=1316196477; x=1317406077; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=IqQkYbqzonu33EACpAmKlRUnUxCbOsaT1MKVagtAx/c=; b=fngCvMRao7CwRJgU/h9pm6oSZbnbB/ssd5WH1wvqwASl2C1PxAh2/E83 K9R83TYknyVkjCVv5wXw/L0elCqFwddiq97CQtOuXFA54A4A6kAM3lckj 8UC5TYszEnJM7w7wluIqBtVjb9MH473yk/smnBBRmeb/QbC06EzRTRxXO 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwAACuPc06rRDoH/2dsb2JhbABCmGGBbI0Sd4FTAQEBAQMICgEXED8MAQMCCQ4BAgQBAQEnBxkjCgkIAQEEARILF51wAZ4uhngEh2+dJw X-IronPort-AV: E=Sophos;i="4.68,394,1312156800"; d="scan'208";a="2605162" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 16 Sep 2011 18:07:57 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8GI7ujS015593; Fri, 16 Sep 2011 18:07:56 GMT From: "Dan Wing" To: "'Eric Rescorla'" , "'Christer Holmberg'" References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Date: Fri, 16 Sep 2011 11:07:56 -0700 Message-ID: <092401cc749b$8fd64940$af82dbc0$@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: AcxzBEynNTNEBP85Q82P6pVLYZbepgBlyOkA Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 18:05:42 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Eric Rescorla > Sent: Wednesday, September 14, 2011 10:32 AM > To: Christer Holmberg > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] STUN for keep-alive > > On Wed, Sep 14, 2011 at 10:20 AM, Christer Holmberg > wrote: > > > > Hi, > > > >>One new concern in this context is maintaining the consent freshness. > >>The browser needs to be sure that the recipient of traffic is stil > responding in a way that can't be forged. It's likely RTCP provides > this (though we'd need to analyze to be sure) but perhaps better would > be to mandate STUN checks > >>at enough frequency that you get some sort of level of freshness.... > maybe every 2 minutes or something. > > > > Please note that the STUN keep-alives are implemented using STUN > indication messages, so there are no replies (nor does the receiver > perform an authentication check). > > > Oh... I had forgotten that.... that's not good. The RTCP receiver reports should be adequate for 'consent freshness', no? If I still like receiving the traffic, I'll report that I'm receiving it. If I have crashed or disconnected or am not listening on that port, I won't. -d From dzonatas@gmail.com Fri Sep 16 11:13: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 6610821F886A for ; Fri, 16 Sep 2011 11:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.863 X-Spam-Level: X-Spam-Status: No, score=-3.863 tagged_above=-999 required=5 tests=[AWL=-0.264, 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 07UrJkJc-voJ for ; Fri, 16 Sep 2011 11:13:17 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F41E21F8801 for ; Fri, 16 Sep 2011 11:13:17 -0700 (PDT) Received: by iaby26 with SMTP id y26so3127148iab.31 for ; Fri, 16 Sep 2011 11:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=kvm29/ceqhr8Rk9E/4NT1qrnvH+UfaCI3K0yNv7QThg=; b=OfSBmWOGsmupmxkkg9y8XiVGSsypwQrQtyYPQU82cbM2RhjHy3/OQnytn5ubrn/53/ 5RalMitaJ+eSCOYI+R2eSae/5MJHbEEZ1v6T7Dg0Oz4U1k6Iabjb4rSPUkjMKlFgbQvD W2pl5Zh7KlT3WKk8U+zzzd/uWZsUbVdyKikKM= Received: by 10.231.51.4 with SMTP id b4mr4221534ibg.99.1316196932767; Fri, 16 Sep 2011 11:15:32 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id z11sm10382028iba.6.2011.09.16.11.15.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Sep 2011 11:15:31 -0700 (PDT) Message-ID: <4E7392C6.9040604@gmail.com> Date: Fri, 16 Sep 2011 11:17:42 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <092301cc749b$26223270$72669750$@com> In-Reply-To: <092301cc749b$26223270$72669750$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 18:13:18 -0000 On 09/16/2011 11:04 AM, Dan Wing wrote: >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Muthu Arul Mozhi Perumal (mperumal) >> Sent: Wednesday, September 14, 2011 4:24 AM >> To: Christer Holmberg; rtcweb@ietf.org >> Subject: Re: [rtcweb] STUN for keep-alive >> >> |Well, it depends on the amount of outgoing media traffic, >> |but in cases where you only receive media you would still >> |need to send keep-alives. >> >> If you are not sending anything the NAT binding in that direction will >> likely timeout. On the other hand, if you are operating in a controlled >> environment ICE already allows you to set the STUN keepalive duration >> to >> the longest duration possible in your environment, so it is already >> flexible. >> > PCP can allow the client to know and control the NAT's UDP timeout, > http://tools.ietf.org/html/draft-ietf-pcp-base-13#section-7.3. > > -d > NAT64 doesn't have to worry about UDP content or timeouts like in IPv4 when set up correctly, yet we can' expect everybody to use such configuration we consider correct. +1 for OAuth MAC for this reason. > >> However, it mandates STUN keepalives to be used when an agent is a full >> ICE implementation and is communicating with a peer that supports ICE >> (lite/full). Are you saying it should allow a different UDP keepalive >> method because it can possible have a lesser performance impact? >> >> Muthu >> >> |-----Original Message----- >> |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> |Sent: Wednesday, September 14, 2011 3:59 PM >> |To: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org >> |Subject: RE: [rtcweb] STUN for keep-alive >> | >> | >> |Hi, >> | >> |>|Because, eventhough the keep-alives messages aren't authenticated, >> and >> |>|do not trigger responses, a gateway would still have to >> |>|process them, and since a gateway typically would serve a large >> number of browser >> |>|clients, that could have quite big performance impact (the number of >> |>|STUN keep-alives sent per session of course depend on how much other >> |>|media traffic there is, but still). >> |> >> |>STUN keepalives are required by ICE only in the absence of >> |>media traffic. >> | >> |Yes. That's what I meant with the: >> | >> | "(the number of STUN keep-alives sent per session of course >> depend on how much other media >> |traffic there is, but still)" >> | >> |...statement :) >> | >> |>Here are the snip from RFC 5245: >> |> >> |> >> |>10. Keepalives >> |> >> |>If there has been no packet sent on the candidate pair ICE is >> |>using for a media component for Tr seconds (where packets >> |>include those defined for the component (RTP or RTCP) and >> |>previous keepalives), an agent MUST generate a keepalive on >> |>that pair. Tr SHOULD be configurable and SHOULD have a >> |>default of 15 seconds. Tr MUST NOT be configured to less >> |>than 15 seconds. >> |> >> |> >> |> >> |>20.2.3. Keepalives >> |> >> |>STUN keepalives (in the form of STUN Binding Indications) are >> |>sent in the middle of a media session. However, they are >> |>sent only in the absence of actual media traffic. In >> |>deployments that are not utilizing Voice Activity Detection >> |>(VAD), the keepalives are never used and there is no increase >> |>in bandwidth usage. When VAD is being used, keepalives will >> |>be sent during silence periods. This involves a single >> |>packet every 15-20 seconds, far less than the packet every >> |>20-30 ms that is sent when there is voice. Therefore, >> |>keepalives don't have any real impact on capacity planning. >> |> >> |> >> |>Do you think there is still a problem? >> | >> |Well, it depends on the amount of outgoing media traffic, but in cases >> where you only receive media >> |you would still need to send keep-alives. >> | >> |Regards, >> | >> |Christer >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- --- The wheel. From HKaplan@acmepacket.com Fri Sep 16 11:26: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 E99E621F84D1 for ; Fri, 16 Sep 2011 11:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 0dYk0YDT18XS for ; Fri, 16 Sep 2011 11:26:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id F07A221F841A for ; Fri, 16 Sep 2011 11:26: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; Fri, 16 Sep 2011 14:29:01 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 16 Sep 2011 14:29:01 -0400 From: Hadriel Kaplan To: Harald Alvestrand Thread-Topic: SDP offer/answer vs. JSON (was: About defining a signaling protocol for WebRTC (or not)) Thread-Index: AQHMdJ6ASfE9VHVwDUuGxXm7AxKbwQ== Date: Fri, 16 Sep 2011 18:29:00 +0000 Message-ID: References: <4E71927C.1090606@skype.net> <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com> <20110915140248.4cc17977@lminiero-acer> <4E71F90D.8030302@alvestrand.no> In-Reply-To: <4E71F90D.8030302@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <936B9D931B4B4343873754E972E12572@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: [rtcweb] SDP offer/answer vs. JSON (was: About defining a signaling protocol for WebRTC (or not)) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 18:26:48 -0000 On Sep 15, 2011, at 9:09 AM, Harald Alvestrand wrote: > The disadvantage of parsing to another structure (I am fond of JSON mysel= f) is that one has to maintain a data definition for the format being parse= d to, a defined transform between that and the "canonical SDP structure" ha= s to be implemented in user space when one does SDP interoperability, both = of those have to be updated for every SDP extension that someone defines so= mewhere, and one is still not free to define extensions on the non-SDP side= if one still requires the ability to map them into SDP. >=20 > If one uses the "native" SDP format, which is the format in which every e= xtension to the format gets documented, the browsers are the ones who *have= * to parse it (although others are likely to). Right so the above paragraphs get to the heart of the matter, methinks. Ul= timately we need W3C to define an API, and the API has to provide a means o= f learning RTP/media info from the browser and commanding the browser to pe= rform certain things with RTP/media. One could expose this API as a true d= ata structure, or as a long string of tokens to be parsed/serialized back/f= orth. If the latter, then the choices are basically JSON or SDP. And SDP = seems advantageous because it appears to be the least work for the simple u= se-cases, because the javascript could just copy back/forth the SDP between= the browser and server. In other words you're optimizing for the very sim= ple use-cases, in exchange for making it more complicated for the advanced = use-cases. Right? OK, that's a laudable goal. And I recognize that the decision has basicall= y already been made, and nothing's going to change it.=20 But email's free... so for the sake of posterity (and email archiving) here= 're some reasons not to use SDP anyway: 1) Incorporating SDP and the offer/answer model into the Browser and W3C AP= I inexorably ties the W3C to the IETF MMUSIC working group for all time. S= o far, I had been going on the assumption the IETF would be defining what t= he RTP library had to do/expose, while W3C would define the API. But if th= e API includes SDP offer/answer, that portion is the IETF's domain too, afa= ik. Anything the W3C wants to do in the future for that has to go through = the IETF, not just IANA. (right?) 2) This isn't just about JSON vs. SDP - it's about SDP *offer/answer*. SDP= offer/answer wasn't meant to be an API between an application and its RTP = library - it's a *protocol* between applications. One side-effect of this = is it has historic state. For example, if an SDP offer contains two media = lines, and one media is removed, the number of SDP media lines don't reduce= back to one - EVER. So if PeerConnection.removeStream() is invoked, the B= rowser needs to remember there was that stream and signal it in SDP as disa= bled for all time, until PeerConnection is closed. If addStream() is invok= ed later, it could/could-not re-use that same (disabled) media line, or add= a new one. As another example, if a new SDP offer is sent out in SIP and gets rejected= with a 488, the session reverts to the previously agreed SDP state. The B= rowser would therefore have to keep state of previous SDP and revert to it = to handle this case. For example, if my Javascript started with only an au= dio MediaStream in PeerConnection and later added a video MediaStream to it= , the new SDP offer would contain two media lines - if the offer gets rejec= ted with 488, how is that communicated to the Browser and what will the bro= wser do? 3) You might well want information conveyed across that "API" that is not m= eant to be sent on the wire in SDP - things you don't want defined by IANA = as SDP tokens. For example, you may want to provide packet counts, jitter,= latency, and other meta-information about individual RTP codecs. Using JS= ON allows you to have data member variables which will not get serialized i= nto SDP, but are purely for the javascript's use, while still within the re= ferential tree structure of the media stream info. Or they may be for send= ing to peers, but simply not for SDP. (like you could send the jitter/laten= cy info through the signaling channel) 4) Obviously if the application as a whole needs to do SDP offer/answer, th= en *someone* will have to implement it correctly, including the state-relat= ed stuff. It could be the browser or the javascript that do this. Chrome = may do a perfect job of that in the browser, afaik. But there are other br= owser vendors, including niche ones such as Dolphin and Skyfire. What are = the odds they all get it right the first time? So which would you rather have updating an SDP engine, if one is even neede= d... or updating "every SDP extension that someone defines somewhere": the = javascript which is written by the developer that knows what they want when= they want it, and can update their code by updating their javascript (or n= ot if they don't need to); or the browsers which are written by companies n= ot under the javascript developer's control, at a time of the browser compa= nies' choosing?=20 Obviously for some things the browser will have to be updated regardless, f= or example to understand rather than just ignore new JSON entries, to provi= de new codecs, etc. But not all new SDP attributes require changes in the = media plane, nor encoding into JSON. In fact, a lot doesn't - some of it's= higher-application info, not really for the RTP library, and more of it's = coming in the future.=20 -hadriel From ekr@rtfm.com Fri Sep 16 11:28: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 4970B21F8C51 for ; Fri, 16 Sep 2011 11:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.903 X-Spam-Level: X-Spam-Status: No, score=-102.903 tagged_above=-999 required=5 tests=[AWL=0.074, 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 8pSdihj1WE40 for ; Fri, 16 Sep 2011 11:28:51 -0700 (PDT) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8D82E21F8C4E for ; Fri, 16 Sep 2011 11:28:51 -0700 (PDT) Received: by wyh15 with SMTP id 15so7261965wyh.27 for ; Fri, 16 Sep 2011 11:31:06 -0700 (PDT) Received: by 10.227.28.141 with SMTP id m13mr1379241wbc.37.1316197866189; Fri, 16 Sep 2011 11:31:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.196.9 with HTTP; Fri, 16 Sep 2011 11:30:46 -0700 (PDT) In-Reply-To: <092401cc749b$8fd64940$af82dbc0$@com> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> From: Eric Rescorla Date: Fri, 16 Sep 2011 11:30:46 -0700 Message-ID: To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 18:28:52 -0000 On Fri, Sep 16, 2011 at 11:07 AM, Dan Wing wrote: >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Eric Rescorla >> Sent: Wednesday, September 14, 2011 10:32 AM >> To: Christer Holmberg >> Cc: rtcweb@ietf.org >> Subject: Re: [rtcweb] STUN for keep-alive >> >> On Wed, Sep 14, 2011 at 10:20 AM, Christer Holmberg >> wrote: >> > >> > Hi, >> > >> >>One new concern in this context is maintaining the consent freshness. >> >>The browser needs to be sure that the recipient of traffic is stil >> responding in a way that can't be forged. It's likely RTCP provides >> this (though we'd need to analyze to be sure) but perhaps better would >> be to mandate STUN checks >> >>at enough frequency that you get some sort of level of freshness.... >> maybe every 2 minutes or something. >> > >> > Please note that the STUN keep-alives are implemented using STUN >> indication messages, so there are no replies (nor does the receiver >> perform an authentication check). >> >> >> Oh... I had forgotten that.... that's not good. > > The RTCP receiver reports should be adequate for 'consent freshness', no? > If I still like receiving the traffic, I'll report that I'm receiving it. > If I have crashed or disconnected or am not listening on that port, I won't. I believe so, though I'd have to make sure there's enough entropy. And of course some implementations may not do RTCP... -Ekr From dwing@cisco.com Fri Sep 16 12:32: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 68B0B21F8CF6 for ; Fri, 16 Sep 2011 12:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.162 X-Spam-Level: X-Spam-Status: No, score=-103.162 tagged_above=-999 required=5 tests=[AWL=-0.563, 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 aF8VlRIAFI6E for ; Fri, 16 Sep 2011 12:32:11 -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 7FB7B21F8D2C for ; Fri, 16 Sep 2011 12:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5304; q=dns/txt; s=iport; t=1316201667; x=1317411267; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=SPCFHvemytKIuHnxa3GNzMKYGNQidK1T8MAuFnKhkEI=; b=S1QrmBmFew2n2v8J1yB1Thf16Jx+Q+bBV3PL41y36vdu8QoXxdAZ3QOa HAgcbMxMXhBQbBYAuwnmpVwNMvdTF6oYzkVYySYbWX/ixj7PNwyZaZKw2 Tcxkt4+RaSI31MBRre5I4D1b8IjSP0oTtBTpbBUa4smL8ojjqVhlIvs13 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0AANajc06rRDoJ/2dsb2JhbABBmGKBbI0Sd4FTAQEBAQMBAQEFCgEXEDQXAQMCCQ8CBAEBAScHGQ4VCgkIAQEEARILF4dZlXUBnjOGeASHb50n X-IronPort-AV: E=Sophos;i="4.68,395,1312156800"; d="scan'208";a="2617415" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 16 Sep 2011 19:34:27 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8GJYQA8005733; Fri, 16 Sep 2011 19:34:26 GMT From: "Dan Wing" To: "'Dzonatas Sol'" , References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <092301cc749b$26223270$72669750$@com> <4E7392C6.9040604@gmail.com> In-Reply-To: <4E7392C6.9040604@gmail.com> Date: Fri, 16 Sep 2011 12:34:26 -0700 Message-ID: <095801cc74a7$a5362010$efa26030$@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: Acx0nK6aUpNzwm2ISym/dE+mqDrM3gACrI6g Content-Language: en-us Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 19:32:12 -0000 > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Dzonatas Sol > Sent: Friday, September 16, 2011 11:18 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] STUN for keep-alive > > On 09/16/2011 11:04 AM, Dan Wing wrote: > >> -----Original Message----- > >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >> Behalf Of Muthu Arul Mozhi Perumal (mperumal) > >> Sent: Wednesday, September 14, 2011 4:24 AM > >> To: Christer Holmberg; rtcweb@ietf.org > >> Subject: Re: [rtcweb] STUN for keep-alive > >> > >> |Well, it depends on the amount of outgoing media traffic, > >> |but in cases where you only receive media you would still > >> |need to send keep-alives. > >> > >> If you are not sending anything the NAT binding in that direction > will > >> likely timeout. On the other hand, if you are operating in a > controlled > >> environment ICE already allows you to set the STUN keepalive > duration > >> to > >> the longest duration possible in your environment, so it is already > >> flexible. > >> > > PCP can allow the client to know and control the NAT's UDP timeout, > > http://tools.ietf.org/html/draft-ietf-pcp-base-13#section-7.3. > > > > -d > > > > NAT64 doesn't have to worry about UDP content or timeouts like in IPv4 > when set up correctly, yet we can' expect everybody to use such > configuration we consider correct. There are two types of NAT64: stateless (which has the characteristic you describe) and stateful (which would require keepalive traffic for all the reasons today's NAPT44 devices require keepalives). I don't know what is meant by "when set up correctly". -d > +1 for OAuth MAC for this reason. > > > > > > >> However, it mandates STUN keepalives to be used when an agent is a > full > >> ICE implementation and is communicating with a peer that supports > ICE > >> (lite/full). Are you saying it should allow a different UDP > keepalive > >> method because it can possible have a lesser performance impact? > >> > >> Muthu > >> > >> |-----Original Message----- > >> |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >> |Sent: Wednesday, September 14, 2011 3:59 PM > >> |To: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org > >> |Subject: RE: [rtcweb] STUN for keep-alive > >> | > >> | > >> |Hi, > >> | > >> |>|Because, eventhough the keep-alives messages aren't > authenticated, > >> and > >> |>|do not trigger responses, a gateway would still have to > >> |>|process them, and since a gateway typically would serve a large > >> number of browser > >> |>|clients, that could have quite big performance impact (the number > of > >> |>|STUN keep-alives sent per session of course depend on how much > other > >> |>|media traffic there is, but still). > >> |> > >> |>STUN keepalives are required by ICE only in the absence of > >> |>media traffic. > >> | > >> |Yes. That's what I meant with the: > >> | > >> | "(the number of STUN keep-alives sent per session of course > >> depend on how much other media > >> |traffic there is, but still)" > >> | > >> |...statement :) > >> | > >> |>Here are the snip from RFC 5245: > >> |> > >> |> > >> |>10. Keepalives > >> |> > >> |>If there has been no packet sent on the candidate pair ICE is > >> |>using for a media component for Tr seconds (where packets > >> |>include those defined for the component (RTP or RTCP) and > >> |>previous keepalives), an agent MUST generate a keepalive on > >> |>that pair. Tr SHOULD be configurable and SHOULD have a > >> |>default of 15 seconds. Tr MUST NOT be configured to less > >> |>than 15 seconds. > >> |> > >> |> > >> |> > >> |>20.2.3. Keepalives > >> |> > >> |>STUN keepalives (in the form of STUN Binding Indications) are > >> |>sent in the middle of a media session. However, they are > >> |>sent only in the absence of actual media traffic. In > >> |>deployments that are not utilizing Voice Activity Detection > >> |>(VAD), the keepalives are never used and there is no increase > >> |>in bandwidth usage. When VAD is being used, keepalives will > >> |>be sent during silence periods. This involves a single > >> |>packet every 15-20 seconds, far less than the packet every > >> |>20-30 ms that is sent when there is voice. Therefore, > >> |>keepalives don't have any real impact on capacity planning. > >> |> > >> |> > >> |>Do you think there is still a problem? > >> | > >> |Well, it depends on the amount of outgoing media traffic, but in > cases > >> where you only receive media > >> |you would still need to send keep-alives. > >> | > >> |Regards, > >> | > >> |Christer > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > > -- > > --- > The wheel. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From dzonatas@gmail.com Fri Sep 16 12:53: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 3EE0121F8D08 for ; Fri, 16 Sep 2011 12:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[AWL=-0.260, 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 8LTAFGNG9rzO for ; Fri, 16 Sep 2011 12:53:08 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7BE21F8CF1 for ; Fri, 16 Sep 2011 12:53:08 -0700 (PDT) Received: by iaby26 with SMTP id y26so3215381iab.31 for ; Fri, 16 Sep 2011 12:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Np/gZdZcrakk0uhNMU5ce9RhpYiuRUkj/rBkmkrZXwg=; b=i84fva4CiHmn0JCL2rCK1ZdXxbxedHGSyI7z1bjU1ebDsQeCyiMAADiJ6qWPl7t9mD V52sEVYW+Wqx7WyyxhuT9W3A994z0qOYukB+TWAbh00DDNjlqefLKSMAoMYLg1sOaLZc T+EafPO0ygdgTb7BlDMuM/ZEJPEtswXhiT/Vw= Received: by 10.42.72.129 with SMTP id o1mr1990107icj.211.1316202918251; Fri, 16 Sep 2011 12:55:18 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id z11sm10719883iba.6.2011.09.16.12.55.16 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Sep 2011 12:55:17 -0700 (PDT) Message-ID: <4E73AA28.1080208@gmail.com> Date: Fri, 16 Sep 2011 12:57:28 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: Dan Wing References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <092301cc749b$26223270$72669750$@com> <4E7392C6.9040604@gmail.com> <095801cc74a7$a5362010$efa26030$@com> In-Reply-To: <095801cc74a7$a5362010$efa26030$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 19:53:13 -0000 On 09/16/2011 12:34 PM, Dan Wing wrote: >> -----Original Message----- >> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >> Behalf Of Dzonatas Sol >> Sent: Friday, September 16, 2011 11:18 AM >> To: rtcweb@ietf.org >> Subject: Re: [rtcweb] STUN for keep-alive >> >> On 09/16/2011 11:04 AM, Dan Wing wrote: >> >>>> -----Original Message----- >>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>> Behalf Of Muthu Arul Mozhi Perumal (mperumal) >>>> Sent: Wednesday, September 14, 2011 4:24 AM >>>> To: Christer Holmberg; rtcweb@ietf.org >>>> Subject: Re: [rtcweb] STUN for keep-alive >>>> >>>> |Well, it depends on the amount of outgoing media traffic, >>>> |but in cases where you only receive media you would still >>>> |need to send keep-alives. >>>> >>>> If you are not sending anything the NAT binding in that direction >>>> >> will >> >>>> likely timeout. On the other hand, if you are operating in a >>>> >> controlled >> >>>> environment ICE already allows you to set the STUN keepalive >>>> >> duration >> >>>> to >>>> the longest duration possible in your environment, so it is already >>>> flexible. >>>> >>>> >>> PCP can allow the client to know and control the NAT's UDP timeout, >>> http://tools.ietf.org/html/draft-ietf-pcp-base-13#section-7.3. >>> >>> -d >>> >>> >> NAT64 doesn't have to worry about UDP content or timeouts like in IPv4 >> when set up correctly, yet we can' expect everybody to use such >> configuration we consider correct. >> > There are two types of NAT64: stateless (which has the characteristic > you describe) and stateful (which would require keepalive traffic > for all the reasons today's NAPT44 devices require keepalives). I > don't know what is meant by "when set up correctly". > > -d > We call those "which would require keepalive traffic" simply battery systems (in simulation-only context). Chakra and aha (no AI, no artificial entropy)! Is there an additional "signaling" when SIP throws 402? Within the box we first assume the battery is the source. In physical simulations, we consider the ground is the source ("historic"). I think JSON can send-on its own port and not constantly munge with XML ports that forces an option to show. JSON could be the default for websockets. > >> +1 for OAuth MAC for this reason. >> >> >> >> >>> >>>> However, it mandates STUN keepalives to be used when an agent is a >>>> >> full >> >>>> ICE implementation and is communicating with a peer that supports >>>> >> ICE >> >>>> (lite/full). Are you saying it should allow a different UDP >>>> >> keepalive >> >>>> method because it can possible have a lesser performance impact? >>>> >>>> Muthu >>>> >>>> |-----Original Message----- >>>> |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> |Sent: Wednesday, September 14, 2011 3:59 PM >>>> |To: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org >>>> |Subject: RE: [rtcweb] STUN for keep-alive >>>> | >>>> | >>>> |Hi, >>>> | >>>> |>|Because, eventhough the keep-alives messages aren't >>>> >> authenticated, >> >>>> and >>>> |>|do not trigger responses, a gateway would still have to >>>> |>|process them, and since a gateway typically would serve a large >>>> number of browser >>>> |>|clients, that could have quite big performance impact (the number >>>> >> of >> >>>> |>|STUN keep-alives sent per session of course depend on how much >>>> >> other >> >>>> |>|media traffic there is, but still). >>>> |> >>>> |>STUN keepalives are required by ICE only in the absence of >>>> |>media traffic. >>>> | >>>> |Yes. That's what I meant with the: >>>> | >>>> | "(the number of STUN keep-alives sent per session of course >>>> depend on how much other media >>>> |traffic there is, but still)" >>>> | >>>> |...statement :) >>>> | >>>> |>Here are the snip from RFC 5245: >>>> |> >>>> |> >>>> |>10. Keepalives >>>> |> >>>> |>If there has been no packet sent on the candidate pair ICE is >>>> |>using for a media component for Tr seconds (where packets >>>> |>include those defined for the component (RTP or RTCP) and >>>> |>previous keepalives), an agent MUST generate a keepalive on >>>> |>that pair. Tr SHOULD be configurable and SHOULD have a >>>> |>default of 15 seconds. Tr MUST NOT be configured to less >>>> |>than 15 seconds. >>>> |> >>>> |> >>>> |> >>>> |>20.2.3. Keepalives >>>> |> >>>> |>STUN keepalives (in the form of STUN Binding Indications) are >>>> |>sent in the middle of a media session. However, they are >>>> |>sent only in the absence of actual media traffic. In >>>> |>deployments that are not utilizing Voice Activity Detection >>>> |>(VAD), the keepalives are never used and there is no increase >>>> |>in bandwidth usage. When VAD is being used, keepalives will >>>> |>be sent during silence periods. This involves a single >>>> |>packet every 15-20 seconds, far less than the packet every >>>> |>20-30 ms that is sent when there is voice. Therefore, >>>> |>keepalives don't have any real impact on capacity planning. >>>> |> >>>> |> >>>> |>Do you think there is still a problem? >>>> | >>>> |Well, it depends on the amount of outgoing media traffic, but in >>>> >> cases >> >>>> where you only receive media >>>> |you would still need to send keep-alives. >>>> | >>>> |Regards, >>>> | >>>> |Christer >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >>> >> >> -- >> >> --- >> The wheel. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > -- --- The wheel. From ted.ietf@gmail.com Fri Sep 16 13:41: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 B5ADE21F8D6F for ; Fri, 16 Sep 2011 13:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.592 X-Spam-Level: X-Spam-Status: No, score=-3.592 tagged_above=-999 required=5 tests=[AWL=0.006, 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 DT4fMdzyTNqX for ; Fri, 16 Sep 2011 13:41:19 -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 C6D9E21F8D66 for ; Fri, 16 Sep 2011 13:41:18 -0700 (PDT) Received: by ywa6 with SMTP id 6so3764644ywa.31 for ; Fri, 16 Sep 2011 13:43:34 -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=50CfTpakE3V3CXotuv+VzS/ik9Yz13JFsnPDxQ19H8Q=; b=aoivHSGqf6pQus/ynOskHI865zfZot9FoSy43UXq7PhtE8Lao3GjCF+9CHsVkTcapw 7BFiuxhY2SwLEzXJSLYTp4AFXsZLe6k7LX2hRkPeApM7PL7k8VrU+2aJvX2BwNP/CFxV 3hy/IBSph8lZTqs/02jTONRtD84xVsq0kh+mQ= MIME-Version: 1.0 Received: by 10.236.201.129 with SMTP id b1mr12973522yho.19.1316205814205; Fri, 16 Sep 2011 13:43:34 -0700 (PDT) Received: by 10.236.105.201 with HTTP; Fri, 16 Sep 2011 13:43:34 -0700 (PDT) In-Reply-To: <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> Date: Fri, 16 Sep 2011 13:43:34 -0700 Message-ID: From: Ted Hardie To: Jim McEachern Content-Type: multipart/alternative; boundary=20cf303dd4e801cda004ad150cea Cc: "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 20:41:19 -0000 --20cf303dd4e801cda004ad150cea Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 15, 2011 at 8:23 PM, Jim McEachern wrote: > Hadriel, > Well said. > > Your closing paragraph sums it up nicely in my mind. > > > The only thing we need to do for rtcweb is make sure the RTP library built > into the browser supports media in such a way that it can communicate with > other RTP peers at a media plane, regardless of what signaling protocol > those peers might be using, preferably without going through media gateways. > And ... we need to make sure it's possible to use SIP on the rtcweb > server.... > > > I think there is more to it than this for it to be a success. We have to make sure that it is relatively easy to adopt rtcweb in javascript applications. The way we've discussed that in the past was "2 party video chat in 20 lines of javascript". If a novel signalling protocol is created every time, that won't be a practical choice. Even if the signalling is segmented into libraries, the app will have to download the one in use by a particular website, potentially every time. This is better than a plugin in some ways and potentially actually worse in others. We also have to make sure that the resulting application does not flood or fry the network. That means it will have to have real congestion control mechanisms. Trusting the javascript application for that has some real issues which we've already discussed. Splitting signaling and congestion control isn't a lot better. If congestion control at the network level is managed by the browser but signalling is in the javascript, then information about that state has to pass into the JS application, so it can manage the signalling. That makes the APIs more complex and runs the risk that a naive javascript application will not adjust to the congestion control requirements at all. The early web took off in part because of the ease of embedding things like images (compared to gopher, for example) into rich content. We have the opportunity to create native web applications with much richer and more interactive experiences with rtcweb, but if it is not easy to do, it won't have the same impact. If this is something that can be done only by folks who can roll their own signalling protocol, it's dead, because the number of content authors is too small. If it even requires selecting among an unbounded set of variously maintained libraries , it will be frustrating for the developer of simple applications. At that level, the existing plugins will simply be more stable and better known. Providing baseline APIs into a well-known signaling capability seems to me far more likely to result in a real flowering of rtcweb content. That's why I want it. Just my two cents, not taken from any hat, Ted --20cf303dd4e801cda004ad150cea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Sep 15, 2011 at 8:23 PM, Jim McEachern <jim.mceachern@genband.com> wrote:
Hadriel,
Well said.

Your closing paragraph sums it up nicely in my mind.

<snip>
The only thing we need to do for rtcweb is make sure the RTP library built = into the browser supports media in such a way that it can communicate with = other RTP peers at a media plane, regardless of what signaling protocol tho= se peers might be using, preferably without going through media gateways. = =A0And ... we need to make sure it's possible to use SIP on the rtcweb = server....
</snip>


I think there is m= ore to it than this for it to be a success.=A0 We have to make sure that it= is relatively easy to adopt=A0 rtcweb in javascript applications.=A0 The w= ay we've discussed that in the past was "2 party video chat in 20 = lines of javascript".=A0=A0 If a novel signalling protocol is created = every time, that won't be a practical choice.=A0 Even if the signalling= is segmented into libraries, the app will have to download the one in use = by a particular website, potentially every time.=A0 This is better than a p= lugin in some ways and potentially actually worse in others.

We also have to make sure that the resulting application does not flood= or fry the network. That means it will have to have real congestion contro= l mechanisms.=A0=A0 Trusting the javascript application for that has some r= eal issues which we've already discussed. =A0 Splitting signaling and c= ongestion control isn't a lot better.=A0 If congestion control at the n= etwork level is managed by the browser but signalling is in the javascript,= then information about that state has to pass into the JS application, so = it can manage the signalling.=A0 That makes the APIs more complex and runs = the risk that a naive javascript application will not adjust to the congest= ion control requirements at all.

The early web took off in part because of the ease of embedding things = like images (compared to gopher, for example) into rich content.=A0 We have= the opportunity to create native web applications with much richer and mor= e interactive experiences with rtcweb, but if it is not easy to do, it won&= #39;t have the same impact.=A0 If this is something that can be done only b= y folks who can roll their own signalling protocol, it's dead, because = the number of content authors is too small.=A0 If it even requires selectin= g among an unbounded set of variously maintained libraries , it will be fru= strating for the developer of simple applications. =A0 At that level, the e= xisting plugins will simply be more stable and better known.

Providing baseline APIs into a well-known signaling capability seems to= me far more likely to result in a real flowering of rtcweb content.=A0 Tha= t's why I want it.

Just my two cents, not taken from any hat,
Ted
--20cf303dd4e801cda004ad150cea-- From cbran@cisco.com Fri Sep 16 13: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 C01EF21F8D0E for ; Fri, 16 Sep 2011 13:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTk7Eph-kTEU for ; Fri, 16 Sep 2011 13:48:17 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id EBB3321F8D0D for ; Fri, 16 Sep 2011 13:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cbran@cisco.com; l=7855; q=dns/txt; s=iport; t=1316206232; x=1317415832; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=egtJjtjZGZev0ElDhKuIHV5EnVwxYlVNvVGv1tWtTw8=; b=ZHY84gXqMJkLDEwLxeaeN/uoufGz8Le4TOPrEFLf2L3sr6rwXT6Wyh/d eatCPxXoxTONHG5wqZ2lpcVYLmQkIVeDY67ok8hW+eLcy7hjGjjFkZiD4 9ntAmqzYcVSsPzDGo+ehPluYxWd2BVkLgqX8wubcL7GeGto5cg0q4H8gz g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAHAFm2c06rRDoG/2dsb2JhbABBgk2kDoEDAneBUwEBAQECAQEBAQ8BKjELBQ0BCAkPIywGMAEBBAENBSKHVQSWOgGeIYZ4BIc/MIRehn2FJoRshzo X-IronPort-AV: E=Sophos;i="4.68,395,1312156800"; d="scan'208,217";a="2639465" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 16 Sep 2011 20:50:32 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8GKoW7h019253; Fri, 16 Sep 2011 20:50:32 GMT Received: from xmb-sjc-228.amer.cisco.com ([128.107.191.125]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Sep 2011 13:50:32 -0700 Received: from 64.101.44.136 ([64.101.44.136]) by xmb-sjc-228.amer.cisco.com ([128.107.191.125]) with Microsoft Exchange Server HTTP-DAV ; Fri, 16 Sep 2011 20:50:31 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Fri, 16 Sep 2011 13:50:30 -0700 From: cbran To: Ted Hardie , Jim McEachern Message-ID: Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: Acx0skUlp3o+dLYgY0SRUu0WF3nTZA== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3399025830_19869571" X-OriginalArrivalTime: 16 Sep 2011 20:50:32.0231 (UTC) FILETIME=[467A1B70:01CC74B2] Cc: "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 20:48:18 -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_3399025830_19869571 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable +1 Ted =AD totally agree. On 9/16/11 1:43 PM, "Ted Hardie" wrote: > On Thu, Sep 15, 2011 at 8:23 PM, Jim McEachern > wrote: >> Hadriel, >> Well said. >>=20 >> Your closing paragraph sums it up nicely in my mind. >>=20 >> >> The only thing we need to do for rtcweb is make sure the RTP library bui= lt >> into the browser supports media in such a way that it can communicate wi= th >> other RTP peers at a media plane, regardless of what signaling protocol = those >> peers might be using, preferably without going through media gateways. =A0= And >> ... we need to make sure it's possible to use SIP on the rtcweb server..= .. >> >>=20 >=20 > I think there is more to it than this for it to be a success.=A0 We have to= make > sure that it is relatively easy to adopt=A0 rtcweb in javascript applicatio= ns.=A0 > The way we've discussed that in the past was "2 party video chat in 20 li= nes > of javascript".=A0=A0 If a novel signalling protocol is created every time, t= hat > won't be a practical choice.=A0 Even if the signalling is segmented into > libraries, the app will have to download the one in use by a particular > website, potentially every time.=A0 This is better than a plugin in some wa= ys > and potentially actually worse in others. >=20 > We also have to make sure that the resulting application does not flood o= r fry > the network. That means it will have to have real congestion control > mechanisms.=A0=A0 Trusting the javascript application for that has some real > issues which we've already discussed. =A0 Splitting signaling and congestio= n > control isn't a lot better.=A0 If congestion control at the network level i= s > managed by the browser but signalling is in the javascript, then informat= ion > about that state has to pass into the JS application, so it can manage th= e > signalling.=A0 That makes the APIs more complex and runs the risk that a na= ive > javascript application will not adjust to the congestion control requirem= ents > at all. >=20 > The early web took off in part because of the ease of embedding things li= ke > images (compared to gopher, for example) into rich content.=A0 We have the > opportunity to create native web applications with much richer and more > interactive experiences with rtcweb, but if it is not easy to do, it won'= t > have the same impact.=A0 If this is something that can be done only by folk= s who > can roll their own signalling protocol, it's dead, because the number of > content authors is too small.=A0 If it even requires selecting among an > unbounded set of variously maintained libraries , it will be frustrating = for > the developer of simple applications. =A0 At that level, the existing plugi= ns > will simply be more stable and better known. >=20 > Providing baseline APIs into a well-known signaling capability seems to m= e far > more likely to result in a real flowering of rtcweb content.=A0 That's why = I > want it. >=20 > Just my two cents, not taken from any hat, >=20 > Ted >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --B_3399025830_19869571 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defini= ng a signaling protocol for WebRTC (or not)] +1 Ted – tota= lly agree.



On 9/16/11 1:43 PM, "Ted Hardie" <ted.ietf@gmail.com> wrote:

On Thu, Sep 15, 2011 at 8:23 PM, Jim McEachern <jim.mceachern@genband.com> wrote:
Hadriel,
Well said.

Your closing paragraph sums it up nicely in my mind.

<snip>
The only thing we need to do for rtcweb is make sure the RTP library built = into the browser supports media in such a way that it can communicate with o= ther RTP peers at a media plane, regardless of what signaling protocol those= peers might be using, preferably without going through media gateways. =A0And= ... we need to make sure it's possible to use SIP on the rtcweb server....<= BR> </snip>


I think there is more to it than this for it to be a success.=A0 We have to m= ake sure that it is relatively easy to adopt=A0 rtcweb in javascript applicati= ons.=A0 The way we've discussed that in the past was "2 party video chat = in 20 lines of javascript".=A0=A0 If a novel signalling protocol is created= every time, that won't be a practical choice.=A0 Even if the signalling is se= gmented into libraries, the app will have to download the one in use by a pa= rticular website, potentially every time.=A0 This is better than a plugin in s= ome ways and potentially actually worse in others.

We also have to make sure that the resulting application does not flood or = fry the network. That means it will have to have real congestion control mec= hanisms.=A0=A0 Trusting the javascript application for that has some real issues= which we've already discussed. =A0 Splitting signaling and congestion control= isn't a lot better.=A0 If congestion control at the network level is managed = by the browser but signalling is in the javascript, then information about t= hat state has to pass into the JS application, so it can manage the signalli= ng.=A0 That makes the APIs more complex and runs the risk that a naive javascr= ipt application will not adjust to the congestion control requirements at al= l.

The early web took off in part because of the ease of embedding things like= images (compared to gopher, for example) into rich content.=A0 We have the op= portunity to create native web applications with much richer and more intera= ctive experiences with rtcweb, but if it is not easy to do, it won't have th= e same impact.=A0 If this is something that can be done only by folks who can = roll their own signalling protocol, it's dead, because the number of content= authors is too small.=A0 If it even requires selecting among an unbounded set= of variously maintained libraries , it will be frustrating for the develope= r of simple applications. =A0 At that level, the existing plugins will simply = be more stable and better known.

Providing baseline APIs into a well-known signaling capability seems to me = far more likely to result in a real flowering of rtcweb content.=A0 That's why= I want it.

Just my two cents, not taken from any hat,

Ted

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org= /mailman/listinfo/rtcweb
--B_3399025830_19869571-- From henry.sinnreich@gmail.com Fri Sep 16 13:54: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 33ACB21F8D1D for ; Fri, 16 Sep 2011 13:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_BACKHAIR_43=1, 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 z98nlcCT1CTz for ; Fri, 16 Sep 2011 13:54:40 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBD721F8D1B for ; Fri, 16 Sep 2011 13:54:40 -0700 (PDT) Received: by gxk19 with SMTP id 19so3849701gxk.31 for ; Fri, 16 Sep 2011 13:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=sPL/66yFnMshM9MpCWgBP5U13m85ioJk9ze+VLmCJUc=; b=LWq/s7fQCDWDSKJnwRAIqYNwmVKnsRMS9SfQRDZ28WS5qc9Fa+Ij85DN+glHNV+/Oc KlAQaaphwjwZJ88yFuTRQPpwaFKeUoNlNjBbrFKUINZhFo/7CWPJEVIzI8fcq6DJIkgv 6+KE/lD5IQXTf0QIPwoG5Cjq6XWea29t8Otgg= Received: by 10.236.183.170 with SMTP id q30mr14781825yhm.42.1316206613141; Fri, 16 Sep 2011 13:56:53 -0700 (PDT) Received: from [192.168.15.2] (cpe-76-184-249-163.tx.res.rr.com. [76.184.249.163]) by mx.google.com with ESMTPS id f63sm8895391yhj.14.2011.09.16.13.56.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Sep 2011 13:56:51 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Fri, 16 Sep 2011 15:56:48 -0500 From: Henry Sinnreich To: =?ISO-8859-1?B?SfFha2k=?= Baz Castillo , Message-ID: Thread-Topic: [rtcweb] Another consideration about signaling Thread-Index: Acx0syZzLo57rL1lF0KNa/24X9wTtQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [rtcweb] Another consideration about signaling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 20:54:41 -0000 +1 These are indeed critical items to consider >if the signaling is implemented within HTTP or WebSocket (by using >any custom mechanism), it would be easy for the web server to know the act= ive >sessions status in detail, and it could use such a information for renderi= ng >it in the webpage (so others web visitors can see the status of my calls, = for >example). >I just see advantages in *non* mandating a separate and specific >signaling protocol within rtcweb, even more taking into account >that this is supposed to be an added value for the web. This is: a >web-browser MUST NOT be a native SIP phone (IMHO). Though I would add the "other web visitors" may well be other app component= s that creative developers may assemble into rich apps. Thanks, Henry On 9/16/11 10:42 AM, "I=F1aki Baz Castillo" wrote: > Hi all, Let's imagine that rtcweb defines a specific signaling protocol > (i.e. SIP) so browsers MUST use it natively for signaling the media > streams. Of course this would require a SIP proxy/server in server side > (think about NAT) which IMHO seems a showstopper (how to deploy such a > SIP proxy in shared web hostings? a "mod_sip" for Apache? should I make > a XMPP<->SIP protocol gateway in order to intercommunicate web-browsers with > pure XMPP clients?) But there is another important drawback with this > assumption: A web site could be interested in drawing in the web the status > of the different audio/video streams between users connected to the web. > This could mean displaying in the web the active streams (audio/video), when a > session is on hold, when it's resumed again, when a new stream is added to a > multimedia session (i.e. offering video within an already established audio > session). If the signaling uses a separate channel (i.e. SIP) then there is > no way for the web server to know what happens during multimedia sessions (or > it would be really difficult to achieve). So multimedia sessions would be > completely separated from the web page itself. Is that what we want? In the > other side, if the signaling is implemented within HTTP or WebSocket (by using > any custom mechanism), it would be easy for the web server to know the active > sessions status in detail, and it could use such a information for rendering > it in the webpage (so others web visitors can see the status of my calls, for > example). I just see advantages in *non* mandating a separate and > specific signaling protocol within rtcweb, even more taking into account > that this is supposed to be an added value for the web. This is: a web-browser > MUST NOT be a native SIP phone (IMHO). I wouldn't like to see a competition > between Firefox 12 and Chrome 17 in next SIPit (Session Initiation Protocol > Interoperability Test). Best regards. -- I=F1aki Baz > Castillo _______________________________________________ rtcwe > b mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From dzonatas@gmail.com Fri Sep 16 14:06: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 C0F9021F8876 for ; Fri, 16 Sep 2011 14:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.356 X-Spam-Level: X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[AWL=-0.757, BAYES_00=-2.599, J_BACKHAIR_43=1, 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 gxhtHuXh5ZEi for ; Fri, 16 Sep 2011 14:06:08 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3172621F886A for ; Fri, 16 Sep 2011 14:06:08 -0700 (PDT) Received: by pzk33 with SMTP id 33so4163617pzk.4 for ; Fri, 16 Sep 2011 14:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ChVmqjZw+kKpEqGuqfe/pwDwA0WrZ6o3BwkXc4duMuU=; b=P9IOZlZOl8EwruNTeMWCtq7zm+voO7uaFMwByu5xcGLHHiC9fWm2yLVLIGt4OT+zOc yDyCi2jJbNnOlKpruVJSQY5h/HMSeL9cKxs8kCPQmvye1gjIwn2qxrrkD/ljIlsfoNTk kFMKhqPtmYyeMlJbGDorli645EgzVAB98r4Ns= Received: by 10.68.56.232 with SMTP id d8mr1825015pbq.169.1316207302189; Fri, 16 Sep 2011 14:08:22 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id z1sm36389075pbz.6.2011.09.16.14.08.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Sep 2011 14:08:21 -0700 (PDT) Message-ID: <4E73BB48.3070201@gmail.com> Date: Fri, 16 Sep 2011 14:10:32 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] Another consideration about signaling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 21:06:08 -0000 On 09/16/2011 01:56 PM, Henry Sinnreich wrote: > +1 > > These are indeed critical items to consider > > >> if the signaling is implemented within HTTP or WebSocket (by using >> any custom mechanism), it would be easy for the web server to know the active >> sessions status in detail, and it could use such a information for rendering >> it in the webpage (so others web visitors can see the status of my calls, for >> example). >> > >> I just see advantages in *non* mandating a separate and specific >> signaling protocol within rtcweb, even more taking into account >> that this is supposed to be an added value for the web. This is: a >> web-browser MUST NOT be a native SIP phone (IMHO). >> > Though I would add the "other web visitors" may well be other app components > that creative developers may assemble into rich apps. > > Thanks, Henry > Let JSON be the default for websockets, and we can call those lambda expressions. > > On 9/16/11 10:42 AM, "I�aki Baz Castillo" wrote: > > >> Hi all, >> > Let's imagine that rtcweb defines a specific signaling protocol > >> (i.e. >> > SIP) so browsers MUST use it natively for signaling the media > >> streams. >> > Of course this would require a SIP proxy/server in server side > >> (think >> > about NAT) which IMHO seems a showstopper (how to deploy such a > >> SIP >> > proxy in shared web hostings? a "mod_sip" for Apache? should I make > >> a >> > XMPP<->SIP protocol gateway in order to intercommunicate web-browsers > with > >> pure XMPP clients?) >> > But there is another important drawback with this > >> assumption: >> > A web site could be interested in drawing in the web the status > >> of the >> > different audio/video streams between users connected to the web. > >> This >> > could mean displaying in the web the active streams (audio/video), > when a > >> session is on hold, when it's resumed again, when a new stream >> > is added to a > >> multimedia session (i.e. offering video within an >> > already established audio > >> session). >> > If the signaling uses a separate channel (i.e. SIP) then there is > >> no >> > way for the web server to know what happens during multimedia sessions > (or > >> it would be really difficult to achieve). So multimedia sessions >> > would be > >> completely separated from the web page itself. Is that what >> > we want? > > In the > >> other side, if the signaling is implemented within HTTP or >> > WebSocket (by using > >> any custom mechanism), it would be easy for the >> > web server to know the active > >> sessions status in detail, and it could >> > use such a information for rendering > >> it in the webpage (so others web >> > visitors can see the status of my calls, for > >> example). >> > I just see advantages in *non* mandating a separate and > >> specific >> > signaling protocol within rtcweb, even more taking into account > >> that >> > this is supposed to be an added value for the web. This is: a > web-browser > >> MUST NOT be a native SIP phone (IMHO). I wouldn't like to >> > see a competition > >> between Firefox 12 and Chrome 17 in next SIPit >> > (Session Initiation Protocol > >> Interoperability Test). >> > Best regards. > > -- --- The wheel. From HKaplan@acmepacket.com Fri Sep 16 14:12: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 F1D8021F8C7E for ; Fri, 16 Sep 2011 14:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 HRLHDhCYwq52 for ; Fri, 16 Sep 2011 14:12:56 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD3E21F8C41 for ; Fri, 16 Sep 2011 14:12:56 -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, 16 Sep 2011 17:15:09 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 16 Sep 2011 17:15:09 -0400 From: Hadriel Kaplan To: Ted Hardie Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: AQHMdLW2EiwyblOJ60uEF0NrtxmELg== Date: Fri, 16 Sep 2011 21:15:09 +0000 Message-ID: <857CF434-8957-48AD-8399-0F305F08CA8E@acmepacket.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 21:12:57 -0000 On Sep 16, 2011, at 4:43 PM, Ted Hardie wrote: > We also have to make sure that the resulting application does not flood o= r fry the network. That means it will have to have real congestion control = mechanisms. Trusting the javascript application for that has some real is= sues which we've already discussed. Splitting signaling and congestion co= ntrol isn't a lot better. If congestion control at the network level is ma= naged by the browser but signalling is in the javascript, then information = about that state has to pass into the JS application, so it can manage the = signalling. That makes the APIs more complex and runs the risk that a naiv= e javascript application will not adjust to the congestion control requirem= ents at all. Yes you're right we have to make sure things don't collapse, but I'm confus= ed why congestion control would be handled in the JS, or in signaling. Wou= ldn't it be done in the RTP/RTCP layer, such as draft-alvestrand-rtcweb-con= gestion-00 or whatever, if the RTP peer supported it? Who said it would be= in signaling? (I must have missed something, or misunderstand you) -hadriel From stewe@stewe.org Fri Sep 16 16:33: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 EE0EE21F8B78 for ; Fri, 16 Sep 2011 16:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, 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 4fFbEjPhI-nP for ; Fri, 16 Sep 2011 16:33:50 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id C745C21F8B70 for ; Fri, 16 Sep 2011 16:33:49 -0700 (PDT) Received: from [192.168.1.62] (unverified [71.202.147.60]) by stewe.org (SurgeMail 3.9e) with ESMTP id 38455-1743317 for ; Sat, 17 Sep 2011 01:36:02 +0200 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Fri, 16 Sep 2011 16:35:53 -0700 From: Stephan Wenger To: "" Message-ID: Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3399035762_15862410" 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] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 16 Sep 2011 23:33:51 -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_3399035762_15862410 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, From: Ted Hardie Date: Fri, 16 Sep 2011 13:43:34 -0700 To: Jim McEachern Cc: "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] [=8A] > We have to make sure that it is relatively easy to adopt rtcweb in > javascript applications. The way we've discussed that in the past was "2 > party video chat in 20 lines of javascript". [=8A] I think that something along these lines ought to be added to the requirements draft (perhaps in softened form, and perhaps not even as a Requirement but rather in the intro section), and a discussion about issues that libraries may have ought to be added to framework drafts. Stephan --B_3399035762_15862410 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi,

From: Ted Hardie <ted.ietf@gmail.com>
Date: Fri, 16 Sep 2011 13:43:34 -0700
To: <= /span> Jim McEachern <jim.mcea= chern@genband.com>
Cc: "<= ;rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: A= bout defining a signaling protocol for WebRTC (or not)]

[…]
  We have to make sure that = it is relatively easy to adopt  rtcweb in javascript applications. = ; The way we've discussed that in the past was "2 party video chat in 20 lin= es of javascript".  
[…]

=
I think that something a= long these lines ought to be added to the requirements draft (perhaps in sof= tened form, and perhaps not even as a Requirement but rather in the intro se= ction), and a discussion about issues that libraries may have ought to be ad= ded to framework drafts.    

Stephan

--B_3399035762_15862410-- From matthew.kaufman@skype.net Fri Sep 16 20:45: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 34DA121F8B44 for ; Fri, 16 Sep 2011 20:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.76 X-Spam-Level: X-Spam-Status: No, score=-4.76 tagged_above=-999 required=5 tests=[AWL=0.770, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 lH4XLm0y26o8 for ; Fri, 16 Sep 2011 20:45:55 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id EBD0121F8B3F for ; Fri, 16 Sep 2011 20:45:54 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id CA0E77FE; Sat, 17 Sep 2011 05:48:08 +0200 (CEST) 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=fjzjB99rBF3sjB MSQrh0mnb61JU=; b=qUsBGTZQIRYgIeM6PmwSdriigWn9h1p3ACGdjJIVLK6YsL NIcZHuzdhrRuQDvdnLpRKH4qo0Ke6HtTVlWPubW73ry8Ic5LqksZOA4rSuaF7jB+ fq+0E9/rbZaZaY4Kz7z416NnlpwK6mUDlM6+iohUQhJTYi+6Df/Qm4d2iqvMs= 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=Ga+m15JI14QzihsswbD520 zsYocZnKo5olC8fQmN2EZUZ4l5uV7LW4UOT2x5Nc81m6cr14qDW6Tk3xYik3C6++ 3qic0WmPlNLjXKQqZmJwvLBSLtl8AHMY+s0TX9Czi3s7mJXygtuYw/Gudf6T5sVC J7JJ7tdieuTcYMoWwUMBo= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id C616A7FC; Sat, 17 Sep 2011 05:48:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 9EF443506F2B; Sat, 17 Sep 2011 05:48:08 +0200 (CEST) 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 IerB7CgVJeqJ; Sat, 17 Sep 2011 05:48:07 +0200 (CEST) Received: from dhcp-209.braemoor.net (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id B6B153506E9B; Sat, 17 Sep 2011 05:48:06 +0200 (CEST) Message-ID: <4E73BA23.6040305@skype.net> Date: Fri, 16 Sep 2011 23:05:39 +0200 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> In-Reply-To: <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Sep 2011 03:45:56 -0000 On 9/16/11 4:24 AM, Hadriel Kaplan wrote: > There is no need for a "default signaling protocol", because the "signaling" is between the browser's Javascript and its web server. And as for the signaling protocol the web server has to support in order to speak to other servers or non-RTCweb endpoints, even if we specified to use SIP we'd just be summarily ignored by those who don't want to, because they actually don't *need* to. It doesn't hurt interoperability of rtcweb if they don't implement SIP - it just means they can't talk to other SIP devices/servers. But it's not like we need an RFC to say "if you don't implement X then you can't talk to people who do X". Agree. > > Think of this RTCWEB concept as Skinny/SCCP. The Web Server is Call Manager, and the browser is the Skinny phone, but in this case instead of needing a 7960 phone, the Skinny protocol was written in javascript and uses a browser's user interface for its GUI and the built-in RTP library for media. (in fact one could probably write a javascript to do just that, if Call Manager handled SCCP over websocket) Actually, it is even better than this. Think of the RTCWEB Javascript API as "Skinny/SCCP". The web developer is then free to have "call manager" be up in the server and simply pass down data that is reflected directly into the API... or the web developer can use the fact that there's a complete programming environment on the browser to implement some or all of "call manager" *at the browser*, and that choice is completely in the application developer's hands. They can write Skinny in Javascript and use the browser UI for the GUI and RTP library for media, and interoperate with SIP by building a complete SIP-to-Skinny translation at the server. But they can also write SIP in Javascript and use the browser UI for the GUI and RTP library for the media, and interoperate with SIP by building just a Websocket-to-SIP converter up at the server. Completely up to them... *if* we build a Javascript API that actually lets the programmer make this decision, just like they can make the same decision when they are programming to the Windows or Mac APIs. On other other hand, if we bake too much in (a SIP implementation, all the semantics of SDP offer-answer, etc.) then the application developer either has their hands tied, or is forced to resort to silly things like taking an SDP offer and parsing it in Javascript to get the capabilities of the browser they're running in and then writing it back out as a different SDP offer that matches what they really want. > > Clearly the IETF does not need to define for Cisco a standardized replacement for the SCCP protocol for this to work, because one isn't needed since the client javascript and server are built by the same developers and they know how their proprietary signaling works. Indeed. The protocol needs exactly the same level of standardization that Google needed to build Gmail. You need HTTP, possibly Websockets, a common programming language (Javascript) and a common set of interfaces (the Javascript API). The rest, including exactly what is transported on the wire, should be up to the developer. The format, how much of the logic lives at each end, etc. > So how about for the signaling Call Manager would use to other VoIP devices, like gateways or VoIP service providers? Does the IETF need to tell Cisco what peer-to-peer protocol(s) to implement on Call Manager? No, and we never have. Cisco's product managers decide that. They decide if Call Manager needs to be able to communicate a standard protocol at all, such as SIP or H.323, and which one/any of those. They decide based on their use-cases/need. Agree. If they want to connect to SIP providers for PSTN access, they can implement that. If they want to talk XMPP and Jingle because that's their preferred federation protocol, that's ok too. > > Some rtcweb developers may not do any standard signaling protocol, ever. For example many Instant Messaging providers still have closed environments to this day. (e.g., AIM, YIM, MSN, etc.) My employer is arguably one of the largest VoIP providers in the world, and most definitely isn't using standard signaling protocols. > Some may choose to only use H.323, or XMPP, or IAX, or even BICC. Some may choose to only support SIP with 3GPP extensions. Obviously most of us think/hope people do SIP, but really the market makes those types of decisions, not the IETF. Just like the IETF standardized MGCP but didn't specify what the MGCP Call Agent had to support to speak to other Call Agents. SIP was given as an example in MGCP, but not mandated. > > The only thing we need to do for rtcweb is make sure the RTP library built into the browser supports media in such a way that it can communicate with other RTP peers at a media plane, regardless of what signaling protocol those peers might be using, preferably without going through media gateways. This, and supports enough security/safety that the library can be trusted to run in the browser environment. (This is where the ICE requirement comes from.) > And obviously since SIP is a very common protocol and defined by the IETF we need to make sure it's possible to use SIP on the rtcweb server, but we can't *mandate* that it be used or supported, and if we did it wouldn't change anything. Obviously it is always possible to use SIP on the RTCWEB server. After all, it is fairly trivial to gateway from Flash Player and RTMP or RTMFP to SIP, and there's no commonality there at all. The odds are extremely high that we can make interoperation even easier, both by opening up the capability and control APIs and by using a standard media transport so that media gateways can be avoided in many cases. Matthew Kaufman From matthew.kaufman@skype.net Fri Sep 16 20:45: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 C1AD221F8B94 for ; Fri, 16 Sep 2011 20:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.792 X-Spam-Level: X-Spam-Status: No, score=-4.792 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 E+xQSaSlR41G for ; Fri, 16 Sep 2011 20:45:58 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 13E9121F8B44 for ; Fri, 16 Sep 2011 20:45:58 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 047917FE; Sat, 17 Sep 2011 05:48:14 +0200 (CEST) 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=beWWcilJDy4OSv mcafwZUrvBopQ=; b=xRKXMb2QH9JZsKxqEH8JbQIqXI4QeGCdS/6QD+aiakOsxn 8M7kuy3HKnIO1ESFvmrO0zhi+bimcUOAEs2Wzi2Kl86frGv7yAGP/gew3OzR+IMK FunkJSXoTDO7/kW/6x6pA72o3F9kVqhWnRcvL62ZsOPdFrVA2/So6Oio6uVPA= 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=YdR1AjcvF8bWc+8q+tx33Q iW/PZjJq+KloztH3SXVUAdD9xO6ldsLHvfIxJ9VL0cb0CSIpzZcuBx1N4nfQR8yK i6lGo6F0MqmJH9FuI44X9A1DXsB32Xy83EpVjiIQXNrWqvRl3CiLGDBsMI7zdFjJ TC0OGq47DGjt6zvFvEomM= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 02DBD7FC; Sat, 17 Sep 2011 05:48:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id D67863506E9B; Sat, 17 Sep 2011 05:48:13 +0200 (CEST) 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 XSaO0isX3fex; Sat, 17 Sep 2011 05:48:13 +0200 (CEST) Received: from dhcp-209.braemoor.net (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 181903506E99; Sat, 17 Sep 2011 05:48:11 +0200 (CEST) Message-ID: <4E73BBC8.7070507@skype.net> Date: Fri, 16 Sep 2011 23:12:40 +0200 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <4E71927C.1090606@skype.net> <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com> <20110915140248.4cc17977@lminiero-acer> <4E71F90D.8030302@alvestrand.no> In-Reply-To: <4E71F90D.8030302@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Sep 2011 03:45:58 -0000 On 9/15/11 3:09 PM, Harald Alvestrand wrote: > The disadvantage of parsing to another structure (I am fond of JSON > myself) is that one has to maintain a data definition for the format > being parsed to, a defined transform between that and the "canonical > SDP structure" has to be implemented in user space when one does SDP > interoperability, both of those have to be updated for every SDP > extension that someone defines somewhere, and one is still not free to > define extensions on the non-SDP side if one still requires the > ability to map them into SDP. > > If one uses the "native" SDP format, which is the format in which > every extension to the format gets documented, the browsers are the > ones who *have* to parse it (although others are likely to). Of course what you're also saying here is that it takes a trip to the IETF to make every extension. So if the *only* Javascript API for controlling the codec (or getting its capabilities by triggering an offer) is a pile of SDP in string form, then nothing that hasn't been standardized can be described. For example: forcing the Opus codec to "music" mode no matter what the input. Matthew Kaufman From matthew.kaufman@skype.net Fri Sep 16 20:54: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 50DD121F8B74 for ; Fri, 16 Sep 2011 20:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.822 X-Spam-Level: X-Spam-Status: No, score=-4.822 tagged_above=-999 required=5 tests=[AWL=0.708, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 a3IwthdCIrRH for ; Fri, 16 Sep 2011 20:54:19 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id BDAD521F8B73 for ; Fri, 16 Sep 2011 20:54:18 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 2F6467FE; Sat, 17 Sep 2011 05:48:17 +0200 (CEST) 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=KUKHFMy4vibz29 5yYMqFFYJs970=; b=FXot+LVVRmI8PXViEl4Rw83w9Qdlc7mTGQGnqO0eLNUSha CdQc+JY9HkgUUhED/uP5TgdI0OwERCyxRyvHdDyKyRrqBJH10lA0CMZivr5I+8bE 7JlUd+ZkG08v3jRRDuvGghrQII7Ty6ICBxgmL9vzHbROV1YYGh7s/eb05rBAg= 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=vDxUMShsfK3oYzRu00YeWS Mh7tYvvGf7PlIpFjavjcQUe9eTb6iGzHsxE19jy2fC8Jddp+3AezKx34PtBtNX/j R+2rFfS5gRalI4+1a9Tvgb4WKKxCSJ1aWg8bwsK3X+6Q4RlqcuQeuTZGZBoaOA5x MTNCcSRVF+BnU4QDxe3Qs= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 24F347FC; Sat, 17 Sep 2011 05:48:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id E528D3506E9B; Sat, 17 Sep 2011 05:48:16 +0200 (CEST) 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 HR9AJo90J5Qv; Sat, 17 Sep 2011 05:48:16 +0200 (CEST) Received: from dhcp-209.braemoor.net (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 553523506E99; Sat, 17 Sep 2011 05:48:15 +0200 (CEST) Message-ID: <4E73C056.2090003@skype.net> Date: Fri, 16 Sep 2011 23:32:06 +0200 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Ravindran Parthasarathi References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Sep 2011 03:54:22 -0000 On 9/16/11 1:56 AM, Ravindran Parthasarathi wrote: > Hi Saul, > > I really didn't get your argument fully because in case there is no default signaling protocol, it is unavoidable to have island of devices without gateways but you argue other way around. Browsers cannot talk to each other without at least a web server to serve up the application (HTML and Javascript) and a server over which to exchange the ICE signaling information, so they won't be talking to each other "on their own" anyway. Once you have that, RTCWEB calling is no more or less an island than web-based messaging services. Some of them let users compose messages that stay within the "walled garden" of the service (and that is their choice), others let users compose email which is exchanged with other services over standard protocols like SMTP. > > I specifically asked for the scope of your opinion on RTCWeb work is between browser-to-browser RTCWEB needs to specify the browser-to-browser media and the APIs by which that media channel is created and controlled. That is all. > or browser-to-other end-point to know whether parallel universe has to be build or not. For the media channel, it would be helpful if the "browser-to-browser" media uses a standard such as RTP so that "browser-to-other" can be done directly, without media gateways. For signaling, this is not nearly so important a requirement, and in fact conflicts with the goals of providing flexible APIs that allow developers to use web browsers as a development platform... an operating system and runtime, rather than a pre-built "phone" as I've said before. > In case there is no default signaling protocol, it is impossible to communicate between browser-to-endpoint without gateways. Signaling? True. Media? Hopefully not. > Let us assume that the intention of RTCWeb is to create island of browser devices The intention of RTCWeb is to bring real-time communication capabilities to the browser environment so that developers may create applications that leverage these features. Whether or not that results in an "island" will be up to the developers of these applications. Does "the Linux operating system" create an "island of computer devices" because someone else needs to supply the software that lets them play real-time games with each other? > even then the native signaling protocol for RTCWeb has advantage over Jquery library and plugin is not the solution. There is no need for a "native signaling protocol for RTCWeb", just a standard way of delivering applications (HTTP) and running them in the browser (HTML + Javascript) > > Having said that, I agree that it is possible to implement RTP or STUN or SIP stack or codec using Javascript or plugins but interop and better performance is not guaranteed. > Why is that even necessary for interop? Hotmail didn't write IMAP and SMTP in Javascript to make Hotmail work and yet it seems to interoperate with the world of SMTP email services just fine. Matthew Kaufman From oej@edvina.net Sat Sep 17 01:20: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 A3B9121F8B0E for ; Sat, 17 Sep 2011 01:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwK+ybgHSxJQ for ; Sat, 17 Sep 2011 01:20:31 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id D76F921F8A96 for ; Sat, 17 Sep 2011 01:20:30 -0700 (PDT) Received: from [IPv6:2001:470:1f15:d79:4011:f094:8b7:a6e1] (unknown [IPv6:2001:470:1f15:d79:4011:f094:8b7:a6e1]) by smtp7.webway.se (Postfix) with ESMTPA id 96683754BCE4; Sat, 17 Sep 2011 08:22:41 +0000 (UTC) From: "Olle E. Johansson" Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_0A764E9B-9CCD-481F-946B-F29A47966B7A" Date: Sat, 17 Sep 2011 10:22:42 +0200 In-Reply-To: <4E73BA23.6040305@skype.net> To: Matthew Kaufman , rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <4E73BA23.6040305@skype.net> Message-Id: X-Mailer: Apple Mail (2.1244.3) Subject: Re: [rtcweb] ICE and security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 08:20:33 -0000 --Apple-Mail=_0A764E9B-9CCD-481F-946B-F29A47966B7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 16 sep 2011 kl. 23:05 skrev Matthew Kaufman: >> The only thing we need to do for rtcweb is make sure the RTP library = built into the browser supports media in such a way that it can = communicate with other RTP peers at a media plane, regardless of what = signaling protocol those peers might be using, preferably without going = through media gateways. >=20 > This, and supports enough security/safety that the library can be = trusted to run in the browser environment. (This is where the ICE = requirement comes from.) Matt, Can you please elaborate how ice relates to security? THanks, /O= --Apple-Mail=_0A764E9B-9CCD-481F-946B-F29A47966B7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The only thing we need to do for rtcweb = is make sure the RTP library built into the browser supports media in = such a way that it can communicate with other RTP peers at a media = plane, regardless of what signaling protocol those peers might be using, = preferably without going through media = gateways.

This, and supports enough security/safety = that the library can be trusted to run in the browser environment. (This = is where the ICE requirement comes = from.)

In-Reply-To: <4E73C056.2090003@skype.net> Date: Sat, 17 Sep 2011 10:27:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> To: Matthew Kaufman X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Sep 2011 08:24:47 -0000 16 sep 2011 kl. 23:32 skrev Matthew Kaufman: > On 9/16/11 1:56 AM, Ravindran Parthasarathi wrote: >> Hi Saul, >>=20 >> I really didn't get your argument fully because in case there is no = default signaling protocol, it is unavoidable to have island of devices = without gateways but you argue other way around. > Browsers cannot talk to each other without at least a web server to = serve up the application (HTML and Javascript) and a server over which = to exchange the ICE signaling information, so they won't be talking to = each other "on their own" anyway. They will be able to use the rtcweb data channel, which is a concern. >=20 > Once you have that, RTCWEB calling is no more or less an island than = web-based messaging services. Some of them let users compose messages = that stay within the "walled garden" of the service (and that is their = choice), others let users compose email which is exchanged with other = services over standard protocols like SMTP. >=20 >>=20 >> I specifically asked for the scope of your opinion on RTCWeb work is = between browser-to-browser >=20 > RTCWEB needs to specify the browser-to-browser media and the APIs by = which that media channel is created and controlled. That is all. According to the wg charter there's a data channel ability too. >=20 >> or browser-to-other end-point to know whether parallel universe has = to be build or not. >=20 > For the media channel, it would be helpful if the "browser-to-browser" = media uses a standard such as RTP so that "browser-to-other" can be done = directly, without media gateways. >=20 > For signaling, this is not nearly so important a requirement, and in = fact conflicts with the goals of providing flexible APIs that allow = developers to use web browsers as a development platform... an operating = system and runtime, rather than a pre-built "phone" as I've said before. >=20 >> In case there is no default signaling protocol, it is impossible to = communicate between browser-to-endpoint without gateways. >=20 > Signaling? True. >=20 > Media? Hopefully not. Data which can carry signalling - maybe... Sorry to keep repeating the data channel issue, but it disturbes me a = bit. /O= From dzonatas@gmail.com Sat Sep 17 10:20: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 26EE521F899D for ; Sat, 17 Sep 2011 10:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.845 X-Spam-Level: X-Spam-Status: No, score=-3.845 tagged_above=-999 required=5 tests=[AWL=-0.246, 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 VeWw21l8HahB for ; Sat, 17 Sep 2011 10:20:02 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6AC21F8997 for ; Sat, 17 Sep 2011 10:20:02 -0700 (PDT) Received: by pzk33 with SMTP id 33so8913309pzk.4 for ; Sat, 17 Sep 2011 10:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gRc4kw++CArdk7FGBULVbjviCQa3Wr1jZ7oJmQnm4IE=; b=gTMwkf5scnzSRzUiFTBTrQCLtJj99sF08eDGARPkr2nUSU2drKYlb/RYv8uEk0Va9g lip0O5ScqaddDImgyVgrT7hyRVu8b0nLQT6MUOUFxt2pqJoGzoo7JRuB6MNqMWQnkU08 1M0e/NAZLyujtO4G7piOqTJmTbuulMBKvX+08= Received: by 10.68.47.74 with SMTP id b10mr1261776pbn.293.1316280140290; Sat, 17 Sep 2011 10:22:20 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id f8sm46120152pbc.3.2011.09.17.10.22.17 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Sep 2011 10:22:18 -0700 (PDT) Message-ID: <4E74D7CE.3090505@gmail.com> Date: Sat, 17 Sep 2011 10:24:30 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <4E73BA23.6040305@skype.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] ICE and security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 17:20:03 -0000 On 09/17/2011 01:22 AM, Olle E. Johansson wrote: > > 16 sep 2011 kl. 23:05 skrev Matthew Kaufman: > >>> The only thing we need to do for rtcweb is make sure the RTP library >>> built into the browser supports media in such a way that it can >>> communicate with other RTP peers at a media plane, regardless of >>> what signaling protocol those peers might be using, preferably >>> without going through media gateways. >> >> This, and supports enough security/safety that the library can be >> trusted to run in the browser environment. (This is where the ICE >> requirement comes from.) > > Matt, > Can you please elaborate how ice relates to security? > Physics prediction on the data channel is possible, yet that doesn't agree to all server models. Win8 reminds me of mosaic reborn, for example. Some argue over the order of the service stack, and they consider those end up in-between as MITM. -- --- The wheel. From HKaplan@acmepacket.com Sat Sep 17 10:24: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 6B79121F8A35 for ; Sat, 17 Sep 2011 10:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, J_CHICKENPOX_24=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 8SSX2rf-N32M for ; Sat, 17 Sep 2011 10:24:55 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id BD48621F8783 for ; Sat, 17 Sep 2011 10:24:55 -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, 17 Sep 2011 13:27:12 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sat, 17 Sep 2011 13:27:12 -0400 From: Hadriel Kaplan To: "Olle E. Johansson" Thread-Topic: [rtcweb] ICE and security Thread-Index: AQHMdV8HZnV0C/itdk+1WJWhe7py/g== Date: Sat, 17 Sep 2011 17:27:10 +0000 Message-ID: <0E6DD5C7-A59F-4C35-9412-780CB19F2DE1@acmepacket.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <4E73BA23.6040305@skype.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <3EAE6F2B1AFA6B4C8BFE0AEF5C7BDBE4@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] ICE and security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 17:24:56 -0000 On Sep 17, 2011, at 4:22 AM, Olle E. Johansson wrote: >=20 > 16 sep 2011 kl. 23:05 skrev Matthew Kaufman: >>=20 >> This, and supports enough security/safety that the library can be truste= d to run in the browser environment. (This is where the ICE requirement com= es from.) >=20 > Matt, > Can you please elaborate how ice relates to security? There's a concern that malicious javascript can make your Browser start sen= ding RTP packets at a target, and that enough people running such a javascr= ipt would be a nice botnet flooding a target. For example, there could be = some malicious website which has some interesting content on it to draw peo= ple to go to it (for example it mirrors real content from somewhere else, o= r it offers pirated content downloading, or porn, or whatever), and on the = same webpage it embeds javascript that makes your Browser start sending RTP= packets against root DNS servers or whatever. IF they got enough browsers= viewing their webpage, then it would be a DDoS flood of RTP against the ta= rget. And of course if we have a UDP-based Data channel and the javascript= can decide what goes in the data packet, then it could craft something nas= ty, to either perform a heavier resource exhaustion attack, or whatever. U= ltimately the concern is that UDP has no SYN/SYN-ACK exchange like TCP does= , to verify the device you're going to send lots of packets to wants to rec= eive any of them. So ICE does that for you - it verifies the IP:port you're going to send you= r RTP packets to is willing to accept your packets. (it has some other secu= rity properties too, but I personally find the rest questionable, compared = to this one) So basically we're stuck with requiring ICE be used for every media/data se= ssion, and thus not being able to interop directly with devices which don't= do ICE (which is most of the SIP world right now). One open question is if javascript will even be allowed to open a media cha= nnel to a peer without human/user consent. I thought we were requiring per= -site consent. I guess a malicious site could still offer legitimate media= usage, and thus get user's consent, and then sometime in the future the sa= me website could turn evil; or it could offer seemingly legitimate service = that works, while in javascript creating a forked stream that is the one at= tacking someone else. I wonder though if even requiring ICE is sufficient. If I'm a malicious ja= vascript, I could add enough ICE candidates against a target that it would = be the same as an RTP stream in aggregate (I believe ICE's throttling limit= was in fact approximately the rate of RTP by design, if I recall correctly= ). -hadriel From HKaplan@acmepacket.com Sat Sep 17 10:24: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 A68D721F8783 for ; Sat, 17 Sep 2011 10:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 oISN7yP0ko0n for ; Sat, 17 Sep 2011 10:24:56 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1231821F899F for ; Sat, 17 Sep 2011 10:24:56 -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, 17 Sep 2011 13:27:13 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sat, 17 Sep 2011 13:27:12 -0400 From: Hadriel Kaplan To: "Olle E. Johansson" Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: AQHMdV8I4HBKBjcFaU22JVwNs0Jxjg== Date: Sat, 17 Sep 2011 17:27:12 +0000 Message-ID: <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> In-Reply-To: <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> 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: <160B3A9C7C30EB4EB94133D6E4F1E21B@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 17 Sep 2011 17:24:56 -0000 On Sep 17, 2011, at 4:27 AM, Olle E. Johansson wrote: > They will be able to use the rtcweb data channel, which is a concern. Yes, that's actually the most interesting piece of this whole thing, in my = opinion. Browsers don't typically offer raw sockets to javascript as far a= s I know. And not only does it raise a lovely set of security concerns, bu= t also network collapse issues since UDP has no congestion backoff and I be= lieve the data channel we're talking about is UDP(?). And since the data channel is actually peer-to-peer rather than client-to-s= erver, the issues with not standardizing its protocol become harder. I.e., = leaving it a raw socket will only work if it goes between the same javascri= pts, inside the same domain - if that's ok, then the only issue is this wou= ld be put into SDP, and SDP isn't constrained by a javascript domain. Hmm.= .. gosh, if only rtcweb didn't use SDP as its browser API... :) -hadriel From dzonatas@gmail.com Sat Sep 17 11: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 4EAC921F87FC for ; Sat, 17 Sep 2011 11:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, J_CHICKENPOX_24=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 iCOEMnYBa-sO for ; Sat, 17 Sep 2011 11:26:58 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 518A621F84F9 for ; Sat, 17 Sep 2011 11:26:57 -0700 (PDT) Received: by iaby26 with SMTP id y26so4416474iab.31 for ; Sat, 17 Sep 2011 11:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=YBbY2fmzIudcela9ihRbYACVGyE64GcPZS+Ct4sI/nA=; b=KV8n7exg0DkcqkN05FIDQ0su5KX36JVc7S6poMrlUOm7xlEhxJ25W3teLbrvQx1cK+ OGLVhRzZFVpHzP0yAnGsep263r3P2DhsxWFPZ52aMR8d23uRHvi4yR7HQzyK2mGhHiRr 9fXOYKuiJtMn+J6A2uA3NqjXY60KY0tezix8A= Received: by 10.68.52.135 with SMTP id t7mr1274733pbo.297.1316284155527; Sat, 17 Sep 2011 11:29:15 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id 4sm46638028pbk.5.2011.09.17.11.29.13 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Sep 2011 11:29:14 -0700 (PDT) Message-ID: <4E74E77E.6030800@gmail.com> Date: Sat, 17 Sep 2011 11:31:26 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <4E73BA23.6040305@skype.net> <0E6DD5C7-A59F-4C35-9412-780CB19F2DE1@acmepacket.com> In-Reply-To: <0E6DD5C7-A59F-4C35-9412-780CB19F2DE1@acmepacket.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [rtcweb] ICE and security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 18:26:59 -0000 On 09/17/2011 10:27 AM, Hadriel Kaplan wrote: > On Sep 17, 2011, at 4:22 AM, Olle E. Johansson wrote: > > =20 >> 16 sep 2011 kl. 23:05 skrev Matthew Kaufman: >> =20 >>> This, and supports enough security/safety that the library can be tru= sted to run in the browser environment. (This is where the ICE requiremen= t comes from.) >>> =20 >> Matt, >> Can you please elaborate how ice relates to security? >> =20 > There's a concern that malicious javascript can make your Browser start= sending RTP packets at a target, and that enough people running such a j= avascript would be a nice botnet flooding a target. For example, there c= ould be some malicious website which has some interesting content on it t= o draw people to go to it (for example it mirrors real content from somew= here else, or it offers pirated content downloading, or porn, or whatever= ), and on the same webpage it embeds javascript that makes your Browser s= tart sending RTP packets against root DNS servers or whatever. IF they g= ot enough browsers viewing their webpage, then it would be a DDoS flood o= f RTP against the target. And of course if we have a UDP-based Data chan= nel and the javascript can decide what goes in the data packet, then it c= ould craft something nasty, to either perform a heavier resource exhausti= on attack, or whatever. Ultimately the concern is that UDP has no SYN/SY= N-ACK exchange like TCP does, to verify the > device you're going to send lots of packets to wants to receive any = of them. > > So ICE does that for you - it verifies the IP:port you're going to send= your RTP packets to is willing to accept your packets. (it has some othe= r security properties too, but I personally find the rest questionable, c= ompared to this one) > So basically we're stuck with requiring ICE be used for every media/dat= a session, and thus not being able to interop directly with devices which= don't do ICE (which is most of the SIP world right now). > > One open question is if javascript will even be allowed to open a media= channel to a peer without human/user consent. I thought we were requiri= ng per-site consent. I guess a malicious site could still offer legitima= te media usage, and thus get user's consent, and then sometime in the fut= ure the same website could turn evil; or it could offer seemingly legitim= ate service that works, while in javascript creating a forked stream that= is the one attacking someone else. > > I wonder though if even requiring ICE is sufficient. If I'm a maliciou= s javascript, I could add enough ICE candidates against a target that it = would be the same as an RTP stream in aggregate (I believe ICE's throttli= ng limit was in fact approximately the rate of RTP by design, if I recall= correctly). > > -hadriel > > =20 I'd be in favor of the "WebSIM" flavor of OpenSim as the test ground for = your evil; with +Platform on OpenSim to make it "WebSim", thats a good=20 start. I hesitate on further description of this here. --=20 --- The wheel. From ekr@rtfm.com Sat Sep 17 21:59: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 5FD8921F8663 for ; Sat, 17 Sep 2011 21:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.605 X-Spam-Level: X-Spam-Status: No, score=-102.605 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=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 Wb8POPtR3Xj5 for ; Sat, 17 Sep 2011 21:59:01 -0700 (PDT) Received: from mail-wy0-f170.google.com (mail-wy0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 94E3A21F85FF for ; Sat, 17 Sep 2011 21:59:01 -0700 (PDT) Received: by wyg8 with SMTP id 8so5396216wyg.15 for ; Sat, 17 Sep 2011 22:01:20 -0700 (PDT) Received: by 10.227.165.202 with SMTP id j10mr1265382wby.18.1316322080201; Sat, 17 Sep 2011 22:01:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.38.9 with HTTP; Sat, 17 Sep 2011 22:01:00 -0700 (PDT) In-Reply-To: <0E6DD5C7-A59F-4C35-9412-780CB19F2DE1@acmepacket.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <4E73BA23.6040305@skype.net> <0E6DD5C7-A59F-4C35-9412-780CB19F2DE1@acmepacket.com> From: Eric Rescorla Date: Sat, 17 Sep 2011 22:01:00 -0700 Message-ID: To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] ICE and security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 04:59:02 -0000 On Sat, Sep 17, 2011 at 10:27 AM, Hadriel Kaplan w= rote: > > On Sep 17, 2011, at 4:22 AM, Olle E. Johansson wrote: > >> >> 16 sep 2011 kl. 23:05 skrev Matthew Kaufman: >>> >>> This, and supports enough security/safety that the library can be trust= ed to run in the browser environment. (This is where the ICE requirement co= mes from.) >> >> Matt, >> Can you please elaborate how ice relates to security? > > There's a concern that malicious javascript can make your Browser start s= ending RTP packets at a target, and that enough people running such a javas= cript would be a nice botnet flooding a target. =A0For example, there could= be some malicious website which has some interesting content on it to draw= people to go to it (for example it mirrors real content from somewhere els= e, or it offers pirated content downloading, or porn, or whatever), and on = the same webpage it embeds javascript that makes your Browser start sending= RTP packets against root DNS servers or whatever. =A0IF they got enough br= owsers viewing their webpage, then it would be a DDoS flood of RTP against = the target. =A0And of course if we have a UDP-based Data channel and the ja= vascript can decide what goes in the data packet, then it could craft somet= hing nasty, to either perform a heavier resource exhaustion attack, or what= ever. =A0Ultimately the concern is that UDP has no SYN/SYN-ACK exchange lik= e TCP does, to verify the > =A0device you're going to send lots of packets to wants to receive any of= them. > > So ICE does that for you - it verifies the IP:port you're going to send y= our RTP packets to is willing to accept your packets. (it has some other se= curity properties too, but I personally find the rest questionable, compare= d to this one) > So basically we're stuck with requiring ICE be used for every media/data = session, and thus not being able to interop directly with devices which don= 't do ICE (which is most of the SIP world right now). > > One open question is if javascript will even be allowed to open a media c= hannel to a peer without human/user consent. =A0I thought we were requiring= per-site consent. =A0I guess a malicious site could still offer legitimate= media usage, and thus get user's consent, and then sometime in the future = the same website could turn evil; or it could offer seemingly legitimate se= rvice that works, while in javascript creating a forked stream that is the = one attacking someone else. I don't see any reason not to allow (for instance) a data channel w/o user consent. > I wonder though if even requiring ICE is sufficient. =A0If I'm a maliciou= s javascript, I could add enough ICE candidates against a target that it wo= uld be the same as an RTP stream in aggregate (I believe ICE's throttling l= imit was in fact approximately the rate of RTP by design, if I recall corre= ctly). At best this would be a DoS attack, however. -Ekr > -hadriel > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From harald@alvestrand.no Sun Sep 18 01:07: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 153D621F8512 for ; Sun, 18 Sep 2011 01:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.799 X-Spam-Level: X-Spam-Status: No, score=-107.799 tagged_above=-999 required=5 tests=[AWL=2.800, 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 q0onPF4l3-1c for ; Sun, 18 Sep 2011 01:07:04 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6F73321F84D8 for ; Sun, 18 Sep 2011 01:07:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 107B339E0CD; Sun, 18 Sep 2011 10:09:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYuuowgGQ-OO; Sun, 18 Sep 2011 10:09:21 +0200 (CEST) Received: from [192.168.1.51] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 959C939E048; Sun, 18 Sep 2011 10:09:21 +0200 (CEST) Message-ID: <4E75A730.8030405@alvestrand.no> Date: Sun, 18 Sep 2011 10:09:20 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Matthew Kaufman References: <4E71927C.1090606@skype.net> <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com> <20110915140248.4cc17977@lminiero-acer> <4E71F90D.8030302@alvestrand.no> <4E73BBC8.7070507@skype.net> In-Reply-To: <4E73BBC8.7070507@skype.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Sep 2011 08:07:05 -0000 On 09/16/2011 11:12 PM, Matthew Kaufman wrote: > On 9/15/11 3:09 PM, Harald Alvestrand wrote: >> The disadvantage of parsing to another structure (I am fond of JSON >> myself) is that one has to maintain a data definition for the format >> being parsed to, a defined transform between that and the "canonical >> SDP structure" has to be implemented in user space when one does SDP >> interoperability, both of those have to be updated for every SDP >> extension that someone defines somewhere, and one is still not free >> to define extensions on the non-SDP side if one still requires the >> ability to map them into SDP. >> >> If one uses the "native" SDP format, which is the format in which >> every extension to the format gets documented, the browsers are the >> ones who *have* to parse it (although others are likely to). > > Of course what you're also saying here is that it takes a trip to the > IETF to make every extension. So if the *only* Javascript API for > controlling the codec (or getting its capabilities by triggering an > offer) is a pile of SDP in string form, then nothing that hasn't been > standardized can be described. 1) No reason that this should be the only interface. I've just argued that I think this interface needs to be supported 2) SDP has a relatively clean "ignore what you don't understand" extension model. It's not my impression that people who want to deploy stuff wait until the standards are done. > > For example: forcing the Opus codec to "music" mode no matter what the > input. I haven't seen the definitions for signalling Opus in SDP, so don't know if such a capability is described there (which may or may not illustrate your point). > > Matthew Kaufman > > From harald@alvestrand.no Sun Sep 18 02:30: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 CBC2F21F8509 for ; Sun, 18 Sep 2011 02:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.647 X-Spam-Level: X-Spam-Status: No, score=-107.647 tagged_above=-999 required=5 tests=[AWL=2.352, BAYES_00=-2.599, J_CHICKENPOX_24=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 DauL11tVCtHH for ; Sun, 18 Sep 2011 02:30:35 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E060021F84D7 for ; Sun, 18 Sep 2011 02:30:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 576A639E0CD for ; Sun, 18 Sep 2011 11:32:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYFpuE-ufEwJ for ; Sun, 18 Sep 2011 11:32:53 +0200 (CEST) Received: from [192.168.1.51] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id A63DC39E048 for ; Sun, 18 Sep 2011 11:32:53 +0200 (CEST) Message-ID: <4E75BAC5.1060809@alvestrand.no> Date: Sun, 18 Sep 2011 11:32:53 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <4E73BA23.6040305@skype.net> <0E6DD5C7-A59F-4C35-9412-780CB19F2DE1@acmepacket.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [rtcweb] ICE and security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 09:30:35 -0000 On 09/18/2011 07:01 AM, Eric Rescorla wrote: > On Sat, Sep 17, 2011 at 10:27 AM, Hadriel Kaplan wrote: >> On Sep 17, 2011, at 4:22 AM, Olle E. Johansson wrote: >> >>> 16 sep 2011 kl. 23:05 skrev Matthew Kaufman: >>>> This, and supports enough security/safety that the library can be tr= usted to run in the browser environment. (This is where the ICE requireme= nt comes from.) >>> Matt, >>> Can you please elaborate how ice relates to security? >> There's a concern that malicious javascript can make your Browser star= t sending RTP packets at a target, and that enough people running such a = javascript would be a nice botnet flooding a target. For example, there = could be some malicious website which has some interesting content on it = to draw people to go to it (for example it mirrors real content from some= where else, or it offers pirated content downloading, or porn, or whateve= r), and on the same webpage it embeds javascript that makes your Browser = start sending RTP packets against root DNS servers or whatever. IF they = got enough browsers viewing their webpage, then it would be a DDoS flood = of RTP against the target. And of course if we have a UDP-based Data cha= nnel and the javascript can decide what goes in the data packet, then it = could craft something nasty, to either perform a heavier resource exhaust= ion attack, or whatever. Ultimately the concern is that UDP has no SYN/S= YN-ACK exchange like TCP does, to verify the >> device you're going to send lots of packets to wants to receive any = of them. >> >> So ICE does that for you - it verifies the IP:port you're going to sen= d your RTP packets to is willing to accept your packets. (it has some oth= er security properties too, but I personally find the rest questionable, = compared to this one) >> So basically we're stuck with requiring ICE be used for every media/da= ta session, and thus not being able to interop directly with devices whic= h don't do ICE (which is most of the SIP world right now). >> >> One open question is if javascript will even be allowed to open a medi= a channel to a peer without human/user consent. I thought we were requir= ing per-site consent. I guess a malicious site could still offer legitim= ate media usage, and thus get user's consent, and then sometime in the fu= ture the same website could turn evil; or it could offer seemingly legiti= mate service that works, while in javascript creating a forked stream tha= t is the one attacking someone else. > I don't see any reason not to allow (for instance) a data channel w/o > user consent. I think it's reasonable to aim to do somewhat better than current HTTP=20 practice, but not to demand that security for UDP connection be at a=20 totally different level than for HTTP/WS connections. When the WG has=20 talked about user consent, that has been related to use of user's camera = and microphone. > >> I wonder though if even requiring ICE is sufficient. If I'm a malicio= us javascript, I could add enough ICE candidates against a target that it= would be the same as an RTP stream in aggregate (I believe ICE's throttl= ing limit was in fact approximately the rate of RTP by design, if I recal= l correctly). > At best this would be a DoS attack, however. And I see every reason for the browser to rate-limit the number of=20 unsuccessful connection attempts a script can make. From prvs=235fd4aa8=tterriberry@mozilla.com Sun Sep 18 04:24: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 3A7FB21F857D for ; Sun, 18 Sep 2011 04:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV2AM4iVCnJa for ; Sun, 18 Sep 2011 04:24:16 -0700 (PDT) Received: from mxip1i.isis.unc.edu (mxip1i.isis.unc.edu [152.2.0.74]) by ietfa.amsl.com (Postfix) with ESMTP id AF5F521F856B for ; Sun, 18 Sep 2011 04:24:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAKbUdU6sGgRa/2dsb2JhbABBpkWBeYFTAQEEAThAAQULCyEWDwkDAgECAUUTAQcCh3MEtRmGeASHb5BlEoww X-IronPort-AV: E=Sophos;i="4.67,546,1309752000"; d="scan'208";a="237741975" Received: from mr2a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.90]) by mxip1o.isis.unc.edu with ESMTP; 18 Sep 2011 07:26:36 -0400 X-UNC-Auth-As: tterribe X-UNC-Auth-IP: 69.181.137.38 Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id p8IBQWos029814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 18 Sep 2011 07:26:35 -0400 (EDT) Message-ID: <4E75D566.7090302@mozilla.com> Date: Sun, 18 Sep 2011 04:26:30 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101120 Gentoo/2.0.10 SeaMonkey/2.0.10 MIME-Version: 1.0 CC: rtcweb@ietf.org References: <4E71927C.1090606@skype.net> <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com> <20110915140248.4cc17977@lminiero-acer> <4E71F90D.8030302@alvestrand.no> <4E73BBC8.7070507@skype.net> <4E75A730.8030405@alvestrand.no> In-Reply-To: <4E75A730.8030405@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] About defining a signaling protocol for WebRTC (or not) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Sep 2011 11:24:17 -0000 > I haven't seen the definitions for signalling Opus in SDP, so don't know > if such a capability is described there (which may or may not illustrate > your point). It's described in Section 7 of the current payload draft: https://datatracker.ietf.org/doc/draft-spittka-payload-rtp-opus/ There's no facility for forcing a "music" mode in the SDP because this can be done unilaterally by the encoder, as Opus currently requires decoder support for all modes to avoid negotiation failure. Also, as I've said before, this is about more than just the encoding format. It has (arguably more important) ramifications for the front-end filtering done on the input audio signal (i.e., whether or not you're sending input from a low-quality mic vs. the direct output of a synth or even pre-recorded/generated content). What we proposed before was a simple means of passing in a "hints" object (whether a JS object of some undetermined form or a string or something else) which could be used to control optional parameters like these. That's sufficient for the "music mode" case, where support on the encoder side is optional and you don't really need to know if it succeeded (i.e., it's not something that will show up in the SDP, whether it's generated by the browser or by script). I don't think it's sufficient for Matthew. From dzonatas@gmail.com Sun Sep 18 09:36: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 5863E21F8512 for ; Sun, 18 Sep 2011 09:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, J_CHICKENPOX_24=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 y63Zfj312Mmc for ; Sun, 18 Sep 2011 09:36:36 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 55B7321F84D4 for ; Sun, 18 Sep 2011 09:36:36 -0700 (PDT) Received: by yxt33 with SMTP id 33so4428264yxt.31 for ; Sun, 18 Sep 2011 09:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=MffYEoX1C8G6WHyDTvtBypF8uxchOzBoVBPkvN4iJF0=; b=ifPNMp5olZ9RW+DxbgvQz7hI4nZAdIVNbT180PTIo/ELdvkLL5/OSOkmCW4SNR8CkR o7vhxd2T1oqtzHspyfOrfeH3GZP5NFG/7e4IoOZIxCr6RAtMX7FTJrx6xCrLFPJ5dzxx AN7cliOxbjCFAIcvKT7OHV/gSNgBEY4oJRQgY= Received: by 10.68.12.196 with SMTP id a4mr2744317pbc.185.1316363936100; Sun, 18 Sep 2011 09:38:56 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id f8sm57597074pbc.3.2011.09.18.09.38.53 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Sep 2011 09:38:54 -0700 (PDT) Message-ID: <4E761F22.1020901@gmail.com> Date: Sun, 18 Sep 2011 09:41:06 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <4E73BA23.6040305@skype.net> <0E6DD5C7-A59F-4C35-9412-780CB19F2DE1@acmepacket.com> <4E75BAC5.1060809@alvestrand.no> In-Reply-To: <4E75BAC5.1060809@alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] ICE and security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 16:36:37 -0000 On 09/18/2011 02:32 AM, Harald Alvestrand wrote: > On 09/18/2011 07:01 AM, Eric Rescorla wrote: >> On Sat, Sep 17, 2011 at 10:27 AM, Hadriel >> Kaplan wrote: >>> On Sep 17, 2011, at 4:22 AM, Olle E. Johansson wrote: >>> >>>> 16 sep 2011 kl. 23:05 skrev Matthew Kaufman: >>>>> This, and supports enough security/safety that the library can be >>>>> trusted to run in the browser environment. (This is where the ICE >>>>> requirement comes from.) >>>> Matt, >>>> Can you please elaborate how ice relates to security? >>> There's a concern that malicious javascript can make your Browser >>> start sending RTP packets at a target, and that enough people >>> running such a javascript would be a nice botnet flooding a target. >>> For example, there could be some malicious website which has some >>> interesting content on it to draw people to go to it (for example it >>> mirrors real content from somewhere else, or it offers pirated >>> content downloading, or porn, or whatever), and on the same webpage >>> it embeds javascript that makes your Browser start sending RTP >>> packets against root DNS servers or whatever. IF they got enough >>> browsers viewing their webpage, then it would be a DDoS flood of RTP >>> against the target. And of course if we have a UDP-based Data >>> channel and the javascript can decide what goes in the data packet, >>> then it could craft something nasty, to either perform a heavier >>> resource exhaustion attack, or whatever. Ultimately the concern is >>> that UDP has no SYN/SYN-ACK exchange like TCP does, to verify > the >>> device you're going to send lots of packets to wants to receive >>> any of them. >>> >>> So ICE does that for you - it verifies the IP:port you're going to >>> send your RTP packets to is willing to accept your packets. (it has >>> some other security properties too, but I personally find the rest >>> questionable, compared to this one) >>> So basically we're stuck with requiring ICE be used for every >>> media/data session, and thus not being able to interop directly with >>> devices which don't do ICE (which is most of the SIP world right now). >>> >>> One open question is if javascript will even be allowed to open a >>> media channel to a peer without human/user consent. I thought we >>> were requiring per-site consent. I guess a malicious site could >>> still offer legitimate media usage, and thus get user's consent, and >>> then sometime in the future the same website could turn evil; or it >>> could offer seemingly legitimate service that works, while in >>> javascript creating a forked stream that is the one attacking >>> someone else. >> I don't see any reason not to allow (for instance) a data channel w/o >> user consent. > I think it's reasonable to aim to do somewhat better than current HTTP > practice, but not to demand that security for UDP connection be at a > totally different level than for HTTP/WS connections. When the WG has > talked about user consent, that has been related to use of user's > camera and microphone. >> >>> I wonder though if even requiring ICE is sufficient. If I'm a >>> malicious javascript, I could add enough ICE candidates against a >>> target that it would be the same as an RTP stream in aggregate (I >>> believe ICE's throttling limit was in fact approximately the rate of >>> RTP by design, if I recall correctly). >> At best this would be a DoS attack, however. > > And I see every reason for the browser to rate-limit the number of > unsuccessful connection attempts a script can make. One difference someone could introduce is pre-mapped and canonicalized resource names (and labels). For example, each escaped and underline name version matches a date; then, the connection must be done JIT such that that any eval() of the date-to-name is already done. See also this with private resources in mind: http://wiki.secondlife.com/wiki/LSL_http_server So maybe it's more clear how we could go from that to RTP usage, so SIP is helpful, yet somewhat backwards step in progress. Either way, the resource either expire or stay open for recorders/playback (as different from rougher rate-limits). At minimal, we need ICE for the resource names that are already standard. Then we contemplate next either S/MIME or SSRC based on direction of duplex. I'd leave in the sideband option (in 802.11n?) even if it's not on the agenda, sideband is like voice and data already mapped like DSL, yet again, I would digress to spectrum. Thanks. -- --- The wheel. From harald@alvestrand.no Sun Sep 18 14:08: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 8EDF321F849E for ; Sun, 18 Sep 2011 14:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.064 X-Spam-Level: X-Spam-Status: No, score=-108.064 tagged_above=-999 required=5 tests=[AWL=2.535, 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 Vxx7Wdz1vkVN for ; Sun, 18 Sep 2011 14:08:16 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA2021F8497 for ; Sun, 18 Sep 2011 14:08:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 64B6839E091; Sun, 18 Sep 2011 23:10:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbAbgLpbqhNb; Sun, 18 Sep 2011 23:10:35 +0200 (CEST) Received: from [192.168.1.51] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id AEC2F39E048; Sun, 18 Sep 2011 23:10:35 +0200 (CEST) Message-ID: <4E765E4A.3050801@alvestrand.no> Date: Sun, 18 Sep 2011 23:10:34 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Eric Rescorla References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 18 Sep 2011 21:08:22 -0000 On 09/16/2011 08:30 PM, Eric Rescorla wrote: > On Fri, Sep 16, 2011 at 11:07 AM, Dan Wing wrote: >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>> Behalf Of Eric Rescorla >>> Sent: Wednesday, September 14, 2011 10:32 AM >>> To: Christer Holmberg >>> Cc: rtcweb@ietf.org >>> Subject: Re: [rtcweb] STUN for keep-alive >>> >>> On Wed, Sep 14, 2011 at 10:20 AM, Christer Holmberg >>> wrote: >>>> Hi, >>>> >>>>> One new concern in this context is maintaining the consent freshness. >>>>> The browser needs to be sure that the recipient of traffic is stil >>> responding in a way that can't be forged. It's likely RTCP provides >>> this (though we'd need to analyze to be sure) but perhaps better would >>> be to mandate STUN checks >>>>> at enough frequency that you get some sort of level of freshness.... >>> maybe every 2 minutes or something. >>>> Please note that the STUN keep-alives are implemented using STUN >>> indication messages, so there are no replies (nor does the receiver >>> perform an authentication check). >>> >>> >>> Oh... I had forgotten that.... that's not good. >> The RTCP receiver reports should be adequate for 'consent freshness', no? >> If I still like receiving the traffic, I'll report that I'm receiving it. >> If I have crashed or disconnected or am not listening on that port, I won't. > I believe so, though I'd have to make sure there's enough entropy. And of course > some implementations may not do RTCP... Depending on RTCP seems less uncomfortable with SRTP than with plaintext RTCP. I don't think we want to support RTCP-less applicaitons; if saying "no" to them helps them not occur (it doesn't always help...) From randell-ietf@jesup.org Sun Sep 18 15:11: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 027C921F891D for ; Sun, 18 Sep 2011 15:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOLE5O7bomlt for ; Sun, 18 Sep 2011 15:11:20 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id CA3E321F8713 for ; Sun, 18 Sep 2011 15:11:20 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5PcK-00030H-VI; Sun, 18 Sep 2011 17:13:41 -0500 Message-ID: <4E766C4C.2020201@jesup.org> Date: Sun, 18 Sep 2011 18:10:20 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> In-Reply-To: <4E734E89.5010105@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-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, 18 Sep 2011 22:11:22 -0000 On 9/16/2011 9:26 AM, Magnus Westerlund wrote: > As an Individual I do have a few comments and question on this document > and its algorithm. As said on the call, I'm going to work with Harald (and Justin, and anyone else interested) to provide requirements and likely a suggested algorithm. At this point, I believe we'll specify the mechanism for telling the other side the apparent bandwidth, but leave the algorithm for finding that out open for innovation. I plan to propose a baseline algorithm. On the sender side, I expect to optionally involve the application in deciding how the bits are allocated among the channels, and the option to add or remove channels based on bandwidth. I expect that we will mandate that if the application doesn't choose, the rtcweb/webrtc code will. This is all still to be hammered out; anyone else interested in helping write the draft requirements let me know. > 1. Section 3: As delay based congestion control has been tried a number > of times and meet with less than stellar success I wonder if you have > any understanding of how this relates to the issues previously encountered: Do you have any pointers to these earlier attempts? My separate experience with this class has been extremely successful, though perhaps with a set of real-world use-cases that don't cover the situations you're referring to. My understanding is that Radvision's NetSense is very similar from their description of it. > - Stability (especially on short RTTs) > - How it competes with TCP flows, which was a real issues for TCP Vegas > but may be less of an issue here. Perhaps Google can comment here about what tests they've done. If anything, this class of algorithm when faced with aggressive TCP flows will eventually have problems, because TCP will tend to fill up the buffers at the bottleneck. Since this algorithm senses buffers starting to fill up, it will tend to back off before TCP is likely to see a loss event. Now, it's more complex than that of course, and multiple flows make it more complex still. It's also sensitive to the adaptation rate of this algorithm and speed of backoff. If I remember, TFRC tends to back off more slowly than TCP but also increase more slowly; I suspect Google's algorithm is similar. Web Browser traffic can be especially aggressive at filling large buffers at a bottleneck router, and will become more so as the initial window of 10 rolls out. > 2. Section 3, I don't see any discussion of the startup issue. Is my > assumption correct, that you will simply start at some rate and then > adapt from that? Startup is an open question; you have to start somewhere, and there's no way to always get the start "right". History of previous sessions may be useful here; it's theoretically possible to use perhaps some of the ICE negotiation for a first-level guess or we could send an initial packet train and measure dispersion. But that's just speculation; history can be very wrong if you've changed networks or the other person has a very different network than the last call (or last call with that person). I'm not sure if we should mandate something here, or use something more open to encourage innovation. > 3. Section 3, I guess this mechanism would get significant issues with > any sender side transmission filtering. Burst transmitting I-frames over > a network, especially for high resolution video can easily result in > packet loss in switch fabrics if there is any cross traffic in the > switch fabric. Thus having a bit of send filtering for frame > transmission is a good idea. Are I understanding it correctly that this > could result in over-use indication if I has such mechanism which > filters a packet to a slower transmission rate than what a single or > small burst can achieve over the same path? Well, such send filtering amounts to a bottleneck in practice at the sending node, so that actually might be ok. I'm assuming you're talking about pacing the actual send()s of large dumps of fragmented IDRs/i-frames to some maximum packet rate or bitrate (almost the same thing). I think the algorithm looks at all the fragments and the time they came in to calculate the bandwidth. If so, it would only think it was over-bandwidth if the pacing slowed them down to less than the actual bottleneck rate; I suspect this would rarely be the case outside of high-bandwidth LANs at very high resolutions. > > 4. Section 4. > > "This algorithm is run every time a receive report arrives at the > sender, which will happen [[how often do we expect? and why?]]. If > no receive report is recieved within [[what timeout?]], the algorithm > will take action as if all packets in the interval have been lost. > [[does that make sense?]]" > > The transmission of receiver reports is highly dependent on RTP profile, > the RTCP bandwidth, trr-int parameter and any feedback events. > > If I start with assuming AVPF which seems reasonable in most browser to > browser case with our current proposals for RTP support. Then if there > are no feedback events the transmission of receiver reports will occur > as often as the bandwidth allows, but no more often than the value of > trr-int parameter. > > Here is might be worth mentioning that I do expect trr-int to be set to > avoid RTCP reporting to often due to the relatively high RTCP bandwidth > values that will be set due to the multiplexing of audio and video in a > single RTP session. Thus avoiding that RTCP rates are as high or larger > than the audio streams they report in steady state. Agreed. This is where my plans to suggest a baseline algorithm that melds the reception data of all the streams in the PeerConnection may be a significant advantage over doing bandwidth estimation on each stream independently. We'll see if I can make the idea work, but there are some significant advantages if it does. If not, we can estimate in each channel independently as per the Google algorithm. You can also use rtcp-fb PLI/etc events to hang these reports off of, increasing the frequency they get through with minimal extra bandwidth use. > When feedback events occur the stack will have the choice of sending a > RTCP RR, that is a choice provided due to the reduced size RTCP > specification included. But if the loss cumulative count diff is > non-zero it might be worth mandating that the RR/SR is included in any > such feedback RTCP packet. Exactly - or a TMMBR with the results of the receiver-side bandwidth calculations. > For that reason causing a feedback event when there is losses and > schedule them using the early algorithm may be a good choice to ensure > timely reporting of any loss. > > If one uses AVP then the RTCP timing rules will give you when you > transmit RTCP feeedback and thus the parameterization becomes central > here. A clear issue is if people uses the minimal interval of 5 seconds > or the 360/Session_BW(in kbps). I would note that 5 seconds is very long > in adaptation situations. Yes. > I think the timeout should be based on the RTT and possible reporting > rate. But there clearly need to be some upper limit, either explicitly > or mandating RTCP bandwidth rates. > > 5. Section 4: > "We motivate the packet loss thresholds by noting that if we have > small amount of packet losses due to over-use, that amount will soon > increase if we don't adjust our bit rate. Therefore we will soon > enough reach above the 10 % threshold and adjust As(i). However if > the packet loss rate does not increase, the losses are probably not > related to self-induced channel over-use and therefore we should not > react on them." > > I am personally worried that a packet loss threshold of 10% is so high > that it might push a lot of other traffic out of the way. Thus being > quite aggressive towards other flows. Yes; I want to visit these tuning parameters and how packet loss is reacted to and at least tweak it. > TCP has this relation between the average packet loss rate and the > highest sustainable rate which can be interpreted as TCP gets more > sensitive to loss the higher the average data rate becomes. Thus in > certain situation the sender side algorithm part will be extremely > aggressive in pushing TCP out of the way. The receiver part may > compensate for this pretty well in a number of situations. > > But, I do wonder why for example the A(i) isn't bounded to be between > TFRC's rate and some multiple of TFRC rate, not unbounded by other than > the receiver side algorithm. Good question; we should look into it. > I do understand this document is to start a discussion. But I think we > need to be sensitive to that it is difficult to get even something that > is self-fair over the wide range of conditions the Internet has to provide. > > Thus I would appreciate what issues with for example TFRC that you > attempt to fix with the various new components you add. Magnus: Welcome to my little congestion-control bof... :-) -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Sun Sep 18 21:24: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 7621D21F8AF7 for ; Sun, 18 Sep 2011 21:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjTvIwEvUvUz for ; Sun, 18 Sep 2011 21:24:53 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7053321F8AF5 for ; Sun, 18 Sep 2011 21:24:46 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5VRj-0006zT-Nc; Sun, 18 Sep 2011 23:27:07 -0500 Message-ID: <4E76C3D2.1010005@jesup.org> Date: Mon, 19 Sep 2011 00:23:46 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> <4E7358AC.8030509@ericsson.com> <4E735FC8.20906@ericsson.com> In-Reply-To: <4E735FC8.20906@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Data transfer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 04:24:54 -0000 On 9/16/2011 10:40 AM, Magnus Westerlund wrote: > On 2011-09-16 16:16, Iñaki Baz Castillo wrote: >> 2011/9/16 Magnus Westerlund: >>> The argument for having a peer to peer unreliable datagram channel has >>> been two: >>> >>> 1) Minimal delay by direct peer-to-peer connection instead of going >>> through a central server. This as you can't normally establish a >>> websocket connection to a browser behind a NAT/FW. >>> >>> 2) Scalability by not requiring a server or having to handle the data >>> flows at all on the server side. >>> >>> As an individual I think these arguments are good, and assuming we can >>> find a reasonable solution that fulfills the requirements we should >>> specify it. >> I'm not opposed to such mechanism if approved. But given the current >> WWW reality, web applications always use HTTP for carrying >> long-data/documents between client and server, or >> client-server-client. > As I said in another email in this thread the WG have had discussion of > also peer to peer reliable data transport that are capable of handling > larger data object transfers between the peers. However, the discussion > didn't result in a clear consensus for this case. Nor a proponent > surfaced that has continued driving the case. I'm a strong proponent of a reliable channel as are the other Mozilla folk, and thought that several of our existing use-cases covered this. For example a two (or multi) player game - games frequently use both unreliable channels (to avoid freezing the game if certain non-critical updates are lost) and reliable data ("you're dead", etc). This has been the case since the earliest days of real-time games on the internet (before the web existed; see the 'netrek' game/protocol for example). There are many other uses of peer-to-peer data, such as file-transfer during chat(you want reliable or you get to re-invent a reliable protocol over UDP), VNC-like screen updates (probably unreliable with a recovery mechanism), mouse/keyboard events when doing remote assistance (reliable), etc. There are some interesting peer-to-peer mesh protocols which would benefit from reliable data that might be possible to layer on top of webrtc; we'll likely be investigating this at mozilla. You also don't want websockets for data channels here; you want it tied to the webrtc session and you don't want the overhead/cost/delay of having to do a separate relay. >> Also I don't think that data transfer can be achieved using an >> unreliable data channel (so UDP), is it? For example in SIP protocol >> MSRP has emerged for this purpose (data transfer) and it uses TCP/TLS >> as transport, so MSRP relay servers are required when both endpoints >> are behind NAT. > I think we all agree that for NAT traversal we are expecting it to be > IP/UDP/FOO. And it is most likely IP/UDP/DTLS/FOO to have confidential, > source authenticated and integrity protected transfers. Where FOO > provides congestion control and possible some type of framing or stream > concept. But the actual solution is still very early in the discussion. Yes, see the congestion control discussion occurring now. > When it comes to data transfer, of course you can achieve reliable > transport over an UDP. I think I can mention several different methods > in how to achieve it. > > 1. In this context one option is to implement a reliability function in > JS, that buffer and retransmit lost data. Yes; the VNC example above might do this. > 2. Another one would be to use NORM (RFC5740) as the transport protocol > inside DTLS. NORM provides both congestion control and reliability. Yes, > it might have a few over designed features being intended for multicast. Interesting; I'll take a look. Thanks. > 3. Use TCP over UDP This is what I had been assuming we'd do. It might have been nice to use SCTP-over-UDP instead; that would cover more cases without having to drop into doing network protocols in javascript for example, but it doesn't appear there's an extant open-source example, so it's a hard sell. -- Randell Jesup randell-ietf@jesup.org From prvs=236d0731c=tterriberry@mozilla.com Sun Sep 18 21:34: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 70CEE21F8B52 for ; Sun, 18 Sep 2011 21:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.955 X-Spam-Level: X-Spam-Status: No, score=-0.955 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GATisPZ0qpsb for ; Sun, 18 Sep 2011 21:34:17 -0700 (PDT) Received: from mxip3i.isis.unc.edu (mxip3i.isis.unc.edu [152.2.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id E955221F8B4D for ; Sun, 18 Sep 2011 21:34:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEACfGdk6sGgRa/2dsb2JhbABChFWhYoF6gVMBAQQBIxVAAQULCxoCBRYLAgIJAwIBAgFFEAMBBwKHc6QhkECBLIQ7gREEh2+QZRKMMA X-IronPort-AV: E=Sophos;i="4.67,550,1309752000"; d="scan'208";a="184450180" Received: from mr2a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.90]) by mxip3o.isis.unc.edu with ESMTP; 19 Sep 2011 00:36:36 -0400 X-UNC-Auth-As: tterribe X-UNC-Auth-IP: 69.181.137.38 Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id p8J4aXIW021949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Sep 2011 00:36:36 -0400 (EDT) Message-ID: <4E76C6D0.6090506@mozilla.com> Date: Sun, 18 Sep 2011 21:36:32 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101120 Gentoo/2.0.10 SeaMonkey/2.0.10 MIME-Version: 1.0 CC: rtcweb@ietf.org References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> <4E7358AC.8030509@ericsson.com> <4E735FC8.20906@ericsson.com> <4E76C3D2.1010005@jesup.org> In-Reply-To: <4E76C3D2.1010005@jesup.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Data transfer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 04:34:17 -0000 > There are many other uses of peer-to-peer data, such as file-transfer > during > chat(you want reliable or you get to re-invent a reliable protocol over > UDP), Perhaps this should be added as a use-case? It has strong implications for the congestion control algorithm, as discussed at the interim telecon: you can have an arbitrarily large amount of data to send as fast as your pipe can carry it, and that has to compete with the media traffic. From pravindran@sonusnet.com Sun Sep 18 22:27: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 B6B1921F8B14 for ; Sun, 18 Sep 2011 22:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.107, 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 035SgpZjUKQY for ; Sun, 18 Sep 2011 22:26:56 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id AC41021F85AA for ; Sun, 18 Sep 2011 22:26:55 -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 p8J5Tht3003167; Mon, 19 Sep 2011 01:29:43 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Sep 2011 01:29:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC768D.0E42C043" Date: Mon, 19 Sep 2011 10:59:08 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0D32@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: Acx0skUlp3o+dLYgY0SRUu0WF3nTZAB2NTGg References: From: "Ravindran Parthasarathi" To: "cbran" , "Ted Hardie" , "Jim McEachern" X-OriginalArrivalTime: 19 Sep 2011 05:29:12.0001 (UTC) FILETIME=[1021AB10:01CC768D] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 05:27:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC768D.0E42C043 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ted/Cary, =20 I agree with you totally. The intention of RTCWeb default signaling protocol is to build the real-time application by any JavaScript web developer without the understanding intricacies of underlying signaling protocol. Also, the default signaling protocol is not going to stop any innovative new or existing signaling protocol in RTCWeb client(browser). =20 IETF provides default signaling protocol and W3C provides browser API. =20 Thanks Partha =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of cbran Sent: Saturday, September 17, 2011 2:21 AM To: Ted Hardie; Jim McEachern Cc: Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] =20 +1 Ted - totally agree. On 9/16/11 1:43 PM, "Ted Hardie" wrote: On Thu, Sep 15, 2011 at 8:23 PM, Jim McEachern wrote: Hadriel, Well said. Your closing paragraph sums it up nicely in my mind. The only thing we need to do for rtcweb is make sure the RTP library built into the browser supports media in such a way that it can communicate with other RTP peers at a media plane, regardless of what signaling protocol those peers might be using, preferably without going through media gateways. And ... we need to make sure it's possible to use SIP on the rtcweb server.... I think there is more to it than this for it to be a success. We have to make sure that it is relatively easy to adopt rtcweb in javascript applications. The way we've discussed that in the past was "2 party video chat in 20 lines of javascript". If a novel signalling protocol is created every time, that won't be a practical choice. Even if the signalling is segmented into libraries, the app will have to download the one in use by a particular website, potentially every time. This is better than a plugin in some ways and potentially actually worse in others. We also have to make sure that the resulting application does not flood or fry the network. That means it will have to have real congestion control mechanisms. Trusting the javascript application for that has some real issues which we've already discussed. Splitting signaling and congestion control isn't a lot better. If congestion control at the network level is managed by the browser but signalling is in the javascript, then information about that state has to pass into the JS application, so it can manage the signalling. That makes the APIs more complex and runs the risk that a naive javascript application will not adjust to the congestion control requirements at all. The early web took off in part because of the ease of embedding things like images (compared to gopher, for example) into rich content. We have the opportunity to create native web applications with much richer and more interactive experiences with rtcweb, but if it is not easy to do, it won't have the same impact. If this is something that can be done only by folks who can roll their own signalling protocol, it's dead, because the number of content authors is too small. If it even requires selecting among an unbounded set of variously maintained libraries , it will be frustrating for the developer of simple applications. At that level, the existing plugins will simply be more stable and better known. Providing baseline APIs into a well-known signaling capability seems to me far more likely to result in a real flowering of rtcweb content. That's why I want it. Just my two cents, not taken from any hat, Ted ________________________________ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb ------_=_NextPart_001_01CC768D.0E42C043 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [rtcweb] RTCWeb default signaling protocol [was RE: About = defining a signaling protocol for WebRTC (or not)]

Ted/Cary,

 

I agree with you totally. The intention of RTCWeb default signaling protocol is to build the real-time application by any = JavaScript web developer without the understanding intricacies of underlying signaling protocol. = Also, the default signaling protocol is not going to stop any innovative new = or existing signaling protocol in RTCWeb client(browser).

 

IETF provides default signaling protocol and W3C provides browser API.

 

Thanks

Partha

 

From:= rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = cbran
Sent: Saturday, September 17, 2011 2:21 AM
To: Ted Hardie; Jim McEachern
Cc: <rtcweb@ietf.org>
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: = About defining a signaling protocol for WebRTC (or not)]

 

+1 Ted – totally agree.



On 9/16/11 1:43 PM, "Ted Hardie" <ted.ietf@gmail.com> wrote:

On Thu, Sep 15, 2011 at 8:23 PM, Jim McEachern <jim.mceachern@genband.com> = wrote:

Hadriel,
Well said.

Your closing paragraph sums it up nicely in my mind.

<snip>
The only thing we need to do for rtcweb is make sure the RTP library = built into the browser supports media in such a way that it can communicate with = other RTP peers at a media plane, regardless of what signaling protocol those = peers might be using, preferably without going through media gateways.  And ... = we need to make sure it's possible to use SIP on the rtcweb server....
</snip>


I think there is more to it than this for it to be a success.  We = have to make sure that it is relatively easy to adopt  rtcweb in javascript applications.  The way we've discussed that in the past was "2 = party video chat in 20 lines of javascript".   If a novel = signalling protocol is created every time, that won't be a practical choice.  = Even if the signalling is segmented into libraries, the app will have to = download the one in use by a particular website, potentially every time.  This = is better than a plugin in some ways and potentially actually worse in = others.

We also have to make sure that the resulting application does not flood = or fry the network. That means it will have to have real congestion control mechanisms.   Trusting the javascript application for that has = some real issues which we've already discussed.   Splitting signaling = and congestion control isn't a lot better.  If congestion control at = the network level is managed by the browser but signalling is in the = javascript, then information about that state has to pass into the JS application, = so it can manage the signalling.  That makes the APIs more complex and = runs the risk that a naive javascript application will not adjust to the = congestion control requirements at all.

The early web took off in part because of the ease of embedding things = like images (compared to gopher, for example) into rich content.  We = have the opportunity to create native web applications with much richer and more interactive experiences with rtcweb, but if it is not easy to do, it = won't have the same impact.  If this is something that can be done only by = folks who can roll their own signalling protocol, it's dead, because the number of content authors is too small.  If it even requires selecting among = an unbounded set of variously maintained libraries , it will be frustrating = for the developer of simple applications.   At that level, the existing plugins will simply be more stable and better known.

Providing baseline APIs into a well-known signaling capability seems to = me far more likely to result in a real flowering of rtcweb content.  = That's why I want it.

Just my two cents, not taken from any hat,

Ted

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

------_=_NextPart_001_01CC768D.0E42C043-- From randell-ietf@jesup.org Sun Sep 18 23:27: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 545DA21F8B14 for ; Sun, 18 Sep 2011 23:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 f3WE-XNiiiGR for ; Sun, 18 Sep 2011 23:27:19 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9616821F8B2E for ; Sun, 18 Sep 2011 23:27:19 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5XML-0003OL-Bl for rtcweb@ietf.org; Mon, 19 Sep 2011 01:29:41 -0500 Message-ID: <4E76E078.5020708@jesup.org> Date: Mon, 19 Sep 2011 02:26:00 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.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] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 06:27:20 -0000 +1 (comments below in-line) On 9/16/2011 4:43 PM, Ted Hardie wrote: > On Thu, Sep 15, 2011 at 8:23 PM, Jim McEachern > > wrote: > > Hadriel, > Well said. > > Your closing paragraph sums it up nicely in my mind. > > > The only thing we need to do for rtcweb is make sure the RTP > library built into the browser supports media in such a way that > it can communicate with other RTP peers at a media plane, > regardless of what signaling protocol those peers might be using, > preferably without going through media gateways. And ... we need > to make sure it's possible to use SIP on the rtcweb server.... > > > > I think there is more to it than this for it to be a success. We have > to make sure that it is relatively easy to adopt rtcweb in javascript > applications. The way we've discussed that in the past was "2 party > video chat in 20 lines of javascript". If a novel signalling > protocol is created every time, that won't be a practical choice. > Even if the signalling is segmented into libraries, the app will have > to download the one in use by a particular website, potentially every > time. This is better than a plugin in some ways and potentially > actually worse in others. I agree whole-heartedly. My (and I'll say Mozilla's) position is that we believe that while enabling unique new signalling and negotiation makes interesting new applications possible, we also must make sure that this ability is equally available to a (say) games developer who wants to add voice or video chat to their game without having to learn or understand 20 years of discussions and experience with signalling and media protocols. The point was made repeatedly when I explained this primary area of contention that we want it to be easy to use by the "little guys", and that even if signalling was a downloaded JS library, you'd end up with a wild mixture of old versions in use, which may complicate interop/federation (plus the overhead to pull them down, and some possible security issues). > > We also have to make sure that the resulting application does not > flood or fry the network. That means it will have to have real > congestion control mechanisms. Trusting the javascript application > for that has some real issues which we've already discussed. > Splitting signaling and congestion control isn't a lot better. If > congestion control at the network level is managed by the browser but > signalling is in the javascript, then information about that state has > to pass into the JS application, so it can manage the signalling. > That makes the APIs more complex and runs the risk that a naive > javascript application will not adjust to the congestion control > requirements at all. I think we do want to optionally include the JS application in the decisions about bit allocation, but handle it automatically for most cases. A class of complex WebRTC apps will want to be able to allocate the bits themselves, and in some cases drop or add streams (or switch operation modes) in response to bandwidth changes. Details to be determined; I plan to make a proposal on this. However, unless you go out of your way none of this will impinge on your straightforward WebRTC app. > > The early web took off in part because of the ease of embedding things > like images (compared to gopher, for example) into rich content. We > have the opportunity to create native web applications with much > richer and more interactive experiences with rtcweb, but if it is not > easy to do, it won't have the same impact. If this is something that > can be done only by folks who can roll their own signalling protocol, > it's dead, because the number of content authors is too small. If it > even requires selecting among an unbounded set of variously maintained > libraries , it will be frustrating for the developer of simple > applications. At that level, the existing plugins will simply be > more stable and better known. +1 > > Providing baseline APIs into a well-known signaling capability seems > to me far more likely to result in a real flowering of rtcweb > content. That's why I want it. > > Just my two cents, not taken from any hat, > > Ted > -- Randell Jesup randell-ietf@jesup.org From oej@edvina.net Sun Sep 18 23:33: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 BD62E21F8B6F for ; Sun, 18 Sep 2011 23:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLLIJAqHfIRM for ; Sun, 18 Sep 2011 23:33:18 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id BBF9821F8B8D for ; Sun, 18 Sep 2011 23:33:17 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 71D89754BCE4; Mon, 19 Sep 2011 06:35:36 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_1D87A847-F747-45C8-A4FE-9234FFD9FAF8" From: "Olle E. Johansson" In-Reply-To: <4E765E4A.3050801@alvestrand.no> Date: Mon, 19 Sep 2011 08:35:44 +0200 Message-Id: <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 06:33:18 -0000 --Apple-Mail=_1D87A847-F747-45C8-A4FE-9234FFD9FAF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 18 sep 2011 kl. 23:10 skrev Harald Alvestrand: > I don't think we want to support RTCP-less applicaitons; if saying = "no" to them helps them not occur (it doesn't always help...) No, we don't want to support applications without RTCP. +1. /O= --Apple-Mail=_1D87A847-F747-45C8-A4FE-9234FFD9FAF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I don't = think we want to support RTCP-less applicaitons; if saying "no" to them = helps them not occur (it doesn't always = help...)

No, we don't want = to support applications without RTCP. = +1.

/O
= --Apple-Mail=_1D87A847-F747-45C8-A4FE-9234FFD9FAF8-- From HKaplan@acmepacket.com Sun Sep 18 23:57: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 5A86121F8B9E for ; Sun, 18 Sep 2011 23:57:53 -0700 (PDT) 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.087, 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 GHdMKt3Qd2O9 for ; Sun, 18 Sep 2011 23:57:52 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3269321F8B91 for ; Sun, 18 Sep 2011 23:57:51 -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; Mon, 19 Sep 2011 03:00:10 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 19 Sep 2011 03:00:07 -0400 From: Hadriel Kaplan To: Randell Jesup Thread-Topic: [rtcweb] Data transfer Thread-Index: AQHMdpnDuV+LINVU8Uu/KmHCjLRx8w== Date: Mon, 19 Sep 2011 07:00:07 +0000 Message-ID: References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> <4E7358AC.8030509@ericsson.com> <4E735FC8.20906@ericsson.com> <4E76C3D2.1010005@jesup.org> In-Reply-To: <4E76C3D2.1010005@jesup.org> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Data transfer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 06:57:53 -0000 On Sep 19, 2011, at 12:23 AM, Randell Jesup wrote: >> 3. Use TCP over UDP > This is what I had been assuming we'd do. It might have been nice to use > SCTP-over-UDP instead; that would cover more cases without having to drop > into doing network protocols in javascript for example, but it doesn't > appear there's an extant open-source example, so it's a hard sell. >=20 I think you'll want to do whatever-shim-transport-it-is in the browser rath= er than in JS no matter what. As much as I hate to say it, SCTP over UDP k= inda makes sense, given all of it's various modes of operation. =20 Whatever gets picked, it needs to support fragmentation at a layer above UD= P to make it through various NATs/firewalls/CGNs.=20 -hadriel p.s. why do you say there's no open-source of SCTP? FreeBSD has it, though= it might be out of date; sctplib is also under LGPL (http://www.sctp.de/s= ctp-download.html). From magnus.westerlund@ericsson.com Sun Sep 18 23:59: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 9050621F8BA9 for ; Sun, 18 Sep 2011 23:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.506 X-Spam-Level: X-Spam-Status: No, score=-106.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 owuzxOuCkXRy for ; Sun, 18 Sep 2011 23:59:41 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C396D21F8BA8 for ; Sun, 18 Sep 2011 23:59:40 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-db-4e76e8e97772 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 35.20.20773.9E8E67E4; Mon, 19 Sep 2011 09:02:01 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Mon, 19 Sep 2011 09:02:01 +0200 Message-ID: <4E76E8E8.2050102@ericsson.com> Date: Mon, 19 Sep 2011 09:02:00 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 06:59:41 -0000 WG, There where some discussion in the Interim meeting last week about a Screen/Application/Desktop sharing support use case. My take away from the discussion is that this use cases is likely well enough understood to actually start a consensus call now. However, to us WG chairs it was clear that the use case in question actually needs to be split into two parts. A) Where the RTCWEB enabled browser can use a local application window, the whole desktop or a Screen as a media source that can be encoded and transported over the peerConnection for displaying/playback at the peer. B) Where a remote peer can provide one or more input types such as mouse and keyboard to control the local system, not only including the browser, but also other operating system resources. This clearly can only happen after additional consent, most likely on a per occasion consent. My interpretation is that A only allows for application sharing in conferencing contexts, like in the WEBEX session the Interim meeting was held with where we shared slides. Where the combination of A and B is providing for VNC/Remote desktop. Thus the question to the WG is the following. 1) Do you support or object the inclusion of use case A, B or Both in our Use case document? 2) Do you have additional comments for or against either of the use cases? As WG chair Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From holmer@google.com Mon Sep 19 00:04: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 9BC3221F84B2 for ; Mon, 19 Sep 2011 00:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.143 X-Spam-Level: X-Spam-Status: No, score=-103.143 tagged_above=-999 required=5 tests=[AWL=-2.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sdYjQVFwXbe for ; Mon, 19 Sep 2011 00:04:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id A6ED421F8B90 for ; Mon, 19 Sep 2011 00:04:00 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p8J76L7r007045 for ; Mon, 19 Sep 2011 00:06:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1316415982; bh=sbgi8prxfdQB9xvYeR3kc2wnkJw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=IONN80kXgJe8e/j09u6T+52zEDA/Bg5IsujoEuG8j4CZgBY+YONajNEyn74bhvD+9 wwKCt+BncdSmcxfPFcPvQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=dPU+CyfmKVxoKpBrh0+3PHSSZ0W79kN5b+RIf6t0iwWKqiSGy4qP5ayAyMRng0lAW 4ODB/gzXFPjNUfayoinEA== Received: from eyh5 (eyh5.prod.google.com [10.208.8.5]) by wpaz37.hot.corp.google.com with ESMTP id p8J76JeK007741 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 19 Sep 2011 00:06:20 -0700 Received: by eyh5 with SMTP id 5so2263814eyh.38 for ; Mon, 19 Sep 2011 00:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=soWr1VTqU0fqkYePex4HpGBaIz0ZGyvsMc1Kg3QtCT8=; b=OsBKW24ncNQ156Nh924c6q/BqLhacBgAxB8X39m+kWoh5bMl/p/r5NyjR5o2Ag/6JZ 6XM9L6S+vswdN9wn/qvw== Received: by 10.213.113.8 with SMTP id y8mr614585ebp.50.1316415977001; Mon, 19 Sep 2011 00:06:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.113.8 with SMTP id y8mr614575ebp.50.1316415975391; Mon, 19 Sep 2011 00:06:15 -0700 (PDT) Received: by 10.213.15.82 with HTTP; Mon, 19 Sep 2011 00:06:15 -0700 (PDT) In-Reply-To: <4E766C4C.2020201@jesup.org> References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> Date: Mon, 19 Sep 2011 09:06:15 +0200 Message-ID: From: Stefan Holmer To: Randell Jesup Content-Type: multipart/alternative; boundary=0015174c0ef897017304ad45fa28 X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 07:04:02 -0000 --0015174c0ef897017304ad45fa28 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 19, 2011 at 12:10 AM, Randell Jesup wrote: > On 9/16/2011 9:26 AM, Magnus Westerlund wrote: > >> As an Individual I do have a few comments and question on this document >> and its algorithm. >> > As said on the call, I'm going to work with Harald (and Justin, and anyone > else interested) to provide requirements and likely a suggested algorithm. > At this point, I believe we'll specify the mechanism for telling the other > side the apparent bandwidth, but leave the algorithm for finding that out > open for innovation. I plan to propose a baseline algorithm. On the > sender > side, I expect to optionally involve the application in deciding how the > bits are allocated among the channels, and the option to add or remove > channels based on bandwidth. I expect that we will mandate that if the > application doesn't choose, the rtcweb/webrtc code will. This is all still > to be hammered out; anyone else interested in helping write the draft > requirements let me know. > > > 1. Section 3: As delay based congestion control has been tried a number >> of times and meet with less than stellar success I wonder if you have >> any understanding of how this relates to the issues previously >> encountered: >> > Do you have any pointers to these earlier attempts? My separate experience > with this class has been extremely successful, though perhaps with a set of > real-world use-cases that don't cover the situations you're referring to. > My understanding is that Radvision's NetSense is very similar from their > description of it. > > I'm interested in any references you may have as well. > > - Stability (especially on short RTTs) >> - How it competes with TCP flows, which was a real issues for TCP Vegas >> but may be less of an issue here. >> > Perhaps Google can comment here about what tests they've done. If > anything, > this class of algorithm when faced with aggressive TCP flows will > eventually > have problems, because TCP will tend to fill up the buffers at the > bottleneck. > Since this algorithm senses buffers starting to fill up, it will tend to > back > off before TCP is likely to see a loss event. Now, it's more complex than > that of course, and multiple flows make it more complex still. It's also > sensitive to the adaptation rate of this algorithm and speed of backoff. > If I remember, TFRC tends to back off more slowly than TCP but also > increase > more slowly; I suspect Google's algorithm is similar. > As you're saying, it will always be hard for delay based congestion control algorithms to compete with a packet loss based algorithm. The delay based algorithm will detect over-use much earlier than the packet loss based one, and that's basically what we've seen in the tests we've been running as well. I do think we would benefit from more tests in this area. For instance, we might want to go with an additive increase approach rather than the current one which is multiplicative, this would likely help improve the algorithms self fairness as well. > Web Browser traffic can be especially aggressive at filling large buffers > at > a bottleneck router, and will become more so as the initial window of 10 > rolls out. > > > > 2. Section 3, I don't see any discussion of the startup issue. Is my >> assumption correct, that you will simply start at some rate and then >> adapt from that? >> > Startup is an open question; you have to start somewhere, and there's > no way to always get the start "right". History of previous sessions may > be useful here; it's theoretically possible to use perhaps some of the > ICE negotiation for a first-level guess or we could send an initial packet > train and measure dispersion. But that's just speculation; history can be > very wrong if you've changed networks or the other person has a very > different > network than the last call (or last call with that person). I'm not sure > if > we should mandate something here, or use something more open to encourage > innovation. > > > 3. Section 3, I guess this mechanism would get significant issues with >> any sender side transmission filtering. Burst transmitting I-frames over >> a network, especially for high resolution video can easily result in >> packet loss in switch fabrics if there is any cross traffic in the >> switch fabric. Thus having a bit of send filtering for frame >> transmission is a good idea. Are I understanding it correctly that this >> could result in over-use indication if I has such mechanism which >> filters a packet to a slower transmission rate than what a single or >> small burst can achieve over the same path? >> > Well, such send filtering amounts to a bottleneck in practice at the > sending > node, so that actually might be ok. I'm assuming you're talking about > pacing > the actual send()s of large dumps of fragmented IDRs/i-frames to some > maximum packet rate or bitrate (almost the same thing). I think the > algorithm > looks at all the fragments and the time they came in to calculate the > bandwidth. > If so, it would only think it was over-bandwidth if the pacing slowed them > down > to less than the actual bottleneck rate; I suspect this would rarely be the > case > outside of high-bandwidth LANs at very high resolutions. > > > > >> 4. Section 4. >> >> "This algorithm is run every time a receive report arrives at the >> sender, which will happen [[how often do we expect? and why?]]. If >> no receive report is recieved within [[what timeout?]], the algorithm >> will take action as if all packets in the interval have been lost. >> [[does that make sense?]]" >> >> The transmission of receiver reports is highly dependent on RTP profile, >> the RTCP bandwidth, trr-int parameter and any feedback events. >> >> If I start with assuming AVPF which seems reasonable in most browser to >> browser case with our current proposals for RTP support. Then if there >> are no feedback events the transmission of receiver reports will occur >> as often as the bandwidth allows, but no more often than the value of >> trr-int parameter. >> >> Here is might be worth mentioning that I do expect trr-int to be set to >> avoid RTCP reporting to often due to the relatively high RTCP bandwidth >> values that will be set due to the multiplexing of audio and video in a >> single RTP session. Thus avoiding that RTCP rates are as high or larger >> than the audio streams they report in steady state. >> > Agreed. This is where my plans to suggest a baseline algorithm that melds > the reception data of all the streams in the PeerConnection may be a > significant advantage over doing bandwidth estimation on each stream > independently. We'll see if I can make the idea work, but there are some > significant advantages if it does. If not, we can estimate in each channel > independently as per the Google algorithm. > You can also use rtcp-fb PLI/etc events to hang these reports off of, > increasing > the frequency they get through with minimal extra bandwidth use. > > > > When feedback events occur the stack will have the choice of sending a >> RTCP RR, that is a choice provided due to the reduced size RTCP >> specification included. But if the loss cumulative count diff is >> non-zero it might be worth mandating that the RR/SR is included in any >> such feedback RTCP packet. >> > Exactly - or a TMMBR with the results of the receiver-side bandwidth > calculations. > > > For that reason causing a feedback event when there is losses and >> schedule them using the early algorithm may be a good choice to ensure >> timely reporting of any loss. >> >> If one uses AVP then the RTCP timing rules will give you when you >> transmit RTCP feeedback and thus the parameterization becomes central >> here. A clear issue is if people uses the minimal interval of 5 seconds >> or the 360/Session_BW(in kbps). I would note that 5 seconds is very long >> in adaptation situations. >> > > Yes. > > > > I think the timeout should be based on the RTT and possible reporting >> rate. But there clearly need to be some upper limit, either explicitly >> or mandating RTCP bandwidth rates. >> >> 5. Section 4: >> "We motivate the packet loss thresholds by noting that if we have >> small amount of packet losses due to over-use, that amount will soon >> increase if we don't adjust our bit rate. Therefore we will soon >> enough reach above the 10 % threshold and adjust As(i). However if >> the packet loss rate does not increase, the losses are probably not >> related to self-induced channel over-use and therefore we should not >> react on them." >> >> I am personally worried that a packet loss threshold of 10% is so high >> that it might push a lot of other traffic out of the way. Thus being >> quite aggressive towards other flows. >> > Yes; I want to visit these tuning parameters and how packet loss is > reacted to and at least tweak it. > > > TCP has this relation between the average packet loss rate and the >> highest sustainable rate which can be interpreted as TCP gets more >> sensitive to loss the higher the average data rate becomes. Thus in >> certain situation the sender side algorithm part will be extremely >> aggressive in pushing TCP out of the way. The receiver part may >> compensate for this pretty well in a number of situations. >> >> But, I do wonder why for example the A(i) isn't bounded to be between >> TFRC's rate and some multiple of TFRC rate, not unbounded by other than >> the receiver side algorithm. >> > Good question; we should look into it. > > The idea behind those bounds is that if we believe in the TFRC equation, we should be able to transmit with that rate while still being fair to TCP. > > I do understand this document is to start a discussion. But I think we >> need to be sensitive to that it is difficult to get even something that >> is self-fair over the wide range of conditions the Internet has to >> provide. >> >> Thus I would appreciate what issues with for example TFRC that you >> attempt to fix with the various new components you add. >> > Magnus: Welcome to my little congestion-control bof... :-) > > I'm interested in continued discussions as well. > -- > Randell Jesup > randell-ietf@jesup.org > > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --0015174c0ef897017304ad45fa28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 19, 2011 at 12:10 AM, Randell Jesup = <randell-iet= f@jesup.org> wrote:
On 9/16/2011 9:26 AM, Magnus Westerlund wrote:
As an Individual I do have a few comments and question on this document
and its algorithm.
As said on the call, I'm going to work with Harald (and Justin, and any= one
else interested) to provide requirements and likely a suggested algorithm.<= br> At this point, I believe we'll specify the mechanism for telling the ot= her
side the apparent bandwidth, but leave the algorithm for finding that out open for innovation. =A0I plan to propose a baseline algorithm. =A0On the s= ender
side, I expect to optionally involve the application in deciding how the bits are allocated among the channels, and the option to add or remove
channels based on bandwidth. =A0I expect that we will mandate that if the application doesn't choose, the rtcweb/webrtc code will. =A0This is all= still
to be hammered out; anyone else interested in helping write the draft
requirements let me know.


1. Section 3: As delay based congestion control has been tried a number
of times and meet with less than stellar success I wonder if you have
any understanding of how this relates to the issues previously encountered:=
Do you have any pointers to these earlier attempts? =A0My separate experien= ce
with this class has been extremely successful, though perhaps with a set of=
real-world use-cases that don't cover the situations you're referri= ng to.
My understanding is that Radvision's NetSense is very similar from thei= r
description of it.


<= div>I'm interested in any references you may have as well.
= =A0

- Stability (especially on short RTTs)
- How it competes with TCP flows, which was a real issues for TCP Vegas
but may be less of an issue here.
Perhaps Google can comment here about what tests they've done. =A0If an= ything,
this class of algorithm when faced with aggressive TCP flows will eventuall= y
have problems, because TCP will tend to fill up the buffers at the bottlene= ck.
Since this algorithm senses buffers starting to fill up, it will tend to ba= ck
off before TCP is likely to see a loss event. =A0Now, it's more complex= than
that of course, and multiple flows make it more complex still. =A0It's = also
sensitive to the adaptation rate of this algorithm and speed of backoff. If I remember, TFRC tends to back off more slowly than TCP but also increas= e
more slowly; I suspect Google's algorithm is similar.
<= div>
As you're saying, it will always be hard for delay b= ased congestion control algorithms to compete with a packet loss based algo= rithm. The delay based algorithm will detect over-use much earlier than the= packet loss based one, and that's basically what we've seen in the= tests we've been running as well. I do think we would benefit from mor= e tests in this area. For instance, we might want to go with an additive in= crease approach rather than the current one which is multiplicative, this w= ould likely help improve the algorithms self fairness as well.


Web Browser traffic can be especially aggressive at filling large buffers a= t
a bottleneck router, and will become more so as the initial window of 10 rolls out.



2. Section 3, I don't see any discussion of the startup issue. Is my assumption correct, that you will simply start at some rate and then
adapt from that?
Startup is an open question; you have to start somewhere, and there's no way to always get the start "right". =A0History of previous se= ssions may
be useful here; it's theoretically possible to use perhaps some of the<= br> ICE negotiation for a first-level guess or we could send an initial packet<= br> train and measure dispersion. =A0But that's just speculation; history c= an be
very wrong if you've changed networks or the other person has a very di= fferent
network than the last call (or last call with that person). =A0I'm not = sure if
we should mandate something here, or use something more open to encourage innovation.


3. Section 3, I guess this mechanism would get significant issues with
any sender side transmission filtering. Burst transmitting I-frames over a network, especially for high resolution video can easily result in
packet loss in switch fabrics if there is any cross traffic in the
switch fabric. Thus having a bit of send filtering for frame
transmission is a good idea. Are I understanding it correctly that this
could result in over-use indication if I has such mechanism which
filters a packet to a slower transmission rate than what a single or
small burst can achieve over the same path?
Well, such send filtering amounts to a bottleneck in practice at the sendin= g
node, so that actually might be ok. =A0I'm assuming you're talking = about pacing
the actual send()s of large dumps of fragmented IDRs/i-frames to some
maximum packet rate or bitrate (almost the same thing). =A0I think the algo= rithm
looks at all the fragments and the time they came in to calculate the bandw= idth.
If so, it would only think it was over-bandwidth if the pacing slowed them = down
to less than the actual bottleneck rate; I suspect this would rarely be the= case
outside of high-bandwidth LANs at very high resolutions.
<= br>


4. Section 4.

"This algorithm is run every time a receive report arrives at the
=A0 =A0sender, which will happen [[how often do we expect? and why?]]. =A0= If
=A0 =A0no receive report is recieved within [[what timeout?]], the algorit= hm
=A0 =A0will take action as if all packets in the interval have been lost.<= br> =A0 =A0[[does that make sense?]]"

The transmission of receiver reports is highly dependent on RTP profile, the RTCP bandwidth, trr-int parameter and any feedback events.

If I start with assuming AVPF which seems reasonable in most browser to
browser case with our current proposals for RTP support. Then if there
are no feedback events the transmission of receiver reports will occur
as often as the bandwidth allows, but no more often than the value of
trr-int parameter.

Here is might be worth mentioning that I do expect trr-int to be set to
avoid RTCP reporting to often due to the relatively high RTCP bandwidth
values that will be set due to the multiplexing of audio and video in a
single RTP session. Thus avoiding that RTCP rates are as high or larger
than the audio streams they report in steady state.
Agreed. =A0This is where my plans to suggest a baseline algorithm that meld= s
the reception data of all the streams in the PeerConnection may be a
significant advantage over doing bandwidth estimation on each stream
independently. =A0We'll see if I can make the idea work, but there are = some
significant advantages if it does. =A0If not, we can estimate in each chann= el
independently as per the Google algorithm.=A0

You can also use rtcp-fb PLI/etc events to hang these reports off of, incre= asing
the frequency they get through with minimal extra bandwidth use.



When feedback events occur the stack will have the choice of sending a
RTCP RR, that is a choice provided due to the reduced size RTCP
specification included. But if the loss cumulative count diff is
non-zero it might be worth mandating that the RR/SR is included in any
such feedback RTCP packet.
Exactly - or a TMMBR with the results of the receiver-side bandwidth
calculations.


For that reason causing a feedback event when there is losses and
schedule them using the early algorithm may be a good choice to ensure
timely reporting of any loss.

If one uses AVP then the RTCP timing rules will give you when you
transmit RTCP feeedback and thus the parameterization becomes central
here. A clear issue is if people uses the minimal interval of 5 seconds
or the 360/Session_BW(in kbps). I would note that 5 seconds is very long in adaptation situations.

Yes.



I think the timeout should be based on the RTT and possible reporting
rate. But there clearly need to be some upper limit, either explicitly
or mandating RTCP bandwidth rates.

5. Section 4:
"We motivate the packet loss thresholds by noting that if we have
=A0 =A0small amount of packet losses due to over-use, that amount will soo= n
=A0 =A0increase if we don't adjust our bit rate. =A0Therefore we will = soon
=A0 =A0enough reach above the 10 % threshold and adjust As(i). =A0However = if
=A0 =A0the packet loss rate does not increase, the losses are probably not=
=A0 =A0related to self-induced channel over-use and therefore we should no= t
=A0 =A0react on them."

I am personally worried that a packet loss threshold of 10% is so high
that it might push a lot of other traffic out of the way. Thus being
quite aggressive towards other flows.
Yes; I want to visit these tuning parameters and how packet loss is
reacted to and at least tweak it.


TCP has this relation between the average packet loss rate and the
highest sustainable rate which can be interpreted as TCP gets more
sensitive to loss the higher the average data rate becomes. Thus in
certain situation the sender side algorithm part will be extremely
aggressive in pushing TCP out of the way. The receiver part may
compensate for this pretty well in a number of situations.

But, I do wonder why for example the A(i) isn't bounded to be between TFRC's rate and some multiple of TFRC rate, not unbounded by other than=
the receiver side algorithm.
Good question; we should look into it.


The idea behind those bounds is that if we believe = in the TFRC equation, we should be able to transmit with that rate while st= ill being fair to TCP.=A0
=A0

I do understand this document is to start a discussion. But I think we
need to be sensitive to that it is difficult to get even something that
is self-fair over the wide range of conditions the Internet has to provide.=

Thus I would appreciate what issues with for example TFRC that you
attempt to fix with the various new components you add.
Magnus: Welcome to my little congestion-control bof... :-)


I'm interested in co= ntinued discussions as well.=A0
=A0
--
Randell Jesup
randell-ietf@je= sup.org


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

--0015174c0ef897017304ad45fa28-- From randell-ietf@jesup.org Mon Sep 19 00:23: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 C05B521F8B66 for ; Mon, 19 Sep 2011 00:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 e8KY6A7F-5gt for ; Mon, 19 Sep 2011 00:23:30 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 3549B21F8B5A for ; Mon, 19 Sep 2011 00:23:30 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5YEi-0007ti-3E for rtcweb@ietf.org; Mon, 19 Sep 2011 02:25:52 -0500 Message-ID: <4E76EDB6.8090004@jesup.org> Date: Mon, 19 Sep 2011 03:22:30 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> In-Reply-To: <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.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 default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 07:23:30 -0000 On 9/17/2011 1:27 PM, Hadriel Kaplan wrote: > On Sep 17, 2011, at 4:27 AM, Olle E. Johansson wrote: > >> They will be able to use the rtcweb data channel, which is a concern. > Yes, that's actually the most interesting piece of this whole thing, in my opinion. Browsers don't typically offer raw sockets to javascript as far as I know. And not only does it raise a lovely set of security concerns, but also network collapse issues since UDP has no congestion backoff and I believe the data channel we're talking about is UDP(?). Actually DTLS channels; they're effectively UDP, but encrypted. However, per a few messages you'll have seen from me, discussion at the last IETF and the call a week and a bit ago, we will plan to extend the congestion control domain to include controlling the data channels. Ironically reliable data channels would be easier to handle than unreliable (you could just use TCP-over-UDP); but we plan to do better than that. > And since the data channel is actually peer-to-peer rather than client-to-server, the issues with not standardizing its protocol become harder. I.e., leaving it a raw socket will only work if it goes between the same javascripts, inside the same domain - if that's ok, then the only issue is this would be put into SDP, and SDP isn't constrained by a javascript domain. Hmm... gosh, if only rtcweb didn't use SDP as its browser API... > :) Well, depending on how the data channels are set up, they may not be required to include in the SDP at all; they could be instantiated on-demand in the of an open PeerConnection. Data channels at this point are assumed to be application-specific and not subject to being exchanged during federation; we should think a little about this. -- Randell Jesup randell-ietf@jesup.org From christer.holmberg@ericsson.com Mon Sep 19 00: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 B83C621F8B7D for ; Mon, 19 Sep 2011 00:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 eAWhUHuzIX7J for ; Mon, 19 Sep 2011 00:24:15 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id DF67E21F8B79 for ; Mon, 19 Sep 2011 00:24:14 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-c2-4e76eeacbe12 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B1.43.02839.CAEE67E4; Mon, 19 Sep 2011 09:26:36 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 19 Sep 2011 09:26:36 +0200 From: Christer Holmberg To: Hadriel Kaplan , Roni Even Date: Mon, 19 Sep 2011 09:26:35 +0200 Thread-Topic: [rtcweb] AVPF vs AVP Thread-Index: AQHMcvCC1935An+dNEG35IBBpAPmuZVUUyUA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233F1EB52@ESESSCMS0356.eemea.ericsson.se> References: <4E70C387.1070707@ericsson.com> <4e73497a.280d440a.69d0.ffff9f98@mx.google.com> <87AC7090-D372-4CC7-A20B-560B0598D7E5@acmepacket.com> In-Reply-To: <87AC7090-D372-4CC7-A20B-560B0598D7E5@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [rtcweb] AVPF vs AVP X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 07:24:15 -0000 Hi, I agree with Hadriel and Harald. Also, even if there is no SBC, a UAS that doesn't support MULTIPLEX would s= ee an offer of two different streams, and if it accepts both a second o/a w= ould be needed anyway. And, as Harald said, the backward compability is for entities that do not s= upport multiplexing. Regards, Christer =20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 16. syyskuuta 2011 21:06 > To: Roni Even > Cc: > Subject: Re: [rtcweb] AVPF vs AVP >=20 >=20 > On Sep 16, 2011, at 9:03 AM, Roni Even wrote: >=20 > > Magnus, > > Maybe we can take the approach from > > draft-holmberg-mmusic-sdp-multiplex-negotiation and offer the same=20 > > m-line with the same port number twice, one as AVP and one=20 > as AVPF and=20 > > let the other side chose, he can answer with a port=3D0 for=20 > the profile=20 > > it does not want. If the multiplex proposal has backward=20 > > interoperability than this proposal also does. >=20 > You can't do that. Not only is it not kosher in the sense=20 > that you're really offering two media sessions, rather than=20 > alternatives for one, but it actually won't work in practice:=20 > if the SDP offer crosses an SBC or App-Server B2BUA, some of=20 > them will treat them as two media sessions and thus offer 2=20 > different port numbers on their UAC side and make it no=20 > longer distinguishable from a normal offer of two media sessions. > (and I've tested this on an SBC) >=20 > -hadriel >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From harald@alvestrand.no Mon Sep 19 00:26: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 06EBF21F8560 for ; Mon, 19 Sep 2011 00:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.185 X-Spam-Level: X-Spam-Status: No, score=-108.185 tagged_above=-999 required=5 tests=[AWL=2.414, 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 wnCASRT3BeDn for ; Mon, 19 Sep 2011 00:26:38 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 22D5921F852E for ; Mon, 19 Sep 2011 00:26:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CCF9339E0CD; Mon, 19 Sep 2011 09:28:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNvhpkvvdKDK; Mon, 19 Sep 2011 09:28:59 +0200 (CEST) Received: from [192.168.1.51] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 425F139E051; Mon, 19 Sep 2011 09:28:59 +0200 (CEST) Message-ID: <4E76EF3A.4010500@alvestrand.no> Date: Mon, 19 Sep 2011 09:28:58 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Magnus Westerlund References: <4E76E8E8.2050102@ericsson.com> In-Reply-To: <4E76E8E8.2050102@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 07:26:39 -0000 On 09/19/2011 09:02 AM, Magnus Westerlund wrote: > WG, > > There where some discussion in the Interim meeting last week about a > Screen/Application/Desktop sharing support use case. My take away from > the discussion is that this use cases is likely well enough understood > to actually start a consensus call now. However, to us WG chairs it was > clear that the use case in question actually needs to be split into two > parts. > > A) Where the RTCWEB enabled browser can use a local application window, > the whole desktop or a Screen as a media source that can be encoded and > transported over the peerConnection for displaying/playback at the peer. I think this is a fairly well defined applicaiton (basically, take input from a synthetic source, where the synthetic source may be anything available to the browser), the baseline (but not the optimum) could simply be encoding the stuff using a default codec, and the access procedures shouldn't be much different than for microphone and camera. I support its inclusion in the document. Note: The implementation of such a feature is far from trivial. I would not want to require that all browsers implementing RTCWeb support the feature. > B) Where a remote peer can provide one or more input types such as mouse > and keyboard to control the local system, not only including the > browser, but also other operating system resources. This clearly can > only happen after additional consent, most likely on a per occasion > consent. I see this as a more tricky thing to get right (in most apps, the mixing of events from multiple sources depends strongly on both proper timing/sequencing and reliable delivery). I would like to not address this for now (RTCWeb version 1). > My interpretation is that A only allows for application sharing in > conferencing contexts, like in the WEBEX session the Interim meeting was > held with where we shared slides. Where the combination of A and B is > providing for VNC/Remote desktop. > > Thus the question to the WG is the following. > > 1) Do you support or object the inclusion of use case A, B or Both in > our Use case document? > > 2) Do you have additional comments for or against either of the use cases? > > > As WG chair > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Frgatan 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 harald@alvestrand.no Mon Sep 19 00: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 83AEE21F8B76 for ; Mon, 19 Sep 2011 00:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.995 X-Spam-Level: X-Spam-Status: No, score=-107.995 tagged_above=-999 required=5 tests=[AWL=2.004, BAYES_00=-2.599, J_CHICKENPOX_43=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 Xi8cHdppouob for ; Mon, 19 Sep 2011 00:28:43 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0041421F8B75 for ; Mon, 19 Sep 2011 00:28:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EC75039E0CD for ; Mon, 19 Sep 2011 09:31:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTmTIiObE1eG for ; Mon, 19 Sep 2011 09:31:04 +0200 (CEST) Received: from [192.168.1.51] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 8E85D39E051 for ; Mon, 19 Sep 2011 09:31:04 +0200 (CEST) Message-ID: <4E76EFB8.90303@alvestrand.no> Date: Mon, 19 Sep 2011 09:31:04 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: rtcweb@ietf.org References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> <4E7358AC.8030509@ericsson.com> <4E735FC8.20906@ericsson.com> <4E76C3D2.1010005@jesup.org> <4E76C6D0.6090506@mozilla.com> In-Reply-To: <4E76C6D0.6090506@mozilla.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Data transfer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 07:28:43 -0000 On 09/19/2011 06:36 AM, Timothy B. Terriberry wrote: >> There are many other uses of peer-to-peer data, such as file-transfer >> during >> chat(you want reliable or you get to re-invent a reliable protocol over >> UDP), > > Perhaps this should be added as a use-case? It has strong implications > for the congestion control algorithm, as discussed at the interim > telecon: you can have an arbitrarily large amount of data to send as > fast as your pipe can carry it, and that has to compete with the media > traffic. Last round, PseudoTCP over UDP (or UDP/DTLS) seemed to be the favourite protocol for reliable data delivery. From oej@edvina.net Mon Sep 19 00:29: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 0E07121F8B76 for ; Mon, 19 Sep 2011 00:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wha2fV3Bc+9D for ; Mon, 19 Sep 2011 00:29:58 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 4E49821F8B08 for ; Mon, 19 Sep 2011 00:29:52 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id D07C5754BCE5; Mon, 19 Sep 2011 07:32:12 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_38E66013-C090-4985-9BE1-C128CECD4440" From: "Olle E. Johansson" In-Reply-To: <4E76E8E8.2050102@ericsson.com> Date: Mon, 19 Sep 2011 09:32:20 +0200 Message-Id: <504F8A52-0D1E-4334-A77C-14BCB4349F79@edvina.net> References: <4E76E8E8.2050102@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1244.3) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 07:29:59 -0000 --Apple-Mail=_38E66013-C090-4985-9BE1-C128CECD4440 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 19 sep 2011 kl. 09:02 skrev Magnus Westerlund: > WG, >=20 > There where some discussion in the Interim meeting last week about a > Screen/Application/Desktop sharing support use case. My take away from > the discussion is that this use cases is likely well enough understood > to actually start a consensus call now. However, to us WG chairs it = was > clear that the use case in question actually needs to be split into = two > parts. >=20 > A) Where the RTCWEB enabled browser can use a local application = window, > the whole desktop or a Screen as a media source that can be encoded = and > transported over the peerConnection for displaying/playback at the = peer. >=20 > B) Where a remote peer can provide one or more input types such as = mouse > and keyboard to control the local system, not only including the > browser, but also other operating system resources. This clearly can > only happen after additional consent, most likely on a per occasion > consent. >=20 > My interpretation is that A only allows for application sharing in > conferencing contexts, like in the WEBEX session the Interim meeting = was > held with where we shared slides. Where the combination of A and B is > providing for VNC/Remote desktop. >=20 > Thus the question to the WG is the following. >=20 > 1) Do you support or object the inclusion of use case A, B or Both in > our Use case document? Yes. >=20 > 2) Do you have additional comments for or against either of the use = cases? Nitpick: Case A also requires user consent. /O >=20 >=20 > As WG chair >=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 --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden --Apple-Mail=_38E66013-C090-4985-9BE1-C128CECD4440 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
WG,

There where some discussion in the Interim = meeting last week about a
Screen/Application/Desktop sharing support = use case. My take away from
the discussion is that this use cases is = likely well enough understood
to actually start a consensus call now. = However, to us WG chairs it was
clear that the use case in question = actually needs to be split into two
parts.

A) Where the RTCWEB = enabled browser can use a local application window,
the whole desktop = or a Screen as a media source that can be encoded and
transported = over the peerConnection for displaying/playback at the peer.

B) = Where a remote peer can provide one or more input types such as = mouse
and keyboard to control the local system, not only including = the
browser, but also other operating system resources. This clearly = can
only happen after additional consent, most likely on a per = occasion
consent.

My interpretation is that A only allows for = application sharing in
conferencing contexts, like in the WEBEX = session the Interim meeting was
held with where we shared slides. = Where the combination of A and B is
providing for VNC/Remote = desktop.

Thus the question to the WG is the following.

1) = Do you support or object the inclusion of use case A, B or Both = in
our Use case document?
Yes.

2) Do you have additional comments for or against = either of the use cases?
Nitpick: Case A also = requires user consent.

/O


As WG chair

Magnus = Westerlund

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

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

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



= --Apple-Mail=_38E66013-C090-4985-9BE1-C128CECD4440-- From randell-ietf@jesup.org Mon Sep 19 00:32: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 C8A6B21F8B53 for ; Mon, 19 Sep 2011 00:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 ZfYZGIv35vpz for ; Mon, 19 Sep 2011 00:32:31 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 00DC721F8B8C for ; Mon, 19 Sep 2011 00:32:30 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5YNR-0002TX-7y for rtcweb@ietf.org; Mon, 19 Sep 2011 02:34:53 -0500 Message-ID: <4E76EFD4.6010707@jesup.org> Date: Mon, 19 Sep 2011 03:31:32 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> <4E7358AC.8030509@ericsson.com> <4E735FC8.20906@ericsson.com> <4E76C3D2.1010005@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] Data transfer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 07:32:31 -0000 On 9/19/2011 3:00 AM, Hadriel Kaplan wrote: > On Sep 19, 2011, at 12:23 AM, Randell Jesup wrote: > >>> 3. Use TCP over UDP >> This is what I had been assuming we'd do. It might have been nice to use >> SCTP-over-UDP instead; that would cover more cases without having to drop >> into doing network protocols in javascript for example, but it doesn't >> appear there's an extant open-source example, so it's a hard sell. >> > I think you'll want to do whatever-shim-transport-it-is in the browser rather than in JS no matter what. As much as I hate to say it, SCTP over UDP kinda makes sense, given all of it's various modes of operation. > > Whatever gets picked, it needs to support fragmentation at a layer above UDP to make it through various NATs/firewalls/CGNs. > > -hadriel > p.s. why do you say there's no open-source of SCTP? FreeBSD has it, though it might be out of date; sctplib is also under LGPL (http://www.sctp.de/sctp-download.html). I meant SCTP-over-UDP, not direct SCTP. (Yes, I assume a working SCTP can be transformed into SCTP-over-UDP, but without spending some time it's hard for me to say what level of work this would involve and the amount of testing needed. I'm now tempted to add *another* item to my plate... (I need a helper just to carry it...) :-) -- Randell Jesup randell-ietf@jesup.org From saul@ag-projects.com Mon Sep 19 00:35: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 5456D21F8B8B for ; Mon, 19 Sep 2011 00:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YACh6vgyWVoI for ; Mon, 19 Sep 2011 00:35:48 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id CAB1421F8461 for ; Mon, 19 Sep 2011 00:35:47 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id AA985B01B0; Mon, 19 Sep 2011 09:38:08 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 068FEB019A; Mon, 19 Sep 2011 09:38:08 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <4E76E8E8.2050102@ericsson.com> Date: Mon, 19 Sep 2011 09:38:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3740CF72-D108-4C85-BE69-41285BA9550C@ag-projects.com> References: <4E76E8E8.2050102@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 07:35:48 -0000 On Sep 19, 2011, at 9:02 AM, Magnus Westerlund wrote: > WG, >=20 > There where some discussion in the Interim meeting last week about a > Screen/Application/Desktop sharing support use case. My take away from > the discussion is that this use cases is likely well enough understood > to actually start a consensus call now. However, to us WG chairs it = was > clear that the use case in question actually needs to be split into = two > parts. >=20 > A) Where the RTCWEB enabled browser can use a local application = window, > the whole desktop or a Screen as a media source that can be encoded = and > transported over the peerConnection for displaying/playback at the = peer. >=20 > B) Where a remote peer can provide one or more input types such as = mouse > and keyboard to control the local system, not only including the > browser, but also other operating system resources. This clearly can > only happen after additional consent, most likely on a per occasion > consent. >=20 > My interpretation is that A only allows for application sharing in > conferencing contexts, like in the WEBEX session the Interim meeting = was > held with where we shared slides. Where the combination of A and B is > providing for VNC/Remote desktop. >=20 > Thus the question to the WG is the following. >=20 > 1) Do you support or object the inclusion of use case A, B or Both in > our Use case document? >=20 I'd go for both. > 2) Do you have additional comments for or against either of the use = cases? >=20 As Harald already said, this is far from being an easy task, so I wonder = if this should be defined as a standardized use case or a 'mandatory = feature'. -- Sa=FAl Ibarra Corretg=E9 AG Projects From oej@edvina.net Mon Sep 19 00:48: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 0CA1821F8B36 for ; Mon, 19 Sep 2011 00:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.010, 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 IW3rT7dxkOtH for ; Mon, 19 Sep 2011 00:48:30 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 68FE921F8B28 for ; Mon, 19 Sep 2011 00:48:30 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id A61D0754BCE4; Mon, 19 Sep 2011 07:50:50 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <4E76EF3A.4010500@alvestrand.no> Date: Mon, 19 Sep 2011 09:50:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E76E8E8.2050102@ericsson.com> <4E76EF3A.4010500@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1244.3) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 07:48:31 -0000 19 sep 2011 kl. 09:28 skrev Harald Alvestrand: > On 09/19/2011 09:02 AM, Magnus Westerlund wrote: >> WG, >>=20 >> There where some discussion in the Interim meeting last week about a >> Screen/Application/Desktop sharing support use case. My take away = from >> the discussion is that this use cases is likely well enough = understood >> to actually start a consensus call now. However, to us WG chairs it = was >> clear that the use case in question actually needs to be split into = two >> parts. >>=20 >> A) Where the RTCWEB enabled browser can use a local application = window, >> the whole desktop or a Screen as a media source that can be encoded = and >> transported over the peerConnection for displaying/playback at the = peer. > I think this is a fairly well defined applicaiton (basically, take = input from a synthetic source, where the synthetic source may be = anything available to the browser), the baseline (but not the optimum) = could simply be encoding the stuff using a default codec, and the access = procedures shouldn't be much different than for microphone and camera. I = support its inclusion in the document. >=20 > Note: The implementation of such a feature is far from trivial. I = would not want to require that all browsers implementing RTCWeb support = the feature. I can agree with that, but I want to explore how this use case would = affect RTCweb architecture. >> B) Where a remote peer can provide one or more input types such as = mouse >> and keyboard to control the local system, not only including the >> browser, but also other operating system resources. This clearly can >> only happen after additional consent, most likely on a per occasion >> consent. > I see this as a more tricky thing to get right (in most apps, the = mixing of events from multiple sources depends strongly on both proper = timing/sequencing and reliable delivery). I would like to not address = this for now (RTCWeb version 1). I think it's a good use case for the data channel. How many such use = cases do we have? While use case A is quite often handled as a normal = video stream, use case B is likely something like VNC. This is an = application that is part of Microsoft Lync as well as the free SIP = client Blink today. /O= From randell-ietf@jesup.org Mon Sep 19 00:55: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 6F52721F8A7A for ; Mon, 19 Sep 2011 00:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, 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 8bzMPJdp21NX for ; Mon, 19 Sep 2011 00:55:43 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 8110121F8A66 for ; Mon, 19 Sep 2011 00:55:43 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5Yjt-0001QP-25; Mon, 19 Sep 2011 02:58:05 -0500 Message-ID: <4E76F544.1040108@jesup.org> Date: Mon, 19 Sep 2011 03:54:44 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Stefan Holmer References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050407030409030209020507" 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: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 07:55:44 -0000 This is a multi-part message in MIME format. --------------050407030409030209020507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Open question to the list: should the congestion-control-geeks discuss here on the list the nitty-gritty details required to build the requirements and especially to design and debate a possible proposed "baseline" congestion-control algorithm? We can certainly do that detailed discussion by email and come back with a draft; I had been planning to do it by email, but recent discussion on rtcweb made me think I should ask for opinions on this. Given the structure, if there's any significant support for "on-the-list" I'll do that. Realize though that they may get pretty long and detailed without really touching on the larger issues being discussed here. Right now the bof members to discuss this and propose a draft would be myself, Harald, Justin, Stefan Holmer and Magnus. On 9/19/2011 3:06 AM, Stefan Holmer wrote: > On Mon, Sep 19, 2011 at 12:10 AM, Randell Jesup > > wrote: > > On 9/16/2011 9:26 AM, Magnus Westerlund wrote: > > 1. Section 3: As delay based congestion control has been tried > a number > of times and meet with less than stellar success I wonder if > you have > any understanding of how this relates to the issues previously > encountered: > > Do you have any pointers to these earlier attempts? My separate > experience > with this class has been extremely successful, though perhaps with > a set of > real-world use-cases that don't cover the situations you're > referring to. > My understanding is that Radvision's NetSense is very similar from > their > description of it. > > > I'm interested in any references you may have as well. I doubt you'll find many/any, as the first published discussion I saw of delay-sensing congestion control for RTP data was Radvision's posts about Netsense last year and in their Android webcasts; and that was pretty detail-free until their recent blog posts. There's plenty of un-published experience with them at various companies I believe.... Not just Google and Radvision. > > - Stability (especially on short RTTs) > - How it competes with TCP flows, which was a real issues for > TCP Vegas > but may be less of an issue here. > > Perhaps Google can comment here about what tests they've done. If > anything, > this class of algorithm when faced with aggressive TCP flows will > eventually > have problems, because TCP will tend to fill up the buffers at the > bottleneck. > Since this algorithm senses buffers starting to fill up, it will > tend to back > off before TCP is likely to see a loss event. Now, it's more > complex than > that of course, and multiple flows make it more complex still. > It's also > sensitive to the adaptation rate of this algorithm and speed of > backoff. > If I remember, TFRC tends to back off more slowly than TCP but > also increase > more slowly; I suspect Google's algorithm is similar. > > > As you're saying, it will always be hard for delay based congestion > control algorithms to compete with a packet loss based algorithm. The > delay based algorithm will detect over-use much earlier than the > packet loss based one, and that's basically what we've seen in the > tests we've been running as well. I do think we would benefit from > more tests in this area. For instance, we might want to go with an > additive increase approach rather than the current one which is > multiplicative, this would likely help improve the algorithms self > fairness as well. Probably; additive increase is probably better, or possible using a fraction-of- predicted-bandwidth increase. If you use additive increase, it should probably be partly proportional to the maximum "good" bandwidth seen during the connection. This provides some needed scaling of the ramp-up rate to the absolute magnitude of bandwidth available. -- Randell Jesup randell-ietf@jesup.org --------------050407030409030209020507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Open question to the list: should the congestion-control-geeks discuss here on the
list the nitty-gritty details required to build the requirements and especially to design
and debate a possible proposed "baseline" congestion-control algorithm?

We can certainly do that detailed discussion by email and come back with a
draft;  I had been planning to do it by email, but recent discussion on rtcweb
made me think I should ask for opinions on this.  Given the structure, if there's
any significant support for "on-the-list" I'll do that.  Realize though that they may
get pretty long and detailed without really touching on the larger issues being
discussed here.

Right now the bof members to discuss this and propose a draft would be myself,
Harald, Justin,  Stefan Holmer and Magnus.

On 9/19/2011 3:06 AM, Stefan Holmer wrote:
On Mon, Sep 19, 2011 at 12:10 AM, Randell Jesup <randell-ietf@jesup.org> wrote:
On 9/16/2011 9:26 AM, Magnus Westerlund wrote:
1. Section 3: As delay based congestion control has been tried a number
of times and meet with less than stellar success I wonder if you have
any understanding of how this relates to the issues previously encountered:
Do you have any pointers to these earlier attempts?  My separate experience
with this class has been extremely successful, though perhaps with a set of
real-world use-cases that don't cover the situations you're referring to.
My understanding is that Radvision's NetSense is very similar from their
description of it.


I'm interested in any references you may have as well.


I doubt you'll find many/any, as the first published discussion I saw of delay-sensing
congestion control for RTP data was Radvision's posts about Netsense last year
and in their Android webcasts; and  that was pretty detail-free until their recent
blog posts.  There's plenty of un-published experience with them at various companies
I believe....  Not just Google and Radvision.

 

- Stability (especially on short RTTs)
- How it competes with TCP flows, which was a real issues for TCP Vegas
but may be less of an issue here.
Perhaps Google can comment here about what tests they've done.  If anything,
this class of algorithm when faced with aggressive TCP flows will eventually
have problems, because TCP will tend to fill up the buffers at the bottleneck.
Since this algorithm senses buffers starting to fill up, it will tend to back
off before TCP is likely to see a loss event.  Now, it's more complex than
that of course, and multiple flows make it more complex still.  It's also
sensitive to the adaptation rate of this algorithm and speed of backoff.
If I remember, TFRC tends to back off more slowly than TCP but also increase
more slowly; I suspect Google's algorithm is similar.

As you're saying, it will always be hard for delay based congestion control algorithms to compete with a packet loss based algorithm. The delay based algorithm will detect over-use much earlier than the packet loss based one, and that's basically what we've seen in the tests we've been running as well. I do think we would benefit from more tests in this area. For instance, we might want to go with an additive increase approach rather than the current one which is multiplicative, this would likely help improve the algorithms self fairness as well.

Probably; additive increase is probably better, or possible using a fraction-of-
predicted-bandwidth increase.  If you use additive increase, it should probably be
partly proportional to the maximum "good" bandwidth seen during the connection.
This provides some needed scaling of the ramp-up rate to the absolute magnitude
of bandwidth available.


-- 
Randell Jesup
randell-ietf@jesup.org
--------------050407030409030209020507-- From hlundin@google.com Mon Sep 19 01:02: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 69D0B21F8B1A for ; Mon, 19 Sep 2011 01:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.092 X-Spam-Level: X-Spam-Status: No, score=-105.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XS-k4A6eTgQm for ; Mon, 19 Sep 2011 01:02:30 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 596B421F8AF8 for ; Mon, 19 Sep 2011 01:02:30 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p8J84mZO008452 for ; Mon, 19 Sep 2011 01:04:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1316419488; bh=tPzjzmG7+GeFuklnKUgLc0PZhV0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=fTHl+52TCGlg3VZXbvRK/vku/TSRL0KBV2YdIQrQzOoPAEXAiNAupefklbzFjxusd Y/1iW8iaCLelkdte3xwiA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=flArzXafQp2wPlgBSMD3jpT83g9UC6R5CxlNptFYFfrw7waOiH3SX04RMrkyJGoXM p0BwA+jybT+U8DqRhY9IQ== Received: from qyl38 (qyl38.prod.google.com [10.241.83.230]) by wpaz21.hot.corp.google.com with ESMTP id p8J84Vo5007175 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 19 Sep 2011 01:04:47 -0700 Received: by qyl38 with SMTP id 38so2427734qyl.14 for ; Mon, 19 Sep 2011 01:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hAqdUbIMgdvfZOPh/ZdLjPUkXhkR82a/R8yRwLf3ZkI=; b=UhactoP5D8iODgzEGd6oWkZtm73QtGt9s3lZApKaLy0juHOg7J9hLkE3JKcAZVe43R zHMr8YaI79vXyuysL4Bg== Received: by 10.229.235.200 with SMTP id kh8mr1770130qcb.101.1316419487280; Mon, 19 Sep 2011 01:04:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.235.200 with SMTP id kh8mr1770124qcb.101.1316419487118; Mon, 19 Sep 2011 01:04:47 -0700 (PDT) Received: by 10.229.55.139 with HTTP; Mon, 19 Sep 2011 01:04:47 -0700 (PDT) In-Reply-To: <4E76F544.1040108@jesup.org> References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <4E76F544.1040108@jesup.org> Date: Mon, 19 Sep 2011 10:04:47 +0200 Message-ID: From: Henrik Lundin To: Randell Jesup Content-Type: multipart/alternative; boundary=0016e64ddbe2e7b6d404ad46cb9e X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 08:02:31 -0000 --0016e64ddbe2e7b6d404ad46cb9e Content-Type: text/plain; charset=ISO-8859-1 Add me to the bof members list. /Henrik L On Mon, Sep 19, 2011 at 9:54 AM, Randell Jesup wrote: > Open question to the list: should the congestion-control-geeks discuss > here on the > list the nitty-gritty details required to build the requirements and > especially to design > and debate a possible proposed "baseline" congestion-control algorithm? > > We can certainly do that detailed discussion by email and come back with a > draft; I had been planning to do it by email, but recent discussion on > rtcweb > made me think I should ask for opinions on this. Given the structure, if > there's > any significant support for "on-the-list" I'll do that. Realize though > that they may > get pretty long and detailed without really touching on the larger issues > being > discussed here. > > Right now the bof members to discuss this and propose a draft would be > myself, > Harald, Justin, Stefan Holmer and Magnus. > > > On 9/19/2011 3:06 AM, Stefan Holmer wrote: > > On Mon, Sep 19, 2011 at 12:10 AM, Randell Jesup wrote: > >> On 9/16/2011 9:26 AM, Magnus Westerlund wrote: >> >>> 1. Section 3: As delay based congestion control has been tried a number >>> of times and meet with less than stellar success I wonder if you have >>> any understanding of how this relates to the issues previously >>> encountered: >>> >> Do you have any pointers to these earlier attempts? My separate >> experience >> with this class has been extremely successful, though perhaps with a set >> of >> real-world use-cases that don't cover the situations you're referring to. >> My understanding is that Radvision's NetSense is very similar from their >> description of it. >> >> > I'm interested in any references you may have as well. > > > > I doubt you'll find many/any, as the first published discussion I saw of > delay-sensing > congestion control for RTP data was Radvision's posts about Netsense last > year > and in their Android webcasts; and that was pretty detail-free until their > recent > blog posts. There's plenty of un-published experience with them at various > companies > I believe.... Not just Google and Radvision. > > > > >> >> - Stability (especially on short RTTs) >>> - How it competes with TCP flows, which was a real issues for TCP Vegas >>> but may be less of an issue here. >>> >> Perhaps Google can comment here about what tests they've done. If >> anything, >> this class of algorithm when faced with aggressive TCP flows will >> eventually >> have problems, because TCP will tend to fill up the buffers at the >> bottleneck. >> Since this algorithm senses buffers starting to fill up, it will tend to >> back >> off before TCP is likely to see a loss event. Now, it's more complex than >> that of course, and multiple flows make it more complex still. It's also >> sensitive to the adaptation rate of this algorithm and speed of backoff. >> If I remember, TFRC tends to back off more slowly than TCP but also >> increase >> more slowly; I suspect Google's algorithm is similar. >> > > As you're saying, it will always be hard for delay based congestion > control algorithms to compete with a packet loss based algorithm. The delay > based algorithm will detect over-use much earlier than the packet loss based > one, and that's basically what we've seen in the tests we've been running as > well. I do think we would benefit from more tests in this area. For > instance, we might want to go with an additive increase approach rather than > the current one which is multiplicative, this would likely help improve the > algorithms self fairness as well. > > > Probably; additive increase is probably better, or possible using a > fraction-of- > predicted-bandwidth increase. If you use additive increase, it should > probably be > partly proportional to the maximum "good" bandwidth seen during the > connection. > This provides some needed scaling of the ramp-up rate to the absolute > magnitude > of bandwidth available. > > > -- > Randell Jesuprandell-ietf@jesup.org > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41 --0016e64ddbe2e7b6d404ad46cb9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Add me to the bof members list.

/Henrik L

=

On Mon, Sep 19, 2011 at 9:54 AM, Rande= ll Jesup <ra= ndell-ietf@jesup.org> wrote:
=20 =20 =20
Open question to the list: should the congestion-control-geeks discuss here on the
list the nitty-gritty details required to build the requirements and especially to design
and debate a possible proposed "baseline" congestion-control algorithm?

We can certainly do that detailed discussion by email and come back with a
draft;=A0 I had been planning to do it by email, but recent discussion on rtcweb
made me think I should ask for opinions on this.=A0 Given the structure, if there's
any significant support for "on-the-list" I'll do that.= =A0 Realize though that they may
get pretty long and detailed without really touching on the larger issues being
discussed here.

Right now the bof members to discuss this and propose a draft would be myself,
Harald, Justin,=A0 Stefan Holmer and Magnus.


On 9/19/2011 3:06 AM, Stefan Holmer wrote:
On Mon, Sep 19, 2011 at = 12:10 AM, Randell Jesup <randell-ietf@jesup.org> wrote:
On 9/16/2011 9:26 AM, Magnus Westerlund wr= ote:
1. Section 3: As delay based congestion control has been tried a number
of times and meet with less than stellar success I wonder if you have
any understanding of how this relates to the issues previously encountered:
Do you have any pointers to these earlier attempts? =A0My separate experience
with this class has been extremely successful, though perhaps with a set of
real-world use-cases that don't cover the situations you'= re referring to.
My understanding is that Radvision's NetSense is very similar from their
description of it.


I'm interested in any references you may have as well.


I doubt you'll find many/any, as the first published discussion I saw of delay-sensing
congestion control for RTP data was Radvision's posts about Netsens= e last year
and in their Android webcasts; and=A0 that was pretty detail-free until their recent
blog posts.=A0 There's plenty of un-published experience with them = at various companies
I believe....=A0 Not just Google and Radvision.


=A0

- Stability (especially on short RTTs)
- How it competes with TCP flows, which was a real issues for TCP Vegas
but may be less of an issue here.
Perhaps Google can comment here about what tests they've done= . =A0If anything,
this class of algorithm when faced with aggressive TCP flows will eventually
have problems, because TCP will tend to fill up the buffers at the bottleneck.
Since this algorithm senses buffers starting to fill up, it will tend to back
off before TCP is likely to see a loss event. =A0Now, it's mo= re complex than
that of course, and multiple flows make it more complex still. =A0It's also
sensitive to the adaptation rate of this algorithm and speed of backoff.
If I remember, TFRC tends to back off more slowly than TCP but also increase
more slowly; I suspect Google's algorithm is similar.

As you're saying, it will always be hard for delay based congestion control algorithms to compete with a packet loss based algorithm. The delay based algorithm will detect over-use much earlier than the packet loss based one, and that's basically what we've seen in the tests we've b= een running as well. I do think we would benefit from more tests in this area. For instance, we might want to go with an additive increase approach rather than the current one which is multiplicative, this would likely help improve the algorithms self fairness as well.

Probably; additive increase is probably better, or possible using a fraction-of-
predicted-bandwidth increase.=A0 If you use additive increase, it should probably be
partly proportional to the maximum "good" bandwidth seen duri= ng the connection.
This provides some needed scaling of the ramp-up rate to the absolute magnitude
of bandwidth available.


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

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




--
Henrik Lundin=A0|=A0WebRTC Software Eng=A0|=A0hlundin@google.com=A0|=A0+46 70 646 13 41<= /span>


--0016e64ddbe2e7b6d404ad46cb9e-- From randell-ietf@jesup.org Mon Sep 19 01:02: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 7D82021F8B2E for ; Mon, 19 Sep 2011 01:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 f6WQ-gbWErkO for ; Mon, 19 Sep 2011 01:02:44 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 02C5121F8AF7 for ; Mon, 19 Sep 2011 01:02:44 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5Yqg-0003Zz-EB for rtcweb@ietf.org; Mon, 19 Sep 2011 03:05:06 -0500 Message-ID: <4E76F6E9.4010404@jesup.org> Date: Mon, 19 Sep 2011 04:01:45 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E76E8E8.2050102@ericsson.com> In-Reply-To: <4E76E8E8.2050102@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] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 08:02:44 -0000 On 9/19/2011 3:02 AM, Magnus Westerlund wrote: > > A) Where the RTCWEB enabled browser can use a local application window, > the whole desktop or a Screen as a media source that can be encoded and > transported over the peerConnection for displaying/playback at the peer. > > B) Where a remote peer can provide one or more input types such as mouse > and keyboard to control the local system, not only including the > browser, but also other operating system resources. This clearly can > only happen after additional consent, most likely on a per occasion > consent. > > My interpretation is that A only allows for application sharing in > conferencing contexts, like in the WEBEX session the Interim meeting was > held with where we shared slides. Where the combination of A and B is > providing for VNC/Remote desktop. > > Thus the question to the WG is the following. > > 1) Do you support or object the inclusion of use case A, B or Both in > our Use case document? Both. > > 2) Do you have additional comments for or against either of the use cases? > IMHO: Both use-cases involve extra-fun security issues, but both are actually pretty compelling and useful cases to users. Everyone I mentioned them to at the Mozilla All-Hands event "got" the wish for these use-cases pretty immediately. VNC-like transfer of screen data is a particularly tough one for the current permission and access model to enable, but that may change. A lot of this is likely to be tied-to or echo the security model and concerns for HTML5 "installed webapps". -- Randell Jesup randell-ietf@jesup.org From vsingh.ietf@gmail.com Mon Sep 19 01:05: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 B9E3021F8B34 for ; Mon, 19 Sep 2011 01:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 77-7PMGA6fsP for ; Mon, 19 Sep 2011 01:05:53 -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 24C7721F8B28 for ; Mon, 19 Sep 2011 01:05:52 -0700 (PDT) Received: by fxd18 with SMTP id 18so3978590fxd.31 for ; Mon, 19 Sep 2011 01:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type; bh=otmg+SvWf77GF2eUd0+Ta6DbFxjY3hVrLsuGTxECtdE=; b=EPuEz+u2KfB+5KQruAaTo5j3bf6wxeyY8p9fQ+ntiTjWRCWmwSn5+j80vpj99h9EVk fS+O9tDOF852dVBrvTozqtb9Vk03v0IyRdtoB9Ph/LhhK81jbJ3OKLq22hupQXyPP4R8 iMkG2B0p5bEt3asnO9wa+nehgtV52SKuJNYf8= Received: by 10.223.10.84 with SMTP id o20mr1048763fao.25.1316419694870; Mon, 19 Sep 2011 01:08:14 -0700 (PDT) References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <4E76F544.1040108@jesup.org> From: Varun Singh In-Reply-To: Mime-Version: 1.0 (1.0) Date: Mon, 19 Sep 2011 11:08:09 +0300 Message-ID: <-2862138070495616930@unknownmsgid> To: Henrik Lundin Content-Type: multipart/alternative; boundary=0015174795c649bfa704ad46d86b Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 08:05:54 -0000 --0015174795c649bfa704ad46d86b Content-Type: text/plain; charset=ISO-8859-1 I'd be interested in this as well. Regards, Varun ---- http://www.netlab.tkk.fi/~varun On 19.9.2011, at 11.04, Henrik Lundin wrote: Add me to the bof members list. /Henrik L On Mon, Sep 19, 2011 at 9:54 AM, Randell Jesup wrote: > Open question to the list: should the congestion-control-geeks discuss > here on the > list the nitty-gritty details required to build the requirements and > especially to design > and debate a possible proposed "baseline" congestion-control algorithm? > > We can certainly do that detailed discussion by email and come back with a > draft; I had been planning to do it by email, but recent discussion on > rtcweb > made me think I should ask for opinions on this. Given the structure, if > there's > any significant support for "on-the-list" I'll do that. Realize though > that they may > get pretty long and detailed without really touching on the larger issues > being > discussed here. > > Right now the bof members to discuss this and propose a draft would be > myself, > Harald, Justin, Stefan Holmer and Magnus. > > > On 9/19/2011 3:06 AM, Stefan Holmer wrote: > > On Mon, Sep 19, 2011 at 12:10 AM, Randell Jesup wrote: > >> On 9/16/2011 9:26 AM, Magnus Westerlund wrote: >> >>> 1. Section 3: As delay based congestion control has been tried a number >>> of times and meet with less than stellar success I wonder if you have >>> any understanding of how this relates to the issues previously >>> encountered: >>> >> Do you have any pointers to these earlier attempts? My separate >> experience >> with this class has been extremely successful, though perhaps with a set >> of >> real-world use-cases that don't cover the situations you're referring to. >> My understanding is that Radvision's NetSense is very similar from their >> description of it. >> >> > I'm interested in any references you may have as well. > > > > I doubt you'll find many/any, as the first published discussion I saw of > delay-sensing > congestion control for RTP data was Radvision's posts about Netsense last > year > and in their Android webcasts; and that was pretty detail-free until their > recent > blog posts. There's plenty of un-published experience with them at various > companies > I believe.... Not just Google and Radvision. > > > > >> >> - Stability (especially on short RTTs) >>> - How it competes with TCP flows, which was a real issues for TCP Vegas >>> but may be less of an issue here. >>> >> Perhaps Google can comment here about what tests they've done. If >> anything, >> this class of algorithm when faced with aggressive TCP flows will >> eventually >> have problems, because TCP will tend to fill up the buffers at the >> bottleneck. >> Since this algorithm senses buffers starting to fill up, it will tend to >> back >> off before TCP is likely to see a loss event. Now, it's more complex than >> that of course, and multiple flows make it more complex still. It's also >> sensitive to the adaptation rate of this algorithm and speed of backoff. >> If I remember, TFRC tends to back off more slowly than TCP but also >> increase >> more slowly; I suspect Google's algorithm is similar. >> > > As you're saying, it will always be hard for delay based congestion > control algorithms to compete with a packet loss based algorithm. The delay > based algorithm will detect over-use much earlier than the packet loss based > one, and that's basically what we've seen in the tests we've been running as > well. I do think we would benefit from more tests in this area. For > instance, we might want to go with an additive increase approach rather than > the current one which is multiplicative, this would likely help improve the > algorithms self fairness as well. > > > Probably; additive increase is probably better, or possible using a > fraction-of- > predicted-bandwidth increase. If you use additive increase, it should > probably be > partly proportional to the maximum "good" bandwidth seen during the > connection. > This provides some needed scaling of the ramp-up rate to the absolute > magnitude > of bandwidth available. > > > -- > Randell Jesuprandell-ietf@jesup.org > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --0015174795c649bfa704ad46d86b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'd be interested in = this as well.=A0

Regards,
Varun

<= div>----

On 19.9.2011, at 11.04, Henrik Lundin <hlundin@google.com> wrote:

Add me to the bof members list.

<= /div>
/Henrik L


On Mon, S= ep 19, 2011 at 9:54 AM, Randell Jesup <randell-ietf@jesup.org> wrote:
=20 =20 =20
Open question to the list: should the congestion-control-geeks discuss here on the
list the nitty-gritty details required to build the requirements and especially to design
and debate a possible proposed "baseline" congestion-control algorithm?

We can certainly do that detailed discussion by email and come back with a
draft;=A0 I had been planning to do it by email, but recent discussion on rtcweb
made me think I should ask for opinions on this.=A0 Given the structure, if there's
any significant support for "on-the-list" I'll do that.= =A0 Realize though that they may
get pretty long and detailed without really touching on the larger issues being
discussed here.

Right now the bof members to discuss this and propose a draft would be myself,
Harald, Justin,=A0 Stefan Holmer and Magnus.


On 9/19/2011 3:06 AM, Stefan Holmer wrote:
On Mon, Sep 19, 2011 at = 12:10 AM, Randell Jesup <randell-ietf@jesup.org> wrote:
On 9/16/2011 9:26 AM, Magnus Westerlund wr= ote:
1. Section 3: As delay based congestion control has been tried a number
of times and meet with less than stellar success I wonder if you have
any understanding of how this relates to the issues previously encountered:
Do you have any pointers to these earlier attempts? =A0My separate experience
with this class has been extremely successful, though perhaps with a set of
real-world use-cases that don't cover the situations you'= re referring to.
My understanding is that Radvision's NetSense is very similar from their
description of it.


I'm interested in any references you may have as well.


I doubt you'll find many/any, as the first published discussion I saw of delay-sensing
congestion control for RTP data was Radvision's posts about Netsens= e last year
and in their Android webcasts; and=A0 that was pretty detail-free until their recent
blog posts.=A0 There's plenty of un-published experience with them = at various companies
I believe....=A0 Not just Google and Radvision.


=A0

- Stability (especially on short RTTs)
- How it competes with TCP flows, which was a real issues for TCP Vegas
but may be less of an issue here.
Perhaps Google can comment here about what tests they've done= . =A0If anything,
this class of algorithm when faced with aggressive TCP flows will eventually
have problems, because TCP will tend to fill up the buffers at the bottleneck.
Since this algorithm senses buffers starting to fill up, it will tend to back
off before TCP is likely to see a loss event. =A0Now, it's mo= re complex than
that of course, and multiple flows make it more complex still. =A0It's also
sensitive to the adaptation rate of this algorithm and speed of backoff.
If I remember, TFRC tends to back off more slowly than TCP but also increase
more slowly; I suspect Google's algorithm is similar.

As you're saying, it will always be hard for delay based congestion control algorithms to compete with a packet loss based algorithm. The delay based algorithm will detect over-use much earlier than the packet loss based one, and that's basically what we've seen in the tests we've b= een running as well. I do think we would benefit from more tests in this area. For instance, we might want to go with an additive increase approach rather than the current one which is multiplicative, this would likely help improve the algorithms self fairness as well.

Probably; additive increase is probably better, or possible using a fraction-of-
predicted-bandwidth increase.=A0 If you use additive increase, it should probably be
partly proportional to the maximum "good" bandwidth seen duri= ng the connection.
This provides some needed scaling of the ramp-up rate to the absolute magnitude
of bandwidth available.


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

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




--
Henrik Lundin=A0|=A0WebRTC Software Eng=A0|=A0hlundin@google.com=A0|=A0+46 70 646 13 41<= /span>


___________________= ____________________________
rtcweb mailing list
= rtcweb@ietf.org
https://www.ietf= .org/mailman/listinfo/rtcweb
--0015174795c649bfa704ad46d86b-- From oej@edvina.net Mon Sep 19 01:09: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 F029621F8B28 for ; Mon, 19 Sep 2011 01:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Ls9TQzAvplzx for ; Mon, 19 Sep 2011 01:09:22 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 79F4821F8B14 for ; Mon, 19 Sep 2011 01:09:22 -0700 (PDT) Received: from [IPv6:2001:470:1f15:d79:fd1e:4ba7:1d71:283e] (unknown [IPv6:2001:470:1f15:d79:fd1e:4ba7:1d71:283e]) by smtp7.webway.se (Postfix) with ESMTPA id 20CD8754BCE4; Mon, 19 Sep 2011 08:11:43 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <4E76F6E9.4010404@jesup.org> Date: Mon, 19 Sep 2011 10:11:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <16C76AEF-608E-4120-AB3B-995B51168643@edvina.net> References: <4E76E8E8.2050102@ericsson.com> <4E76F6E9.4010404@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 08:09:23 -0000 19 sep 2011 kl. 10:01 skrev Randell Jesup: > A lot of this is > likely to be tied-to or echo the security model and concerns for HTML5 = "installed > webapps". Randell, Do you have any pointers to this security model for further reading? Thanks, /O= From hlundin@google.com Mon Sep 19 01:10: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 EE3FF21F8B34 for ; Mon, 19 Sep 2011 01:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.426 X-Spam-Level: X-Spam-Status: No, score=-103.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4Nr8P9HHak5 for ; Mon, 19 Sep 2011 01:10:42 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCE021F8B28 for ; Mon, 19 Sep 2011 01:10:41 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p8J8CfBu031289 for ; Mon, 19 Sep 2011 01:12:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1316419961; bh=67qwcgG+yQWPNIF6qYhC5X6HZB4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ZZ1gKqqtF4uaqCn54JzeE4UbqlWhhUOFVMx3kOdxPCpX3P5+4fwwAyGU+thMm18mM UgFBtJ8qNbFs6IXr8vvTA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=qRysF3utjJGWiYR29jcORWaA6CF7YHxvjzV8DVkmynW1LDretaIaL/8AcpZHPHMQ1 T9jVjFbQx3+uEw9rkAV+A== Received: from qwa26 (qwa26.prod.google.com [10.241.193.26]) by hpaq5.eem.corp.google.com with ESMTP id p8J8BJDH025038 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 19 Sep 2011 01:12:40 -0700 Received: by qwa26 with SMTP id 26so5391248qwa.0 for ; Mon, 19 Sep 2011 01:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1vi6Bb203EQ5wiY3XBx7p4EDAdcjWr/DDfLTDQgEp88=; b=RqLuzT4nJHChnoHWQPUv0zZb/eV7moAILF0Q8tFUd12SfF94LS504lAjzLatv4Tvhn L5J61ni48srdzZEcCYuQ== Received: by 10.229.235.200 with SMTP id kh8mr1775807qcb.101.1316419959655; Mon, 19 Sep 2011 01:12:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.235.200 with SMTP id kh8mr1775801qcb.101.1316419959398; Mon, 19 Sep 2011 01:12:39 -0700 (PDT) Received: by 10.229.55.139 with HTTP; Mon, 19 Sep 2011 01:12:39 -0700 (PDT) In-Reply-To: References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> Date: Mon, 19 Sep 2011 10:12:39 +0200 Message-ID: From: Henrik Lundin To: Stefan Holmer Content-Type: multipart/alternative; boundary=0016e64ddbe20e227a04ad46e854 X-System-Of-Record: true Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 08:10:44 -0000 --0016e64ddbe20e227a04ad46e854 Content-Type: text/plain; charset=ISO-8859-1 A few comments on the nitty-gritty details inline. /Henrik On Mon, Sep 19, 2011 at 9:06 AM, Stefan Holmer wrote: > On Mon, Sep 19, 2011 at 12:10 AM, Randell Jesup wrote: > >> On 9/16/2011 9:26 AM, Magnus Westerlund wrote: >> >>> As an Individual I do have a few comments and question on this document >>> and its algorithm. >>> >> As said on the call, I'm going to work with Harald (and Justin, and anyone >> else interested) to provide requirements and likely a suggested algorithm. >> At this point, I believe we'll specify the mechanism for telling the other >> side the apparent bandwidth, but leave the algorithm for finding that out >> open for innovation. I plan to propose a baseline algorithm. On the >> sender >> side, I expect to optionally involve the application in deciding how the >> bits are allocated among the channels, and the option to add or remove >> channels based on bandwidth. I expect that we will mandate that if the >> application doesn't choose, the rtcweb/webrtc code will. This is all >> still >> to be hammered out; anyone else interested in helping write the draft >> requirements let me know. >> >> >> 1. Section 3: As delay based congestion control has been tried a number >>> of times and meet with less than stellar success I wonder if you have >>> any understanding of how this relates to the issues previously >>> encountered: >>> >> Do you have any pointers to these earlier attempts? My separate >> experience >> with this class has been extremely successful, though perhaps with a set >> of >> real-world use-cases that don't cover the situations you're referring to. >> My understanding is that Radvision's NetSense is very similar from their >> description of it. >> >> > I'm interested in any references you may have as well. > > >> >> - Stability (especially on short RTTs) >>> - How it competes with TCP flows, which was a real issues for TCP Vegas >>> but may be less of an issue here. >>> >> Perhaps Google can comment here about what tests they've done. If >> anything, >> this class of algorithm when faced with aggressive TCP flows will >> eventually >> have problems, because TCP will tend to fill up the buffers at the >> bottleneck. >> Since this algorithm senses buffers starting to fill up, it will tend to >> back >> off before TCP is likely to see a loss event. Now, it's more complex than >> that of course, and multiple flows make it more complex still. It's also >> sensitive to the adaptation rate of this algorithm and speed of backoff. >> If I remember, TFRC tends to back off more slowly than TCP but also >> increase >> more slowly; I suspect Google's algorithm is similar. >> > > As you're saying, it will always be hard for delay based congestion control > algorithms to compete with a packet loss based algorithm. The delay based > algorithm will detect over-use much earlier than the packet loss based one, > and that's basically what we've seen in the tests we've been running as > well. I do think we would benefit from more tests in this area. For > instance, we might want to go with an additive increase approach rather than > the current one which is multiplicative, this would likely help improve the > algorithms self fairness as well. > > >> Web Browser traffic can be especially aggressive at filling large buffers >> at >> a bottleneck router, and will become more so as the initial window of 10 >> rolls out. >> >> >> >> 2. Section 3, I don't see any discussion of the startup issue. Is my >>> assumption correct, that you will simply start at some rate and then >>> adapt from that? >>> >> Startup is an open question; you have to start somewhere, and there's >> no way to always get the start "right". History of previous sessions may >> be useful here; it's theoretically possible to use perhaps some of the >> ICE negotiation for a first-level guess or we could send an initial packet >> train and measure dispersion. But that's just speculation; history can be >> very wrong if you've changed networks or the other person has a very >> different >> network than the last call (or last call with that person). I'm not sure >> if >> we should mandate something here, or use something more open to encourage >> innovation. >> >> >> 3. Section 3, I guess this mechanism would get significant issues with >>> any sender side transmission filtering. Burst transmitting I-frames over >>> a network, especially for high resolution video can easily result in >>> packet loss in switch fabrics if there is any cross traffic in the >>> switch fabric. Thus having a bit of send filtering for frame >>> transmission is a good idea. Are I understanding it correctly that this >>> could result in over-use indication if I has such mechanism which >>> filters a packet to a slower transmission rate than what a single or >>> small burst can achieve over the same path? >>> >> Well, such send filtering amounts to a bottleneck in practice at the >> sending >> node, so that actually might be ok. I'm assuming you're talking about >> pacing >> the actual send()s of large dumps of fragmented IDRs/i-frames to some >> maximum packet rate or bitrate (almost the same thing). I think the >> algorithm >> looks at all the fragments and the time they came in to calculate the >> bandwidth. >> If so, it would only think it was over-bandwidth if the pacing slowed them >> down >> to less than the actual bottleneck rate; I suspect this would rarely be >> the case >> outside of high-bandwidth LANs at very high resolutions. > > Yes, the algorithm looks at the arrival of complete frames. And you are right, Randell, as long as you do not spread the packets more than the bottleneck link does, the over-use detector won't trigger. > >> >> >> >>> 4. Section 4. >>> >>> "This algorithm is run every time a receive report arrives at the >>> sender, which will happen [[how often do we expect? and why?]]. If >>> no receive report is recieved within [[what timeout?]], the algorithm >>> will take action as if all packets in the interval have been lost. >>> [[does that make sense?]]" >>> >>> The transmission of receiver reports is highly dependent on RTP profile, >>> the RTCP bandwidth, trr-int parameter and any feedback events. >>> >>> If I start with assuming AVPF which seems reasonable in most browser to >>> browser case with our current proposals for RTP support. Then if there >>> are no feedback events the transmission of receiver reports will occur >>> as often as the bandwidth allows, but no more often than the value of >>> trr-int parameter. >>> >>> Here is might be worth mentioning that I do expect trr-int to be set to >>> avoid RTCP reporting to often due to the relatively high RTCP bandwidth >>> values that will be set due to the multiplexing of audio and video in a >>> single RTP session. Thus avoiding that RTCP rates are as high or larger >>> than the audio streams they report in steady state. >>> >> Agreed. This is where my plans to suggest a baseline algorithm that melds >> the reception data of all the streams in the PeerConnection may be a >> significant advantage over doing bandwidth estimation on each stream >> independently. We'll see if I can make the idea work, but there are some >> significant advantages if it does. If not, we can estimate in each >> channel >> independently as per the Google algorithm. > > >> You can also use rtcp-fb PLI/etc events to hang these reports off of, >> increasing >> the frequency they get through with minimal extra bandwidth use. >> >> >> >> When feedback events occur the stack will have the choice of sending a >>> RTCP RR, that is a choice provided due to the reduced size RTCP >>> specification included. But if the loss cumulative count diff is >>> non-zero it might be worth mandating that the RR/SR is included in any >>> such feedback RTCP packet. >>> >> Exactly - or a TMMBR with the results of the receiver-side bandwidth >> calculations. >> >> >> For that reason causing a feedback event when there is losses and >>> schedule them using the early algorithm may be a good choice to ensure >>> timely reporting of any loss. >>> >>> If one uses AVP then the RTCP timing rules will give you when you >>> transmit RTCP feeedback and thus the parameterization becomes central >>> here. A clear issue is if people uses the minimal interval of 5 seconds >>> or the 360/Session_BW(in kbps). I would note that 5 seconds is very long >>> in adaptation situations. >>> >> >> Yes. > > In the proposed algorithm, the RTCP interval adds to the system response time. The response time governs the bandwidth increase rate so that the step into over-use will have a limited delay build-up before it can be detected and mitigated. Thus, a long RTCP interval results in a slow adaptation, but it should still be stable. > >> >> >> I think the timeout should be based on the RTT and possible reporting >>> rate. But there clearly need to be some upper limit, either explicitly >>> or mandating RTCP bandwidth rates. >>> >>> 5. Section 4: >>> "We motivate the packet loss thresholds by noting that if we have >>> small amount of packet losses due to over-use, that amount will soon >>> increase if we don't adjust our bit rate. Therefore we will soon >>> enough reach above the 10 % threshold and adjust As(i). However if >>> the packet loss rate does not increase, the losses are probably not >>> related to self-induced channel over-use and therefore we should not >>> react on them." >>> >>> I am personally worried that a packet loss threshold of 10% is so high >>> that it might push a lot of other traffic out of the way. Thus being >>> quite aggressive towards other flows. >>> >> Yes; I want to visit these tuning parameters and how packet loss is >> reacted to and at least tweak it. >> >> >> TCP has this relation between the average packet loss rate and the >>> highest sustainable rate which can be interpreted as TCP gets more >>> sensitive to loss the higher the average data rate becomes. Thus in >>> certain situation the sender side algorithm part will be extremely >>> aggressive in pushing TCP out of the way. The receiver part may >>> compensate for this pretty well in a number of situations. >>> >>> But, I do wonder why for example the A(i) isn't bounded to be between >>> TFRC's rate and some multiple of TFRC rate, not unbounded by other than >>> the receiver side algorithm. >>> >> Good question; we should look into it. >> >> > The idea behind those bounds is that if we believe in the TFRC equation, we > should be able to transmit with that rate while still being fair to TCP. > > >> >> I do understand this document is to start a discussion. But I think we >>> need to be sensitive to that it is difficult to get even something that >>> is self-fair over the wide range of conditions the Internet has to >>> provide. >>> >>> Thus I would appreciate what issues with for example TFRC that you >>> attempt to fix with the various new components you add. >>> >> Magnus: Welcome to my little congestion-control bof... :-) >> >> > I'm interested in continued discussions as well. > > >> -- >> Randell Jesup >> randell-ietf@jesup.org >> >> >> ______________________________**_________________ >> 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 > > -- Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41 --0016e64ddbe20e227a04ad46e854 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A few comments on the nitty-gritty details inline.

/Henr= ik



On Mon, Sep = 19, 2011 at 9:06 AM, Stefan Holmer <holmer@google.com> wrote:
On Mon, Sep 19, 2011 at 12:10 AM, Randell Jesup <randell-ietf@jesup= .org> wrote:
On 9/16/2011 9:26 AM, Magnus Westerlund wrote:
As an Individual I do have a few comments and question on this document
and its algorithm.
As said on the call, I'm going to work with Harald (and Justin, and any= one
else interested) to provide requirements and likely a suggested algorithm.<= br> At this point, I believe we'll specify the mechanism for telling the ot= her
side the apparent bandwidth, but leave the algorithm for finding that out open for innovation. =A0I plan to propose a baseline algorithm. =A0On the s= ender
side, I expect to optionally involve the application in deciding how the bits are allocated among the channels, and the option to add or remove
channels based on bandwidth. =A0I expect that we will mandate that if the application doesn't choose, the rtcweb/webrtc code will. =A0This is all= still
to be hammered out; anyone else interested in helping write the draft
requirements let me know.


1. Section 3: As delay based congestion control has been tried a number
of times and meet with less than stellar success I wonder if you have
any understanding of how this relates to the issues previously encountered:=
Do you have any pointers to these earlier attempts? =A0My separate experien= ce
with this class has been extremely successful, though perhaps with a set of=
real-world use-cases that don't cover the situations you're referri= ng to.
My understanding is that Radvision's NetSense is very similar from thei= r
description of it.


I&#= 39;m interested in any references you may have as well.
=A0

- Stability (especially on short RTTs)
- How it competes with TCP flows, which was a real issues for TCP Vegas
but may be less of an issue here.
Perhaps Google can comment here about what tests they've done. =A0If an= ything,
this class of algorithm when faced with aggressive TCP flows will eventuall= y
have problems, because TCP will tend to fill up the buffers at the bottlene= ck.
Since this algorithm senses buffers starting to fill up, it will tend to ba= ck
off before TCP is likely to see a loss event. =A0Now, it's more complex= than
that of course, and multiple flows make it more complex still. =A0It's = also
sensitive to the adaptation rate of this algorithm and speed of backoff. If I remember, TFRC tends to back off more slowly than TCP but also increas= e
more slowly; I suspect Google's algorithm is similar.
<= div>
As you're saying, it will always be hard for d= elay based congestion control algorithms to compete with a packet loss base= d algorithm. The delay based algorithm will detect over-use much earlier th= an the packet loss based one, and that's basically what we've seen = in the tests we've been running as well. I do think we would benefit fr= om more tests in this area. For instance, we might want to go with an addit= ive increase approach rather than the current one which is multiplicative, = this would likely help improve the algorithms self fairness as well.


Web Browser traffic can be especially aggressive at filling large buffers a= t
a bottleneck router, and will become more so as the initial window of 10 rolls out.



2. Section 3, I don't see any discussion of the startup issue. Is my assumption correct, that you will simply start at some rate and then
adapt from that?
Startup is an open question; you have to start somewhere, and there's no way to always get the start "right". =A0History of previous se= ssions may
be useful here; it's theoretically possible to use perhaps some of the<= br> ICE negotiation for a first-level guess or we could send an initial packet<= br> train and measure dispersion. =A0But that's just speculation; history c= an be
very wrong if you've changed networks or the other person has a very di= fferent
network than the last call (or last call with that person). =A0I'm not = sure if
we should mandate something here, or use something more open to encourage innovation.


3. Section 3, I guess this mechanism would get significant issues with
any sender side transmission filtering. Burst transmitting I-frames over a network, especially for high resolution video can easily result in
packet loss in switch fabrics if there is any cross traffic in the
switch fabric. Thus having a bit of send filtering for frame
transmission is a good idea. Are I understanding it correctly that this
could result in over-use indication if I has such mechanism which
filters a packet to a slower transmission rate than what a single or
small burst can achieve over the same path?
Well, such send filtering amounts to a bottleneck in practice at the sendin= g
node, so that actually might be ok. =A0I'm assuming you're talking = about pacing
the actual send()s of large dumps of fragmented IDRs/i-frames to some
maximum packet rate or bitrate (almost the same thing). =A0I think the algo= rithm
looks at all the fragments and the time they came in to calculate the bandw= idth.
If so, it would only think it was over-bandwidth if the pacing slowed them = down
to less than the actual bottleneck rate; I suspect this would rarely be the= case
outside of high-bandwidth LANs at very high resolutions.
=
Yes, the algorithm looks at the arrival = of complete frames. And you are right, Randell, as long as you do not sprea= d the packets more than the bottleneck link does, the over-use detector won= 't trigger.
=A0




4. Section 4.

"This algorithm is run every time a receive report arrives at the
=A0 =A0sender, which will happen [[how often do we expect? and why?]]. =A0= If
=A0 =A0no receive report is recieved within [[what timeout?]], the algorit= hm
=A0 =A0will take action as if all packets in the interval have been lost.<= br> =A0 =A0[[does that make sense?]]"

The transmission of receiver reports is highly dependent on RTP profile, the RTCP bandwidth, trr-int parameter and any feedback events.

If I start with assuming AVPF which seems reasonable in most browser to
browser case with our current proposals for RTP support. Then if there
are no feedback events the transmission of receiver reports will occur
as often as the bandwidth allows, but no more often than the value of
trr-int parameter.

Here is might be worth mentioning that I do expect trr-int to be set to
avoid RTCP reporting to often due to the relatively high RTCP bandwidth
values that will be set due to the multiplexing of audio and video in a
single RTP session. Thus avoiding that RTCP rates are as high or larger
than the audio streams they report in steady state.
Agreed. =A0This is where my plans to suggest a baseline algorithm that meld= s
the reception data of all the streams in the PeerConnection may be a
significant advantage over doing bandwidth estimation on each stream
independently. =A0We'll see if I can make the idea work, but there are = some
significant advantages if it does. =A0If not, we can estimate in each chann= el
independently as per the Google algorithm.=A0

You can also use rtcp-fb PLI/etc events to hang these reports off of, incre= asing
the frequency they get through with minimal extra bandwidth use.



When feedback events occur the stack will have the choice of sending a
RTCP RR, that is a choice provided due to the reduced size RTCP
specification included. But if the loss cumulative count diff is
non-zero it might be worth mandating that the RR/SR is included in any
such feedback RTCP packet.
Exactly - or a TMMBR with the results of the receiver-side bandwidth
calculations.


For that reason causing a feedback event when there is losses and
schedule them using the early algorithm may be a good choice to ensure
timely reporting of any loss.

If one uses AVP then the RTCP timing rules will give you when you
transmit RTCP feeedback and thus the parameterization becomes central
here. A clear issue is if people uses the minimal interval of 5 seconds
or the 360/Session_BW(in kbps). I would note that 5 seconds is very long in adaptation situations.

Yes.
In the proposed a= lgorithm, the RTCP interval adds to the system response time. The response = time governs the bandwidth increase rate so that the step into over-use wil= l have a limited delay build-up before it can be detected and mitigated. Th= us, a long RTCP interval results in a slow adaptation, but it should still = be stable.
=A0



I think the timeout should be based on the RTT and possible reporting
rate. But there clearly need to be some upper limit, either explicitly
or mandating RTCP bandwidth rates.

5. Section 4:
"We motivate the packet loss thresholds by noting that if we have
=A0 =A0small amount of packet losses due to over-use, that amount will soo= n
=A0 =A0increase if we don't adjust our bit rate. =A0Therefore we will = soon
=A0 =A0enough reach above the 10 % threshold and adjust As(i). =A0However = if
=A0 =A0the packet loss rate does not increase, the losses are probably not=
=A0 =A0related to self-induced channel over-use and therefore we should no= t
=A0 =A0react on them."

I am personally worried that a packet loss threshold of 10% is so high
that it might push a lot of other traffic out of the way. Thus being
quite aggressive towards other flows.
Yes; I want to visit these tuning parameters and how packet loss is
reacted to and at least tweak it.


TCP has this relation between the average packet loss rate and the
highest sustainable rate which can be interpreted as TCP gets more
sensitive to loss the higher the average data rate becomes. Thus in
certain situation the sender side algorithm part will be extremely
aggressive in pushing TCP out of the way. The receiver part may
compensate for this pretty well in a number of situations.

But, I do wonder why for example the A(i) isn't bounded to be between TFRC's rate and some multiple of TFRC rate, not unbounded by other than=
the receiver side algorithm.
Good question; we should look into it.


=
The idea behind those bounds is that if we believe i= n the TFRC equation, we should be able to transmit with that rate while sti= ll being fair to TCP.=A0
=A0

I do understand this document is to start a discussion. But I think we
need to be sensitive to that it is difficult to get even something that
is self-fair over the wide range of conditions the Internet has to provide.=

Thus I would appreciate what issues with for example TFRC that you
attempt to fix with the various new components you add.
Magnus: Welcome to my little congestion-control bof... :-)


I'm interested= in continued discussions as well.=A0
=A0
=
--
Randell Jesup
randell-ietf@je= sup.org


_______________________________________________
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




--
Henrik Lundin=A0|=A0WebRTC Software Eng=A0|=A0hlundin@google.com=A0|=A0+46 70 646 13 41<= /span>


--0016e64ddbe20e227a04ad46e854-- From tim@phonefromhere.com Mon Sep 19 01: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 4BA5021F8B2E for ; Mon, 19 Sep 2011 01:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ts+7tt1clEIo for ; Mon, 19 Sep 2011 01:19:06 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 77B2021F8B28 for ; Mon, 19 Sep 2011 01:19:06 -0700 (PDT) Received: from [10.14.26.192] (095-097-078-010.static.chello.nl [95.97.78.10]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id EE27E37A902; Mon, 19 Sep 2011 09:34:17 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: <4E76F544.1040108@jesup.org> Date: Mon, 19 Sep 2011 09:21:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <382A4C80-101D-4FD0-8473-04679248ACFB@phonefromhere.com> References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <4E76F544.1040108@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 08:19:07 -0000 On 19 Sep 2011, at 08:54, Randell Jesup wrote: > Open question to the list: should the congestion-control-geeks discuss = here on the=20 > list the nitty-gritty details required to build the requirements and = especially to design > and debate a possible proposed "baseline" congestion-control = algorithm? >=20 > We can certainly do that detailed discussion by email and come back = with a=20 > draft; I had been planning to do it by email, but recent discussion = on rtcweb > made me think I should ask for opinions on this. Given the structure, = if there's > any significant support for "on-the-list" I'll do that. Realize = though that they may > get pretty long and detailed without really touching on the larger = issues being > discussed here. >=20 > Right now the bof members to discuss this and propose a draft would be = myself, > Harald, Justin, Stefan Holmer and Magnus. >=20 I'd like to lurk on any BoF list, if I may, but I have a feeling that congestion control isn't quite such a = self-contained problem as forming a BoF list might imply. Roughly, my argument is that any modern congestion control for RTC needs = to involve the application and the codec. Here's an example: I'm in a video conference with 4 other people and I'm exceeding = the available downlink bandwidth. What I want is that the video degrades (framerate of quality) = without _any_ degradation of the video. I might even want to drop all the video but keep the audio = and screenshare alive. Conversely if I'm watching an ice hockey game - I'd rather lose = audio quality than frame-rate. But in _both_ cases I'd like the app to try and tweak the encoder params = to get within the available bandwidth=20 before we start injecting delay or dropping frames. So my proposal is that the web app is given a chance to get within the = available bandwidth=20 before the system starts putting hard constraints on the RTP level. All of which makes it something we need to discuss in a holistic fashion = with the rest of the API. Tim. From hlundin@google.com Mon Sep 19 01:26: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 712FF21F87C2 for ; Mon, 19 Sep 2011 01:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.092 X-Spam-Level: X-Spam-Status: No, score=-105.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuzT5is5M0tC for ; Mon, 19 Sep 2011 01:26:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 435EC21F84AD for ; Mon, 19 Sep 2011 01:26:45 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p8J8T7nC014154 for ; Mon, 19 Sep 2011 01:29:07 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1316420947; bh=orUj2kb96oRoFL6nPBBYEh7557A=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=BC9FBTrPeOmlBSAswDCR5hw9lXuQimm7uATW5iyroYqXFkfv4UrKFnMAJAOOlE1BE 1UDneGJg6ng1EGm1ARV3Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=a9Mul+q91q/GJp3Ft7xon4xfMJqTZAvQZKjPexpb+12zBrPn8Py9j7Nylfju9sb4s 37UBP1YGfZJtSY/zQeg1Q== Received: from qyk31 (qyk31.prod.google.com [10.241.83.159]) by hpaq13.eem.corp.google.com with ESMTP id p8J8T47V020965 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 19 Sep 2011 01:29:05 -0700 Received: by qyk31 with SMTP id 31so5079494qyk.15 for ; Mon, 19 Sep 2011 01:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Nmk0g1AnXW4fsMR6UODlcFOdLHJ/TuRalbknUNJZdWA=; b=xeKJvi8hrIKQlWisPZpCl2e38vNUqeHKMvw7vZYlaRAPSW8XcFtz53ljswMg3WJMRG oc50genXKooy1q/n/A8w== Received: by 10.229.235.200 with SMTP id kh8mr1787675qcb.101.1316420943520; Mon, 19 Sep 2011 01:29:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.235.200 with SMTP id kh8mr1787664qcb.101.1316420943139; Mon, 19 Sep 2011 01:29:03 -0700 (PDT) Received: by 10.229.55.139 with HTTP; Mon, 19 Sep 2011 01:29:03 -0700 (PDT) In-Reply-To: <382A4C80-101D-4FD0-8473-04679248ACFB@phonefromhere.com> References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <4E76F544.1040108@jesup.org> <382A4C80-101D-4FD0-8473-04679248ACFB@phonefromhere.com> Date: Mon, 19 Sep 2011 10:29:03 +0200 Message-ID: From: Henrik Lundin To: Tim Panton Content-Type: multipart/alternative; boundary=0016e64ddbe2b0d50604ad47220a X-System-Of-Record: true Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 08:26:46 -0000 --0016e64ddbe2b0d50604ad47220a Content-Type: text/plain; charset=ISO-8859-1 Tim, The problem that we are trying to attack with the proposal is perhaps better described as "available bandwidth estimation" rather than congestion control. I _would_ like to try and separated it from codecs. The bandwidth estimator should inform the sender of the current feasible rate between two endpoints, and it should then be up to the sending client (application, codecs, channel coding, etc) to figure out a way to stay within that limit, while maintaining an acceptable quality for the use-case at hand. /Henrik On Mon, Sep 19, 2011 at 10:21 AM, Tim Panton wrote: > On 19 Sep 2011, at 08:54, Randell Jesup wrote: > > > Open question to the list: should the congestion-control-geeks discuss > here on the > > list the nitty-gritty details required to build the requirements and > especially to design > > and debate a possible proposed "baseline" congestion-control algorithm? > > > > We can certainly do that detailed discussion by email and come back with > a > > draft; I had been planning to do it by email, but recent discussion on > rtcweb > > made me think I should ask for opinions on this. Given the structure, if > there's > > any significant support for "on-the-list" I'll do that. Realize though > that they may > > get pretty long and detailed without really touching on the larger issues > being > > discussed here. > > > > Right now the bof members to discuss this and propose a draft would be > myself, > > Harald, Justin, Stefan Holmer and Magnus. > > > > I'd like to lurk on any BoF list, if I may, > but I have a feeling that congestion control isn't quite such a > self-contained problem > as forming a BoF list might imply. > > Roughly, my argument is that any modern congestion control for RTC needs to > involve the application > and the codec. > > Here's an example: > I'm in a video conference with 4 other people and I'm exceeding the > available downlink > bandwidth. What I want is that the video degrades (framerate of quality) > without _any_ degradation > of the video. I might even want to drop all the video but keep the audio > and screenshare alive. > Conversely if I'm watching an ice hockey game - I'd rather lose > audio quality than frame-rate. > > But in _both_ cases I'd like the app to try and tweak the encoder params to > get within the available bandwidth > before we start injecting delay or dropping frames. > > So my proposal is that the web app is given a chance to get within the > available bandwidth > before the system starts putting hard constraints on the RTP level. > > All of which makes it something we need to discuss in a holistic fashion > with the rest of the API. > > Tim. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41 --0016e64ddbe2b0d50604ad47220a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tim,

The problem that we are trying to attack with the p= roposal is perhaps better described as "available bandwidth estimation= " rather than congestion control. I _would_ like to try and separated = it from codecs. The bandwidth estimator should inform the sender of the cur= rent feasible rate between two endpoints, and it should then be up to the s= ending client (application, codecs, channel coding, etc) to figure out a wa= y to stay within that limit, while maintaining an acceptable quality for th= e use-case at hand.

/Henrik



On Mon, Sep 19, 2011 at 10:21 AM, Tim Panton <tim@phonefromhere.com>= wrote:
On 19 Sep 2011, at 08:54,= Randell Jesup wrote:

> Open question to the list: should the congestion-control-geeks discuss= here on the
> list the nitty-gritty details required to build the requirements and e= specially to design
> and debate a possible proposed "baseline" congestion-control= algorithm?
>
> We can certainly do that detailed discussion by email and come back wi= th a
> draft; =A0I had been planning to do it by email, but recent discussion= on rtcweb
> made me think I should ask for opinions on this. =A0Given the structur= e, if there's
> any significant support for "on-the-list" I'll do that. = =A0Realize though that they may
> get pretty long and detailed without really touching on the larger iss= ues being
> discussed here.
>
> Right now the bof members to discuss this and propose a draft would be= myself,
> Harald, Justin, =A0Stefan Holmer and Magnus.
>

I'd like to lurk =A0on any BoF list, if I may,
but I have a feeling that congestion control isn't quite such a self-co= ntained problem
as forming a BoF list might imply.

Roughly, my argument is that any modern congestion control for RTC needs to= involve the application
and the codec.

Here's an example:
=A0 =A0 =A0 =A0I'm in a video conference with 4 other people and I'= ;m exceeding the available downlink
bandwidth. What I want is that the video degrades (framerate of quality) wi= thout _any_ degradation
of the video. I might even want to drop all the video but keep the audio an= d screenshare alive.
=A0 =A0 =A0 =A0Conversely if I'm watching an ice hockey game - I'd= rather lose audio quality than frame-rate.

But in _both_ cases I'd like the app to try and tweak the encoder param= s to get within the available bandwidth
before we start injecting delay or dropping frames.

So my proposal is that the web app is given a chance to get within the avai= lable bandwidth
before the system starts putting hard constraints on the RTP level.

All of which makes it something we need to discuss in a holistic fashion wi= th the rest of the API.

Tim.

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



--
=
Henrik Lundin=A0|=A0WebRTC Software Eng=A0|=A0hlundin@google.com=A0|=A0+46 70 64= 6 13 41


--0016e64ddbe2b0d50604ad47220a-- From magnus.westerlund@ericsson.com Mon Sep 19 02:20: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 725B621F8B6C for ; Mon, 19 Sep 2011 02:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.507 X-Spam-Level: X-Spam-Status: No, score=-106.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 OWZke-DzpuYb for ; Mon, 19 Sep 2011 02:20:54 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB6221F8B67 for ; Mon, 19 Sep 2011 02:20:54 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-eb-4e770a043d62 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BC.11.20773.40A077E4; Mon, 19 Sep 2011 11:23:16 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Mon, 19 Sep 2011 11:23:15 +0200 Message-ID: <4E770A02.6070009@ericsson.com> Date: Mon, 19 Sep 2011 11:23:14 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Olle E. Johansson" References: <4E76E8E8.2050102@ericsson.com> <504F8A52-0D1E-4334-A77C-14BCB4349F79@edvina.net> In-Reply-To: <504F8A52-0D1E-4334-A77C-14BCB4349F79@edvina.net> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 09:20:55 -0000 Olle, On 2011-09-19 09:32, Olle E. Johansson wrote: >> Thus the question to the WG is the following. >> >> 1) Do you support or object the inclusion of use case A, B or Both in >> our Use case document? > Yes. Can you please clarify if Yes, means Both cases? >> >> 2) Do you have additional comments for or against either of the use cases? > Nitpick: Case A also requires user consent. Fully agree. Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Sep 19 02:30: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 C725F21F8B39 for ; Mon, 19 Sep 2011 02:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.508 X-Spam-Level: X-Spam-Status: No, score=-106.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 4TsZbzzvOdE2 for ; Mon, 19 Sep 2011 02:30:28 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id AF7A821F8B28 for ; Mon, 19 Sep 2011 02:30:21 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-d0-4e770c3bb9aa Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FC.F2.20773.B3C077E4; Mon, 19 Sep 2011 11:32:43 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Mon, 19 Sep 2011 11:32:43 +0200 Message-ID: <4E770C3B.3020402@ericsson.com> Date: Mon, 19 Sep 2011 11:32:43 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E76E8E8.2050102@ericsson.com> In-Reply-To: <4E76E8E8.2050102@ericsson.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 09:30:28 -0000 As Individual On 2011-09-19 09:02, Magnus Westerlund wrote: > WG, > > There where some discussion in the Interim meeting last week about a > Screen/Application/Desktop sharing support use case. My take away from > the discussion is that this use cases is likely well enough understood > to actually start a consensus call now. However, to us WG chairs it was > clear that the use case in question actually needs to be split into two > parts. > > A) Where the RTCWEB enabled browser can use a local application window, > the whole desktop or a Screen as a media source that can be encoded and > transported over the peerConnection for displaying/playback at the peer. > > B) Where a remote peer can provide one or more input types such as mouse > and keyboard to control the local system, not only including the > browser, but also other operating system resources. This clearly can > only happen after additional consent, most likely on a per occasion > consent. > > My interpretation is that A only allows for application sharing in > conferencing contexts, like in the WEBEX session the Interim meeting was > held with where we shared slides. Where the combination of A and B is > providing for VNC/Remote desktop. > > Thus the question to the WG is the following. > > 1) Do you support or object the inclusion of use case A, B or Both in > our Use case document? I think A only should be dealt with now. The reason being that handling a local synthetic source is from this WGs standardization almost without additional requirements. There is a bit of extra API demands. There is the extra dimension of consent, where I think this type needs user consent every time to pick the whole screen or a particular application instance. The only real question for us would be if the application output is fine to encode using the video codecs that are proposed or if the media encoding uses should be specialized for synthetic content? As a question on the requirement I would also ask is sound output from a particular application also should be included? From a requirement point of view it doesn't seem difficult. Implementation may be far from easy. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From jmillan@aliax.net Mon Sep 19 03:15: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 78AB721F8B7F for ; Mon, 19 Sep 2011 03:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRsqmkZuNK-X for ; Mon, 19 Sep 2011 03:15:15 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7199021F8B7A for ; Mon, 19 Sep 2011 03:15:15 -0700 (PDT) Received: by iaby26 with SMTP id y26so6540477iab.31 for ; Mon, 19 Sep 2011 03:17:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.66.14 with SMTP id l14mr3827459ibi.69.1316427457949; Mon, 19 Sep 2011 03:17:37 -0700 (PDT) Received: by 10.231.36.201 with HTTP; Mon, 19 Sep 2011 03:17:37 -0700 (PDT) In-Reply-To: <4E76E078.5020708@jesup.org> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> Date: Mon, 19 Sep 2011 12:17:37 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: Randell Jesup Content-Type: multipart/alternative; boundary=00151773e02800ef6804ad48a71c Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 10:15:16 -0000 --00151773e02800ef6804ad48a71c Content-Type: text/plain; charset=ISO-8859-1 Hi, 2011/9/19 Randell Jesup > +1 (comments below in-line) > > On 9/16/2011 4:43 PM, Ted Hardie wrote: > > On Thu, Sep 15, 2011 at 8:23 PM, Jim McEachern > jim.mceachern@genband.**com >> wrote: >> >> Hadriel, >> Well said. >> >> Your closing paragraph sums it up nicely in my mind. >> >> >> The only thing we need to do for rtcweb is make sure the RTP >> library built into the browser supports media in such a way that >> it can communicate with other RTP peers at a media plane, >> regardless of what signaling protocol those peers might be using, >> preferably without going through media gateways. And ... we need >> to make sure it's possible to use SIP on the rtcweb server.... >> >> >> >> I think there is more to it than this for it to be a success. We have to >> make sure that it is relatively easy to adopt rtcweb in javascript >> applications. The way we've discussed that in the past was "2 party video >> chat in 20 lines of javascript". If a novel signalling protocol is created >> every time, that won't be a practical choice. Even if the signalling is >> segmented into libraries, the app will have to download the one in use by a >> particular website, potentially every time. This is better than a plugin in >> some ways and potentially actually worse in others. >> > > I agree whole-heartedly. My (and I'll say Mozilla's) position is that we > believe that while enabling unique new signalling and negotiation makes > interesting new applications possible, we also must make sure that this > ability is equally available to a (say) games developer who wants to add > voice or video chat to their game without having to learn or understand 20 > years of discussions and experience with signalling and media protocols. > > As far as I know, this is achieved by a user level API regardless of the signalling controller nature; browser built-in or JS stack, which serves as an abstraction of the library underlying ins and outs. > The point was made repeatedly when I explained this primary area of > contention that we want it to be easy to use by the "little guys", and that > even if signalling was a downloaded JS library, you'd end up with a wild > mixture of old versions in use, which may complicate interop/federation > (plus the overhead to pull them down, and some possible security issues). I would say that Mixture of old versions and the possible security issues are problems to face in any case. >> We also have to make sure that the resulting application does not flood or >> fry the network. That means it will have to have real congestion control >> mechanisms. Trusting the javascript application for that has some real >> issues which we've already discussed. Splitting signaling and congestion >> control isn't a lot better. If congestion control at the network level is >> managed by the browser but signalling is in the javascript, then information >> about that state has to pass into the JS application, so it can manage the >> signalling. That makes the APIs more complex and runs the risk that a naive >> javascript application will not adjust to the congestion control >> requirements at all. >> > > I think we do want to optionally include the JS application in the > decisions about bit allocation, but handle it automatically for most cases. > A class of complex WebRTC apps will want to be able to allocate the bits > themselves, and in some cases drop or add streams (or switch operation > modes) in response to bandwidth changes. Details to be determined; I plan > to make a proposal on this. However, unless you go out of your way none of > this will impinge on your straightforward WebRTC app. > > > >> The early web took off in part because of the ease of embedding things >> like images (compared to gopher, for example) into rich content. We have >> the opportunity to create native web applications with much richer and more >> interactive experiences with rtcweb, but if it is not easy to do, it won't >> have the same impact. If this is something that can be done only by folks >> who can roll their own signalling protocol, it's dead, because the number of >> content authors is too small. If it even requires selecting among an >> unbounded set of variously maintained libraries , it will be frustrating for >> the developer of simple applications. At that level, the existing plugins >> will simply be more stable and better known. >> > > +1 > > > >> Providing baseline APIs into a well-known signaling capability seems to me >> far more likely to result in a real flowering of rtcweb content. That's why >> I want it. >> >> Just my two cents, not taken from any hat, >> >> Ted >> >> Regards, > > -- > Randell Jesup > randell-ietf@jesup.org > > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --00151773e02800ef6804ad48a71c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
This is where you get it = wrong. You are pushing the decision to the user. They have to evaluate = the network
their browser is currently attached = to and make a decision on what kind of security = they 
need for this particular network. Even in the = office, the iPad on your desk might be connected
to 3G because = it lost contact with the wifi. 

I think we = can not require that users are able to perform a security evaluation of = each and
every network the device their browser is running on = connects to. Make it secure by default.
I mean, this is the = year 2011 and we do have CPUs that can handle it. People walk = around
with dual core in their = pockets.

/O
= --Apple-Mail=_ED103BF4-3318-43D9-833A-12F8EC55983C-- From ibc@aliax.net Sat Sep 24 06:35: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 A3C2121F8B48 for ; Sat, 24 Sep 2011 06:35:13 -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.035, 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 ESKLZecwLNWP for ; Sat, 24 Sep 2011 06:35:13 -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 0511321F8B46 for ; Sat, 24 Sep 2011 06:35:12 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so2417851vcb.31 for ; Sat, 24 Sep 2011 06:37:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.171.208 with SMTP id i16mr294807vcz.122.1316871468884; Sat, 24 Sep 2011 06:37:48 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Sat, 24 Sep 2011 06:37:43 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Sat, 24 Sep 2011 06:37:43 -0700 (PDT) In-Reply-To: <7DEACFFC-8AF3-4450-8844-FF6E187AE4D2@edvina.net> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> <7DEACFFC-8AF3-4450-8844-FF6E187AE4D2@edvina.net> Date: Sat, 24 Sep 2011 15:37:43 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=0016363107411e24bc04adb008b7 Cc: "" , Colin Perkins Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Sep 2011 13:35:13 -0000 --0016363107411e24bc04adb008b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi. I dont mean that security decisions are taken by the final user, but by the service provider. If it is a local intranet or the users access the intranet via a secure vpn, security can be relaxed ans the site provider could determine that plain rtp is allowed. El 24/09/2011 13:51, "Olle E. Johansson" escribi=C3=B3: > > 22 sep 2011 kl. 13:08 skrev I=C3=B1aki Baz Castillo: > >> I can understand that some requirements can be imposed to RTCweb >> environments in the media plane, but try at least to make it >> compatible with VoIP networks out there. For example, requiring SRTP o >> ZRTP could make sense (anyhow I don't see why that should be a >> requirement in a local intranet in which plain-RTP is already used for >> SIP communication). > > This is where you get it wrong. You are pushing the decision to the user. They have to evaluate the network > their browser is currently attached to and make a decision on what kind o= f security they > need for this particular network. Even in the office, the iPad on your desk might be connected > to 3G because it lost contact with the wifi. > > I think we can not require that users are able to perform a security evaluation of each and > every network the device their browser is running on connects to. Make it secure by default. > I mean, this is the year 2011 and we do have CPUs that can handle it. People walk around > with dual core in their pockets. > > /O --0016363107411e24bc04adb008b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi. I dont mean that security decisions are taken by the final user, but= by the service provider. If it is a local intranet or the users access the= intranet via a secure vpn, security can be relaxed ans the site provider c= ould determine that plain rtp is allowed.

El 24/09/2011 13:51, "Olle E. Johansson&quo= t; <oej@edvina.net> escribi=C3= =B3:
>
> 22 sep 2011 kl. 13:08 skrev I=C3= =B1aki Baz Castillo:
>
>> I can understand that some requirements can be imposed to= RTCweb
>> environments in the media plane, but try at least to ma= ke it
>> compatible with VoIP networks out there. For example, req= uiring SRTP o
>> ZRTP could make sense (anyhow I don't see why that should be a=
>> requirement in a local intranet in which plain-RTP is already = used for
>> SIP communication).
>
> This is where you= get it wrong. You are pushing the decision to the user. They have to evalu= ate the network
> their browser is currently attached to and make a decision on what kin= d of security they
> need for this particular network. Even in the o= ffice, the iPad on your desk might be connected
> to 3G because it lo= st contact with the wifi.
>
> I think we can not require that users are able to perform a s= ecurity evaluation of each and
> every network the device their brows= er is running on connects to. Make it secure by default.
> I mean, th= is is the year 2011 and we do have CPUs that can handle it. People walk aro= und
> with dual core in their pockets.
>
> /O
--0016363107411e24bc04adb008b7-- From harald@alvestrand.no Sat Sep 24 08:34: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 87F9C21F8B31 for ; Sat, 24 Sep 2011 08:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.284 X-Spam-Level: X-Spam-Status: No, score=-109.284 tagged_above=-999 required=5 tests=[AWL=1.315, 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 ZFwaSwI3JfJQ for ; Sat, 24 Sep 2011 08:34:38 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E063E21F8B2B for ; Sat, 24 Sep 2011 08:34:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DE1C639E0E7 for ; Sat, 24 Sep 2011 17:37:07 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9Wcd0Sv-7dW for ; Sat, 24 Sep 2011 17:37:07 +0200 (CEST) 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 5778339E082 for ; Sat, 24 Sep 2011 17:37:07 +0200 (CEST) Message-ID: <4E7DF923.1070308@alvestrand.no> Date: Sat, 24 Sep 2011 17:37:07 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> <7DEACFFC-8AF3-4450-8844-FF6E187AE4D2@edvina.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Sep 2011 15:34:38 -0000 On 09/24/2011 03:37 PM, Iñaki Baz Castillo wrote: > > Hi. I dont mean that security decisions are taken by the final user, > but by the service provider. If it is a local intranet or the users > access the intranet via a secure vpn, security can be relaxed ans the > site provider could determine that plain rtp is allowed. > Remember that in the RTCWEB context, the service provider (the provider of the Javascript and the Web service) is presumed malicious. From ibc@aliax.net Sat Sep 24 08:52: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 8A9D921F8551 for ; Sat, 24 Sep 2011 08:52:07 -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.036, 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 J7wFsoQGbFoo for ; Sat, 24 Sep 2011 08:52:06 -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 C73A021F854D for ; Sat, 24 Sep 2011 08:52:06 -0700 (PDT) Received: by vws5 with SMTP id 5so5410471vws.31 for ; Sat, 24 Sep 2011 08:54:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.29.75 with SMTP id i11mr4422393vdh.296.1316879682214; Sat, 24 Sep 2011 08:54:42 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Sat, 24 Sep 2011 08:54:42 -0700 (PDT) In-Reply-To: <4E7DF923.1070308@alvestrand.no> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> <7DEACFFC-8AF3-4450-8844-FF6E187AE4D2@edvina.net> <4E7DF923.1070308@alvestrand.no> Date: Sat, 24 Sep 2011 17:54:42 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Sep 2011 15:52:07 -0000 2011/9/24 Harald Alvestrand : > On 09/24/2011 03:37 PM, I=C3=B1aki Baz Castillo wrote: >> >> Hi. I dont mean that security decisions are taken by the final user, but >> by the service provider. If it is a local intranet or the users access t= he >> intranet via a secure vpn, security can be relaxed ans the site provider >> could determine that plain rtp is allowed. >> > Remember that in the RTCWEB context, the service provider (the provider o= f > the Javascript and the Web service) is presumed malicious. But the user would *always* be asked for permission before starting/accepting a media session, right? The same as it occurs with Flash applications asking for micro/webcam usage. Such prompt should be standarized by RTCweb and should let the user know the security aspects of the offer: ------------------- The web site www.domain.org asks you for permissions to start a audio/[video] session using your micro and web cam. Audio/video communication is not required to be encripted/secured. Do you accept? [ yes ] [ no ] ------------------ --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Sat Sep 24 09:02: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 ED5BB21F8678 for ; Sat, 24 Sep 2011 09:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.211 X-Spam-Level: X-Spam-Status: No, score=-109.211 tagged_above=-999 required=5 tests=[AWL=1.088, 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 PyJH+BIsL-lk for ; Sat, 24 Sep 2011 09:02:22 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0614921F85A1 for ; Sat, 24 Sep 2011 09:02:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0B41C39E0E7; Sat, 24 Sep 2011 18:04:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdUlHGccx8Zh; Sat, 24 Sep 2011 18:04:58 +0200 (CEST) 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 2F85F39E082; Sat, 24 Sep 2011 18:04:58 +0200 (CEST) Message-ID: <4E7DFFAA.2040306@alvestrand.no> Date: Sat, 24 Sep 2011 18:04:58 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> <7DEACFFC-8AF3-4450-8844-FF6E187AE4D2@edvina.net> <4E7DF923.1070308@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Sep 2011 16:02:23 -0000 On 09/24/2011 05:54 PM, Iñaki Baz Castillo wrote: > 2011/9/24 Harald Alvestrand: >> On 09/24/2011 03:37 PM, Iñaki Baz Castillo wrote: >>> Hi. I dont mean that security decisions are taken by the final user, but >>> by the service provider. If it is a local intranet or the users access the >>> intranet via a secure vpn, security can be relaxed ans the site provider >>> could determine that plain rtp is allowed. >>> >> Remember that in the RTCWEB context, the service provider (the provider of >> the Javascript and the Web service) is presumed malicious. > But the user would *always* be asked for permission before > starting/accepting a media session, right? The same as it occurs with > Flash applications asking for micro/webcam usage. Such prompt should > be standarized by RTCweb and should let the user know the security > aspects of the offer: > > ------------------- > The web site www.domain.org asks you for permissions to start a > audio/[video] session using your micro and web cam. > Audio/video communication is not required to be encripted/secured. > > Do you accept? > > [ yes ] [ no ] > ------------------ Are we on the same subject line? In the context we are talking about here (RTCP-less RTP flows), the prompt would have to be: ----------- The web site www.domain.org wishes to send media to some other place on the Internet, and to set the option that allows it to communicate without using congestion control being available. You have no way of figuring out where the packets are going, whether this will cause harm to you, your network or anything else between here and there. Do you accept? [ yes ] [ no ] ---------- (note that if we want to include the place stuff is going to in the prompt, the prompt has to pop up AFTER we've established the call, and pop up again every time the transport addres is renegotiated.) Does this seem reasonable? > From ibc@aliax.net Sat Sep 24 09:21: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 9017021F850B for ; Sat, 24 Sep 2011 09:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E98AX-BuS-QO for ; Sat, 24 Sep 2011 09:21:49 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8136F21F8509 for ; Sat, 24 Sep 2011 09:21:49 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so2499244vcb.31 for ; Sat, 24 Sep 2011 09:24:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.29.75 with SMTP id i11mr4446981vdh.296.1316881465641; Sat, 24 Sep 2011 09:24:25 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Sat, 24 Sep 2011 09:24:25 -0700 (PDT) In-Reply-To: <4E7DFFAA.2040306@alvestrand.no> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> <7DEACFFC-8AF3-4450-8844-FF6E187AE4D2@edvina.net> <4E7DF923.1070308@alvestrand.no> <4E7DFFAA.2040306@alvestrand.no> Date: Sat, 24 Sep 2011 18:24:25 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Sep 2011 16:21:50 -0000 2011/9/24 Harald Alvestrand : > Are we on the same subject line? > > In the context we are talking about here (RTCP-less RTP flows), the promp= t > would have to be: > > ----------- > The web site www.domain.org wishes to send media to some other place on t= he > Internet, and to set the option that allows it to communicate without usi= ng > congestion control being available. You have no way of figuring out where > the packets are going, whether this will cause harm to you, your network = or > anything else between here and there. > > Do you accept? > > [ yes ] [ no ] > ---------- > (note that if we want to include the place stuff is going to in the promp= t, > the prompt has to pop up AFTER we've established the call, and pop up aga= in > every time the transport addres is renegotiated.) Just wondering: is not possible to indicate support for RTCP in the SDP? Anyhow... > Does this seem reasonable? No, but what are we trying to prevent? a malicious site could always initiate a session with a user in behalf of him best friend. I mean a valid audio/video session (with ICE, RTCP, SRTP and so). The the user (the WebRTC client) sends RTP there and the malicious site/user uploads it to Youtube. How can rtcweb security constrains prevent that??? In the other side, if user A establishes an audio session with user B, and user B indicates a "malicious" address in the SDP (and does not send RTCP reports) then user A would realize in just a few seconds that "something is wrong since there is no audio" and would hangup. In the meanwhile user A would send a few useless UDP packets to somewhere within his LAN network, is that so critic? I really wonder what we are trying to achieve in all these threads about security in rtcweb. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Sat Sep 24 09:53: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 39FBA21F888A for ; Sat, 24 Sep 2011 09:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.271 X-Spam-Level: X-Spam-Status: No, score=-109.271 tagged_above=-999 required=5 tests=[AWL=1.028, 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 XCKqCPBjNF40 for ; Sat, 24 Sep 2011 09:53:03 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 99B2621F8888 for ; Sat, 24 Sep 2011 09:53:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B779D39E0E7; Sat, 24 Sep 2011 18:55:40 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYdco6n78+vz; Sat, 24 Sep 2011 18:55:40 +0200 (CEST) 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 375D039E082; Sat, 24 Sep 2011 18:55:40 +0200 (CEST) Message-ID: <4E7E0B8C.5010807@alvestrand.no> Date: Sat, 24 Sep 2011 18:55:40 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> <7DEACFFC-8AF3-4450-8844-FF6E187AE4D2@edvina.net> <4E7DF923.1070308@alvestrand.no> <4E7DFFAA.2040306@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Sep 2011 16:53:04 -0000 On 09/24/2011 06:24 PM, Iñaki Baz Castillo wrote: > >> Does this seem reasonable? > No, but what are we trying to prevent? In this case (keepalive using RTCP) we're trying to prevent the Javascript running in user A's browser from connecting to user B, having user B hang up, and the packets continuing to flow "forever" from A to B. > a malicious site could always > initiate a session with a user in behalf of him best friend. I mean a > valid audio/video session (with ICE, RTCP, SRTP and so). The the user > (the WebRTC client) sends RTP there and the malicious site/user > uploads it to Youtube. How can rtcweb security constrains prevent > that??? > > In the other side, if user A establishes an audio session with user B, > and user B indicates a "malicious" address in the SDP (and does not > send RTCP reports) then user A would realize in just a few seconds > that "something is wrong since there is no audio" and would hangup. In > the meanwhile user A would send a few useless UDP packets to somewhere > within his LAN network, is that so critic? If the JS in user A negotiates one connection to user B and another to user C, and hears audio from user C, when would he realize that user B had dropped off the conference call? > I really wonder what we are trying to achieve in all these threads > about security in rtcweb. > If you can formulate your wondering in terms of "draft-ietf-rtcweb-security should be changed to say *this* to make it clear", that would be most helpful. I think I'll take my own advice and shut up on this thread... From ibc@aliax.net Sat Sep 24 09: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 79C8921F891D for ; Sat, 24 Sep 2011 09:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qA2asWCva8b for ; Sat, 24 Sep 2011 09:56:10 -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 EAEED21F888A for ; Sat, 24 Sep 2011 09:56:09 -0700 (PDT) Received: by vws5 with SMTP id 5so5440889vws.31 for ; Sat, 24 Sep 2011 09:58:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.29.75 with SMTP id i11mr4475386vdh.296.1316883527117; Sat, 24 Sep 2011 09:58:47 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Sat, 24 Sep 2011 09:58:47 -0700 (PDT) In-Reply-To: <4E7E0B8C.5010807@alvestrand.no> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> <7DEACFFC-8AF3-4450-8844-FF6E187AE4D2@edvina.net> <4E7DF923.1070308@alvestrand.no> <4E7DFFAA.2040306@alvestrand.no> <4E7E0B8C.5010807@alvestrand.no> Date: Sat, 24 Sep 2011 18:58:47 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Sep 2011 16:56:10 -0000 2011/9/24 Harald Alvestrand : > If you can formulate your wondering in terms of "draft-ietf-rtcweb-securi= ty > should be changed to say *this* to make it clear", that would be most > helpful. I will take a look to that draft. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Sat Sep 24 13:30: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 110D321F8B4F for ; Sat, 24 Sep 2011 13:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttwqaI8Xv8Fe for ; Sat, 24 Sep 2011 13:30:47 -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 81BC121F8B4B for ; Sat, 24 Sep 2011 13:30:47 -0700 (PDT) Received: by vws5 with SMTP id 5so5536440vws.31 for ; Sat, 24 Sep 2011 13:33:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.29.75 with SMTP id i11mr4627725vdh.296.1316896404889; Sat, 24 Sep 2011 13:33:24 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Sat, 24 Sep 2011 13:33:24 -0700 (PDT) Date: Sat, 24 Sep 2011 22:33:24 +0200 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] ICE does not work if both peers are behind symmetric NAT X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Sep 2011 20:30:48 -0000 Hi, I expect this topic has already been addressed in this maillist. But it not, I would like to comment that ICE does not work when both peers are behind symmetric NAT (very common in home routers). In that case, the only solution is to use TURN by adding it the last candidate in the ICE SDP, but TURN requires authentication and, of course, a TURN server. Has been this topic discussed? If the website supposed to provide the WebRTC client with information about which TURN server to use and username:password for using it? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From aeh@db.org Sat Sep 24 14:10: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 3DA5621F8B58 for ; Sat, 24 Sep 2011 14:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO1RxMJQZ68m for ; Sat, 24 Sep 2011 14:10:15 -0700 (PDT) Received: from mailstore05.sysedata.no (mailstore05.sysedata.no [195.159.29.9]) by ietfa.amsl.com (Postfix) with ESMTP id ADE4021F8AF9 for ; Sat, 24 Sep 2011 14:10:15 -0700 (PDT) Received: from [84.215.116.142] (helo=macbook.lan) by mailstore05.sysedata.no with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1R7ZWl-0002bv-6c; Sat, 24 Sep 2011 23:12:51 +0200 Message-ID: <4E7E47D1.9040100@db.org> Date: Sat, 24 Sep 2011 23:12:49 +0200 From: "Alfred E. Heggestad" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ICE does not work if both peers are behind symmetric NAT X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Sep 2011 21:10:16 -0000 On 9/24/11 10:33 PM, Iñaki Baz Castillo wrote: > Hi, I expect this topic has already been addressed in this maillist. > But it not, I would like to comment that ICE does not work when both > peers are behind symmetric NAT (very common in home routers). > > In that case, the only solution is to use TURN by adding it the last > candidate in the ICE SDP, but TURN requires authentication and, of > course, a TURN server. > > Has been this topic discussed? If the website supposed to provide the > WebRTC client with information about which TURN server to use and > username:password for using it? > "ICE does not work" is not correct. ICE will still "work" even if both peers are behind NAT. the media will simply be relayed via a TURN server, and not flow directly between peers. the TURN server credentials should be provisioned by the service provider /alfred From ibc@aliax.net Sat Sep 24 14:12: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 0D8A521F8AF9 for ; Sat, 24 Sep 2011 14:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzBdYy7e6i1C for ; Sat, 24 Sep 2011 14:12: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 7CF1A21F8ACA for ; Sat, 24 Sep 2011 14:12:31 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so2630075vcb.31 for ; Sat, 24 Sep 2011 14:15:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.175.229 with SMTP id cd5mr4719723vdc.363.1316898908149; Sat, 24 Sep 2011 14:15:08 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Sat, 24 Sep 2011 14:15:08 -0700 (PDT) In-Reply-To: <4E7E47D1.9040100@db.org> References: <4E7E47D1.9040100@db.org> Date: Sat, 24 Sep 2011 23:15:08 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Alfred E. Heggestad" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ICE does not work if both peers are behind symmetric NAT X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Sep 2011 21:12:32 -0000 2011/9/24 Alfred E. Heggestad : > "ICE does not work" is not correct. ICE will still "work" even if both > peers are behind NAT. the media will simply be relayed via a TURN server, > and not flow directly between peers. Yes, that's exactly what I said in my second paragraph :) > the TURN server credentials should be provisioned by the service provider And is that estandarized within rtcweb? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Sun Sep 25 03:48: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 38CB021F8B4F for ; Sun, 25 Sep 2011 03:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.326 X-Spam-Level: X-Spam-Status: No, score=-109.326 tagged_above=-999 required=5 tests=[AWL=0.973, 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 Za+3MBeYQEic for ; Sun, 25 Sep 2011 03:48:49 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 76B1721F8B4B for ; Sun, 25 Sep 2011 03:48:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CF3A439E13B; Sun, 25 Sep 2011 12:51:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dnd-NQMkJhDT; Sun, 25 Sep 2011 12:51:25 +0200 (CEST) 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 D3EDB39E08B; Sun, 25 Sep 2011 12:51:25 +0200 (CEST) Message-ID: <4E7F07AD.9030409@alvestrand.no> Date: Sun, 25 Sep 2011 12:51:25 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4E7E47D1.9040100@db.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ICE does not work if both peers are behind symmetric NAT X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 25 Sep 2011 10:48:50 -0000 On 09/24/2011 11:15 PM, Iñaki Baz Castillo wrote: > 2011/9/24 Alfred E. Heggestad: >> "ICE does not work" is not correct. ICE will still "work" even if both >> peers are behind NAT. the media will simply be relayed via a TURN server, >> and not flow directly between peers. > Yes, that's exactly what I said in my second paragraph :) > > >> the TURN server credentials should be provisioned by the service provider > And is that estandarized within rtcweb? so far, the only place where it has been mentioned is in the W3C API document, which documents how a PeerConnection is initialized with info on TURN / STUN servers. I think that part needs attention of a TURN expert; it doesn't look right to me. But I don't think anything more is needed. Harald From roman@telurix.com Sun Sep 25 14:02: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 A257A21F8797 for ; Sun, 25 Sep 2011 14:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpDu-8vPFBcQ for ; Sun, 25 Sep 2011 14:02:53 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF31521F84C1 for ; Sun, 25 Sep 2011 14:02:52 -0700 (PDT) Received: by gwj15 with SMTP id 15so4942093gwj.31 for ; Sun, 25 Sep 2011 14:05:33 -0700 (PDT) Received: by 10.150.165.3 with SMTP id n3mr5481217ybe.397.1316984733511; Sun, 25 Sep 2011 14:05:33 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id q16sm1948442ybf.23.2011.09.25.14.05.31 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Sep 2011 14:05:33 -0700 (PDT) Received: by ywa6 with SMTP id 6so4811853ywa.31 for ; Sun, 25 Sep 2011 14:05:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.33.130 with SMTP id r2mr25072694pbi.71.1316984731069; Sun, 25 Sep 2011 14:05:31 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Sun, 25 Sep 2011 14:05:30 -0700 (PDT) In-Reply-To: <4E7F07AD.9030409@alvestrand.no> References: <4E7E47D1.9040100@db.org> <4E7F07AD.9030409@alvestrand.no> Date: Sun, 25 Sep 2011 17:05:30 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=bcaec520f6111203f404adca67d5 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ICE does not work if both peers are behind symmetric NAT X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 25 Sep 2011 21:02:53 -0000 --bcaec520f6111203f404adca67d5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It is most likely not right since it assumes that different servers are use= d for STUN and TURN. In real life these are the same server. We also need to specify if TURN should be used for this call, or if we plan to use STUN onl= y and never proxy media. Finally we need to specify credentials to use with server STUN/TURN. One more thing that we should decide on is if we need mandate TURNS, or if we assume that sRTP security is sufficient and TURNS is only used when connection to TURN server cannot be setup. We also need to figure out how w= e need to interact with proxy configuration of the browser. We can either always use a proxy, use proxy as one of the ICE candidates, only use a prox= y if direct connection to TURN server is not possible. P.S. We should probably try to get more people with VoIP expertise involved on W3C side, since right now it looks like they are underrepresented there. _____________ Roman Shpount On Sun, Sep 25, 2011 at 6:51 AM, Harald Alvestrand wr= ote: > On 09/24/2011 11:15 PM, I=F1aki Baz Castillo wrote: > >> 2011/9/24 Alfred E. Heggestad: >> >>> "ICE does not work" is not correct. ICE will still "work" even if both >>> peers are behind NAT. the media will simply be relayed via a TURN serve= r, >>> and not flow directly between peers. >>> >> Yes, that's exactly what I said in my second paragraph :) >> >> >> the TURN server credentials should be provisioned by the service provid= er >>> >> And is that estandarized within rtcweb? >> > so far, the only place where it has been mentioned is in the W3C API > document, which documents how a PeerConnection is initialized with info o= n > TURN / STUN servers. > > I think that part needs attention of a TURN expert; it doesn't look right > to me. > But I don't think anything more is needed. > > Harald > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --bcaec520f6111203f404adca67d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It is most likely not right since it assumes that different servers are use= d for STUN and TURN. In real life these are the same server. We also need t= o specify if TURN should be used for this call, or if we plan to use STUN o= nly and never proxy media. Finally we need to specify credentials to use wi= th server STUN/TURN.

One more thing that we should decide on is if we need mandate TURNS, or= if we assume that sRTP security is sufficient and TURNS is only used when = connection to TURN server cannot be setup. We also need to figure out how w= e need to interact with proxy configuration of the browser. We can either a= lways use a proxy, use proxy as one of the ICE candidates, only use a proxy= if direct connection to TURN server is not possible.

P.S. We should probably try to get more people with VoIP expertise invo= lved on W3C side, since right now it looks like they are underrepresented t= here.
_____________
Roman Shpount


On Sun, Sep 25, 2011 at 6:51 AM, Harald = Alvestrand <ha= rald@alvestrand.no> wrote:
On 09/24/2011 11:15 PM, I=F1aki Baz Castillo wrote:
2011/9/24 Alfred E. Heggestad<aeh@db.org>:
"ICE does not work" is not correct. ICE will still "work&quo= t; even if both
peers are behind NAT. the media will simply be relayed via a TURN server, and not flow directly between peers.
Yes, that's exactly what I said in my second paragraph :)


the TURN server credentials should be provisioned by the service provider
And is that estandarized within rtcweb?
so far, the only place where it has been mentioned is in the W3C API docume= nt, which documents how a PeerConnection is initialized with info on TURN /= STUN servers.

I think that part needs attention of a TURN expert; it doesn't look rig= ht to me.
But I don't think anything more is needed.

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

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

--bcaec520f6111203f404adca67d5-- From cb.list6@gmail.com Sun Sep 25 14: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 451DC21F8B28 for ; Sun, 25 Sep 2011 14:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=-0.940, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 zXmHj-yTDxsG for ; Sun, 25 Sep 2011 14:33:41 -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 B7C4C21F8B27 for ; Sun, 25 Sep 2011 14:33:41 -0700 (PDT) Received: by gyd12 with SMTP id 12so4654987gyd.31 for ; Sun, 25 Sep 2011 14:36:22 -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:content-transfer-encoding; bh=RN2JqYmhdXSCyKgiNngbqj2XfqDVtXI88861Nb/nbuo=; b=AxJyNIOcfEK/QsvZB5nhvsqf+kcvJztDSK/0kuHFuJJhRff6tR/xp37NGGw02+iORK 3PdaL1m1BCaYtxExPmuK4PabeGK9l03rqbybZNv3b6QKMfkqlY5Rlxue5z5UfLdyl3Hj ex13I0kyIxgpav0mGjDYGuWMw+d1c6yEp6CmQ= MIME-Version: 1.0 Received: by 10.68.15.194 with SMTP id z2mr25118847pbc.47.1316986580492; Sun, 25 Sep 2011 14:36:20 -0700 (PDT) Received: by 10.142.89.1 with HTTP; Sun, 25 Sep 2011 14:36:20 -0700 (PDT) In-Reply-To: References: <4E7E47D1.9040100@db.org> <4E7F07AD.9030409@alvestrand.no> Date: Sun, 25 Sep 2011 14:36:20 -0700 Message-ID: From: Cameron Byrne To: Roman Shpount Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ICE does not work if both peers are behind symmetric NAT X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 25 Sep 2011 21:33:42 -0000 On Sun, Sep 25, 2011 at 2:05 PM, Roman Shpount wrote: > It is most likely not right since it assumes that different servers are u= sed > for STUN and TURN. In real life these are the same server. We also need t= o > specify if TURN should be used for this call, or if we plan to use STUN o= nly > and never proxy media. Finally we need to specify credentials to use with > server STUN/TURN. > Not creating a path for proxying media will be a real mistake. There is too much NAT444, ipv6-only, and other complicated CGN work going on to not account for this. That said, TURN with support not only for overcoming NAT44 but also NAT64 should be required as defined in RFC 6156 http://tools.ietf.org/html/rfc6156 CB > One more thing that we should decide on is if we need mandate TURNS, or i= f > we assume that sRTP security is sufficient and TURNS is only used when > connection to TURN server cannot be setup. We also need to figure out how= we > need to interact with proxy configuration of the browser. We can either > always use a proxy, use proxy as one of the ICE candidates, only use a pr= oxy > if direct connection to TURN server is not possible. > > P.S. We should probably try to get more people with VoIP expertise involv= ed > on W3C side, since right now it looks like they are underrepresented ther= e. > _____________ > Roman Shpount > > > On Sun, Sep 25, 2011 at 6:51 AM, Harald Alvestrand > wrote: >> >> On 09/24/2011 11:15 PM, I=F1aki Baz Castillo wrote: >>> >>> 2011/9/24 Alfred E. Heggestad: >>>> >>>> "ICE does not work" is not correct. ICE will still "work" even if both >>>> peers are behind NAT. the media will simply be relayed via a TURN >>>> server, >>>> and not flow directly between peers. >>> >>> Yes, that's exactly what I said in my second paragraph :) >>> >>> >>>> the TURN server credentials should be provisioned by the service >>>> provider >>> >>> And is that estandarized within rtcweb? >> >> so far, the only place where it has been mentioned is in the W3C API >> document, which documents how a PeerConnection is initialized with info = on >> TURN / STUN servers. >> >> I think that part needs attention of a TURN expert; it doesn't look righ= t >> to me. >> But I don't think anything more is needed. >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Harald >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > From randell-ietf@jesup.org Sun Sep 25 14:49: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 8B3F121F8B2E for ; Sun, 25 Sep 2011 14:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[AWL=-1.311, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60QfWSsl1iFW for ; Sun, 25 Sep 2011 14:49:16 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id B4FCD21F8B29 for ; Sun, 25 Sep 2011 14:49:16 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R7wc9-0000Ul-6b for rtcweb@ietf.org; Sun, 25 Sep 2011 16:51:57 -0500 Message-ID: <4E7FA1A3.60908@jesup.org> Date: Sun, 25 Sep 2011 17:48:19 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: "rtcweb@ietf.org" 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: [rtcweb] Security and browser/screen access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 25 Sep 2011 21:49:17 -0000 This is an issue that impacts at a usecase we've been discussing: access to the browser or screen bitmap is inherently very risky, security-wise. See Robert O'Callahan's blog post triggered by discussions of these usecases at our recent Mozilla All-Hands: http://robert.ocallahan.org/2011/08/securing-full-screen.html This directly affects use-cases like WebEx (of course), remote assistance, etc. We've glossed the security side of those so far. Note that these use-cases replace desktop or plugin installs which implicitly gave the provider access to far more than just the screen, so from that perspective screen access is actually a reduction in exposure. However, there's a definitive decision (whether well-informed or not) to install these apps, and most of them (not all!) don't auto-update without asking; and you can un-install them. This once again as I've mentioned in some other cases wanders into the same territory as WebApp installation, which we also talked about looking at for handling "ongoing permissions" for camera/mic for services similar to Skype - tie it to a user "install". Whether that's good enough, and how that actually works are good questions. -- Randell Jesup randell-ietf@jesup.org From roman@telurix.com Sun Sep 25 15:35: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 7D14421F8A6F for ; Sun, 25 Sep 2011 15:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 yrLao1ICrM81 for ; Sun, 25 Sep 2011 15:35:52 -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 9672F21F8A56 for ; Sun, 25 Sep 2011 15:35:52 -0700 (PDT) Received: by ywa6 with SMTP id 6so4847430ywa.31 for ; Sun, 25 Sep 2011 15:38:33 -0700 (PDT) Received: by 10.236.79.197 with SMTP id i45mr35230727yhe.28.1316990313360; Sun, 25 Sep 2011 15:38:33 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by mx.google.com with ESMTPS id h20sm62960333ani.16.2011.09.25.15.38.32 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Sep 2011 15:38:32 -0700 (PDT) Received: by gwj15 with SMTP id 15so4977845gwj.31 for ; Sun, 25 Sep 2011 15:38:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.11.138 with SMTP id q10mr25511066pbb.37.1316990311819; Sun, 25 Sep 2011 15:38:31 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Sun, 25 Sep 2011 15:38:31 -0700 (PDT) In-Reply-To: References: <4E7E47D1.9040100@db.org> <4E7F07AD.9030409@alvestrand.no> Date: Sun, 25 Sep 2011 18:38:31 -0400 Message-ID: From: Roman Shpount To: Cameron Byrne Content-Type: multipart/alternative; boundary=bcaec5314ad1b5686704adcbb326 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ICE does not work if both peers are behind symmetric NAT X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 25 Sep 2011 22:35:53 -0000 --bcaec5314ad1b5686704adcbb326 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What I meant was that RTC client should have TURN support, but should be able to fallback to use case when only STUN server is available. In real life TURN server might not always be available to the application developer= . TURN servers for large applications can consume a lot of bandwidth and typically not offered as a free service. On the other hand, STUN servers a not resource intensive at all. _____________ Roman Shpount On Sun, Sep 25, 2011 at 5:36 PM, Cameron Byrne wrote: > On Sun, Sep 25, 2011 at 2:05 PM, Roman Shpount wrote: > > It is most likely not right since it assumes that different servers are > used > > for STUN and TURN. In real life these are the same server. We also need > to > > specify if TURN should be used for this call, or if we plan to use STUN > only > > and never proxy media. Finally we need to specify credentials to use wi= th > > server STUN/TURN. > > > > Not creating a path for proxying media will be a real mistake. There > is too much NAT444, ipv6-only, and other complicated CGN work going on > to not account for this. > > That said, TURN with support not only for overcoming NAT44 but also > NAT64 should be required as defined in RFC 6156 > > http://tools.ietf.org/html/rfc6156 > > CB > > > > One more thing that we should decide on is if we need mandate TURNS, or > if > > we assume that sRTP security is sufficient and TURNS is only used when > > connection to TURN server cannot be setup. We also need to figure out h= ow > we > > need to interact with proxy configuration of the browser. We can either > > always use a proxy, use proxy as one of the ICE candidates, only use a > proxy > > if direct connection to TURN server is not possible. > > > > P.S. We should probably try to get more people with VoIP expertise > involved > > on W3C side, since right now it looks like they are underrepresented > there. > > _____________ > > Roman Shpount > > > > > > On Sun, Sep 25, 2011 at 6:51 AM, Harald Alvestrand > > > wrote: > >> > >> On 09/24/2011 11:15 PM, I=F1aki Baz Castillo wrote: > >>> > >>> 2011/9/24 Alfred E. Heggestad: > >>>> > >>>> "ICE does not work" is not correct. ICE will still "work" even if bo= th > >>>> peers are behind NAT. the media will simply be relayed via a TURN > >>>> server, > >>>> and not flow directly between peers. > >>> > >>> Yes, that's exactly what I said in my second paragraph :) > >>> > >>> > >>>> the TURN server credentials should be provisioned by the service > >>>> provider > >>> > >>> And is that estandarized within rtcweb? > >> > >> so far, the only place where it has been mentioned is in the W3C API > >> document, which documents how a PeerConnection is initialized with inf= o > on > >> TURN / STUN servers. > >> > >> I think that part needs attention of a TURN expert; it doesn't look > right > >> to me. > >> But I don't think anything more is needed. > >> > >> Harald > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > --bcaec5314ad1b5686704adcbb326 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What I meant was that RTC client should have TURN support, but should be ab= le to fallback to use case when only STUN server is available. In real life= TURN server might not always be available to the application developer. TU= RN servers for large applications can consume a lot of bandwidth and typica= lly not offered as a free service. On the other hand, STUN servers a not re= source intensive at all.
_____________
Roman Shpount


On Sun, Sep 25, 2011 at 5:36 PM, Cameron= Byrne <cb.list6= @gmail.com> wrote:
On Sun, Sep 25, 2011 at 2:05 PM, Roman Shpount <roman@telurix.com> wrote:
> It is most likely not right since it assumes that different servers ar= e used
> for STUN and TURN. In real life these are the same server. We also nee= d to
> specify if TURN should be used for this call, or if we plan to use STU= N only
> and never proxy media. Finally we need to specify credentials to use w= ith
> server STUN/TURN.
>

Not creating a path for proxying media will be a real mistake. =A0The= re
is too much NAT444, ipv6-only, and other complicated CGN work going on
to not account for this.

That said, TURN with support not only for overcoming NAT44 but also
NAT64 should be required as defined in RFC 6156

http://too= ls.ietf.org/html/rfc6156

CB


> One more thing that we should decide on is if we need mandate TURNS, o= r if
> we assume that sRTP security is sufficient and TURNS is only used when=
> connection to TURN server cannot be setup. We also need to figure out = how we
> need to interact with proxy configuration of the browser. We can eithe= r
> always use a proxy, use proxy as one of the ICE candidates, only use a= proxy
> if direct connection to TURN server is not possible.
>
> P.S. We should probably try to get more people with VoIP expertise inv= olved
> on W3C side, since right now it looks like they are underrepresented t= here.
> _____________
> Roman Shpount
>
>
> On Sun, Sep 25, 2011 at 6:51 AM, Harald Alvestrand <harald@alvestrand.no>
> wrote:
>>
>> On 09/24/2011 11:15 PM, I=F1aki Baz Castillo wrote:
>>>
>>> 2011/9/24 Alfred E. Heggestad<aeh@db.org>:
>>>>
>>>> "ICE does not work" is not correct. ICE will sti= ll "work" even if both
>>>> peers are behind NAT. the media will simply be relayed via= a TURN
>>>> server,
>>>> and not flow directly between peers.
>>>
>>> Yes, that's exactly what I said in my second paragraph :)<= br> >>>
>>>
>>>> the TURN server credentials should be provisioned by the s= ervice
>>>> provider
>>>
>>> And is that estandarized within rtcweb?
>>
>> so far, the only place where it has been mentioned is in the W3C A= PI
>> document, which documents how a PeerConnection is initialized with= info on
>> TURN / STUN servers.
>>
>> I think that part needs attention of a TURN expert; it doesn't= look right
>> to me.
>> But I don't think anything more is needed.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Harald
>>
>> _______________________________________________
>> 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
>
>

--bcaec5314ad1b5686704adcbb326-- From bernard_aboba@hotmail.com Sun Sep 25 17:10: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 5FC2821F8AA8 for ; Sun, 25 Sep 2011 17:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.975 X-Spam-Level: X-Spam-Status: No, score=-100.975 tagged_above=-999 required=5 tests=[AWL=-1.106, BAYES_05=-1.11, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ipJxN2VIZ+X for ; Sun, 25 Sep 2011 17:10:27 -0700 (PDT) Received: from blu0-omc3-s12.blu0.hotmail.com (blu0-omc3-s12.blu0.hotmail.com [65.55.116.87]) by ietfa.amsl.com (Postfix) with ESMTP id 69E2021F8A97 for ; Sun, 25 Sep 2011 17:10:27 -0700 (PDT) Received: from BLU152-W31 ([65.55.116.73]) by blu0-omc3-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Sep 2011 17:13:08 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_7fa10192-4537-42a3-a018-098e126fdca9_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: Date: Sun, 25 Sep 2011 17:13:08 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 26 Sep 2011 00:13:08.0673 (UTC) FILETIME=[11FFB310:01CC7BE1] Subject: [rtcweb] RTCWEB and emergency services X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 00:10:28 -0000 --_7fa10192-4537-42a3-a018-098e126fdca9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm putting together a draft on the subject of RTCWEB and emergency service= s. However=2C before submitting this=2C it seemed useful to get some feedb= ack from the group on the general direction of the document.=20 1. The overall requirements for emergency services support will vary by jur= isdiction and are likely to change. Therefore the document=2C while citin= g ongoing regulatory proceedings within the US and EU=2C does not attempt t= o provide legal advice or offer a definitive statement of the regulatory re= quirements. Instead=2C the document cites documents from the ECRIT WG=2C = such as the ECRIT Framework and Phone-BCP documents which provide guidance = on best current or future practices. =20 2. The overall requirements for emergency services support also vary by th= e type of service that is being implemented. For example=2C adding suppo= rt for real-time conferencing to a social networking service or a game (e.g= . non-interconnected VoIP) will result in different requirements than say= =2C implementing a phone dialing service that can both make outgoing calls = and take incoming calls from E.164 numbers (e.g. interconnected VoIP). =20 It should therefore be understood that the burden for implementation of eme= rgency services falls principally upon the operator of the service=2C and t= hat the role of the RTCWEB implementer is to deliver basic capabilities and= to enable an operator to add to this functionality=2C rather than providin= g for every possible need natively ("I want a pony"). =20 3. The emergency services capabilities of the browser are comprised of the= functionality that is implemented in the browser=2C as well functionality = that can be added via Javascript libraries. In some circumstances=2C it m= ay be viable to supplement functionality with plugins. For example=2C a "w= ebphone" intended for use with an IP PBX=2C whose firmware is controlled by= the IP PBX vendor=2C could include within its code load plugins to provid= e additional functionality=2C including signaling protocols and codecs. As= a result=2C it is not required for an RTCWEB implementation to natively sa= tisfy every requirement of ECRIT Phone-BCP. Examples of requirements whi= ch may not be satisfiable without plugins include some of the endpoint medi= a requirements of PhoneBCP Section 14=2C such as ED-77 (video codec support= ). However=2C it would appear that some of the requirements of that secti= on such as ED-71 (RTP Support) and ED-73 (G.711 support) are appropriate. = =20 4. With respect to location capabilities=2C the W3C Location APIs and assoc= iated Location-Based Services are not adequate in terms of their support fo= r emergency services=20 location. This gap exists in part because the requirements and scenarios f= or Location-Based Services (LBS) are different from those of Location Info= rmation Services (LISes) used for emergency purposes. While in the long-t= erm it may be possible to close the gaps=2C in the short term the gaps may= be addressed via Javascript libraries implementing elements of the ECRIT=20 architecture such as HELD=2C or even LoST. =20 In addition=2C in some scenarios=2C it is quite feasible for this=20 2. Similarly=2C the requirements for native browser functionality will var= y according to the scenario. =20 2. In some scenarios=2C=20 In meeting the requirements for emergency services support=2C the importan= t question to answer is what functionality MUST be present natively within = the browser = --_7fa10192-4537-42a3-a018-098e126fdca9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm putting together a draft on the subject of RTCWEB and = emergency services. =3B However=2C before submitting this=2C it seemed = useful to get some feedback from the group on the general direction of the = document.

1. The overall requirements for emergency services suppor= t will vary by jurisdiction and are likely to change. =3B =3B There= fore the document=2C while citing ongoing regulatory proceedings within the= US and EU=2C does not attempt to provide legal advice or offer a definitiv= e statement of the regulatory requirements. =3B Instead=2C the document= cites =3B documents from the ECRIT WG=2C such as the ECRIT Framework a= nd Phone-BCP documents which provide guidance on best current or future pra= ctices.  =3B

2. =3B The overall requirements for emergency = services support also vary by the type of service that is being implemented= . =3B =3B For example=2C =3B adding support for real-time confe= rencing to a social networking service or a game (e.g. non-interconnected V= oIP) will result in different requirements than say=2C implementing a phone= dialing service that can both make outgoing calls and take incoming calls = from E.164 numbers (e.g. interconnected VoIP). =3B =3B

It s= hould therefore be understood that the burden for implementation of emergen= cy services falls principally upon the operator of the service=2C and that = the role of the RTCWEB implementer is to deliver basic capabilities and to = enable an operator to add to this functionality=2C rather than providing fo= r every possible need natively ("I want a pony"). =3B =3B

3= . =3B The emergency services capabilities of the browser are comprised = of the functionality that is implemented in the browser=2C as well function= ality that can be added via Javascript libraries. =3B =3B In some c= ircumstances=2C it may be viable to supplement functionality with plugins.&= nbsp=3B For example=2C a "webphone" intended for use with an IP PBX=2C whos= e firmware is controlled by the IP PBX vendor=2C =3B could include with= in its code load plugins to provide additional functionality=2C including s= ignaling protocols and codecs. =3B As a result=2C it is not required fo= r an RTCWEB implementation to natively satisfy every requirement of ECRIT P= hone-BCP. =3B =3B =3B Examples of requirements which may not be= satisfiable without plugins include some of the endpoint media requirement= s of PhoneBCP Section 14=2C such as ED-77 (video codec support). =3B&nb= sp=3B However=2C it would appear that some of the requirements of that sect= ion such as ED-71 (RTP Support) and ED-73 (G.711 support) are appropriate.&= nbsp=3B

4. With respect to location capabilities=2C the W3C Locatio= n APIs and associated Location-Based Services are not adequate in terms of = their support for emergency services=20 location. =3B This gap exists in part because the requirements and scen= arios for =3B Location-Based Services (LBS) are different from those of= Location Information Services (LISes) used for emergency purposes. =3B=  =3B While in the long-term it may be possible to close the gaps=2C&nbs= p=3B in the short term the gaps may be addressed via Javascript libraries i= mplementing elements of the ECRIT=20 architecture such as HELD=2C or even LoST. =3B =3B






In addition=2C in some scenarios=2C it is quite fea= sible for this

2. =3B Similarly=2C the requirements for native = browser functionality will vary according to the scenario. =3B

= 2. In some scenarios=2C


 =3BIn meeting the requirements for= emergency services support=2C the important question to answer is what fun= ctionality MUST be present natively within the browser


= --_7fa10192-4537-42a3-a018-098e126fdca9_-- From randell-ietf@jesup.org Sun Sep 25 22:24: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 3C22221F84FD for ; Sun, 25 Sep 2011 22:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=-0.602, BAYES_00=-2.599, 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 PDMJouPTVfW2 for ; Sun, 25 Sep 2011 22:24: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 9591D21F84FC for ; Sun, 25 Sep 2011 22:24:49 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R83j0-0004Kj-4J for rtcweb@ietf.org; Mon, 26 Sep 2011 00:27:30 -0500 Message-ID: <4E800C67.9070006@jesup.org> Date: Mon, 26 Sep 2011 01:23:51 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> <4E7B7272.7020204@alvestrand.no> <18FFF339-E7EB-4EEB-BCD8-E6728A56A24A@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FBC@ESESSCMS0356.eemea.ericsson.se> <271E29CD-D561-4E29-9E2D-DD15B9461F98@cisco.com> In-Reply-To: <271E29CD-D561-4E29-9E2D-DD15B9461F98@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] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 05:24:50 -0000 On 9/22/2011 4:37 PM, Cullen Jennings wrote: > On Sep 22, 2011, at 2:04 PM, Christer Holmberg wrote: > >> If so, what is your assumption then regarding ICE? That the SIP nodes >> will support ICE, or that the browser will be allowed to communicate >> with the SIP nodes without enabling ICE? > I see no way of solving the security problems without having ICE or something more or less like it. Therefore, I'm working on the assumption that it will only work if the SIP side supports ICE, or is front ended by a SBC with media GW that does ICE. In the short term, there will be some devices that don't do ICE but SIP devices are increasingly having ICE added. Particularly SIP devices that are internet facing because the need for NAT traversal. > > I find requiring ICE to be a very unfortunate assumption to have to make - obviously it reduces the number of legacy voip devices WebRTC devices can talk to without an SBC but I don't see any way around this limitation. Allowing web browsers inside the firewall to send packets to an arbitrary address that is inside the firewall with no validation that address speaks RTP is not acceptable. I agree we can't solve the security issue with permission to send with the current threat model without ICE or some equivalent. There is another option that may help with some of the use cases (I've mentioned this before in the discussion on screensharing, among others). For a number of the use cases security is an impassible problem with the current threat model. Those use cases generally involve replacing cases where an existing desktop install or plugin was used (webex, screensharing, vnc, SIP softclient, Skype, etc). Those cases all currently involve the user implicitly giving these apps total or close to code that could do pretty much anything on the user's computer, and are also often the "ongoing usage" authentication cases. The only mitigating safety of the external app/plugin model is that they're typically signed and go through the platforms software-install procedure, cert-showing, UACs, etc. Currently people are trying to work out the HTML5 "installed" webapp security model; if that's far enough along we may be able to piggyback off that. I'm looking into it. -- Randell Jesup randell-ietf@jesup.org From magnus.westerlund@ericsson.com Sun Sep 25 23:32: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 692B821F84B7 for ; Sun, 25 Sep 2011 23:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 1L0DhegsEGIB for ; Sun, 25 Sep 2011 23:32:12 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A959D21F84B0 for ; Sun, 25 Sep 2011 23:32:11 -0700 (PDT) X-AuditID: c1b4fb3d-b7b1aae000001146-14-4e80392b69c9 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.115.90]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 93.76.04422.B29308E4; Mon, 26 Sep 2011 10:34:51 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 26 Sep 2011 08:34:41 +0200 Message-ID: <4E801CFE.4030504@ericsson.com> Date: Mon, 26 Sep 2011 08:34:38 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 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] draft-ietf-rtcweb-use-cases-and-requirements-05 addition around IPv6 only and dualstack X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 06:32:12 -0000 Hi, (as individual) I would suggest that some section for general requirements that aren't use case specific is created and at least one such requirement is added. The requirement is the need to support IPv4 only, IPv6 only and dual-stack deployments as required by our charter. I think this should be added into the use-case and requirement document for two reasons. First, that is located next to the other requirements, secondly because W3C has decided to use our document also, I think it is important that such a general requirement both on protocols and any address field in the API handling both address families are covered. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From saul@ag-projects.com Mon Sep 26 00:08: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 CB00E21F850B for ; Mon, 26 Sep 2011 00:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.706 X-Spam-Level: X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFfa43TKP+bn for ; Mon, 26 Sep 2011 00:08:14 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 26C7D21F8508 for ; Mon, 26 Sep 2011 00:08:13 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 6FC80B01BB; Mon, 26 Sep 2011 09:10:53 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id A1DE2B017D; Mon, 26 Sep 2011 09:10:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <0FEA137C08A9DF4781EEF745038C969430A51F6401@nambx03.corp.adobe.com> Date: Mon, 26 Sep 2011 09:10:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5290D7E8-31AB-44BB-A8B2-3D1C2A4FB797@ag-projects.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <4E79A964.2050007@alvestran d.no> <0FEA137C08A9DF4781EEF745038C969430A51F6401@nambx03.corp.adobe.com> To: Jozsef Vass X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 07:08:14 -0000 On Sep 23, 2011, at 2:58 AM, Jozsef Vass wrote: > I am in support of having some basic mechanism in the browser as part = of rtcweb to enable developers to quickly and easily setup media between = participants. Furthermore, if an API is too complex or too hard to use, = people will not use it or misuse it. I can only see a handful of = companies developing advanced calling feature on top of rtcweb, most = people just want to have something simple to work without caring too = much about the details. >=20 > Maybe it would be advantages to specify such a very basic use case, = e.g., targeting gaming. It must work behind NATs using peer-to-peer = media transport (but fallback to media relay may not be required). Since = it is targeting closed community, there is no need for interoperability, = there is no need for SIP, Jingle, etc. At the minimum, this would = require a simple service for ip address lookup and to aid NAT and = firewall traversal. >=20 This is a no go. What "closed community" are you talking about? = Interoperability is a MUST here, even if I'm in favor of not having any = default signaling protocol specified. We need to be able to communicate = with other protocols without building gateways. This can be achieved = with both SIP and XMPP, so I see no need for reinventing the wheel. Lets = let developers use whatever protocol they like and just use RTCweb for = the media part. > For example, when a user registers with this service, he/she is = assigned an identifier or blob. In order to communicate with another = party, all they need to do is to exchange this information (this can be = done using websocket, etc.) and setup media channel. There should be no = need for parsing SDP, etc. >=20 What service? Who would host a server? -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Mon Sep 26 00:52: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 EF61221F8AD9 for ; Mon, 26 Sep 2011 00:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.415 X-Spam-Level: X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[AWL=-1.193, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, 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 ijLNvnHDGi0X for ; Mon, 26 Sep 2011 00:52:40 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBC821F8569 for ; Mon, 26 Sep 2011 00:52:40 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so3608734vcb.31 for ; Mon, 26 Sep 2011 00:55:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.69.18 with SMTP id a18mr5478742vdu.430.1317023721966; Mon, 26 Sep 2011 00:55:21 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Mon, 26 Sep 2011 00:55:21 -0700 (PDT) In-Reply-To: <0FEA137C08A9DF4781EEF745038C969430A51F6401@nambx03.corp.adobe.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <4E79A964.2050007@alvestrand.no> <0FEA137C08A9DF4781EEF745038C969430A51F6401@nambx03.corp.adobe.com> Date: Mon, 26 Sep 2011 09:55:21 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Jozsef Vass Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 07:52:41 -0000 2011/9/23 Jozsef Vass : > there is no need for interoperability, there is no need for SIP, Jingle, = etc. At the minimum, this would require a simple service for ip address loo= kup and to aid NAT and firewall traversal. > For example, when a user registers with this service, he/she is assigned = an identifier or blob. In order to communicate with another party, all they= need to do is to exchange this information (this can be done using websock= et, etc.) and setup media channel. There should be no need for parsing SDP,= etc. ...and when you need more features (like adding video within an existing audio session, or putting the session on hold, or negotiating codecs and encryption parameters) you will realize that you are reinventing SDP. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Mon Sep 26 00: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 D44B221F8A97 for ; Mon, 26 Sep 2011 00:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.524 X-Spam-Level: X-Spam-Status: No, score=-109.524 tagged_above=-999 required=5 tests=[AWL=1.075, 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 BznYtsBCOlou for ; Mon, 26 Sep 2011 00:59:55 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id D606B21F8A6C for ; Mon, 26 Sep 2011 00:59:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3999139E112; Mon, 26 Sep 2011 10:02:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZtROP8Y2cgL; Mon, 26 Sep 2011 10:02:35 +0200 (CEST) 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 9F04739E048; Mon, 26 Sep 2011 10:02:35 +0200 (CEST) Message-ID: <4E80319B.2000109@alvestrand.no> Date: Mon, 26 Sep 2011 10:02:35 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Randell Jesup References: <4E7FA1A3.60908@jesup.org> In-Reply-To: <4E7FA1A3.60908@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" , public-webrtc@w3.org Subject: Re: [rtcweb] Security and browser/screen access X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 07:59:55 -0000 On 09/25/2011 11:48 PM, Randell Jesup wrote: > This is an issue that impacts at a usecase we've been discussing: > access to the > browser or screen bitmap is inherently very risky, security-wise. > > See Robert O'Callahan's blog post triggered by discussions of these > usecases at > our recent Mozilla All-Hands: > http://robert.ocallahan.org/2011/08/securing-full-screen.html > > This directly affects use-cases like WebEx (of course), remote > assistance, etc. > We've glossed the security side of those so far. This also is something that affects the W3 side of things more than it affects the IETF side of things; can I encourage people to join the W3C WEBRTC mailing list and take those discussions there? > > Note that these use-cases replace desktop or plugin installs which > implicitly gave > the provider access to far more than just the screen, so from that > perspective > screen access is actually a reduction in exposure. However, there's a > definitive > decision (whether well-informed or not) to install these apps, and > most of them > (not all!) don't auto-update without asking; and you can un-install them. > > This once again as I've mentioned in some other cases wanders into the > same territory > as WebApp installation, which we also talked about looking at for > handling "ongoing > permissions" for camera/mic for services similar to Skype - tie it to > a user "install". > Whether that's good enough, and how that actually works are good > questions. > Fully agree on the situation description. From ibc@aliax.net Mon Sep 26 01:06: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 1A53021F8B43 for ; Mon, 26 Sep 2011 01:06:17 -0700 (PDT) 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.038, 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 SeqcKr52enuY for ; Mon, 26 Sep 2011 01:06:16 -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 674CF21F8B3F for ; Mon, 26 Sep 2011 01:06:16 -0700 (PDT) Received: by vws5 with SMTP id 5so6537826vws.31 for ; Mon, 26 Sep 2011 01:08:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.69.18 with SMTP id a18mr5489437vdu.430.1317024538163; Mon, 26 Sep 2011 01:08:58 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Mon, 26 Sep 2011 01:08:58 -0700 (PDT) In-Reply-To: References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <4E79A964.2050007@alvestrand.no> <0FEA137C08A9DF4781EEF745038C969430A51F6401@nambx03.corp.adobe.com> Date: Mon, 26 Sep 2011 10:08:58 +0200 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" , Jozsef Vass Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 08:06:17 -0000 2011/9/23 Roman Shpount : > With the API we are discussing (ie have methods to generate an offer, > process an answer or answer update to the last generated offer, process t= he > last offer refusal, process an offer and generate an answer to it) it is > very simple to build a simple point to point RTC call: > > First client uses the API to generate an offer. > > First client sends this offer (at this point it does not matter if offer = is > JSON or SDP encoded, as long as client can get this description and encod= e > it into something that can be send over http), using http post to a web > server. > > Web server stores this offer into some type of storage (local file, in > memory db) > > Second client pulls the web server using some sort of timer for an offer > using http GET. > > As soon as offer is created and stored, web server reads the offer from t= he > storage and sends it to the second client. > > Second client uses API to process the offer and generate an answer. > > Second client sends the answer to the web server using http post. > > Web server stores answer in the storage. > > After sending the offer first client is pulling web server for the offer > using some sort of timer http get. > > As soon as answer is created and stored, web server reads the answer from > the storage and sends it to the first client. > > First client gets an answer from the web server, passes it to the API as = an > answer to the last offer. I strongly agree. Just take into account that the second client could reject the call ("I'm bussy"), so there would not be SDP answer. Of course carrying that information (the call rejection) is responsability of the signaling protocol (which also carries the SDP bodies, as it occurs in SIP and XMPP/Jingle). > Connection is setup!. No SIP is used. But it could be (I mean encapsulating SIP over HTTP or WebSocket) :) So freedom for all. > Application like this can be developed > by a fifth grader as a homework project and installed on any shared hosti= ng > provider. And the audio/video sessions go through the web server so the web application logic can decide wheter to terminate an existing audio/video session (in case an user has been banned from a room-chat, for example). > If you have websockets or some other javascript eventing library > you can make this a lot more interactive. WebSocket is for sure the way to go. > If you do SIP on the other hand, you will end up with a the same or more > work as a developer, will have to install a lot more software on the web > server, Yes. In case the browser must speak native SIP or XMPP that will be the end of this history (because a SIP proxy/registrar or XMPP server would be required for ***each*** website). > will have to learn a whole bunch about new signaling protocols until > you figure out why things do not work. The only server side requirement would be providing a STUN/TURN server (and TURN authentication accounts). --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Mon Sep 26 02:46: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 416E621F8B40 for ; Mon, 26 Sep 2011 02:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.28 X-Spam-Level: X-Spam-Status: No, score=-108.28 tagged_above=-999 required=5 tests=[AWL=1.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lMjLBRa88yJ for ; Mon, 26 Sep 2011 02:46:17 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 070BD21F8B57 for ; Mon, 26 Sep 2011 02:46:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8802B39E112; Mon, 26 Sep 2011 11:48:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGHlnBdChIBM; Mon, 26 Sep 2011 11:48:56 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 44FA139E048; Mon, 26 Sep 2011 11:48:56 +0200 (CEST) Message-ID: <4E804A88.5010301@alvestrand.no> Date: Mon, 26 Sep 2011 11:48:56 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040901080508010505060000" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB and emergency services X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 09:46:18 -0000 This is a multi-part message in MIME format. --------------040901080508010505060000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard, one more architecture-level question: is it appropriate to address requirements on the equipment surrounding the browser in addition to those on the browser and JS running within the browser? For instance, if traffic prioritization is required for proper operation, the CPE and intervening NAT boxes will have to offer functionality for (properly authorized ... aurgh) access to traffic prioritization functions. On 09/26/11 02:13, Bernard Aboba wrote: > I'm putting together a draft on the subject of RTCWEB and emergency > services. However, before submitting this, it seemed useful to get > some feedback from the group on the general direction of the document. > > 1. The overall requirements for emergency services support will vary > by jurisdiction and are likely to change. Therefore the document, > while citing ongoing regulatory proceedings within the US and EU, does > not attempt to provide legal advice or offer a definitive statement of > the regulatory requirements. Instead, the document cites documents > from the ECRIT WG, such as the ECRIT Framework and Phone-BCP documents > which provide guidance on best current or future practices. > > 2. The overall requirements for emergency services support also vary > by the type of service that is being implemented. For example, > adding support for real-time conferencing to a social networking > service or a game (e.g. non-interconnected VoIP) will result in > different requirements than say, implementing a phone dialing service > that can both make outgoing calls and take incoming calls from E.164 > numbers (e.g. interconnected VoIP). > > It should therefore be understood that the burden for implementation > of emergency services falls principally upon the operator of the > service, and that the role of the RTCWEB implementer is to deliver > basic capabilities and to enable an operator to add to this > functionality, rather than providing for every possible need natively > ("I want a pony"). > > 3. The emergency services capabilities of the browser are comprised > of the functionality that is implemented in the browser, as well > functionality that can be added via Javascript libraries. In some > circumstances, it may be viable to supplement functionality with > plugins. For example, a "webphone" intended for use with an IP PBX, > whose firmware is controlled by the IP PBX vendor, could include > within its code load plugins to provide additional functionality, > including signaling protocols and codecs. As a result, it is not > required for an RTCWEB implementation to natively satisfy every > requirement of ECRIT Phone-BCP. Examples of requirements which may > not be satisfiable without plugins include some of the endpoint media > requirements of PhoneBCP Section 14, such as ED-77 (video codec > support). However, it would appear that some of the requirements of > that section such as ED-71 (RTP Support) and ED-73 (G.711 support) are > appropriate. > > 4. With respect to location capabilities, the W3C Location APIs and > associated Location-Based Services are not adequate in terms of their > support for emergency services location. This gap exists in part > because the requirements and scenarios for Location-Based Services > (LBS) are different from those of Location Information Services > (LISes) used for emergency purposes. While in the long-term it may > be possible to close the gaps, in the short term the gaps may be > addressed via Javascript libraries implementing elements of the ECRIT > architecture such as HELD, or even LoST. > > > > > > > In addition, in some scenarios, it is quite feasible for this > > 2. Similarly, the requirements for native browser functionality will > vary according to the scenario. > > 2. In some scenarios, > > > In meeting the requirements for emergency services support, the > important question to answer is what functionality MUST be present > natively within the browser > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------040901080508010505060000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard,
one more architecture-level question:

is it appropriate to address requirements on the equipment surrounding the browser in addition to those on the browser and JS running within the browser?

For instance, if traffic prioritization is required for proper operation, the CPE and intervening NAT boxes will have to offer functionality for (properly authorized ... aurgh) access to traffic prioritization functions.

On 09/26/11 02:13, Bernard Aboba wrote:
I'm putting together a draft on the subject of RTCWEB and emergency services.  However, before submitting this, it seemed useful to get some feedback from the group on the general direction of the document.

1. The overall requirements for emergency services support will vary by jurisdiction and are likely to change.   Therefore the document, while citing ongoing regulatory proceedings within the US and EU, does not attempt to provide legal advice or offer a definitive statement of the regulatory requirements.  Instead, the document cites  documents from the ECRIT WG, such as the ECRIT Framework and Phone-BCP documents which provide guidance on best current or future practices.  

2.  The overall requirements for emergency services support also vary by the type of service that is being implemented.   For example,  adding support for real-time conferencing to a social networking service or a game (e.g. non-interconnected VoIP) will result in different requirements than say, implementing a phone dialing service that can both make outgoing calls and take incoming calls from E.164 numbers (e.g. interconnected VoIP).  

It should therefore be understood that the burden for implementation of emergency services falls principally upon the operator of the service, and that the role of the RTCWEB implementer is to deliver basic capabilities and to enable an operator to add to this functionality, rather than providing for every possible need natively ("I want a pony").  

3.  The emergency services capabilities of the browser are comprised of the functionality that is implemented in the browser, as well functionality that can be added via Javascript libraries.   In some circumstances, it may be viable to supplement functionality with plugins.  For example, a "webphone" intended for use with an IP PBX, whose firmware is controlled by the IP PBX vendor,  could include within its code load plugins to provide additional functionality, including signaling protocols and codecs.  As a result, it is not required for an RTCWEB implementation to natively satisfy every requirement of ECRIT Phone-BCP.    Examples of requirements which may not be satisfiable without plugins include some of the endpoint media requirements of PhoneBCP Section 14, such as ED-77 (video codec support).   However, it would appear that some of the requirements of that section such as ED-71 (RTP Support) and ED-73 (G.711 support) are appropriate. 

4. With respect to location capabilities, the W3C Location APIs and associated Location-Based Services are not adequate in terms of their support for emergency services location.  This gap exists in part because the requirements and scenarios for  Location-Based Services (LBS) are different from those of Location Information Services (LISes) used for emergency purposes.   While in the long-term it may be possible to close the gaps,  in the short term the gaps may be addressed via Javascript libraries implementing elements of the ECRIT architecture such as HELD, or even LoST.  






In addition, in some scenarios, it is quite feasible for this

2.  Similarly, the requirements for native browser functionality will vary according to the scenario. 

2. In some scenarios,


 In meeting the requirements for emergency services support, the important question to answer is what functionality MUST be present natively within the browser



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

--------------040901080508010505060000-- From harald@alvestrand.no Mon Sep 26 02:55: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 E649221F8B57 for ; Mon, 26 Sep 2011 02:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.915 X-Spam-Level: X-Spam-Status: No, score=-108.915 tagged_above=-999 required=5 tests=[AWL=1.684, 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 QCPo5WAGHNX4 for ; Mon, 26 Sep 2011 02:55:02 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F165921F8B40 for ; Mon, 26 Sep 2011 02:55:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DD5C839E112; Mon, 26 Sep 2011 11:57:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOgTFURTE3+F; Mon, 26 Sep 2011 11:57:43 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 2CFB939E048; Mon, 26 Sep 2011 11:57:43 +0200 (CEST) Message-ID: <4E804C96.1090701@alvestrand.no> Date: Mon, 26 Sep 2011 11:57:42 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Magnus Westerlund References: <4E801CFE.4030504@ericsson.com> In-Reply-To: <4E801CFE.4030504@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-use-cases-and-requirements-05 addition around IPv6 only and dualstack X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 09:55:03 -0000 On 09/26/11 08:34, Magnus Westerlund wrote: > Hi, > > (as individual) > > I would suggest that some section for general requirements that aren't > use case specific is created and at least one such requirement is added. > > The requirement is the need to support IPv4 only, IPv6 only and > dual-stack deployments as required by our charter. I think this should > be added into the use-case and requirement document for two reasons. > First, that is located next to the other requirements, secondly because > W3C has decided to use our document also, I think it is important that > such a general requirement both on protocols and any address field in > the API handling both address families are covered. I support adding those requirements. I think that it can also be instantiated within the specific use cases, such as: - Point to point call: One endpoint on IPv4, the other endpoint on IPv6 - Multipoint call (with and without central server): One user on IPv4, one user on IPv6 This is a limitation of the use-case-based model; it gets messy to shoehorn all the "permutations" of situations into a single set of use cases, without the list of use cases growing impossibly long or the use cases' description expanding into incomprehensibility. On balance, I think having a "considerations applicable to all scenarios" section saying: - Clients can be on IPv4-only - Clients can be on IPv6-only - Clients can be on dual-stack - Clients can be on wideband (10s of Mbits/sec) - Clients can be on narrowband (10s to 100s of Kbits/sec) - Clients can be on variable-media-quality networks (wireless) - Clients can be on congested networks - Clients can be on firewalled networks with no UDP allowed - Clients can be on networks with cone NAT - Clients can be on networks with symmetric NAT might be a good way to go forward. A particular query on v4/v6 interoperation: Should we make it a requirement that dual-stack to IPv4 always use the IPv4 native path rather than a gateway functionality (and the converse for IPv6), or should we just be silent about it? I think it may affect some tuning of the ICE address selection algorithm, in particular if we encounter 6to4 addresses. There might be RFCs we can cite already. > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Frgatan 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 stefan.lk.hakansson@ericsson.com Mon Sep 26 05:24: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 7568F21F8C06 for ; Mon, 26 Sep 2011 05:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.334 X-Spam-Level: X-Spam-Status: No, score=-6.334 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 oDYTnCqRDMDw for ; Mon, 26 Sep 2011 05:24:30 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8723E21F8BEF for ; Mon, 26 Sep 2011 05:24:30 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-37-4e806fa0ac04 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.115.96]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 47.41.20773.0AF608E4; Mon, 26 Sep 2011 14:27:12 +0200 (CEST) Received: from [150.132.141.36] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Mon, 26 Sep 2011 14:27:05 +0200 Message-ID: <4E806F99.1080104@ericsson.com> Date: Mon, 26 Sep 2011 14:27:05 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E801CFE.4030504@ericsson.com> <4E804C96.1090701@alvestrand.no> In-Reply-To: <4E804C96.1090701@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] draft-ietf-rtcweb-use-cases-and-requirements-05 addition around IPv6 only and dualstack X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 12:24:31 -0000 Hi, as editor: I have some difficulties right now to judge what should be in and what should be out (in terms of use cases). I think some more consensus calls might be needed, but I need guidance from the chairs. Then there are some pieces that are discussed that are not really new use cases, but things that could be added existing ones or as a separate section. I keep a list of these at the *W3C* webrtc WiKi (because that is convenient to me, and to show that there are two stakeholders!): Please give me a heads up of the things I have missed to put in that list. Stefan On 2011-09-26 11:57, Harald Alvestrand wrote: > On 09/26/11 08:34, Magnus Westerlund wrote: >> Hi, >> >> (as individual) >> >> I would suggest that some section for general requirements that aren't >> use case specific is created and at least one such requirement is added. >> >> The requirement is the need to support IPv4 only, IPv6 only and >> dual-stack deployments as required by our charter. I think this should >> be added into the use-case and requirement document for two reasons. >> First, that is located next to the other requirements, secondly because >> W3C has decided to use our document also, I think it is important that >> such a general requirement both on protocols and any address field in >> the API handling both address families are covered. > I support adding those requirements. > > I think that it can also be instantiated within the specific use cases, > such as: > - Point to point call: One endpoint on IPv4, the other endpoint on IPv6 > - Multipoint call (with and without central server): One user on IPv4, > one user on IPv6 > > This is a limitation of the use-case-based model; it gets messy to > shoehorn all the "permutations" of situations into a single set of use > cases, without the list of use cases growing impossibly long or the use > cases' description expanding into incomprehensibility. > > On balance, I think having a "considerations applicable to all > scenarios" section saying: > > - Clients can be on IPv4-only > - Clients can be on IPv6-only > - Clients can be on dual-stack > - Clients can be on wideband (10s of Mbits/sec) > - Clients can be on narrowband (10s to 100s of Kbits/sec) > - Clients can be on variable-media-quality networks (wireless) > - Clients can be on congested networks > - Clients can be on firewalled networks with no UDP allowed > - Clients can be on networks with cone NAT > - Clients can be on networks with symmetric NAT > > might be a good way to go forward. > > A particular query on v4/v6 interoperation: Should we make it a > requirement that dual-stack to IPv4 always use the IPv4 native path > rather than a gateway functionality (and the converse for IPv6), or > should we just be silent about it? > I think it may affect some tuning of the ICE address selection > algorithm, in particular if we encounter 6to4 addresses. There might be > RFCs we can cite already. > > >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Frgatan 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 roman@telurix.com Mon Sep 26 07:27: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 B7A2B21F8C6A for ; Mon, 26 Sep 2011 07:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[AWL=-2.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 aJPL7WVyB8iK for ; Mon, 26 Sep 2011 07:27:24 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD3221F8C69 for ; Mon, 26 Sep 2011 07:27:23 -0700 (PDT) Received: by qyk32 with SMTP id 32so9885617qyk.10 for ; Mon, 26 Sep 2011 07:30:04 -0700 (PDT) Received: by 10.229.46.65 with SMTP id i1mr4839421qcf.86.1317047401289; Mon, 26 Sep 2011 07:30:01 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id he10sm14214469qab.25.2011.09.26.07.30.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Sep 2011 07:30:00 -0700 (PDT) Received: by gyd12 with SMTP id 12so5261526gyd.31 for ; Mon, 26 Sep 2011 07:29:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.22.105 with SMTP id c9mr29785624pbf.88.1317047399199; Mon, 26 Sep 2011 07:29:59 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Mon, 26 Sep 2011 07:29:59 -0700 (PDT) Date: Mon, 26 Sep 2011 10:29:59 -0400 Message-ID: From: Roman Shpount To: Randell Jesup Content-Type: multipart/alternative; boundary=bcaec52154c561b3ea04add8fe65 Cc: rtcweb@ietf.org Subject: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 14:27:24 -0000 --bcaec52154c561b3ea04add8fe65 Content-Type: text/plain; charset=ISO-8859-1 I think requiring ICE in RTC is not only unfortunate, it will make it impossible to connect to PSTN without media gateway. If we complete this specification, and phone carriers decide that there is a business case for them to support RTC clients directly, it will take them 3-5 years to implement ICE in SBC. From what I've seen major carriers run SBC firmware which is normally 2-3 years old. If we add time it takes to implement ICE in SBC, plus time it will take PSTN provider to verify and test the feature, we are easily looking into 5 year time frame. Since we need to have user confirmation to start a media call anyway, and since this is not going to be any different from what SIP clients are currently doing, it would make sense to allow a plain non-ICE, non-SRTP call. Finally, ICE specification are desinged to interop with non-ICE end points. We will need to change ICE to accomplish what you are doing. _____________ Roman Shpount On Mon, Sep 26, 2011 at 1:23 AM, Randell Jesup wrote: > On 9/22/2011 4:37 PM, Cullen Jennings wrote: > >> On Sep 22, 2011, at 2:04 PM, Christer Holmberg wrote: >> >> If so, what is your assumption then regarding ICE? That the SIP nodes >>> will support ICE, or that the browser will be allowed to communicate with >>> the SIP nodes without enabling ICE? >>> >> I see no way of solving the security problems without having ICE or >> something more or less like it. Therefore, I'm working on the assumption >> that it will only work if the SIP side supports ICE, or is front ended by a >> SBC with media GW that does ICE. In the short term, there will be some >> devices that don't do ICE but SIP devices are increasingly having ICE added. >> Particularly SIP devices that are internet facing because the need for NAT >> traversal. >> >> I find requiring ICE to be a very unfortunate assumption to have to make - >> obviously it reduces the number of legacy voip devices WebRTC devices can >> talk to without an SBC but I don't see any way around this limitation. >> Allowing web browsers inside the firewall to send packets to an arbitrary >> address that is inside the firewall with no validation that address speaks >> RTP is not acceptable. >> > > I agree we can't solve the security issue with permission to send with the > current threat model without ICE or some equivalent. > > There is another option that may help with some of the use cases (I've > mentioned > this before in the discussion on screensharing, among others). For a > number > of the use cases security is an impassible problem with the current threat > model. > Those use cases generally involve replacing cases where an existing desktop > install or plugin was used (webex, screensharing, vnc, SIP softclient, > Skype, etc). > Those cases all currently involve the user implicitly giving these apps > total > or close to code that could do pretty much anything on the user's computer, > and are also often the "ongoing usage" authentication cases. > > The only mitigating safety of the external app/plugin model is that they're > typically > signed and go through the platforms software-install procedure, > cert-showing, UACs, etc. > > Currently people are trying to work out the HTML5 "installed" webapp > security model; > if that's far enough along we may be able to piggyback off that. I'm > looking into it. > > > -- > Randell Jesup > randell-ietf@jesup.org > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --bcaec52154c561b3ea04add8fe65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think requiring ICE in RTC is not only unfortunate, it will make it impos= sible to connect to PSTN without media gateway. If we complete this specifi= cation, and phone carriers decide that there is a business case for them to= support RTC clients directly, it will take them 3-5 years to implement ICE= in SBC. From what I've seen major carriers run SBC firmware which is n= ormally 2-3 years old. If we add time it takes to implement ICE in SBC, plu= s time it will take PSTN provider to verify and test the feature, we are ea= sily looking into 5 year time frame.

Since we need to have user confirmation to start a media call anyway, a= nd since this is not going to be any different from what SIP clients are cu= rrently doing, it would make sense to allow a plain non-ICE, non-SRTP call.=

Finally, ICE specification are desinged to interop with non-ICE end poi= nts. We will need to change ICE to accomplish what you are doing.
_____________
Roman Shpount


On Mon, Sep 26, 2011 at 1:23 AM, Randell= Jesup <rand= ell-ietf@jesup.org> wrote:
On 9/22/2011 4:37 PM, Cullen Jennings wrote:
On Sep 22, 2011, at 2:04 PM, Christer Holmberg wrote:

If so, what is your assumption then regarding ICE? That the SIP nodes will = support ICE, or that the browser will be allowed to communicate with the SI= P nodes without enabling ICE?
I see no way of solving the security problems without having ICE or somethi= ng more or less like it. Therefore, I'm working on the assumption that = it will only work if the SIP side supports ICE, or is front ended by a SBC = with media GW that does ICE. In the short term, there will be some devices = that don't do ICE but SIP devices are increasingly having ICE added. Pa= rticularly SIP devices that are internet facing because the need for NAT tr= aversal.

I find requiring ICE to be a very unfortunate assumption to have to make - = obviously it reduces the number of legacy voip devices WebRTC devices can t= alk to without an SBC but I don't see any way around this limitation. A= llowing web browsers inside the firewall to send packets to an arbitrary ad= dress that is inside the firewall with no validation that address speaks RT= P is not acceptable.

I agree we can't solve the security issue with permission to send with = the
current threat model without ICE or some equivalent.

There is another option that may help with some of the use cases (I've = mentioned
this before in the discussion on screensharing, among others). =A0For a num= ber
of the use cases security is an impassible problem with the current threat = model.
Those use cases generally involve replacing cases where an existing desktop=
install or plugin was used (webex, screensharing, vnc, SIP softclient, Skyp= e, etc).
Those cases all currently involve the user implicitly giving these apps tot= al
or close to code that could do pretty much anything on the user's compu= ter,
and are also often the "ongoing usage" authentication cases.

The only mitigating safety of the external app/plugin model is that they= 9;re typically
signed and go through the platforms software-install procedure, cert-showin= g, UACs, etc.

Currently people are trying to work out the HTML5 "installed" web= app security model;
if that's far enough along we may be able to piggyback off that. =A0 I&= #39;m looking into it.


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

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

--bcaec52154c561b3ea04add8fe65-- From cb.list6@gmail.com Mon Sep 26 07:28: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 2E31A21F8D7A for ; Mon, 26 Sep 2011 07:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.140, 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 G4MYwpqyh0QN for ; Mon, 26 Sep 2011 07:28:33 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0E621F8D79 for ; Mon, 26 Sep 2011 07:28:33 -0700 (PDT) Received: by pzk37 with SMTP id 37so15786377pzk.9 for ; Mon, 26 Sep 2011 07:31:16 -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=RiadtKfXKS2tVYnXdqRCyDUmJzFKAiD9XgY7j+VlgP0=; b=Uc4oo0LrVyAjbpW5w2DOvdvFOS7l80eHoCYNhmaYSiu6uQaqRIfxrfZWcAXfhNwz+C Qq3vrmyw0sImJn/YzFm0+qYvBDlLr5toJQbj9BWmwtQ/bxeWeelFnc1eXryTxetuL2mP JHd2n0RsLDQvKeSUVbYB/Zo00qw+XD7IOKtgk= MIME-Version: 1.0 Received: by 10.68.17.193 with SMTP id q1mr21179097pbd.98.1317047476396; Mon, 26 Sep 2011 07:31:16 -0700 (PDT) Received: by 10.142.89.1 with HTTP; Mon, 26 Sep 2011 07:31:16 -0700 (PDT) Received: by 10.142.89.1 with HTTP; Mon, 26 Sep 2011 07:31:16 -0700 (PDT) In-Reply-To: <4E801CFE.4030504@ericsson.com> References: <4E801CFE.4030504@ericsson.com> Date: Mon, 26 Sep 2011 07:31:16 -0700 Message-ID: From: Cameron Byrne To: Magnus Westerlund Content-Type: multipart/alternative; boundary=bcaec520ea43fba33604add90257 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-use-cases-and-requirements-05 addition around IPv6 only and dualstack X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 14:28:34 -0000 --bcaec520ea43fba33604add90257 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sep 25, 2011 11:34 PM, "Magnus Westerlund" < magnus.westerlund@ericsson.com> wrote: > > Hi, > > (as individual) > > I would suggest that some section for general requirements that aren't > use case specific is created and at least one such requirement is added. > > The requirement is the need to support IPv4 only, IPv6 only and > dual-stack deployments as required by our charter. I think this should > be added into the use-case and requirement document for two reasons. > First, that is located next to the other requirements, secondly because > W3C has decided to use our document also, I think it is important that > such a general requirement both on protocols and any address field in > the API handling both address families are covered. > +1 Cb > 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 --bcaec520ea43fba33604add90257 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 25, 2011 11:34 PM, "Magnus Westerlund" <magnus.westerlund@ericsson.com> w= rote:
>
> Hi,
>
> (as individual)
>
> I would suggest that some section for general requirements that aren&#= 39;t
> use case specific is created and at least one such requirement is adde= d.
>
> The requirement is the need to support IPv4 only, IPv6 only and
> dual-stack deployments as required by our charter. I think this should=
> be added into the use-case and requirement document for two reasons. > First, that is located next to the other requirements, secondly becaus= e
> W3C has decided to use our document also, I think it is important that=
> such a general requirement both on protocols and any address field in<= br> > the API handling both address families are covered.
>

+1
Cb

> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------=
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------=
> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 > F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079=
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------=
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb

--bcaec520ea43fba33604add90257-- From cb.list6@gmail.com Mon Sep 26 07:43: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 2B29321F8D71 for ; Mon, 26 Sep 2011 07:43:10 -0700 (PDT) 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.569, 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 5oc0VvYtnlk0 for ; Mon, 26 Sep 2011 07:43:09 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEB821F8D70 for ; Mon, 26 Sep 2011 07:43:09 -0700 (PDT) Received: by pzk37 with SMTP id 37so15820099pzk.9 for ; Mon, 26 Sep 2011 07:45:52 -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=X6VQ7uMRjCXXaF+RpUUGHGbuBAojNAybQmB61TAz8Mg=; b=Y4Ym/Tb9uC+dlQzQtvKgnnpaqFKiCux05YF952HIg+DlbWRps0mlN7yxeNIiNT4MmE YUsjOqlIH74/UrG/fJvDWTtS0hZFYoMO1bf8KWFq2HeAcBrOTE4UrAIJ2zT00jsXbCFl Umhdpws7+awdKhq7m33HZgZfvsA+1Mh59Kc20= MIME-Version: 1.0 Received: by 10.68.39.230 with SMTP id s6mr30279785pbk.81.1317048350695; Mon, 26 Sep 2011 07:45:50 -0700 (PDT) Received: by 10.142.89.1 with HTTP; Mon, 26 Sep 2011 07:45:50 -0700 (PDT) Received: by 10.142.89.1 with HTTP; Mon, 26 Sep 2011 07:45:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Sep 2011 07:45:50 -0700 Message-ID: From: Cameron Byrne To: Roman Shpount Content-Type: multipart/alternative; boundary=bcaec520f41518607004add93758 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 14:43:10 -0000 --bcaec520f41518607004add93758 Content-Type: text/plain; charset=ISO-8859-1 On Sep 26, 2011 7:30 AM, "Roman Shpount" wrote: > > I think requiring ICE in RTC is not only unfortunate, it will make it impossible to connect to PSTN without media gateway. If we complete this specification, and phone carriers decide that there is a business case for them to support RTC clients directly, it will take them 3-5 years to implement ICE in SBC. From what I've seen major carriers run SBC firmware which is normally 2-3 years old. If we add time it takes to implement ICE in SBC, plus time it will take PSTN provider to verify and test the feature, we are easily looking into 5 year time frame. > > Since we need to have user confirmation to start a media call anyway, and since this is not going to be any different from what SIP clients are currently doing, it would make sense to allow a plain non-ICE, non-SRTP call. > > Finally, ICE specification are desinged to interop with non-ICE end points. We will need to change ICE to accomplish what you are doing. > Maybe I misundersatnd you, but the PSTN carriers today and in the future will always run an SBC because that is their security policy. Regarding firmware, they react to market needs and timing. Cb _____________ > Roman Shpount > > > On Mon, Sep 26, 2011 at 1:23 AM, Randell Jesup wrote: >> >> On 9/22/2011 4:37 PM, Cullen Jennings wrote: >>> >>> On Sep 22, 2011, at 2:04 PM, Christer Holmberg wrote: >>> >>>> If so, what is your assumption then regarding ICE? That the SIP nodes will support ICE, or that the browser will be allowed to communicate with the SIP nodes without enabling ICE? >>> >>> I see no way of solving the security problems without having ICE or something more or less like it. Therefore, I'm working on the assumption that it will only work if the SIP side supports ICE, or is front ended by a SBC with media GW that does ICE. In the short term, there will be some devices that don't do ICE but SIP devices are increasingly having ICE added. Particularly SIP devices that are internet facing because the need for NAT traversal. >>> >>> I find requiring ICE to be a very unfortunate assumption to have to make - obviously it reduces the number of legacy voip devices WebRTC devices can talk to without an SBC but I don't see any way around this limitation. Allowing web browsers inside the firewall to send packets to an arbitrary address that is inside the firewall with no validation that address speaks RTP is not acceptable. >> >> >> I agree we can't solve the security issue with permission to send with the >> current threat model without ICE or some equivalent. >> >> There is another option that may help with some of the use cases (I've mentioned >> this before in the discussion on screensharing, among others). For a number >> of the use cases security is an impassible problem with the current threat model. >> Those use cases generally involve replacing cases where an existing desktop >> install or plugin was used (webex, screensharing, vnc, SIP softclient, Skype, etc). >> Those cases all currently involve the user implicitly giving these apps total >> or close to code that could do pretty much anything on the user's computer, >> and are also often the "ongoing usage" authentication cases. >> >> The only mitigating safety of the external app/plugin model is that they're typically >> signed and go through the platforms software-install procedure, cert-showing, UACs, etc. >> >> Currently people are trying to work out the HTML5 "installed" webapp security model; >> if that's far enough along we may be able to piggyback off that. I'm looking into it. >> >> >> -- >> Randell Jesup >> randell-ietf@jesup.org >> >> _______________________________________________ >> 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 > --bcaec520f41518607004add93758 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 26, 2011 7:30 AM, "Roman Shpount" <roman@telurix.com> wrote:
>
> I think requiring ICE in RTC is not only unfortunate, it will make it = impossible to connect to PSTN without media gateway. If we complete this sp= ecification, and phone carriers decide that there is a business case for th= em to support RTC clients directly, it will take them 3-5 years to implemen= t ICE in SBC. From what I've seen major carriers run SBC firmware which= is normally 2-3 years old. If we add time it takes to implement ICE in SBC= , plus time it will take PSTN provider to verify and test the feature, we a= re easily looking into 5 year time frame.
>
> Since we need to have user confirmation to start a media call anyway, = and since this is not going to be any different from what SIP clients are c= urrently doing, it would make sense to allow a plain non-ICE, non-SRTP call= .
>
> Finally, ICE specification are desinged to interop with non-ICE end po= ints. We will need to change ICE to accomplish what you are doing.
>

Maybe I misundersatnd you, but the PSTN carriers today and in the future= will always run an SBC because that is their security policy.

Regarding firmware, they react to market needs and timing.

Cb

_____________
> Roman Shpount
>
>
> On Mon, Sep 26, 2011 at 1:23 AM, Randell Jesup <randell-ietf@jesup.org> wrote:
>>
>> On 9/22/2011 4:37 PM, Cullen Jennings wrote:
>>>
>>> On Sep 22, 2011, at 2:04 PM, Christer Holmberg wrote:
>>>
>>>> If so, what is your assumption then regarding ICE? That th= e SIP nodes will support ICE, or that the browser will be allowed to commun= icate with the SIP nodes without enabling ICE?
>>>
>>> I see no way of solving the security problems without having I= CE or something more or less like it. Therefore, I'm working on the ass= umption that it will only work if the SIP side supports ICE, or is front en= ded by a SBC with media GW that does ICE. In the short term, there will be = some devices that don't do ICE but SIP devices are increasingly having = ICE added. Particularly SIP devices that are internet facing because the ne= ed for NAT traversal.
>>>
>>> I find requiring ICE to be a very unfortunate assumption to ha= ve to make - obviously it reduces the number of legacy voip devices WebRTC = devices can talk to without an SBC but I don't see any way around this = limitation. Allowing web browsers inside the firewall to send packets to an= arbitrary address that is inside the firewall with no validation that addr= ess speaks RTP is not acceptable.
>>
>>
>> I agree we can't solve the security issue with permission to s= end with the
>> current threat model without ICE or some equivalent.
>>
>> There is another option that may help with some of the use cases (= I've mentioned
>> this before in the discussion on screensharing, among others). =A0= For a number
>> of the use cases security is an impassible problem with the curren= t threat model.
>> Those use cases generally involve replacing cases where an existin= g desktop
>> install or plugin was used (webex, screensharing, vnc, SIP softcli= ent, Skype, etc).
>> Those cases all currently involve the user implicitly giving these= apps total
>> or close to code that could do pretty much anything on the user= 9;s computer,
>> and are also often the "ongoing usage" authentication ca= ses.
>>
>> The only mitigating safety of the external app/plugin model is tha= t they're typically
>> signed and go through the platforms software-install procedure, ce= rt-showing, UACs, etc.
>>
>> Currently people are trying to work out the HTML5 "installed&= quot; webapp security model;
>> if that's far enough along we may be able to piggyback off tha= t. =A0 I'm looking into it.
>>
>>
>> --
>> Randell Jesup
>> randell-ietf@jesup.org
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://w= ww.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.i= etf.org/mailman/listinfo/rtcweb
>

--bcaec520f41518607004add93758-- From roman@telurix.com Mon Sep 26 07:49: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 2AEE521F8DD2 for ; Mon, 26 Sep 2011 07:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 E1ojJumdjucS for ; Mon, 26 Sep 2011 07:49:45 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23A0F21F8DD1 for ; Mon, 26 Sep 2011 07:49:45 -0700 (PDT) Received: by qyk32 with SMTP id 32so9909582qyk.10 for ; Mon, 26 Sep 2011 07:52:27 -0700 (PDT) Received: by 10.229.67.196 with SMTP id s4mr4909774qci.192.1317048747778; Mon, 26 Sep 2011 07:52:27 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id z17sm21779524qap.19.2011.09.26.07.52.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Sep 2011 07:52:27 -0700 (PDT) Received: by ywa6 with SMTP id 6so5456967ywa.31 for ; Mon, 26 Sep 2011 07:52:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.12.162 with SMTP id z2mr30015936pbb.122.1317048746229; Mon, 26 Sep 2011 07:52:26 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Mon, 26 Sep 2011 07:52:25 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Sep 2011 10:52:25 -0400 Message-ID: From: Roman Shpount To: Cameron Byrne Content-Type: multipart/alternative; boundary=bcaec5215f65abbfc004add94e86 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 14:49:46 -0000 --bcaec5215f65abbfc004add94e86 Content-Type: text/plain; charset=ISO-8859-1 PSTN carriers today almost always run SBCs. At the same time I have not seen an SBC from any major US carrier with firmware newer the 2 years old. I've never seen an SBC in carrier deployment that currently supports ICE or SRTP. Bottom line, no carriers currently support ICE or SRTP. If we create the market requirements for them to support ICE and SRTP, it will take them 3-5 years to add such support. If we have anybody from SBC manufacturing companies or carriers who can provide evidence to the opposite, I would love to hear from them. In any case, it would be prudent to provide a way to use current non-ICE, non-SRTP with RTC. _____________ Roman Shpount On Mon, Sep 26, 2011 at 10:45 AM, Cameron Byrne wrote: > > On Sep 26, 2011 7:30 AM, "Roman Shpount" wrote: > > > > I think requiring ICE in RTC is not only unfortunate, it will make it > impossible to connect to PSTN without media gateway. If we complete this > specification, and phone carriers decide that there is a business case for > them to support RTC clients directly, it will take them 3-5 years to > implement ICE in SBC. From what I've seen major carriers run SBC firmware > which is normally 2-3 years old. If we add time it takes to implement ICE in > SBC, plus time it will take PSTN provider to verify and test the feature, we > are easily looking into 5 year time frame. > > > > Since we need to have user confirmation to start a media call anyway, and > since this is not going to be any different from what SIP clients are > currently doing, it would make sense to allow a plain non-ICE, non-SRTP > call. > > > > Finally, ICE specification are desinged to interop with non-ICE end > points. We will need to change ICE to accomplish what you are doing. > > > > Maybe I misundersatnd you, but the PSTN carriers today and in the future > will always run an SBC because that is their security policy. > > Regarding firmware, they react to market needs and timing. > > Cb > > _____________ > > Roman Shpount > > > > > > On Mon, Sep 26, 2011 at 1:23 AM, Randell Jesup > wrote: > >> > >> On 9/22/2011 4:37 PM, Cullen Jennings wrote: > >>> > >>> On Sep 22, 2011, at 2:04 PM, Christer Holmberg wrote: > >>> > >>>> If so, what is your assumption then regarding ICE? That the SIP nodes > will support ICE, or that the browser will be allowed to communicate with > the SIP nodes without enabling ICE? > >>> > >>> I see no way of solving the security problems without having ICE or > something more or less like it. Therefore, I'm working on the assumption > that it will only work if the SIP side supports ICE, or is front ended by a > SBC with media GW that does ICE. In the short term, there will be some > devices that don't do ICE but SIP devices are increasingly having ICE added. > Particularly SIP devices that are internet facing because the need for NAT > traversal. > >>> > >>> I find requiring ICE to be a very unfortunate assumption to have to > make - obviously it reduces the number of legacy voip devices WebRTC devices > can talk to without an SBC but I don't see any way around this limitation. > Allowing web browsers inside the firewall to send packets to an arbitrary > address that is inside the firewall with no validation that address speaks > RTP is not acceptable. > >> > >> > >> I agree we can't solve the security issue with permission to send with > the > >> current threat model without ICE or some equivalent. > >> > >> There is another option that may help with some of the use cases (I've > mentioned > >> this before in the discussion on screensharing, among others). For a > number > >> of the use cases security is an impassible problem with the current > threat model. > >> Those use cases generally involve replacing cases where an existing > desktop > >> install or plugin was used (webex, screensharing, vnc, SIP softclient, > Skype, etc). > >> Those cases all currently involve the user implicitly giving these apps > total > >> or close to code that could do pretty much anything on the user's > computer, > >> and are also often the "ongoing usage" authentication cases. > >> > >> The only mitigating safety of the external app/plugin model is that > they're typically > >> signed and go through the platforms software-install procedure, > cert-showing, UACs, etc. > >> > >> Currently people are trying to work out the HTML5 "installed" webapp > security model; > >> if that's far enough along we may be able to piggyback off that. I'm > looking into it. > >> > >> > >> -- > >> Randell Jesup > >> randell-ietf@jesup.org > >> > >> _______________________________________________ > >> 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 > > > --bcaec5215f65abbfc004add94e86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable PSTN carriers today almost always run SBCs. At the same time I have not see= n an SBC from any major US carrier with firmware newer the 2 years old. I&#= 39;ve never seen an SBC in carrier deployment that currently supports ICE o= r SRTP.

Bottom line, no carriers currently support ICE or SRTP. If we create th= e market requirements for them to support ICE and SRTP, it will take them 3= -5 years to add such support. If we have anybody from SBC manufacturing com= panies or carriers who can provide evidence to the opposite, I would love t= o hear from them. In any case, it would be prudent to provide a way to use = current non-ICE, non-SRTP with RTC.
_____________
Roman Shpount


On Mon, Sep 26, 2011 at 10:45 AM, Camero= n Byrne <cb.list= 6@gmail.com> wrote:


On Sep 26, 2011 7:30 AM, "Roman Shpount" <roman@telurix.com> wrote:
>
> I think requiring ICE in RTC is not only unfortunate, it will make it = impossible to connect to PSTN without media gateway. If we complete this sp= ecification, and phone carriers decide that there is a business case for th= em to support RTC clients directly, it will take them 3-5 years to implemen= t ICE in SBC. From what I've seen major carriers run SBC firmware which= is normally 2-3 years old. If we add time it takes to implement ICE in SBC= , plus time it will take PSTN provider to verify and test the feature, we a= re easily looking into 5 year time frame.
>
> Since we need to have user confirmation to start a media call anyway, = and since this is not going to be any different from what SIP clients are c= urrently doing, it would make sense to allow a plain non-ICE, non-SRTP call= .
>
> Finally, ICE specification are desinged to interop with non-ICE end po= ints. We will need to change ICE to accomplish what you are doing.
>

Maybe I misundersatnd you, but the PSTN carriers today and in the = future will always run an SBC because that is their security policy.

Regarding firmware, they react to market needs and timing.

Cb

_____________
> Roman Shpount
>
>
> On Mon, Sep 26, 2011 at 1:23 AM, Randell Jesup <randell-ietf@jesup.org> wro= te:
>>
>> On 9/22/2011 4:37 PM, Cullen Jennings wrote:
>>>
>>> On Sep 22, 2011, at 2:04 PM, Christer Holmberg wrote:
>>>
>>>> If so, what is your assumption then regarding ICE? That th= e SIP nodes will support ICE, or that the browser will be allowed to commun= icate with the SIP nodes without enabling ICE?
>>>
>>> I see no way of solving the security problems without having I= CE or something more or less like it. Therefore, I'm working on the ass= umption that it will only work if the SIP side supports ICE, or is front en= ded by a SBC with media GW that does ICE. In the short term, there will be = some devices that don't do ICE but SIP devices are increasingly having = ICE added. Particularly SIP devices that are internet facing because the ne= ed for NAT traversal.
>>>
>>> I find requiring ICE to be a very unfortunate assumption to ha= ve to make - obviously it reduces the number of legacy voip devices WebRTC = devices can talk to without an SBC but I don't see any way around this = limitation. Allowing web browsers inside the firewall to send packets to an= arbitrary address that is inside the firewall with no validation that addr= ess speaks RTP is not acceptable.
>>
>>
>> I agree we can't solve the security issue with permission to s= end with the
>> current threat model without ICE or some equivalent.
>>
>> There is another option that may help with some of the use cases (= I've mentioned
>> this before in the discussion on screensharing, among others). =A0= For a number
>> of the use cases security is an impassible problem with the curren= t threat model.
>> Those use cases generally involve replacing cases where an existin= g desktop
>> install or plugin was used (webex, screensharing, vnc, SIP softcli= ent, Skype, etc).
>> Those cases all currently involve the user implicitly giving these= apps total
>> or close to code that could do pretty much anything on the user= 9;s computer,
>> and are also often the "ongoing usage" authentication ca= ses.
>>
>> The only mitigating safety of the external app/plugin model is tha= t they're typically
>> signed and go through the platforms software-install procedure, ce= rt-showing, UACs, etc.
>>
>> Currently people are trying to work out the HTML5 "installed&= quot; webapp security model;
>> if that's far enough along we may be able to piggyback off tha= t. =A0 I'm looking into it.
>>
>>
>> --
>> Randell Jesup
>> randel= l-ietf@jesup.org
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


--bcaec5215f65abbfc004add94e86-- From cb.list6@gmail.com Mon Sep 26 08:00: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 3687F21F8DE3 for ; Mon, 26 Sep 2011 08:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.88 X-Spam-Level: X-Spam-Status: No, score=-2.88 tagged_above=-999 required=5 tests=[AWL=-0.522, 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 Tv1CT1JgdTh0 for ; Mon, 26 Sep 2011 08:00:41 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5BC21F8CF7 for ; Mon, 26 Sep 2011 08:00:41 -0700 (PDT) Received: by pzk37 with SMTP id 37so15859107pzk.9 for ; Mon, 26 Sep 2011 08:03:23 -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=zgGahYTYcjm5wM+vBvEEb+E5k1ubPDAxf7am8+88t+U=; b=ZkDrByy6D/lDcNNx7xNTlsSYPX9RlckYGRGmVOe1WMS4NpRtbsG2vTMZZrJVR5ixLb q105vBSNc9OFR9Ac5EHNxmIvN/6973NMjTKM0vRJqziy9cWQEZhSQ5J8fk7aLqKgpk/M NfEmVIRQgAgBmT53uz/0YXrkHtWINche/dZ4Y= MIME-Version: 1.0 Received: by 10.68.39.230 with SMTP id s6mr30381331pbk.81.1317049403064; Mon, 26 Sep 2011 08:03:23 -0700 (PDT) Received: by 10.142.89.1 with HTTP; Mon, 26 Sep 2011 08:03:23 -0700 (PDT) Received: by 10.142.89.1 with HTTP; Mon, 26 Sep 2011 08:03:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Sep 2011 08:03:23 -0700 Message-ID: From: Cameron Byrne To: Roman Shpount Content-Type: multipart/alternative; boundary=bcaec520f415d23fc604add9756a Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 15:00:42 -0000 --bcaec520f415d23fc604add9756a Content-Type: text/plain; charset=ISO-8859-1 On Sep 26, 2011 7:52 AM, "Roman Shpount" wrote: > > PSTN carriers today almost always run SBCs. At the same time I have not seen an SBC from any major US carrier with firmware newer the 2 years old. I've never seen an SBC in carrier deployment that currently supports ICE or SRTP. > > Bottom line, no carriers currently support ICE or SRTP. If we create the market requirements for them to support ICE and SRTP, it will take them 3-5 years to add such support. If we have anybody from SBC manufacturing companies or carriers who can provide evidence to the opposite, I would love to hear from them. In any case, it would be prudent to provide a way to use current non-ICE, non-SRTP with RTC. > _____________ > Roman Shpount > I am with a mobile carrier that does FMC and we have products that use SRTP to an SBC today. I don't know about ICE, but I think your projection is clearly not true. If other carriers delay, I am glad to take their business. Cameron > > > On Mon, Sep 26, 2011 at 10:45 AM, Cameron Byrne wrote: >> >> >> On Sep 26, 2011 7:30 AM, "Roman Shpount" wrote: >> > >> > I think requiring ICE in RTC is not only unfortunate, it will make it impossible to connect to PSTN without media gateway. If we complete this specification, and phone carriers decide that there is a business case for them to support RTC clients directly, it will take them 3-5 years to implement ICE in SBC. From what I've seen major carriers run SBC firmware which is normally 2-3 years old. If we add time it takes to implement ICE in SBC, plus time it will take PSTN provider to verify and test the feature, we are easily looking into 5 year time frame. >> > >> > Since we need to have user confirmation to start a media call anyway, and since this is not going to be any different from what SIP clients are currently doing, it would make sense to allow a plain non-ICE, non-SRTP call. >> > >> > Finally, ICE specification are desinged to interop with non-ICE end points. We will need to change ICE to accomplish what you are doing. >> > >> >> Maybe I misundersatnd you, but the PSTN carriers today and in the future will always run an SBC because that is their security policy. >> >> Regarding firmware, they react to market needs and timing. >> >> Cb >> >> _____________ >> > Roman Shpount >> > >> > >> > On Mon, Sep 26, 2011 at 1:23 AM, Randell Jesup wrote: >> >> >> >> On 9/22/2011 4:37 PM, Cullen Jennings wrote: >> >>> >> >>> On Sep 22, 2011, at 2:04 PM, Christer Holmberg wrote: >> >>> >> >>>> If so, what is your assumption then regarding ICE? That the SIP nodes will support ICE, or that the browser will be allowed to communicate with the SIP nodes without enabling ICE? >> >>> >> >>> I see no way of solving the security problems without having ICE or something more or less like it. Therefore, I'm working on the assumption that it will only work if the SIP side supports ICE, or is front ended by a SBC with media GW that does ICE. In the short term, there will be some devices that don't do ICE but SIP devices are increasingly having ICE added. Particularly SIP devices that are internet facing because the need for NAT traversal. >> >>> >> >>> I find requiring ICE to be a very unfortunate assumption to have to make - obviously it reduces the number of legacy voip devices WebRTC devices can talk to without an SBC but I don't see any way around this limitation. Allowing web browsers inside the firewall to send packets to an arbitrary address that is inside the firewall with no validation that address speaks RTP is not acceptable. >> >> >> >> >> >> I agree we can't solve the security issue with permission to send with the >> >> current threat model without ICE or some equivalent. >> >> >> >> There is another option that may help with some of the use cases (I've mentioned >> >> this before in the discussion on screensharing, among others). For a number >> >> of the use cases security is an impassible problem with the current threat model. >> >> Those use cases generally involve replacing cases where an existing desktop >> >> install or plugin was used (webex, screensharing, vnc, SIP softclient, Skype, etc). >> >> Those cases all currently involve the user implicitly giving these apps total >> >> or close to code that could do pretty much anything on the user's computer, >> >> and are also often the "ongoing usage" authentication cases. >> >> >> >> The only mitigating safety of the external app/plugin model is that they're typically >> >> signed and go through the platforms software-install procedure, cert-showing, UACs, etc. >> >> >> >> Currently people are trying to work out the HTML5 "installed" webapp security model; >> >> if that's far enough along we may be able to piggyback off that. I'm looking into it. >> >> >> >> >> >> -- >> >> Randell Jesup >> >> randell-ietf@jesup.org >> >> >> >> _______________________________________________ >> >> 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 >> > > > --bcaec520f415d23fc604add9756a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 26, 2011 7:52 AM, "Roman Shpount" <roman@telurix.com> wrote:
>
> PSTN carriers today almost always run SBCs. At the same time I have no= t seen an SBC from any major US carrier with firmware newer the 2 years old= . I've never seen an SBC in carrier deployment that currently supports = ICE or SRTP.
>
> Bottom line, no carriers currently support ICE or SRTP. If we create t= he market requirements for them to support ICE and SRTP, it will take them = 3-5 years to add such support. If we have anybody from SBC manufacturing co= mpanies or carriers who can provide evidence to the opposite, I would love = to hear from them. In any case, it would be prudent to provide a way to use= current non-ICE, non-SRTP with RTC.
> _____________
> Roman Shpount
>

I am with a mobile carrier that does FMC and we have products that use S= RTP to an SBC today. I don't know about ICE, but I think your projectio= n is clearly not true.=A0 If other carriers delay, I am glad to take their = business.

Cameron

>
>
> On Mon, Sep 26, 2011 at 10:45 AM, Cameron Byrne <cb.list6@gmail.com> wrote:
>>
>>
>> On Sep 26, 2011 7:30 AM, "Roman Shpount" <roman@telurix.com> wrote:
>> >
>> > I think requiring ICE in RTC is not only unfortunate, it will= make it impossible to connect to PSTN without media gateway. If we complet= e this specification, and phone carriers decide that there is a business ca= se for them to support RTC clients directly, it will take them 3-5 years to= implement ICE in SBC. From what I've seen major carriers run SBC firmw= are which is normally 2-3 years old. If we add time it takes to implement I= CE in SBC, plus time it will take PSTN provider to verify and test the feat= ure, we are easily looking into 5 year time frame.
>> >
>> > Since we need to have user confirmation to start a media call= anyway, and since this is not going to be any different from what SIP clie= nts are currently doing, it would make sense to allow a plain non-ICE, non-= SRTP call.
>> >
>> > Finally, ICE specification are desinged to interop with non-I= CE end points. We will need to change ICE to accomplish what you are doing.=
>> >
>>
>> Maybe I misundersatnd you, but the PSTN carriers today and in the = future will always run an SBC because that is their security policy.
>>
>> Regarding firmware, they react to market needs and timing.
>>
>> Cb
>>
>> _____________
>> > Roman Shpount
>> >
>> >
>> > On Mon, Sep 26, 2011 at 1:23 AM, Randell Jesup <randell-ietf@jesup.org> wrote:
>> >>
>> >> On 9/22/2011 4:37 PM, Cullen Jennings wrote:
>> >>>
>> >>> On Sep 22, 2011, at 2:04 PM, Christer Holmberg wrote:=
>> >>>
>> >>>> If so, what is your assumption then regarding ICE= ? That the SIP nodes will support ICE, or that the browser will be allowed = to communicate with the SIP nodes without enabling ICE?
>> >>>
>> >>> I see no way of solving the security problems without= having ICE or something more or less like it. Therefore, I'm working o= n the assumption that it will only work if the SIP side supports ICE, or is= front ended by a SBC with media GW that does ICE. In the short term, there= will be some devices that don't do ICE but SIP devices are increasingl= y having ICE added. Particularly SIP devices that are internet facing becau= se the need for NAT traversal.
>> >>>
>> >>> I find requiring ICE to be a very unfortunate assumpt= ion to have to make - obviously it reduces the number of legacy voip device= s WebRTC devices can talk to without an SBC but I don't see any way aro= und this limitation. Allowing web browsers inside the firewall to send pack= ets to an arbitrary address that is inside the firewall with no validation = that address speaks RTP is not acceptable.
>> >>
>> >>
>> >> I agree we can't solve the security issue with permis= sion to send with the
>> >> current threat model without ICE or some equivalent.
>> >>
>> >> There is another option that may help with some of the us= e cases (I've mentioned
>> >> this before in the discussion on screensharing, among oth= ers). =A0For a number
>> >> of the use cases security is an impassible problem with t= he current threat model.
>> >> Those use cases generally involve replacing cases where a= n existing desktop
>> >> install or plugin was used (webex, screensharing, vnc, SI= P softclient, Skype, etc).
>> >> Those cases all currently involve the user implicitly giv= ing these apps total
>> >> or close to code that could do pretty much anything on th= e user's computer,
>> >> and are also often the "ongoing usage" authenti= cation cases.
>> >>
>> >> The only mitigating safety of the external app/plugin mod= el is that they're typically
>> >> signed and go through the platforms software-install proc= edure, cert-showing, UACs, etc.
>> >>
>> >> Currently people are trying to work out the HTML5 "i= nstalled" webapp security model;
>> >> if that's far enough along we may be able to piggybac= k off that. =A0 I'm looking into it.
>> >>
>> >>
>> >> --
>> >> Randell Jesup
>> >> randell-ietf@je= sup.org
>> >>
>> >> _______________________________________________
>> >> 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
>> >
>
>

--bcaec520f415d23fc604add9756a-- From ibc@aliax.net Mon Sep 26 08:12: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 4ED3721F8D1A for ; Mon, 26 Sep 2011 08:12:55 -0700 (PDT) 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.038, 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 G5yQYeoIXScm for ; Mon, 26 Sep 2011 08:12:54 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B2EC421F8D15 for ; Mon, 26 Sep 2011 08:12:54 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4038716vcb.31 for ; Mon, 26 Sep 2011 08:15:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.9.129 with SMTP id l1mr1889823vcl.87.1317050137255; Mon, 26 Sep 2011 08:15:37 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Mon, 26 Sep 2011 08:15:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Sep 2011 17:15:37 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Cameron Byrne Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 15:12:55 -0000 2011/9/26 Cameron Byrne : > Maybe I misundersatnd you, but the PSTN carriers today and in the future > will always run an SBC because that is their security policy. Hi. Please let's forget "SBC" and let's go to a simpler case: a PSTN provider that speeak SIP and RTP with clients and SIP/SS7/ISUP with other PSTN operators. The signaling and media conversion is done in PSTN gateways. Most of them, for sure, don't implement ICE neither SRTP. Anyhow, concerning this subject, I already proposed something in other thread: why couldn't the provider (the web site) tell their WebRTC clients wheter they shoud or not accept media sessions without ICE and/or SRTP? For example, a telco operator that creates a web site for allow its clients making PSTN calls from the web, could relax those requirements and don't mandate ICE/SRTP. In the other side, a social network web site which just allows calls between web users could mandate them. Such configuration could be retrieved by the WebRTC client via HTTP or WebSocket by standarizing a document format. Regards. --=20 I=C3=B1aki Baz Castillo From matthew.kaufman@skype.net Mon Sep 26 08:19: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 B80A821F8D74 for ; Mon, 26 Sep 2011 08:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.186 X-Spam-Level: X-Spam-Status: No, score=-5.186 tagged_above=-999 required=5 tests=[AWL=1.113, 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 Hp5RocecAhmG for ; Mon, 26 Sep 2011 08:19:07 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9D121F8C53 for ; Mon, 26 Sep 2011 08:19:07 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 3EE6016F3; Mon, 26 Sep 2011 17:21:49 +0200 (CEST) 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=WgieShguyaQMdk MtXU/UQeTve1M=; b=LgcLYo1LiW4W1wN2K/EONtDAglkZC+PdM07QvCsyZYE5q7 3DYKJ6HrDvfk4Rj01XwC6SBZl/fRiZI8MrHhPPaDb4wOzZTsmRaXmQ5j9F492oFY rKF3pswLoy3J9cFeOsiqzTf0+ZtDoSX4zd7dx99kAabzwXeuczGF/q9tzu0ZY= 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=Nm4wPImSeLl2Cd0vGMUUcu 3hzMsociMCl4cjBW7RknCXlNeuBX6DbMCJYT0WkDt/X8dgfy5oDyy5L8fh0zW/Na z3u7DZhXMiPBIyQ+0wFjElUa7laxmvRtEXdHuOK6Kb8vYpqKq2cB9iJHja98gmF9 PrN7RAZrPaLYIhlEQoo04= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 3D2DF7F8; Mon, 26 Sep 2011 17:21:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id B65441672683; Mon, 26 Sep 2011 17:21:48 +0200 (CEST) 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 TLTLWxFtCFae; Mon, 26 Sep 2011 17:21:48 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 270CF1672682; Mon, 26 Sep 2011 17:21:46 +0200 (CEST) Message-ID: <4E80984A.903@skype.net> Date: Mon, 26 Sep 2011 08:20:42 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 15:19:08 -0000 On 9/26/2011 8:15 AM, I=C3=B1aki Baz Castillo wrote: > 2011/9/26 Cameron Byrne: >> Maybe I misundersatnd you, but the PSTN carriers today and in the futu= re >> will always run an SBC because that is their security policy. > Hi. Please let's forget "SBC" and let's go to a simpler case: a PSTN > provider that speeak SIP and RTP with clients and SIP/SS7/ISUP with > other PSTN operators. The signaling and media conversion is done in > PSTN gateways. Most of them, for sure, don't implement ICE neither > SRTP. > > Anyhow, concerning this subject, I already proposed something in other > thread: why couldn't the provider (the web site) tell their WebRTC > clients wheter they shoud or not accept media sessions without ICE > and/or SRTP? Because that doesn't meet the security requirements. > > For example, a telco operator that creates a web site for allow its > clients making PSTN calls from the web, could relax those requirements > and don't mandate ICE/SRTP. In the other side, a social network web > site which just allows calls between web users could mandate them. > Such configuration could be retrieved by the WebRTC client via HTTP or > WebSocket by standarizing a document format. For example, an evil overlord that creates a web site for allowing its=20 clients to attack systems behind a firewall could relax those=20 requirements and not mandate ICE/SRTP when opening arbitrary connections=20 to systems behind said firewall. The "configuration" must be retrieved by the WebRTC client *from the=20 system it will be sending traffic to*... the best format we have for=20 that is to send a (rate-limited) STUN connectivity check with short-term=20 credentials and see if it is replied to properly. That's how ICE works. Matthew Kaufman From ibc@aliax.net Mon Sep 26 08:26: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 04E6121F8BF6 for ; Mon, 26 Sep 2011 08:26:55 -0700 (PDT) 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.038, 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 8mC18Jnk3o2H for ; Mon, 26 Sep 2011 08:26:54 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7007221F8B06 for ; Mon, 26 Sep 2011 08:26:54 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4055332vcb.31 for ; Mon, 26 Sep 2011 08:29:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.69.18 with SMTP id a18mr5939406vdu.430.1317050977193; Mon, 26 Sep 2011 08:29:37 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Mon, 26 Sep 2011 08:29:37 -0700 (PDT) In-Reply-To: <4E80984A.903@skype.net> References: <4E80984A.903@skype.net> Date: Mon, 26 Sep 2011 17:29:37 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Matthew Kaufman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 15:26:55 -0000 2011/9/26 Matthew Kaufman : > For example, an evil overlord that creates a web site for allowing its > clients to attack systems behind a firewall could relax those requirement= s > and not mandate ICE/SRTP when opening arbitrary connections to systems > behind said firewall. > > The "configuration" must be retrieved by the WebRTC client *from the syst= em > it will be sending traffic to*... the best format we have for that is to > send a (rate-limited) STUN connectivity check with short-term credentials > and see if it is replied to properly. That's how ICE works. I understand your points and I agree. That would be the perfect scenario. But I'm worried about the price to pay for these security constrains (no interoperability with 95% of SIP-PSTN providers within next 3-5 years). Regards. --=20 I=C3=B1aki Baz Castillo From matthew.kaufman@skype.net Mon Sep 26 08:47: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 A0EE121F8C10 for ; Mon, 26 Sep 2011 08:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.226 X-Spam-Level: X-Spam-Status: No, score=-5.226 tagged_above=-999 required=5 tests=[AWL=1.073, 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 nuN0l0zvoBCo for ; Mon, 26 Sep 2011 08:47:20 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id D850F21F8C0F for ; Mon, 26 Sep 2011 08:47:19 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 90A9416F6; Mon, 26 Sep 2011 17:50:00 +0200 (CEST) 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=Y/4AR+leWLFNJ6 qhXvyFEPoTx88=; b=fHikMOP0c/AQycX1EVOqZmL3umPlIcIqus4uM0ds0QScmN MOcd2E9yn4OxaZw9fiMPTPh41eXhnsYmm3YbP5FWSoroktivFG1y40bo6lG4mdfv KYRcaJD63hYs3FgBcy6WNhdnagbEdq68KLEPGJAgVJCdGpfVcrki/z4Bcjn54= 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=ot3BtEVuY8/QA81bIZjTxB 3DLxoQU7GyIS02o8CqskgZkO344CKbGRTi8iVNxHH9izpmf1h8ZEQAMJ47krF+9j DC/IgYKtrYZrqH4LLoUtoz1GWqaFMaYpzb6GAs0SwFyCyaJ0zCDUQMfhVaQlX7An PpJM6iwWXw5Y7ZaILBw2M= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 8F04D7F6; Mon, 26 Sep 2011 17:50:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 5BE6C1672681; Mon, 26 Sep 2011 17:50:00 +0200 (CEST) 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 S6oPLmdpDBmH; Mon, 26 Sep 2011 17:49:59 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id A05231672683; Mon, 26 Sep 2011 17:49:58 +0200 (CEST) Message-ID: <4E809EE6.2050702@skype.net> Date: Mon, 26 Sep 2011 08:48:54 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4E80984A.903@skype.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 15:47:21 -0000 On 9/26/2011 8:29 AM, I=C3=B1aki Baz Castillo wrote: > 2011/9/26 Matthew Kaufman: >> For example, an evil overlord that creates a web site for allowing its >> clients to attack systems behind a firewall could relax those requirem= ents >> and not mandate ICE/SRTP when opening arbitrary connections to systems >> behind said firewall. >> >> The "configuration" must be retrieved by the WebRTC client *from the s= ystem >> it will be sending traffic to*... the best format we have for that is = to >> send a (rate-limited) STUN connectivity check with short-term credenti= als >> and see if it is replied to properly. That's how ICE works. > I understand your points and I agree. That would be the perfect scenari= o. That would be the only scenario that is safe enough to ship in a browser. > But I'm worried about the price to pay for these security constrains > (no interoperability with 95% of SIP-PSTN providers within next 3-5 > years). The alternative is that you don't ship anything in the browser, because=20 the browser *cannot* become an attack vector as a result of adding this=20 feature. And "interoperability with SIP-PSTN providers" is only relevant if you=20 are trying to turn the browser into another phone. We have enough=20 phones. What we don't have are new real-time communication experiences=20 that can only be created within this environment. Matthew Kaufman From roman@telurix.com Mon Sep 26 09:23: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 18DFB21F8D92 for ; Mon, 26 Sep 2011 09:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.864 X-Spam-Level: X-Spam-Status: No, score=-2.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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcGKd5H3h6gD for ; Mon, 26 Sep 2011 09:23:30 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5475321F8D8E for ; Mon, 26 Sep 2011 09:23:30 -0700 (PDT) Received: by gwj15 with SMTP id 15so5689731gwj.31 for ; Mon, 26 Sep 2011 09:26:13 -0700 (PDT) Received: by 10.101.49.4 with SMTP id b4mr4467136ank.61.1317054373185; Mon, 26 Sep 2011 09:26:13 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by mx.google.com with ESMTPS id t10sm70122215anl.26.2011.09.26.09.26.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Sep 2011 09:26:12 -0700 (PDT) Received: by gwj15 with SMTP id 15so5689702gwj.31 for ; Mon, 26 Sep 2011 09:26:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.22.105 with SMTP id c9mr30421202pbf.88.1317054370909; Mon, 26 Sep 2011 09:26:10 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Mon, 26 Sep 2011 09:26:10 -0700 (PDT) In-Reply-To: <4E809EE6.2050702@skype.net> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> Date: Mon, 26 Sep 2011 12:26:10 -0400 Message-ID: From: Roman Shpount To: Matthew Kaufman Content-Type: multipart/alternative; boundary=bcaec52154c5ed8c9704adda9d0e Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 16:23:31 -0000 --bcaec52154c5ed8c9704adda9d0e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 26, 2011 at 11:48 AM, Matthew Kaufman wrote: > And "interoperability with SIP-PSTN providers" is only relevant if you are > trying to turn the browser into another phone. We have enough phones. What > we don't have are new real-time communication experiences that can only be > created within this environment. > Are we deliberately creating an island? To be honest, I actually wanted to put RTC in the phone, instead of SIP. I think it would be a great idea to have desktop phone which runs a webkit browser with RTC and serves as an advanced display phone for a PBX. If RTC would not support no-ICE non-RTP calls, my only option would be to ignore the standard. So, in a sense we do not have enough phones. I think you point in a lot of ways is similar to the argument that we should disable HTTP and leave only HTTPS since it is the only secure way to communicate and everything else would be an attack vector. _____________ Roman Shpount --bcaec52154c5ed8c9704adda9d0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 26, 2011 at 11:48 AM, Matthew Ka= ufman <ma= tthew.kaufman@skype.net> wrote:
And "interoperability with SIP-PSTN providers" is only relevant i= f you are trying to turn the browser into another phone. We have enough pho= nes. What we don't have are new real-time communication experiences tha= t can only be created within this environment.

Are we deliberately creating an island? To be honest= , I actually wanted to put RTC in the phone, instead of SIP. I think it wou= ld be a great idea to have desktop phone which runs a webkit browser with R= TC and serves as an advanced display phone for a PBX. If RTC would not supp= ort no-ICE non-RTP calls, my only option would be to ignore the standard. S= o, in a sense we do not have enough phones.

I think you point in a lot of ways is similar to the argument that we s= hould disable HTTP and leave only HTTPS since it is the only secure way to = communicate and everything else would be an attack vector.
_____________
Roman Shpount

--bcaec52154c5ed8c9704adda9d0e-- From ibc@aliax.net Mon Sep 26 09:37: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 9B1E821F8C49 for ; Mon, 26 Sep 2011 09:37:00 -0700 (PDT) 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.038, 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 iAy3VRlSCjqQ for ; Mon, 26 Sep 2011 09:37:00 -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 007EB21F8C48 for ; Mon, 26 Sep 2011 09:36:59 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4137478vcb.31 for ; Mon, 26 Sep 2011 09:39:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.175.229 with SMTP id cd5mr6687796vdc.363.1317055176638; Mon, 26 Sep 2011 09:39:36 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Mon, 26 Sep 2011 09:39:36 -0700 (PDT) In-Reply-To: <4E809EE6.2050702@skype.net> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> Date: Mon, 26 Sep 2011 18:39:36 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Matthew Kaufman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 16:37:00 -0000 2011/9/26 Matthew Kaufman : > The alternative is that you don't ship anything in the browser, because t= he > browser *cannot* become an attack vector as a result of adding this featu= re. > And "interoperability with SIP-PSTN providers" is only relevant if you ar= e > trying to turn the browser into another phone. If I need to make a call I use my phone rather than opening a web browser. But a phone integrated within a web page has a big added value (real integration of telephony in the web). And I don't speak just about boring PSTN calls. Skype could create a client running in a WebRTC browser for communicating with Skype network (and also PSTN calls, why not?). > We have enough phones. Yes, and some privative VoIP protocols. > What > we don't have are new real-time communication experiences that can only b= e > created within this environment. Good vision. But such vision should not limit/restrict any other posibility for WebRTC (as basic PSTN telephony integration). Regards. --=20 I=C3=B1aki Baz Castillo From jovass@adobe.com Mon Sep 26 10:15: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 C159C21F8CD7 for ; Mon, 26 Sep 2011 10:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[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 H9eOdsFgNwi6 for ; Mon, 26 Sep 2011 10:15:33 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 554E521F8C86 for ; Mon, 26 Sep 2011 10:15:32 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKToCzxof+AE+rivsC6ETd9SbGPuZi+B43@postini.com; Mon, 26 Sep 2011 10:18:16 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p8QHGQdI011133; Mon, 26 Sep 2011 10:16:27 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p8QHCeHS011865; Mon, 26 Sep 2011 10:17:39 -0700 (PDT) Received: from nambx03.corp.adobe.com ([10.8.189.93]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Mon, 26 Sep 2011 10:17:08 -0700 From: Jozsef Vass To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Mon, 26 Sep 2011 10:17:07 -0700 Thread-Topic: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) Thread-Index: Acx8G3BT5l/1JIY9S9Cv+fBuNGuWNgAUlZ3A Message-ID: <0FEA137C08A9DF4781EEF745038C969430A51F67F2@nambx03.corp.adobe.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <4E79A964.2050007@alvestran d.no> <0FEA137C08A9DF4781EEF745038C969430A51F6401@nambx03.corp.adobe.com> <5290D7E8-31AB-44BB-A8B2-3D1C2A4FB797@ag-projects.com> In-Reply-To: <5290D7E8-31AB-44BB-A8B2-3D1C2A4FB797@ag-projects.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 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 17:15:34 -0000 Look at it from a game developer's perspective. I do not want to build a so= ftphone phone with advanced features, just to add voice chat to the game. O= nline registered players should be able to chat with each other, but really= no need to interoperate with anything else (and preferred not to). Quite = often, it is a group of people who are playing together, so multiparty chat= is highly desirable. As I game developer, I do not event know what is SIP= , Jingle or SDP and probably do not even care about it. If you want to communicate behind NATs, firewalls, you need to run a servic= e to determine the reflexive address (in addition to your web server) at le= ast. Jozsef -----Original Message----- From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com]=20 Sent: Monday, September 26, 2011 12:11 AM To: Jozsef Vass Cc: Harald Alvestrand; rtcweb@ietf.org Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [wa= s RE: About defining a signaling protocol for WebRTC (or not)]) On Sep 23, 2011, at 2:58 AM, Jozsef Vass wrote: > I am in support of having some basic mechanism in the browser as part of = rtcweb to enable developers to quickly and easily setup media between parti= cipants. Furthermore, if an API is too complex or too hard to use, people w= ill not use it or misuse it. I can only see a handful of companies developi= ng advanced calling feature on top of rtcweb, most people just want to have= something simple to work without caring too much about the details. >=20 > Maybe it would be advantages to specify such a very basic use case, e.g.,= targeting gaming. It must work behind NATs using peer-to-peer media transp= ort (but fallback to media relay may not be required). Since it is targetin= g closed community, there is no need for interoperability, there is no need= for SIP, Jingle, etc. At the minimum, this would require a simple service = for ip address lookup and to aid NAT and firewall traversal. >=20 This is a no go. What "closed community" are you talking about? Interoperab= ility is a MUST here, even if I'm in favor of not having any default signal= ing protocol specified. We need to be able to communicate with other protoc= ols without building gateways. This can be achieved with both SIP and XMPP,= so I see no need for reinventing the wheel. Lets let developers use whatev= er protocol they like and just use RTCweb for the media part. > For example, when a user registers with this service, he/she is assigned = an identifier or blob. In order to communicate with another party, all they= need to do is to exchange this information (this can be done using websock= et, etc.) and setup media channel. There should be no need for parsing SDP,= etc. >=20 What service? Who would host a server? -- Sa=FAl Ibarra Corretg=E9 AG Projects From jovass@adobe.com Mon Sep 26 10:17: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 B7C1F21F8BE9 for ; Mon, 26 Sep 2011 10:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.072 X-Spam-Level: X-Spam-Status: No, score=-105.072 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 LtwCDPoePja7 for ; Mon, 26 Sep 2011 10:17:29 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 62A3F21F8BD5 for ; Mon, 26 Sep 2011 10:17:28 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKToC0SNlPDIM7CyHD69ZgBzB8A47WVJtd@postini.com; Mon, 26 Sep 2011 10:20:12 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 p8QHK5Fd019301; Mon, 26 Sep 2011 10:20:06 -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 p8QHESHS012664; Mon, 26 Sep 2011 10:19:41 -0700 (PDT) Received: from nambx03.corp.adobe.com ([10.8.189.93]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Mon, 26 Sep 2011 10:19:18 -0700 From: Jozsef Vass To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Mon, 26 Sep 2011 10:19:17 -0700 Thread-Topic: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) Thread-Index: Acx8IajV2s4CvgoLTSyxVqA5p1gROwATn7zw Message-ID: <0FEA137C08A9DF4781EEF745038C969430A51F67F6@nambx03.corp.adobe.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <4E79A964.2050007@alvestrand.no> <0FEA137C08A9DF4781EEF745038C969430A51F6401@nambx03.corp.adobe.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 17:17:30 -0000 QWxsIHRoZXNlIGFkdmFuY2VkIGZlYXR1cmVzIHdpbGwgcHJvYmFibHkgYmUgdXNlZCBieSBhIGhh bmRmdWwgb2YgY29tcGFuaWVzL2RldmVsb3BlcnMuIEkgd291bGQgcmF0aGVyIHNlZSBzb21ldGhp bmcgc2ltcGxlLCB4bWwgYmFzZWQgdGhhdCBpcyBtb3JlIGNvbXBhdGlibGUgd2l0aCB0aGUgd2Vi IHRoYW4gU0RQLiANCg0KSm96c2VmDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86aWJjQGFsaWF4Lm5ldF0gDQpTZW50OiBNb25k YXksIFNlcHRlbWJlciAyNiwgMjAxMSAxMjo1NSBBTQ0KVG86IEpvenNlZiBWYXNzDQpDYzogSGFy YWxkIEFsdmVzdHJhbmQ7IHJ0Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdICIy MCBsaW5lcyIgKFJlOiBSVENXZWIgZGVmYXVsdCBzaWduYWxpbmcgcHJvdG9jb2wgW3dhcyBSRTog QWJvdXQgZGVmaW5pbmcgYSBzaWduYWxpbmcgcHJvdG9jb2wgZm9yIFdlYlJUQyAob3Igbm90KV0p DQoNCjIwMTEvOS8yMyBKb3pzZWYgVmFzcyA8am92YXNzQGFkb2JlLmNvbT46DQo+IHRoZXJlIGlz IG5vIG5lZWQgZm9yIGludGVyb3BlcmFiaWxpdHksIHRoZXJlIGlzIG5vIG5lZWQgZm9yIFNJUCwg SmluZ2xlLCBldGMuIEF0IHRoZSBtaW5pbXVtLCB0aGlzIHdvdWxkIHJlcXVpcmUgYSBzaW1wbGUg c2VydmljZSBmb3IgaXAgYWRkcmVzcyBsb29rdXAgYW5kIHRvIGFpZCBOQVQgYW5kIGZpcmV3YWxs IHRyYXZlcnNhbC4NCj4gRm9yIGV4YW1wbGUsIHdoZW4gYSB1c2VyIHJlZ2lzdGVycyB3aXRoIHRo aXMgc2VydmljZSwgaGUvc2hlIGlzIGFzc2lnbmVkIGFuIGlkZW50aWZpZXIgb3IgYmxvYi4gSW4g b3JkZXIgdG8gY29tbXVuaWNhdGUgd2l0aCBhbm90aGVyIHBhcnR5LCBhbGwgdGhleSBuZWVkIHRv IGRvIGlzIHRvIGV4Y2hhbmdlIHRoaXMgaW5mb3JtYXRpb24gKHRoaXMgY2FuIGJlIGRvbmUgdXNp bmcgd2Vic29ja2V0LCBldGMuKSBhbmQgc2V0dXAgbWVkaWEgY2hhbm5lbC4gVGhlcmUgc2hvdWxk IGJlIG5vIG5lZWQgZm9yIHBhcnNpbmcgU0RQLCBldGMuDQoNCg0KLi4uYW5kIHdoZW4geW91IG5l ZWQgbW9yZSBmZWF0dXJlcyAobGlrZSBhZGRpbmcgdmlkZW8gd2l0aGluIGFuIGV4aXN0aW5nIGF1 ZGlvIHNlc3Npb24sIG9yIHB1dHRpbmcgdGhlIHNlc3Npb24gb24gaG9sZCwgb3IgbmVnb3RpYXRp bmcgY29kZWNzIGFuZCBlbmNyeXB0aW9uIHBhcmFtZXRlcnMpIHlvdSB3aWxsIHJlYWxpemUgdGhh dCB5b3UgYXJlIHJlaW52ZW50aW5nIFNEUC4NCg0KDQoNCg0KDQotLQ0KScOxYWtpIEJheiBDYXN0 aWxsbw0KPGliY0BhbGlheC5uZXQ+DQo= From ibc@aliax.net Mon Sep 26 10:48: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 AB97D21F8C8A for ; Mon, 26 Sep 2011 10:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[AWL=-1.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, 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 ugy8uOKZcQKC for ; Mon, 26 Sep 2011 10:48:05 -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 3428521F8C5F for ; Mon, 26 Sep 2011 10:48:05 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4213892vcb.31 for ; Mon, 26 Sep 2011 10:50:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.213.132 with SMTP id gw4mr1991219vcb.52.1317059447100; Mon, 26 Sep 2011 10:50:47 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Mon, 26 Sep 2011 10:50:47 -0700 (PDT) In-Reply-To: <0FEA137C08A9DF4781EEF745038C969430A51F67F2@nambx03.corp.adobe.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <0FEA137C08A9DF4781EEF745038C969430A51F6401@nambx03.corp.adobe.com> <5290D7E8-31AB-44BB-A8B2-3D1C2A4FB797@ag-projects.com> <0FEA137C08A9DF4781EEF745038C969430A51F67F2@nambx03.corp.adobe.com> Date: Mon, 26 Sep 2011 19:50:47 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Jozsef Vass Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 17:48:05 -0000 2011/9/26 Jozsef Vass : > Look at it from a game developer's perspective. I do not want to build a = softphone phone with advanced features, just to add voice chat to the game.= Online registered players should be able to chat with each other, but real= ly no need to interoperate with anything else (and preferred not to). =C2= =A0Quite often, it is a group of people who are playing together, so multip= arty chat is highly desirable. =C2=A0As I game developer, I do not event kn= ow what is SIP, Jingle or SDP and probably do not even care about it. Indeed there should be a simple mechanism for allowing web developers to run audio/video sessions in their web applications, but that should not avoid or make impossible for others to run a SIP or XMPP/Jingle client within a web. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Mon Sep 26 11:09: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 2F3E221F8C68 for ; Mon, 26 Sep 2011 11:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 r+sku5JmZ4cv for ; Mon, 26 Sep 2011 11:09:26 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6825521F8C67 for ; Mon, 26 Sep 2011 11:09:26 -0700 (PDT) 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 p8QIAlGw019172; Mon, 26 Sep 2011 14:10:47 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 14:10:15 -0400 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: Mon, 26 Sep 2011 23:40:12 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F1086@sonusinmail02.sonusnet.com> In-Reply-To: <0FEA137C08A9DF4781EEF745038C969430A51F67F2@nambx03.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) Thread-Index: Acx8G3BT5l/1JIY9S9Cv+fBuNGuWNgAUlZ3AAAIJ8gA= References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com><05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org><4E79A964.2050007@alvestran d.no><0FEA137C08A 9DF4781E EF745038C969 430A51F6401@nambx03.corp.adobe.com><5290D7E8-31AB-44BB-A8B2-3D1C2A4FB797@ag-projects.com> <0FEA137C08A9DF4781EEF745038C969430A51F67F2@nambx03.corp.adobe.com> From: "Ravindran Parthasarathi" To: "Jozsef Vass" , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-OriginalArrivalTime: 26 Sep 2011 18:10:15.0365 (UTC) FILETIME=[8A824F50:01CC7C77] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 18:09:27 -0000 Hi Jozsef, I agree with you that game developer has no need to know the intricacies = of signaling protocol and also, how the underlying framework makes it = work for traverse through NAT. But the discussion here is which JS API = will make it happen and what are the protocol intricacies involved to = make it happen? As you wish based on lower level JS API, it is possible to give only one = API like peerconnnect([username]) to start the session and how they = connect which is not RTCWeb developer headache but underlying framework = will take care of the stuff.=20 What level of interop is required for the online registered players? All = RTCWEb browser (Mozilla, chrome, IE) player should be able interop = without need of browser specific JS or plugin. Here, there is a need of = defining the common underlying protocol (which is not RTCWeb developer = concern). Thanks Partha =20 >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf >Of Jozsef Vass >Sent: Monday, September 26, 2011 10:47 PM >To: Sa=FAl Ibarra Corretg=E9 >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol >[was RE: About defining a signaling protocol for WebRTC (or not)]) > >Look at it from a game developer's perspective. I do not want to build = a >softphone phone with advanced features, just to add voice chat to the >game. Online registered players should be able to chat with each other, >but really no need to interoperate with anything else (and preferred = not >to). Quite often, it is a group of people who are playing together, so >multiparty chat is highly desirable. As I game developer, I do not >event know what is SIP, Jingle or SDP and probably do not even care >about it. > >If you want to communicate behind NATs, firewalls, you need to run a >service to determine the reflexive address (in addition to your web >server) at least. > >Jozsef > >-----Original Message----- >From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] >Sent: Monday, September 26, 2011 12:11 AM >To: Jozsef Vass >Cc: Harald Alvestrand; rtcweb@ietf.org >Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol >[was RE: About defining a signaling protocol for WebRTC (or not)]) > > >On Sep 23, 2011, at 2:58 AM, Jozsef Vass wrote: > >> I am in support of having some basic mechanism in the browser as part >of rtcweb to enable developers to quickly and easily setup media = between >participants. Furthermore, if an API is too complex or too hard to use, >people will not use it or misuse it. I can only see a handful of >companies developing advanced calling feature on top of rtcweb, most >people just want to have something simple to work without caring too >much about the details. >> >> Maybe it would be advantages to specify such a very basic use case, >e.g., targeting gaming. It must work behind NATs using peer-to-peer >media transport (but fallback to media relay may not be required). = Since >it is targeting closed community, there is no need for = interoperability, >there is no need for SIP, Jingle, etc. At the minimum, this would >require a simple service for ip address lookup and to aid NAT and >firewall traversal. >> > >This is a no go. What "closed community" are you talking about? >Interoperability is a MUST here, even if I'm in favor of not having any >default signaling protocol specified. We need to be able to communicate >with other protocols without building gateways. This can be achieved >with both SIP and XMPP, so I see no need for reinventing the wheel. = Lets >let developers use whatever protocol they like and just use RTCweb for >the media part. > >> For example, when a user registers with this service, he/she is >assigned an identifier or blob. In order to communicate with another >party, all they need to do is to exchange this information (this can be >done using websocket, etc.) and setup media channel. There should be no >need for parsing SDP, etc. >> > >What service? Who would host a server? > >-- >Sa=FAl Ibarra Corretg=E9 >AG Projects > > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Mon Sep 26 11:29: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 6ECCE21F8DCD for ; Mon, 26 Sep 2011 11:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=-0.049, 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 kp3HFO6464ps for ; Mon, 26 Sep 2011 11:29:08 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id DCBEB21F8DCC for ; Mon, 26 Sep 2011 11:29:07 -0700 (PDT) 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 p8QIWLrV001453; Mon, 26 Sep 2011 14:32:21 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 14:31:50 -0400 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: Tue, 27 Sep 2011 00:01:46 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> In-Reply-To: <4E809EE6.2050702@skype.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Requiring ICE for RTC calls Thread-Index: Acx8Y/qkWDkNsFldQJS0ak/HpL4WuAAFc21Q References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> From: "Ravindran Parthasarathi" To: "Matthew Kaufman" , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 26 Sep 2011 18:31:50.0052 (UTC) FILETIME=[8E33DE40:01CC7C7A] Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 18:29:08 -0000 SSdtIHNvcnQgb2YgbGVhbiB0b3dhcmRzIElDRSBvciBJQ0VsaXRlIG1lY2hhbmlzbSBmb3IgTkFU IHRyYXZlcnNhbCBvZiBtZWRpYSBiZWNhdXNlIHRoZXJlIGlzIG5vIGtub3duIGJldHRlciBtZWNo YW5pc20uIEluIGNhc2UgdGhlcmUgaXMga25vd24gYmV0dGVyIG1lY2hhbmlzbSwgUGxlYXNlIGxp c3Qgb3V0IGZvciBkaXNjdXNzaW9uLg0KDQpUaGFua3MNClBhcnRoYQ0KDQo+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj5PZiBNYXR0aGV3IEthdWZtYW4NCj5T ZW50OiBNb25kYXksIFNlcHRlbWJlciAyNiwgMjAxMSA5OjE5IFBNDQo+VG86IEnDsWFraSBCYXog Q2FzdGlsbG8NCj5DYzogUmFuZGVsbCBKZXN1cDsgcnRjd2ViQGlldGYub3JnDQo+U3ViamVjdDog UmU6IFtydGN3ZWJdIFJlcXVpcmluZyBJQ0UgZm9yIFJUQyBjYWxscw0KPg0KPk9uIDkvMjYvMjAx MSA4OjI5IEFNLCBJw7Fha2kgQmF6IENhc3RpbGxvIHdyb3RlOg0KPj4gMjAxMS85LzI2IE1hdHRo ZXcgS2F1Zm1hbjxtYXR0aGV3LmthdWZtYW5Ac2t5cGUubmV0PjoNCj4+PiBGb3IgZXhhbXBsZSwg YW4gZXZpbCBvdmVybG9yZCB0aGF0IGNyZWF0ZXMgYSB3ZWIgc2l0ZSBmb3IgYWxsb3dpbmcNCj5p dHMNCj4+PiBjbGllbnRzIHRvIGF0dGFjayBzeXN0ZW1zIGJlaGluZCBhIGZpcmV3YWxsIGNvdWxk IHJlbGF4IHRob3NlDQo+cmVxdWlyZW1lbnRzDQo+Pj4gYW5kIG5vdCBtYW5kYXRlIElDRS9TUlRQ IHdoZW4gb3BlbmluZyBhcmJpdHJhcnkgY29ubmVjdGlvbnMgdG8NCj5zeXN0ZW1zDQo+Pj4gYmVo aW5kIHNhaWQgZmlyZXdhbGwuDQo+Pj4NCj4+PiBUaGUgImNvbmZpZ3VyYXRpb24iIG11c3QgYmUg cmV0cmlldmVkIGJ5IHRoZSBXZWJSVEMgY2xpZW50ICpmcm9tIHRoZQ0KPnN5c3RlbQ0KPj4+IGl0 IHdpbGwgYmUgc2VuZGluZyB0cmFmZmljIHRvKi4uLiB0aGUgYmVzdCBmb3JtYXQgd2UgaGF2ZSBm b3IgdGhhdCBpcw0KPnRvDQo+Pj4gc2VuZCBhIChyYXRlLWxpbWl0ZWQpIFNUVU4gY29ubmVjdGl2 aXR5IGNoZWNrIHdpdGggc2hvcnQtdGVybQ0KPmNyZWRlbnRpYWxzDQo+Pj4gYW5kIHNlZSBpZiBp dCBpcyByZXBsaWVkIHRvIHByb3Blcmx5LiBUaGF0J3MgaG93IElDRSB3b3Jrcy4NCj4+IEkgdW5k ZXJzdGFuZCB5b3VyIHBvaW50cyBhbmQgSSBhZ3JlZS4gVGhhdCB3b3VsZCBiZSB0aGUgcGVyZmVj dA0KPnNjZW5hcmlvLg0KPg0KPlRoYXQgd291bGQgYmUgdGhlIG9ubHkgc2NlbmFyaW8gdGhhdCBp cyBzYWZlIGVub3VnaCB0byBzaGlwIGluIGENCj5icm93c2VyLg0KPg0KPj4gQnV0IEknbSB3b3Jy aWVkIGFib3V0IHRoZSBwcmljZSB0byBwYXkgZm9yIHRoZXNlIHNlY3VyaXR5IGNvbnN0cmFpbnMN Cj4+IChubyBpbnRlcm9wZXJhYmlsaXR5IHdpdGggOTUlIG9mIFNJUC1QU1ROIHByb3ZpZGVycyB3 aXRoaW4gbmV4dCAzLTUNCj4+IHllYXJzKS4NCj4NCj5UaGUgYWx0ZXJuYXRpdmUgaXMgdGhhdCB5 b3UgZG9uJ3Qgc2hpcCBhbnl0aGluZyBpbiB0aGUgYnJvd3NlciwgYmVjYXVzZQ0KPnRoZSBicm93 c2VyICpjYW5ub3QqIGJlY29tZSBhbiBhdHRhY2sgdmVjdG9yIGFzIGEgcmVzdWx0IG9mIGFkZGlu ZyB0aGlzDQo+ZmVhdHVyZS4NCj4NCj5BbmQgImludGVyb3BlcmFiaWxpdHkgd2l0aCBTSVAtUFNU TiBwcm92aWRlcnMiIGlzIG9ubHkgcmVsZXZhbnQgaWYgeW91DQo+YXJlIHRyeWluZyB0byB0dXJu IHRoZSBicm93c2VyIGludG8gYW5vdGhlciBwaG9uZS4gV2UgaGF2ZSBlbm91Z2gNCj5waG9uZXMu IFdoYXQgd2UgZG9uJ3QgaGF2ZSBhcmUgbmV3IHJlYWwtdGltZSBjb21tdW5pY2F0aW9uIGV4cGVy aWVuY2VzDQo+dGhhdCBjYW4gb25seSBiZSBjcmVhdGVkIHdpdGhpbiB0aGlzIGVudmlyb25tZW50 Lg0KPg0KPk1hdHRoZXcgS2F1Zm1hbg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+cnRjd2ViIG1haWxpbmcgbGlzdA0KPnJ0Y3dlYkBpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo= From ibc@aliax.net Mon Sep 26 11:42: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 862A521F8BEF for ; Mon, 26 Sep 2011 11:42:16 -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 gpnn1wpKLSrJ for ; Mon, 26 Sep 2011 11:42:16 -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 E762F21F8BAD for ; Mon, 26 Sep 2011 11:42:15 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4273786vcb.31 for ; Mon, 26 Sep 2011 11:44:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.94.112 with SMTP id db16mr6342742vdb.497.1317062698912; Mon, 26 Sep 2011 11:44:58 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Mon, 26 Sep 2011 11:44:58 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F1086@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <5290D7E8-31AB-44BB-A8B2-3D1C2A4FB797@ag-projects.com> <0FEA137C08A9DF4781EEF745038C969430A51F67F2@nambx03.corp.adobe.com> <2E239D6FCD033C4BAF15F386A979BF510F1086@sonusinmail02.sonusnet.com> Date: Mon, 26 Sep 2011 20:44:58 +0200 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, Jozsef Vass Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 18:42:16 -0000 2011/9/26 Ravindran Parthasarathi : > What level of interop is required for the online registered players? All = RTCWEb browser (Mozilla, chrome, IE) player should be able interop without = need of browser specific JS or plugin. Ravindran, you insist of that even when multiple comments tell you the opposite. If Mozilla, Chrome or IE browsers are visiting the *same* website then they *already* share the *same* JavaScript (loaded from the website) so they can signal the media thought the web server (by using HTTP or WebSocket) as defined in the retrieved JavaScript code. This is easy to understand IMHO and this is how WWW works for years =3D> interoperability between clients visiting the same website. Period. If the browsers speak *native* SIP (as you suggest in many threads) then the web server is unaware of what is happening at media level between the visitors (because the web server, where the application logic is, does not see the signaling traffic). > Here, there is a need of defining the common underlying protocol (which i= s not RTCWeb developer concern). No, it's not. You can repeat 1000 times by ignoring any rationale already replied to you in multiple threads. But that changes nothing. WebRTC does not need native SIP or native XMPP/Jingle spoken by web browsers. In fact, that would stop innovation, would mandate website admins to provide a SIP/XMPP server within their infrastructure (how!) and would make WebRTC unfeasible in shared web hostings. The only point of discussion here is the requirements for the custom JavaScript code retrieved from the web server in order to interoperate with the WebRTC stack in the browser, and the JS API defining the methods to read and generate media descriptions (like-SDP) that would be sent to the other peer via the signaling path (HTTP/WebSocket). Regards. --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Mon Sep 26 11:45: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 A1BA921F8E26 for ; Mon, 26 Sep 2011 11:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=0.363, 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 V-uXYtyTVZ6Z for ; Mon, 26 Sep 2011 11:45:20 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9706721F8E25 for ; Mon, 26 Sep 2011 11:45:20 -0700 (PDT) Received: by yic13 with SMTP id 13so5350463yic.31 for ; Mon, 26 Sep 2011 11:48:03 -0700 (PDT) Received: by 10.151.28.19 with SMTP id f19mr6249123ybj.151.1317062883672; Mon, 26 Sep 2011 11:48:03 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id o14sm59979935ank.13.2011.09.26.11.48.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Sep 2011 11:48:03 -0700 (PDT) Received: by yxt33 with SMTP id 33so5678886yxt.31 for ; Mon, 26 Sep 2011 11:48:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.4.170 with SMTP id l10mr31236636pbl.3.1317062882351; Mon, 26 Sep 2011 11:48:02 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Mon, 26 Sep 2011 11:48:02 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> Date: Mon, 26 Sep 2011 14:48:02 -0400 Message-ID: From: Roman Shpount To: Ravindran Parthasarathi Content-Type: multipart/alternative; boundary=bcaec5215f353fdd0c04addc99f4 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 18:45:21 -0000 --bcaec5215f353fdd0c04addc99f4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You can determine that end point is not behind symmetric NAT using older STUN specification and list discovered IP as a default contact address in SDP, if you are not behind NAT, you can list the relayed address of the TUR= N server as the default address. If you do this, together with the offer that lists ICE candidates, you would be able to traverse NAT and communicate wit= h non-ICE end points. I think discussion in this thread is not whether ICE needs to be supported or implemented. I would say that ICE without a doubt should be supported. I= t is about changing ICE specification as it stands right now, and force the RTC end point only to communicate with end points that respond with ICE compliant answer and complete ICE hand shake. This is actually against the ICE specification as it is defined in RFC 5245, where answerer actually can refuse to support ICE but still establish a call. _____________ Roman Shpount On Mon, Sep 26, 2011 at 2:31 PM, Ravindran Parthasarathi < pravindran@sonusnet.com> wrote: > I'm sort of lean towards ICE or ICElite mechanism for NAT traversal of > media because there is no known better mechanism. In case there is known > better mechanism, Please list out for discussion. > > Thanks > Partha > > >-----Original Message----- > >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf > >Of Matthew Kaufman > >Sent: Monday, September 26, 2011 9:19 PM > >To: I=F1aki Baz Castillo > >Cc: Randell Jesup; rtcweb@ietf.org > >Subject: Re: [rtcweb] Requiring ICE for RTC calls > > > >On 9/26/2011 8:29 AM, I=F1aki Baz Castillo wrote: > >> 2011/9/26 Matthew Kaufman: > >>> For example, an evil overlord that creates a web site for allowing > >its > >>> clients to attack systems behind a firewall could relax those > >requirements > >>> and not mandate ICE/SRTP when opening arbitrary connections to > >systems > >>> behind said firewall. > >>> > >>> The "configuration" must be retrieved by the WebRTC client *from the > >system > >>> it will be sending traffic to*... the best format we have for that is > >to > >>> send a (rate-limited) STUN connectivity check with short-term > >credentials > >>> and see if it is replied to properly. That's how ICE works. > >> I understand your points and I agree. That would be the perfect > >scenario. > > > >That would be the only scenario that is safe enough to ship in a > >browser. > > > >> But I'm worried about the price to pay for these security constrains > >> (no interoperability with 95% of SIP-PSTN providers within next 3-5 > >> years). > > > >The alternative is that you don't ship anything in the browser, because > >the browser *cannot* become an attack vector as a result of adding this > >feature. > > > >And "interoperability with SIP-PSTN providers" is only relevant if you > >are trying to turn the browser into another phone. We have enough > >phones. What we don't have are new real-time communication experiences > >that can only be created within this environment. > > > >Matthew Kaufman > > > >_______________________________________________ > >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 > --bcaec5215f353fdd0c04addc99f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You can determine that end point is not behind symmetric NAT using older ST= UN specification and list discovered IP as a default contact address in SDP= , if you are not behind NAT, you can list the relayed address of the TURN s= erver as the default address. If you do this, together with the offer that = lists ICE candidates, you would be able to traverse NAT and communicate wit= h non-ICE end points.

I think discussion in this thread is not whether ICE needs to be suppor= ted or implemented. I would say that ICE without a doubt should be supporte= d. It is about changing ICE specification as it stands right now, and force= the RTC end point only to communicate with end points that respond with IC= E compliant answer and complete ICE hand shake. This is actually against th= e ICE specification as it is defined in RFC 5245, where answerer actually c= an refuse to support ICE but still establish a call.
_____________
Roman Shpount


On Mon, Sep 26, 2011 at 2:31 PM, Ravindr= an Parthasarathi <pravindran@sonusnet.com> wrote:
I'm sort of lean towards ICE or ICElite mechanism for NAT traversal of = media because there is no known better mechanism. In case there is known be= tter mechanism, Please list out for discussion.

Thanks
Partha

>-----Original Message-----
>From: rtcweb-bounces@ietf.or= g [mailto:rtcweb-bounces@iet= f.org] On Behalf
>Of Matthew Kaufman
>Sent: Monday, September 26, 2011 9:19 PM
>To: I=F1aki Baz Castillo
>Cc: Randell Jesup; rtcweb@ietf.org
>Subject: Re: [rtcweb] Requiring ICE for RTC calls
>
>On 9/26/2011 8:29 AM, I=F1aki Baz Castillo wrote:
>> 2011/9/26 Matthew Kaufman<matthew.kaufman@skype.net>:
>>> For example, an evil overlord that creates a web site for allo= wing
>its
>>> clients to attack systems behind a firewall could relax those<= br> >requirements
>>> and not mandate ICE/SRTP when opening arbitrary connections to=
>systems
>>> behind said firewall.
>>>
>>> The "configuration" must be retrieved by the WebRTC = client *from the
>system
>>> it will be sending traffic to*... the best format we have for = that is
>to
>>> send a (rate-limited) STUN connectivity check with short-term<= br> >credentials
>>> and see if it is replied to properly. That's how ICE works= .
>> I understand your points and I agree. That would be the perfect >scenario.
>
>That would be the only scenario that is safe enough to ship in a
>browser.
>
>> But I'm worried about the price to pay for these security cons= trains
>> (no interoperability with 95% of SIP-PSTN providers within next 3-= 5
>> years).
>
>The alternative is that you don't ship anything in the browser, bec= ause
>the browser *cannot* become an attack vector as a result of adding this=
>feature.
>
>And "interoperability with SIP-PSTN providers" is only releva= nt if you
>are trying to turn the browser into another phone. We have enough
>phones. What we don't have are new real-time communication experien= ces
>that can only be created within this environment.
>
>Matthew Kaufman
>
>_______________________________________________
>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

--bcaec5215f353fdd0c04addc99f4-- From pravindran@sonusnet.com Mon Sep 26 12:07: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 280A521F8CF6 for ; Mon, 26 Sep 2011 12:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=-0.049, 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 0VIColhgkIGx for ; Mon, 26 Sep 2011 12:07:30 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 67D1D21F8CF3 for ; Mon, 26 Sep 2011 12:07:30 -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 p8QJ912p024667; Mon, 26 Sep 2011 15:09:01 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 15:08:29 -0400 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: Tue, 27 Sep 2011 00:38:25 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F1088@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) Thread-Index: Acx8fGpelGsi5lsQSnqVLI9wNGN89QAAEVyg References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com><05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org><5290D7E8-31AB-44BB-A8B2-3D1C2A4FB797@ag-proj ects.com ><0FEA137C08 A9DF4781EEF745038C969430A51F67F2@nambx03.corp.adobe.com><2E239D6FCD033C4BAF15F386A979BF510F1086@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 26 Sep 2011 19:08:29.0141 (UTC) FILETIME=[ACF63850:01CC7C7F] Cc: rtcweb@ietf.org, Jozsef Vass Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 19:07:31 -0000 SGkgSW5ha2ksDQoNCllvdXIgdmlzaW9uIG9mIEphdmFzY3JpcHQgc2lnbmFsaW5nIHByb3RvY29s IGlzIGV4YWN0bHkgb3Bwb3NpdGUgdG8gSm96c2VmIHByb3Bvc2FsIG9mIGhhdmluZyBYTUwgbWVj aGFuaXNtLiBQbGVhc2UgdHJ5IHRvIHVuZGVyc3RhbmQgdGhhdCBldmVyeWJvZHkgaXMgbm90IGV4 Y2l0ZWQgdG8gZGV2ZWxvcCB0aGVpciBvd24gc2lnbmFsaW5nIHByb3RvY29sIGV2ZW4gdGhvdWdo IHlvdSBjb25zaWRlciBpdCBhcyBhIGZyZWVkb20gd29ybGQuIEkgaGF2ZSBpbnNpc3RlZCBtdWx0 aXBsZSB0aW1lIHRoYXQgSSdtIGFza2luZyBmb3Igb25lIFJUQ1dlYiBzaWduYWxpbmcgcHJvdG9j b2wgYWNyb3NzIGJyb3dzZXIgdmVuZG9yIGJ1dCBpdCBpcyBub3QgcmVxdWlyZWQgdG8gYmUgU0lQ LiBUaGUgYWltIG9mIGhhdmluZyBzdGFuZGFyZCBSVENXZWIgc2lnbmFsaW5nIHByb3RvY29sIGlz IHRvIG1ha2UgYmFzaWMgZGlhbG9nIGJldHdlZW4gdHdvIGRpZmZlcmVudCBicm93c2VycyAoRm9y IGV4OiBNb3ppbGxhICYgY2hyb21lKSB1c2VyLiANCg0KSGF2aW5nIHNlZWluZyB0aGUgbGlzdCBk aXNjdXNzaW9uIG9uIHNpZ25hbGluZyBpbnRyaWNhY2llcyBpbiB0aGlzIGFsaWFzLCBpdCBpcyBu byBwb2ludCBpbiBhc2tpbmcgZWFjaCB3ZWIgZGV2ZWxvcGVyIHRvIGNyZWF0ZSB0aGVpciBvd24g c2lnbmFsaW5nIHByb3RvY29sLiBJdCBpcyBiZXR0ZXIgZm9yIElFVEYgdG8gcmVjb21tZW5kIG9u ZSBwcm90b2NvbCB3aGljaCBiZXN0IHN1aXQgUlRDV2ViIHNpZ25hbGluZyByZXF1aXJlbWVudCBh bmQgYmVzdCBzaW1wbGUgQVBJIGZvciBzaWduYWxpbmcgcHJvdG9jb2wgd2lsbCBiZSBkZWZpbmVk IGJ5IFczQy4NCg0KUGxlYXNlIHJlYWQgaW5saW5lLg0KDQpUaGFua3MNClBhcnRoYQ0KDQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWls dG86aWJjQGFsaWF4Lm5ldF0NCj5TZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjcsIDIwMTEgMTI6 MTUgQU0NCj5UbzogUmF2aW5kcmFuIFBhcnRoYXNhcmF0aGkNCj5DYzogSm96c2VmIFZhc3M7IFNh w7psIEliYXJyYSBDb3JyZXRnw6k7IHJ0Y3dlYkBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbcnRj d2ViXSAiMjAgbGluZXMiIChSZTogUlRDV2ViIGRlZmF1bHQgc2lnbmFsaW5nIHByb3RvY29sDQo+ W3dhcyBSRTogQWJvdXQgZGVmaW5pbmcgYSBzaWduYWxpbmcgcHJvdG9jb2wgZm9yIFdlYlJUQyAo b3Igbm90KV0pDQo+DQo+MjAxMS85LzI2IFJhdmluZHJhbiBQYXJ0aGFzYXJhdGhpIDxwcmF2aW5k cmFuQHNvbnVzbmV0LmNvbT46DQo+PiBXaGF0IGxldmVsIG9mIGludGVyb3AgaXMgcmVxdWlyZWQg Zm9yIHRoZSBvbmxpbmUgcmVnaXN0ZXJlZCBwbGF5ZXJzPw0KPkFsbCBSVENXRWIgYnJvd3NlciAo TW96aWxsYSwgY2hyb21lLCBJRSkgcGxheWVyIHNob3VsZCBiZSBhYmxlIGludGVyb3ANCj53aXRo b3V0IG5lZWQgb2YgYnJvd3NlciBzcGVjaWZpYyBKUyBvciBwbHVnaW4uDQo+DQo+UmF2aW5kcmFu LCB5b3UgaW5zaXN0IG9mIHRoYXQgZXZlbiB3aGVuIG11bHRpcGxlIGNvbW1lbnRzIHRlbGwgeW91 IHRoZQ0KPm9wcG9zaXRlLiBJZiBNb3ppbGxhLCBDaHJvbWUgb3IgSUUgYnJvd3NlcnMgYXJlIHZp c2l0aW5nIHRoZSAqc2FtZSoNCj53ZWJzaXRlIHRoZW4gdGhleSAqYWxyZWFkeSogc2hhcmUgdGhl ICpzYW1lKiBKYXZhU2NyaXB0IChsb2FkZWQgZnJvbQ0KPnRoZSB3ZWJzaXRlKSBzbyB0aGV5IGNh biBzaWduYWwgdGhlIG1lZGlhIHRob3VnaHQgdGhlIHdlYiBzZXJ2ZXIgKGJ5DQo+dXNpbmcgSFRU UCBvciBXZWJTb2NrZXQpIGFzIGRlZmluZWQgaW4gdGhlIHJldHJpZXZlZCBKYXZhU2NyaXB0IGNv ZGUuDQo+VGhpcyBpcyBlYXN5IHRvIHVuZGVyc3RhbmQgSU1ITyBhbmQgdGhpcyBpcyBob3cgV1dX IHdvcmtzIGZvciB5ZWFycyA9Pg0KPmludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBjbGllbnRzIHZp c2l0aW5nIHRoZSBzYW1lIHdlYnNpdGUuIFBlcmlvZC4NCj4NCjxwYXJ0aGE+IFdXVyB3b3JrcyB3 aXRoIHBsdWdpbi4gSWYgeW91IHRoaW5rIG90aGVyd2lzZSwgdGhlcmUgaXMgbm8gbXVjaA0KV29y ayBmb3IgSUVURiBpbiB0aGlzIFdHIDwvcGFydGhhPg0KDQo+SWYgdGhlIGJyb3dzZXJzIHNwZWFr ICpuYXRpdmUqIFNJUCAoYXMgeW91IHN1Z2dlc3QgaW4gbWFueSB0aHJlYWRzKQ0KPHBhcnRoYT4g SSBhc2tlZCBpbml0aWFsbHkgYmVjYXVzZSBpdCBpcyBkZWZhY3RvIHJlY29tbWVuZGVkIElFVEYg DQpyZWFsLXRpbWUgcHJvdG9jb2wgPC9wYXJ0aGE+DQoNCj50aGVuIHRoZSB3ZWIgc2VydmVyIGlz IHVuYXdhcmUgb2Ygd2hhdCBpcyBoYXBwZW5pbmcgYXQgbWVkaWEgbGV2ZWwNCj5iZXR3ZWVuIHRo ZSB2aXNpdG9ycyAoYmVjYXVzZSB0aGUgd2ViIHNlcnZlciwgd2hlcmUgdGhlIGFwcGxpY2F0aW9u DQo+bG9naWMgaXMsIGRvZXMgbm90IHNlZSB0aGUgc2lnbmFsaW5nIHRyYWZmaWMpLg0KPHBhcnRo YT4gSU1PLCBpdCBpcyB5b3VyIGJhZCBhc3N1bXB0aW9uLiBUaGVyZSBhcmUgIm4iIG51bWJlciBv ZiB3YXkgdG8NCkRlc2lnbiBzZXJ2ZXIgZXZlbiBpZiB0aGV5IHNwZWFrIGRpZmZlcmVudCBwcm90 b2NvbCB3aGljaCBpcyBhIGNvbW1vbiANClByYWN0aWNlIGluIGdhdGV3YXkgaW1wbGVtZW50YXRp b24gPC9wYXJ0aGE+DQoNCj4NCj4NCj4+IEhlcmUsIHRoZXJlIGlzIGEgbmVlZCBvZiBkZWZpbmlu ZyB0aGUgY29tbW9uIHVuZGVybHlpbmcgcHJvdG9jb2wNCj4od2hpY2ggaXMgbm90IFJUQ1dlYiBk ZXZlbG9wZXIgY29uY2VybikuDQo+DQo+Tm8sIGl0J3Mgbm90Lg0KPHBhcnRoYT4gVGhlcmUgaXMg YSBzdHJvbmcgbmVlZCB0byBkZWZpbmUgc2lnbmFsaW5nIHByb3RvY29sIHdoaWNoIGhlbHBzDQpC cm93c2VycyB0byBpbnRlcm9wIGFuZCBhbHNvIHJlZHVjZSB0aGUgY29tcGxleGl0eSBmb3Igd2Vi IGRldmVsb3BlcnMgPC9wYXJ0aGE+DQoNCiBZb3UgY2FuIHJlcGVhdCAxMDAwIHRpbWVzIGJ5IGln bm9yaW5nIGFueSByYXRpb25hbGUNCj5hbHJlYWR5IHJlcGxpZWQgdG8geW91IGluIG11bHRpcGxl IHRocmVhZHMuIEJ1dCB0aGF0IGNoYW5nZXMgbm90aGluZy4NCj5XZWJSVEMgZG9lcyBub3QgbmVl ZCBuYXRpdmUgU0lQIG9yIG5hdGl2ZSBYTVBQL0ppbmdsZSBzcG9rZW4gYnkgd2ViDQo+YnJvd3Nl cnMuIEluIGZhY3QsIHRoYXQgd291bGQgc3RvcCBpbm5vdmF0aW9uLCB3b3VsZCBtYW5kYXRlIHdl YnNpdGUNCg0KPHBhcnRoYT4gSSBoYXZlIGNsYXJpZmllZCBtdWx0aXBsZSB0aW1lIHRoYXQgeW91 ciBpbm5vdmF0aW9uIGlzIG5vdCBnb2luZyANCnRvIHN0b3AgYnkgZGVmaW5pbmcgc3RhbmRhcmQg c2lnbmFsaW5nIHByb3RvY29sLiBMZXQgc2F5IFggcHJvdG9jb2wgYmVjb21lDQpzdGFuZGFyZCBz aWduYWxpbmcgcHJvdG9jb2wgd2hpY2ggZG9lcyBub3QgbWVhbiB0aGF0IHlvdSBzaG91bGQgbm90 IA0KaW1wbGVtZW50IHlvdXIgU0lQIG92ZXIgd2Vic29ja2V0IHVzaW5nIEphdmFzY3JpcHQuIFNv LCB0aGlzIGlzIGZhbHNlIA0KcHJvcGFnYW5kYSBieSBmZXcgZm9sa3MgdGhhdCBpdCB3b3VsZCBz dG9wIGlubm92YXRpb24uIDwvcGFydGhhPg0KDQo+YWRtaW5zIHRvIHByb3ZpZGUgYSBTSVAvWE1Q UCBzZXJ2ZXIgd2l0aGluIHRoZWlyIGluZnJhc3RydWN0dXJlIChob3chKQ0KPmFuZCB3b3VsZCBt YWtlIFdlYlJUQyB1bmZlYXNpYmxlIGluIHNoYXJlZCB3ZWIgaG9zdGluZ3MuDQo8cGFydGhhPiBJ biBjYXNlIHlvdSB0YWxraW5nIGFib3V0IG1hbmFnZWFiaWxpdHkgb2YgdGhlIHNlcnZlcnMsIGxv dCBvZiBtb3JlDQpTdHVmZiBpbnZvbHZlZCB0aGFuIHNpbXBsZSBwcm90b2NvbCBkZWNpc2lvbiA8 L3BhcnRoYT4NCg0KDQo+DQo+DQo+VGhlIG9ubHkgcG9pbnQgb2YgZGlzY3Vzc2lvbiBoZXJlIGlz IHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBjdXN0b20NCj5KYXZhU2NyaXB0IGNvZGUgcmV0cmll dmVkIGZyb20gdGhlIHdlYiBzZXJ2ZXIgaW4gb3JkZXIgdG8gaW50ZXJvcGVyYXRlDQo+d2l0aCB0 aGUgV2ViUlRDIHN0YWNrIGluIHRoZSBicm93c2VyLCBhbmQgdGhlIEpTIEFQSSBkZWZpbmluZyB0 aGUNCj5tZXRob2RzIHRvIHJlYWQgYW5kIGdlbmVyYXRlIG1lZGlhIGRlc2NyaXB0aW9ucyAobGlr ZS1TRFApIHRoYXQgd291bGQNCj5iZSBzZW50IHRvIHRoZSBvdGhlciBwZWVyIHZpYSB0aGUgc2ln bmFsaW5nIHBhdGggKEhUVFAvV2ViU29ja2V0KS4NCj4NCj4NCj5SZWdhcmRzLg0KPg0KPg0KPg0K Pi0tDQo+ScOxYWtpIEJheiBDYXN0aWxsbw0KPjxpYmNAYWxpYXgubmV0Pg0K From ibc@aliax.net Mon Sep 26 12:30: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 DE1FA1F0C88 for ; Mon, 26 Sep 2011 12:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pb7KRPrT9qQM for ; Mon, 26 Sep 2011 12:30:07 -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 0307E1F0C7C for ; Mon, 26 Sep 2011 12:30:06 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4325962vcb.31 for ; Mon, 26 Sep 2011 12:32:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.171.208 with SMTP id i16mr1012599vcz.122.1317065569203; Mon, 26 Sep 2011 12:32:49 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Mon, 26 Sep 2011 12:32:49 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F1088@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F1086@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1088@sonusinmail02.sonusnet.com> Date: Mon, 26 Sep 2011 21:32:49 +0200 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, Jozsef Vass Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 19:30:08 -0000 Hi Ravindran, comments inline: 2011/9/26 Ravindran Parthasarathi : > The aim of having standard RTCWeb signaling protocol is to make basic dia= log between two different browsers (For ex: Mozilla & chrome) user. And me and others already said that the aim of WebRTC is not converting web browsers into generic SIP phones capable of establishing a call between them without visiting the same page (replace "SIP" with whichever protocol). WebRTC adds value to the WWW world, so it's assumed that first of all, browsers visit some website, so they can get something (JavaScript code). > Having seeing the list discussion on signaling intricacies in this alias,= it is no point in asking each web developer to create their own signaling = protocol. It is better for IETF to recommend one protocol which best suit R= TCWeb signaling requirement and best simple API for signaling protocol will= be defined by W3C. Ok, but such protocol should be carried within HTTP or WebSocket, rather than being a native SIP/XMPP/whatever-custom-protocol built-in the web browsers. Do we agree on this? I think the answer is "not", so please continue reading. >>Ravindran, you insist of that even when multiple comments tell you the >>opposite. If Mozilla, Chrome or IE browsers are visiting the *same* >>website then they *already* share the *same* JavaScript (loaded from >>the website) so they can signal the media thought the web server (by >>using HTTP or WebSocket) as defined in the retrieved JavaScript code. >>This is easy to understand IMHO and this is how WWW works for years =3D> >>interoperability between clients visiting the same website. Period. >> > WWW works with plugin. If you think otherwise, there is no much > Work for IETF in this WG AFAIK one of the aims of WebRTC is allowing multimedia sessions within browsers *without* the need of external plugins (like Flash or Java applets). >>If the browsers speak *native* SIP (as you suggest in many threads) > I asked initially because it is defacto recommended IETF > real-time protocol I'm sure that fans of XMPP would not like that (even less taking into account that XMPP is much more deployed in pure Internet than SIP). >>then the web server is unaware of what is happening at media level >>between the visitors (because the web server, where the application >>logic is, does not see the signaling traffic). > IMO, it is your bad assumption. There are "n" number of way to > Design server even if they speak different protocol which is a common > Practice in gateway implementation So you want a "built-in protocol" not to bore web developers with custom and complex signaling protocols, but at the same time you want to force them to build a hyper-complex gateway in server side. =C2=BF?=C2= =BF? >>> Here, there is a need of defining the common underlying protocol >>(which is not RTCWeb developer concern). >> >>No, it's not. > There is a strong need to define signaling protocol which helps > Browsers to interop and also reduce the complexity for web developers Again: browsers MUST not *directly* interop with other browsers in the *signaling* plane. If two browsers visit the same page and download the *same* JavaScript, such JS already can say the browsers how to signal the media. Please, don't insist on the same again and again. There is NO need at all for web browsers to natively and directly speak SIP/XMPP/other-protocol between them. In fact, that is undesirable. > =C2=A0You can repeat 1000 times by ignoring any rationale >>already replied to you in multiple threads. But that changes nothing. >>WebRTC does not need native SIP or native XMPP/Jingle spoken by web >>browsers. In fact, that would stop innovation, would mandate website > > I have clarified multiple time that your innovation is not going > to stop by defining standard signaling protocol. Let say X protocol becom= e > standard signaling protocol which does not mean that you should not > implement your SIP over websocket using Javascript. So, this is false > propaganda by few folks that it would stop innovation. Ok. But in other mails you propose that WebRTC should be an island for web browsers. Wouldn't that stop innovation? >>admins to provide a SIP/XMPP server within their infrastructure (how!) >>and would make WebRTC unfeasible in shared web hostings. > In case you talking about manageability of the servers, lot of m= ore > Stuff involved than simple protocol decision No. What I meant is very clear: if the signaling (or the "default signaling" as you propose) is not carried via HTTP or WebSocket, then it would require another kind of centralized server (as a SIP proxy in the provider side). So all those websites hosted in shared hosting datacenters (i.e. using a shared Apache with different virtual domains) would have no chance to use WebRTC. Just it. Regards. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Mon Sep 26 12:50: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 8BB3B1F0CCF for ; Mon, 26 Sep 2011 12:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 ZZbdy6d5G0DU for ; Mon, 26 Sep 2011 12:49:59 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 782D41F0CCD for ; Mon, 26 Sep 2011 12:49:59 -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 p8QJr5nF022001; Mon, 26 Sep 2011 15:53:05 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 15:52:33 -0400 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: Tue, 27 Sep 2011 01:22:30 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F1089@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) Thread-Index: Acx8gxdFWYT6x7fVTD6GagRPu5DTGAAAf52Q References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com><05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org><2E239D6FCD033C4BAF15F386A979BF510F1086@sonus inmail02 .sonusnet.co m><2E239D6FCD033C4BAF15F386A979BF510F1088@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 26 Sep 2011 19:52:33.0827 (UTC) FILETIME=[D5514730:01CC7C85] Cc: rtcweb@ietf.org, Jozsef Vass Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 26 Sep 2011 19:50:00 -0000 SGkgSW5ha2ksDQoNCjxzbmlwPiANCk9rLCBidXQgc3VjaCBwcm90b2NvbCBzaG91bGQgYmUgY2Fy cmllZCB3aXRoaW4gSFRUUCBvciBXZWJTb2NrZXQsIHJhdGhlciB0aGFuIGJlaW5nIGEgbmF0aXZl IFNJUC9YTVBQL3doYXRldmVyLWN1c3RvbS1wcm90b2NvbCBidWlsdC1pbiB0aGUgd2ViIGJyb3dz ZXJzLiBEbyB3ZSBhZ3JlZSBvbiB0aGlzPyBJIHRoaW5rIHRoZSBhbnN3ZXIgaXMgIm5vdCIsIHNv IHBsZWFzZSBjb250aW51ZSByZWFkaW5nLiA8L3NuaXA+DQoNCllvdXIgYXNzdW1wdGlvbiBpcyB3 cm9uZyBoZXJlLiBXaGVuIEkgYXNrIGZvciBzdGFuZGFyZCBzaWduYWxpbmcgcHJvdG9jb2wsIHdl YnNvY2tldCB3aWxsIGJlIG9uZSBvZiB0aGUgYWx0ZXJuYXRpdmUgdG8gY29uc2lkZXJlZCBmb3Ig ZnVydGhlciBkaXNjdXNzaW9uIGluIGNhc2UgdGhlcmUgaXMgYW4gYWdyZWVtZW50IGZvciBoYXZp bmcgc3RhbmRhcmQgc2lnbmFsaW5nIHByb3RvY29sLg0KDQpUaGFua3MNClBhcnRoYQ0KDQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWls dG86aWJjQGFsaWF4Lm5ldF0NCj5TZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjcsIDIwMTEgMTow MyBBTQ0KPlRvOiBSYXZpbmRyYW4gUGFydGhhc2FyYXRoaQ0KPkNjOiBKb3pzZWYgVmFzczsgU2HD umwgSWJhcnJhIENvcnJldGfDqTsgcnRjd2ViQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtydGN3 ZWJdICIyMCBsaW5lcyIgKFJlOiBSVENXZWIgZGVmYXVsdCBzaWduYWxpbmcgcHJvdG9jb2wNCj5b d2FzIFJFOiBBYm91dCBkZWZpbmluZyBhIHNpZ25hbGluZyBwcm90b2NvbCBmb3IgV2ViUlRDIChv ciBub3QpXSkNCj4NCj5IaSBSYXZpbmRyYW4sIGNvbW1lbnRzIGlubGluZToNCj4NCj4NCj4yMDEx LzkvMjYgUmF2aW5kcmFuIFBhcnRoYXNhcmF0aGkgPHByYXZpbmRyYW5Ac29udXNuZXQuY29tPjoN Cj4+IFRoZSBhaW0gb2YgaGF2aW5nIHN0YW5kYXJkIFJUQ1dlYiBzaWduYWxpbmcgcHJvdG9jb2wg aXMgdG8gbWFrZSBiYXNpYw0KPmRpYWxvZyBiZXR3ZWVuIHR3byBkaWZmZXJlbnQgYnJvd3NlcnMg KEZvciBleDogTW96aWxsYSAmIGNocm9tZSkgdXNlci4NCj4NCj5BbmQgbWUgYW5kIG90aGVycyBh bHJlYWR5IHNhaWQgdGhhdCB0aGUgYWltIG9mIFdlYlJUQyBpcyBub3QNCj5jb252ZXJ0aW5nIHdl YiBicm93c2VycyBpbnRvIGdlbmVyaWMgU0lQIHBob25lcyBjYXBhYmxlIG9mDQo+ZXN0YWJsaXNo aW5nIGEgY2FsbCBiZXR3ZWVuIHRoZW0gd2l0aG91dCB2aXNpdGluZyB0aGUgc2FtZSBwYWdlDQo+ KHJlcGxhY2UgIlNJUCIgd2l0aCB3aGljaGV2ZXIgcHJvdG9jb2wpLg0KPg0KPldlYlJUQyBhZGRz IHZhbHVlIHRvIHRoZSBXV1cgd29ybGQsIHNvIGl0J3MgYXNzdW1lZCB0aGF0IGZpcnN0IG9mIGFs bCwNCj5icm93c2VycyB2aXNpdCBzb21lIHdlYnNpdGUsIHNvIHRoZXkgY2FuIGdldCBzb21ldGhp bmcgKEphdmFTY3JpcHQNCj5jb2RlKS4NCj4NCj4NCj4NCj4+IEhhdmluZyBzZWVpbmcgdGhlIGxp c3QgZGlzY3Vzc2lvbiBvbiBzaWduYWxpbmcgaW50cmljYWNpZXMgaW4gdGhpcw0KPmFsaWFzLCBp dCBpcyBubyBwb2ludCBpbiBhc2tpbmcgZWFjaCB3ZWIgZGV2ZWxvcGVyIHRvIGNyZWF0ZSB0aGVp ciBvd24NCj5zaWduYWxpbmcgcHJvdG9jb2wuIEl0IGlzIGJldHRlciBmb3IgSUVURiB0byByZWNv bW1lbmQgb25lIHByb3RvY29sDQo+d2hpY2ggYmVzdCBzdWl0IFJUQ1dlYiBzaWduYWxpbmcgcmVx dWlyZW1lbnQgYW5kIGJlc3Qgc2ltcGxlIEFQSSBmb3INCj5zaWduYWxpbmcgcHJvdG9jb2wgd2ls bCBiZSBkZWZpbmVkIGJ5IFczQy4NCj4NCj5PaywgYnV0IHN1Y2ggcHJvdG9jb2wgc2hvdWxkIGJl IGNhcnJpZWQgd2l0aGluIEhUVFAgb3IgV2ViU29ja2V0LA0KPnJhdGhlciB0aGFuIGJlaW5nIGEg bmF0aXZlIFNJUC9YTVBQL3doYXRldmVyLWN1c3RvbS1wcm90b2NvbCBidWlsdC1pbg0KPnRoZSB3 ZWIgYnJvd3NlcnMuIERvIHdlIGFncmVlIG9uIHRoaXM/IEkgdGhpbmsgdGhlIGFuc3dlciBpcyAi bm90Iiwgc28NCj5wbGVhc2UgY29udGludWUgcmVhZGluZy4NCj4NCj4NCj4NCj4+PlJhdmluZHJh biwgeW91IGluc2lzdCBvZiB0aGF0IGV2ZW4gd2hlbiBtdWx0aXBsZSBjb21tZW50cyB0ZWxsIHlv dSB0aGUNCj4+Pm9wcG9zaXRlLiBJZiBNb3ppbGxhLCBDaHJvbWUgb3IgSUUgYnJvd3NlcnMgYXJl IHZpc2l0aW5nIHRoZSAqc2FtZSoNCj4+PndlYnNpdGUgdGhlbiB0aGV5ICphbHJlYWR5KiBzaGFy ZSB0aGUgKnNhbWUqIEphdmFTY3JpcHQgKGxvYWRlZCBmcm9tDQo+Pj50aGUgd2Vic2l0ZSkgc28g dGhleSBjYW4gc2lnbmFsIHRoZSBtZWRpYSB0aG91Z2h0IHRoZSB3ZWIgc2VydmVyIChieQ0KPj4+ dXNpbmcgSFRUUCBvciBXZWJTb2NrZXQpIGFzIGRlZmluZWQgaW4gdGhlIHJldHJpZXZlZCBKYXZh U2NyaXB0IGNvZGUuDQo+Pj5UaGlzIGlzIGVhc3kgdG8gdW5kZXJzdGFuZCBJTUhPIGFuZCB0aGlz IGlzIGhvdyBXV1cgd29ya3MgZm9yIHllYXJzID0+DQo+Pj5pbnRlcm9wZXJhYmlsaXR5IGJldHdl ZW4gY2xpZW50cyB2aXNpdGluZyB0aGUgc2FtZSB3ZWJzaXRlLiBQZXJpb2QuDQo+Pj4NCj4+IDxw YXJ0aGE+IFdXVyB3b3JrcyB3aXRoIHBsdWdpbi4gSWYgeW91IHRoaW5rIG90aGVyd2lzZSwgdGhl cmUgaXMgbm8NCj5tdWNoDQo+PiBXb3JrIGZvciBJRVRGIGluIHRoaXMgV0cgPC9wYXJ0aGE+DQo+ DQo+QUZBSUsgb25lIG9mIHRoZSBhaW1zIG9mIFdlYlJUQyBpcyBhbGxvd2luZyBtdWx0aW1lZGlh IHNlc3Npb25zIHdpdGhpbg0KPmJyb3dzZXJzICp3aXRob3V0KiB0aGUgbmVlZCBvZiBleHRlcm5h bCBwbHVnaW5zIChsaWtlIEZsYXNoIG9yIEphdmENCj5hcHBsZXRzKS4NCj4NCj4NCj4NCj4NCj4+ PklmIHRoZSBicm93c2VycyBzcGVhayAqbmF0aXZlKiBTSVAgKGFzIHlvdSBzdWdnZXN0IGluIG1h bnkgdGhyZWFkcykNCj4+IDxwYXJ0aGE+IEkgYXNrZWQgaW5pdGlhbGx5IGJlY2F1c2UgaXQgaXMg ZGVmYWN0byByZWNvbW1lbmRlZCBJRVRGDQo+PiByZWFsLXRpbWUgcHJvdG9jb2wgPC9wYXJ0aGE+ DQo+DQo+SSdtIHN1cmUgdGhhdCBmYW5zIG9mIFhNUFAgd291bGQgbm90IGxpa2UgdGhhdCAoZXZl biBsZXNzIHRha2luZyBpbnRvDQo+YWNjb3VudCB0aGF0IFhNUFAgaXMgbXVjaCBtb3JlIGRlcGxv eWVkIGluIHB1cmUgSW50ZXJuZXQgdGhhbiBTSVApLg0KPg0KPg0KPg0KPj4+dGhlbiB0aGUgd2Vi IHNlcnZlciBpcyB1bmF3YXJlIG9mIHdoYXQgaXMgaGFwcGVuaW5nIGF0IG1lZGlhIGxldmVsDQo+ Pj5iZXR3ZWVuIHRoZSB2aXNpdG9ycyAoYmVjYXVzZSB0aGUgd2ViIHNlcnZlciwgd2hlcmUgdGhl IGFwcGxpY2F0aW9uDQo+Pj5sb2dpYyBpcywgZG9lcyBub3Qgc2VlIHRoZSBzaWduYWxpbmcgdHJh ZmZpYykuDQo+DQo+PiA8cGFydGhhPiBJTU8sIGl0IGlzIHlvdXIgYmFkIGFzc3VtcHRpb24uIFRo ZXJlIGFyZSAibiIgbnVtYmVyIG9mIHdheQ0KPnRvDQo+PiBEZXNpZ24gc2VydmVyIGV2ZW4gaWYg dGhleSBzcGVhayBkaWZmZXJlbnQgcHJvdG9jb2wgd2hpY2ggaXMgYSBjb21tb24NCj4+IFByYWN0 aWNlIGluIGdhdGV3YXkgaW1wbGVtZW50YXRpb24gPC9wYXJ0aGE+DQo+DQo+U28geW91IHdhbnQg YSAiYnVpbHQtaW4gcHJvdG9jb2wiIG5vdCB0byBib3JlIHdlYiBkZXZlbG9wZXJzIHdpdGgNCj5j dXN0b20gYW5kIGNvbXBsZXggc2lnbmFsaW5nIHByb3RvY29scywgYnV0IGF0IHRoZSBzYW1lIHRp bWUgeW91IHdhbnQNCj50byBmb3JjZSB0aGVtIHRvIGJ1aWxkIGEgaHlwZXItY29tcGxleCBnYXRl d2F5IGluIHNlcnZlciBzaWRlLiDCvz/Cvz8NCj4NCj4NCj4NCj4+Pj4gSGVyZSwgdGhlcmUgaXMg YSBuZWVkIG9mIGRlZmluaW5nIHRoZSBjb21tb24gdW5kZXJseWluZyBwcm90b2NvbA0KPj4+KHdo aWNoIGlzIG5vdCBSVENXZWIgZGV2ZWxvcGVyIGNvbmNlcm4pLg0KPj4+DQo+Pj5ObywgaXQncyBu b3QuDQo+PiA8cGFydGhhPiBUaGVyZSBpcyBhIHN0cm9uZyBuZWVkIHRvIGRlZmluZSBzaWduYWxp bmcgcHJvdG9jb2wgd2hpY2gNCj5oZWxwcw0KPj4gQnJvd3NlcnMgdG8gaW50ZXJvcCBhbmQgYWxz byByZWR1Y2UgdGhlIGNvbXBsZXhpdHkgZm9yIHdlYiBkZXZlbG9wZXJzDQo+PC9wYXJ0aGE+DQo+ DQo+QWdhaW46IGJyb3dzZXJzIE1VU1Qgbm90ICpkaXJlY3RseSogaW50ZXJvcCB3aXRoIG90aGVy IGJyb3dzZXJzIGluIHRoZQ0KPipzaWduYWxpbmcqIHBsYW5lLiBJZiB0d28gYnJvd3NlcnMgdmlz aXQgdGhlIHNhbWUgcGFnZSBhbmQgZG93bmxvYWQNCj50aGUgKnNhbWUqIEphdmFTY3JpcHQsIHN1 Y2ggSlMgYWxyZWFkeSBjYW4gc2F5IHRoZSBicm93c2VycyBob3cgdG8NCj5zaWduYWwgdGhlIG1l ZGlhLg0KPg0KPlBsZWFzZSwgZG9uJ3QgaW5zaXN0IG9uIHRoZSBzYW1lIGFnYWluIGFuZCBhZ2Fp bi4gVGhlcmUgaXMgTk8gbmVlZCBhdA0KPmFsbCBmb3Igd2ViIGJyb3dzZXJzIHRvIG5hdGl2ZWx5 IGFuZCBkaXJlY3RseSBzcGVhaw0KPlNJUC9YTVBQL290aGVyLXByb3RvY29sIGJldHdlZW4gdGhl bS4gSW4gZmFjdCwgdGhhdCBpcyB1bmRlc2lyYWJsZS4NCj4NCj4NCj4NCj4+IMKgWW91IGNhbiBy ZXBlYXQgMTAwMCB0aW1lcyBieSBpZ25vcmluZyBhbnkgcmF0aW9uYWxlDQo+Pj5hbHJlYWR5IHJl cGxpZWQgdG8geW91IGluIG11bHRpcGxlIHRocmVhZHMuIEJ1dCB0aGF0IGNoYW5nZXMgbm90aGlu Zy4NCj4+PldlYlJUQyBkb2VzIG5vdCBuZWVkIG5hdGl2ZSBTSVAgb3IgbmF0aXZlIFhNUFAvSmlu Z2xlIHNwb2tlbiBieSB3ZWINCj4+PmJyb3dzZXJzLiBJbiBmYWN0LCB0aGF0IHdvdWxkIHN0b3Ag aW5ub3ZhdGlvbiwgd291bGQgbWFuZGF0ZSB3ZWJzaXRlDQo+Pg0KPj4gPHBhcnRoYT4gSSBoYXZl IGNsYXJpZmllZCBtdWx0aXBsZSB0aW1lIHRoYXQgeW91ciBpbm5vdmF0aW9uIGlzIG5vdA0KPmdv aW5nDQo+PiB0byBzdG9wIGJ5IGRlZmluaW5nIHN0YW5kYXJkIHNpZ25hbGluZyBwcm90b2NvbC4g TGV0IHNheSBYIHByb3RvY29sDQo+YmVjb21lDQo+PiBzdGFuZGFyZCBzaWduYWxpbmcgcHJvdG9j b2wgd2hpY2ggZG9lcyBub3QgbWVhbiB0aGF0IHlvdSBzaG91bGQgbm90DQo+PiBpbXBsZW1lbnQg eW91ciBTSVAgb3ZlciB3ZWJzb2NrZXQgdXNpbmcgSmF2YXNjcmlwdC4gU28sIHRoaXMgaXMgZmFs c2UNCj4+IHByb3BhZ2FuZGEgYnkgZmV3IGZvbGtzIHRoYXQgaXQgd291bGQgc3RvcCBpbm5vdmF0 aW9uLiA8L3BhcnRoYT4NCj4NCj5Pay4gQnV0IGluIG90aGVyIG1haWxzIHlvdSBwcm9wb3NlIHRo YXQgV2ViUlRDIHNob3VsZCBiZSBhbiBpc2xhbmQgZm9yDQo+d2ViIGJyb3dzZXJzLiBXb3VsZG4n dCB0aGF0IHN0b3AgaW5ub3ZhdGlvbj8NCj4NCj4NCj4NCj4+PmFkbWlucyB0byBwcm92aWRlIGEg U0lQL1hNUFAgc2VydmVyIHdpdGhpbiB0aGVpciBpbmZyYXN0cnVjdHVyZSAoaG93ISkNCj4+PmFu ZCB3b3VsZCBtYWtlIFdlYlJUQyB1bmZlYXNpYmxlIGluIHNoYXJlZCB3ZWIgaG9zdGluZ3MuDQo+ DQo+PiA8cGFydGhhPiBJbiBjYXNlIHlvdSB0YWxraW5nIGFib3V0IG1hbmFnZWFiaWxpdHkgb2Yg dGhlIHNlcnZlcnMsIGxvdA0KPm9mIG1vcmUNCj4+IFN0dWZmIGludm9sdmVkIHRoYW4gc2ltcGxl IHByb3RvY29sIGRlY2lzaW9uIDwvcGFydGhhPg0KPg0KPk5vLiBXaGF0IEkgbWVhbnQgaXMgdmVy eSBjbGVhcjogaWYgdGhlIHNpZ25hbGluZyAob3IgdGhlICJkZWZhdWx0DQo+c2lnbmFsaW5nIiBh cyB5b3UgcHJvcG9zZSkgaXMgbm90IGNhcnJpZWQgdmlhIEhUVFAgb3IgV2ViU29ja2V0LCB0aGVu DQo+aXQgd291bGQgcmVxdWlyZSBhbm90aGVyIGtpbmQgb2YgY2VudHJhbGl6ZWQgc2VydmVyIChh cyBhIFNJUCBwcm94eSBpbg0KPnRoZSBwcm92aWRlciBzaWRlKS4gU28gYWxsIHRob3NlIHdlYnNp dGVzIGhvc3RlZCBpbiBzaGFyZWQgaG9zdGluZw0KPmRhdGFjZW50ZXJzIChpLmUuIHVzaW5nIGEg c2hhcmVkIEFwYWNoZSB3aXRoIGRpZmZlcmVudCB2aXJ0dWFsDQo+ZG9tYWlucykgd291bGQgaGF2 ZSBubyBjaGFuY2UgdG8gdXNlIFdlYlJUQy4gSnVzdCBpdC4NCj4NCj4NCj4NCj5SZWdhcmRzLg0K Pg0KPg0KPi0tDQo+ScOxYWtpIEJheiBDYXN0aWxsbw0KPjxpYmNAYWxpYXgubmV0Pg0K From bernard_aboba@hotmail.com Mon Sep 26 20:42: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 C7AE321F8B9A for ; Mon, 26 Sep 2011 20:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.324 X-Spam-Level: X-Spam-Status: No, score=-102.324 tagged_above=-999 required=5 tests=[AWL=0.274, 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 SiZ1-EQU-QtN for ; Mon, 26 Sep 2011 20:42:08 -0700 (PDT) Received: from blu0-omc4-s13.blu0.hotmail.com (blu0-omc4-s13.blu0.hotmail.com [65.55.111.152]) by ietfa.amsl.com (Postfix) with ESMTP id 42BEB21F8B91 for ; Mon, 26 Sep 2011 20:42:08 -0700 (PDT) Received: from BLU152-W62 ([65.55.111.135]) by blu0-omc4-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 20:44:48 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_206c3daf-e2bb-4e08-901d-e0fbd7141513_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: Date: Mon, 26 Sep 2011 20:44:48 -0700 Importance: Normal In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> References: <4E80984A.903@skype.net>, <4E809EE6.2050702@skype.net>, <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Sep 2011 03:44:48.0696 (UTC) FILETIME=[CE372B80:01CC7CC7] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 03:42:08 -0000 --_206c3daf-e2bb-4e08-901d-e0fbd7141513_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > And "interoperability with SIP-PSTN providers" is only relevant if you > are trying to turn the browser into another phone. We have enough > phones. What we don't have are new real-time communication experiences > that can only be created within this environment. [BA] I think you may be on to something here. POTS lines are dropping so r= apidly that wireline service won't even exist in some countries within a few years= . While PSTN interop may have been a key scenario in the early days of SIP=2C I hav= e serious doubts as to how much attention we should pay to this in RTCWEB. Ability t= o make a call to an E.164 number? Probably. Support for every potential cor= ner case? Not necessarily.=20 = --_206c3daf-e2bb-4e08-901d-e0fbd7141513_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B And "interoperability with SIP-PSTN providers" is only rele= vant if you
>=3B are trying to turn the browser into another phone. We= have enough
>=3B phones. What we don't have are new real-time communi= cation experiences
>=3B that can only be created within this environme= nt.

[BA] I think you may be on to something here. =3B POTS lines= are dropping so rapidly
that wireline service won't even exist in some = countries within a few years. =3B While
PSTN interop may have been a= key scenario in the early days of SIP=2C I have serious
doubts as to ho= w much attention we should pay to this in RTCWEB. =3B Ability to
mak= e a call to an E.164 number? =3B Probably. =3B Support for every po= tential corner
case? =3B Not necessarily.
= --_206c3daf-e2bb-4e08-901d-e0fbd7141513_-- From tim@phonefromhere.com Mon Sep 26 21: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 85D9421F84FB for ; Mon, 26 Sep 2011 21:46:58 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 hDPW2TaDAWoL for ; Mon, 26 Sep 2011 21:46:58 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id BBB8221F84FD for ; Mon, 26 Sep 2011 21:46:57 -0700 (PDT) Received: from [10.10.3.110] (unknown [216.38.153.2]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id C6CAE37A902; Tue, 27 Sep 2011 06:02:20 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_2E1F0472-25AC-401D-9F6C-CF82C4F01390" From: Tim Panton In-Reply-To: Date: Mon, 26 Sep 2011 21:49:18 -0700 Message-Id: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> To: Roman Shpount X-Mailer: Apple Mail (2.1244.3) Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 04:46:58 -0000 --Apple-Mail=_2E1F0472-25AC-401D-9F6C-CF82C4F01390 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 26 Sep 2011, at 09:26, Roman Shpount wrote: >=20 > On Mon, Sep 26, 2011 at 11:48 AM, Matthew Kaufman = wrote: > And "interoperability with SIP-PSTN providers" is only relevant if you = are trying to turn the browser into another phone. We have enough = phones. What we don't have are new real-time communication experiences = that can only be created within this environment. >=20 > Are we deliberately creating an island? To be honest, I actually = wanted to put RTC in the phone, instead of SIP. I think it would be a = great idea to have desktop phone which runs a webkit browser with RTC = and serves as an advanced display phone for a PBX. If RTC would not = support no-ICE non-RTP calls, my only option would be to ignore the = standard. So, in a sense we do not have enough phones. I am confused. Which phones today connect directly to a SIP to PSTN = gateway ? I'd guess none.=20 Almost all of them go through some registrar and/or proxy. =20 >=20 > I think you point in a lot of ways is similar to the argument that we = should disable HTTP and leave only HTTPS since it is the only secure way = to communicate and everything else would be an attack vector. No, HTTP today does not let me probe the innards of your network ( = inside your firewall) just by sending=20 a legal but evil payload. If you permit webRTC without ICE, then the = browser can be told to fake up UDP packets and send them to anywhere on your inner LAN. DOS-city. Tim.=20= --Apple-Mail=_2E1F0472-25AC-401D-9F6C-CF82C4F01390 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On 26 Sep 2011, at 09:26, Roman Shpount wrote:


On Mon, Sep 26, 2011 at 11:48 AM, Matthew Kaufman <matthew.kaufman@skype.net> wrote:
And "interoperability with SIP-PSTN providers" is only relevant if you are trying to turn the browser into another phone. We have enough phones. What we don't have are new real-time communication experiences that can only be created within this environment.

Are we deliberately creating an island? To be honest, I actually wanted to put RTC in the phone, instead of SIP. I think it would be a great idea to have desktop phone which runs a webkit browser with RTC and serves as an advanced display phone for a PBX. If RTC would not support no-ICE non-RTP calls, my only option would be to ignore the standard. So, in a sense we do not have enough phones.

I am confused. Which phones today connect directly to a SIP to PSTN gateway ? I'd guess none. 
Almost all of them go through some registrar and/or proxy.  


I think you point in a lot of ways is similar to the argument that we should disable HTTP and leave only HTTPS since it is the only secure way to communicate and everything else would be an attack vector.

No, HTTP today does not let me probe the innards of your network ( inside your firewall) just by sending 
a legal but evil payload. If you permit webRTC without ICE, then the browser can be told to fake up UDP packets
and send them to anywhere on your inner LAN. DOS-city.

Tim. 
--Apple-Mail=_2E1F0472-25AC-401D-9F6C-CF82C4F01390-- From juberti@google.com Mon Sep 26 22:33: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 583B521F8D41 for ; Mon, 26 Sep 2011 22:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.539 X-Spam-Level: X-Spam-Status: No, score=-105.539 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5lVDq3XMJEO for ; Mon, 26 Sep 2011 22:33:47 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 75FC921F8CFB for ; Mon, 26 Sep 2011 22:33:40 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p8R5aNpG022402 for ; Mon, 26 Sep 2011 22:36:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317101784; bh=zktBaL9IUT7GySs866fpjcrD8PI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=U6bcW4nyqnIKKX6fHDbTqs/zYoV8ELNr+dkbO0hne+fcRblC44oyszgbQliBq5NbW zGqAEr/2FY2MdeykeK82g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=oN2tsUsk8fv3WDTv6JcYNM28P8QT5/E4AE1rlGn5+To2PUzL68a01oxsp0dmAjGNp g4K5cB93E7TvjMNogPCrA== Received: from iabz21 (iabz21.prod.google.com [10.12.102.21]) by wpaz13.hot.corp.google.com with ESMTP id p8R5aMDF015419 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 26 Sep 2011 22:36:22 -0700 Received: by iabz21 with SMTP id z21so7746614iab.37 for ; Mon, 26 Sep 2011 22:36:22 -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; bh=xyu35xLMWLnb8hyYUzZYhkvtPMcQCuilH0sjNeoLLlQ=; b=F0DAZwvbwIhAnaAWKRf0SXVuxpFqcgQcmBrULphormY2HEPTLrREPNuTE95ESKEp4R rwVWsc1EH7CLs0iCdIEA== Received: by 10.42.139.137 with SMTP id g9mr8826526icu.75.1317101781981; Mon, 26 Sep 2011 22:36:21 -0700 (PDT) Received: by 10.42.139.137 with SMTP id g9mr8826470icu.75.1317101780136; Mon, 26 Sep 2011 22:36:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.34.1 with HTTP; Mon, 26 Sep 2011 22:36:00 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> From: Justin Uberti Date: Tue, 27 Sep 2011 01:36:00 -0400 Message-ID: To: Tim Panton Content-Type: multipart/alternative; boundary=90e6ba6e8a16bcf20d04ade5a70b X-System-Of-Record: true Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 05:33:48 -0000 --90e6ba6e8a16bcf20d04ade5a70b Content-Type: text/plain; charset=UTF-8 Yes, most PSTN providers don't support ICE. They also often don't support SRTP, RTCP, RTP over TCP, or even jitter buffers. To run a robust telephony service, you will need to frontend that traffic with a media gateway of some sort, and that gateway can easily support ICE. On Tue, Sep 27, 2011 at 12:49 AM, Tim Panton wrote: > > On 26 Sep 2011, at 09:26, Roman Shpount wrote: > > > On Mon, Sep 26, 2011 at 11:48 AM, Matthew Kaufman < > matthew.kaufman@skype.net> wrote: > >> And "interoperability with SIP-PSTN providers" is only relevant if you are >> trying to turn the browser into another phone. We have enough phones. What >> we don't have are new real-time communication experiences that can only be >> created within this environment. >> > > Are we deliberately creating an island? To be honest, I actually wanted to > put RTC in the phone, instead of SIP. I think it would be a great idea to > have desktop phone which runs a webkit browser with RTC and serves as an > advanced display phone for a PBX. If RTC would not support no-ICE non-RTP > calls, my only option would be to ignore the standard. So, in a sense we do > not have enough phones. > > > I am confused. Which phones today connect directly to a SIP to PSTN gateway > ? I'd guess none. > Almost all of them go through some registrar and/or proxy. > > > I think you point in a lot of ways is similar to the argument that we > should disable HTTP and leave only HTTPS since it is the only secure way to > communicate and everything else would be an attack vector. > > > No, HTTP today does not let me probe the innards of your network ( inside > your firewall) just by sending > a legal but evil payload. If you permit webRTC without ICE, then the > browser can be told to fake up UDP packets > and send them to anywhere on your inner LAN. DOS-city. > > Tim. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --90e6ba6e8a16bcf20d04ade5a70b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, most PSTN providers don't support ICE. They also often don't s= upport SRTP, RTCP, RTP over TCP, or even jitter buffers. To run a robust te= lephony service, you will need to frontend that traffic with a media gatewa= y of some sort, and that gateway can easily support ICE.

On Tue, Sep 27, 2011 at 12:49 AM, Tim Panton= <tim@phonefr= omhere.com> wrote:

On 26 S= ep 2011, at 09:26, Roman Shpount wrote:

=
On Mon, Sep 26, 2011 at 11:48 AM, Matthew Ka= ufman <matthew.kaufman@skype.net> wrote:
And "interoperability with SIP-PSTN providers" is only relevant i= f you are trying to turn the browser into another phone. We have enough pho= nes. What we don't have are new real-time communication experiences tha= t can only be created within this environment.

Are we deliberately creating an island? To be honest= , I actually wanted to put RTC in the phone, instead of SIP. I think it wou= ld be a great idea to have desktop phone which runs a webkit browser with R= TC and serves as an advanced display phone for a PBX. If RTC would not supp= ort no-ICE non-RTP calls, my only option would be to ignore the standard. S= o, in a sense we do not have enough phones.

I am confused. Which phones today co= nnect directly to a SIP to PSTN gateway ? I'd guess none.=C2=A0
Almost all of them go through some registrar and/or proxy. =C2=A0
<= div class=3D"im">

I think you point in a lot of ways is similar to the argument that we s= hould disable HTTP and leave only HTTPS since it is the only secure way to = communicate and everything else would be an attack vector.

No, HTTP today does not let me probe= the innards of your network ( inside your firewall) just by sending=C2=A0<= /div>
a legal but evil payload. If you permit webRTC without ICE, then = the browser can be told to fake up UDP packets
and send them to anywhere on your inner LAN. DOS-city.

=
Tim.=C2=A0
=

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


--90e6ba6e8a16bcf20d04ade5a70b-- From salvatore.loreto@ericsson.com Tue Sep 27 00:03: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 A846621F8DFE for ; Tue, 27 Sep 2011 00:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 c3xh3OBOiqnk for ; Tue, 27 Sep 2011 00:03:13 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id EA06D21F8DEC for ; Tue, 27 Sep 2011 00:03:12 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-81-4e8175d40a41 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 93.14.20773.4D5718E4; Tue, 27 Sep 2011 09:05:56 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Tue, 27 Sep 2011 09:05:44 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B5C50245F for ; Tue, 27 Sep 2011 10:05:44 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7F8E1514DE for ; Tue, 27 Sep 2011 10:05:44 +0300 (EEST) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3B97D50CEE for ; Tue, 27 Sep 2011 10:05:44 +0300 (EEST) Message-ID: <4E8175C8.2010902@ericsson.com> Date: Tue, 27 Sep 2011 10:05:44 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E801CFE.4030504@ericsson.com> In-Reply-To: <4E801CFE.4030504@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] draft-ietf-rtcweb-use-cases-and-requirements-05 addition around IPv6 only and dualstack X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 07:03:13 -0000 On 9/26/11 9:34 AM, Magnus Westerlund wrote: > Hi, > > (as individual) > > I would suggest that some section for general requirements that aren't > use case specific is created and at least one such requirement is added. > > The requirement is the need to support IPv4 only, IPv6 only and > dual-stack deployments as required by our charter. I think this should > be added into the use-case and requirement document for two reasons. > First, that is located next to the other requirements, secondly because > W3C has decided to use our document also, I think it is important that > such a general requirement both on protocols and any address field in > the API handling both address families are covered. I agree /Sal From saul@ag-projects.com Tue Sep 27 00:23: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 F22FC21F8E06 for ; Tue, 27 Sep 2011 00:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpPQQWRBYfvC for ; Tue, 27 Sep 2011 00:23:53 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id CA80821F8CEC for ; Tue, 27 Sep 2011 00:23:51 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 042F7B01B0; Tue, 27 Sep 2011 09:26:32 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 2CB2CB017D; Tue, 27 Sep 2011 09:26:32 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F1089@sonusinmail02.sonusnet.com> Date: Tue, 27 Sep 2011 09:26:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <34DBD417-B3B0-4659-911D-BC09BBF2559B@ag-projects.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com><05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org><2E239D6FCD033C4BAF15F386A979BF510F1086@sonus inmail02 .sonusnet.co m><2E239D6FCD033C4BAF15F386A979BF510F1088@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F1089@sonusinmail02.sonusnet.com> To: Ravindran Parthasarathi X-Mailer: Apple Mail (2.1084) Cc: Jozsef Vass , rtcweb@ietf.org Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 07:23:54 -0000 Hi, On Sep 26, 2011, at 9:52 PM, Ravindran Parthasarathi wrote: > Hi Inaki, >=20 > =20 > Ok, but such protocol should be carried within HTTP or WebSocket, = rather than being a native SIP/XMPP/whatever-custom-protocol built-in = the web browsers. Do we agree on this? I think the answer is "not", so = please continue reading. >=20 > Your assumption is wrong here. When I ask for standard signaling = protocol, websocket will be one of the alternative to considered for = further discussion in case there is an agreement for having standard = signaling protocol. >=20 I'd consider WebSocket the transport, not the signaling protocol per se. = After reading your last emails I'm not exactly sure about what you are = proposing. Let me state a starting point: two browsers can't communicate = with each other without meeting somewhere, like a server for example. = Both are behind NAT and there is no discovery mechanism, so the only way = for them to communicate is to visit a website, for example. Now, if two users (browsers) are already in the same website, they'd = have downloaded the same JS libraries from the web server, as Inaki = pointed out, so they may speak SIP, XMPP or whatever signaling protocol. What I think you are suggesting is that RTCweb-enabled browsers include = some sort of signaling library built-in, is this correct? Even if they = do that you'll need server cooperation to reach each other, and even in = the multiplayer game example, you are always connected to a server. Thus, I strongly disagree to trying to include any signaling protocol as = part of RTCweb. Developers may choose a JS library to do that, or even = develop their own, and deploy it in the web servers that power their = site. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Tue Sep 27 00:32: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 D4D6F21F8B90 for ; Tue, 27 Sep 2011 00:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjo-pzNvXP30 for ; Tue, 27 Sep 2011 00:32:10 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 53CEB21F8B88 for ; Tue, 27 Sep 2011 00:32:10 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 6AD73B01B4; Tue, 27 Sep 2011 09:34:54 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id B2017B017D; Tue, 27 Sep 2011 09:34:53 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Tue, 27 Sep 2011 09:34:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E80984A.903@skype.net>, <4E809EE6.2050702@skype.net>, <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 07:32:10 -0000 On Sep 27, 2011, at 5:44 AM, Bernard Aboba wrote: >=20 > > And "interoperability with SIP-PSTN providers" is only relevant if = you > > are trying to turn the browser into another phone. We have enough > > phones. What we don't have are new real-time communication = experiences > > that can only be created within this environment. >=20 > [BA] I think you may be on to something here. POTS lines are dropping = so rapidly > that wireline service won't even exist in some countries within a few = years. While > PSTN interop may have been a key scenario in the early days of SIP, I = have serious > doubts as to how much attention we should pay to this in RTCWEB. = Ability to > make a call to an E.164 number? Probably. Support for every = potential corner > case? Not necessarily.=20 PSTN gateways are one example of non-ICE capable devices (usually) as of = today. But it's not the only one. None of the hardware SIP phones I've = used support ICE, so we'd have trouble when talking to them. I do agree that requiring ICE is a good idea, but I don't think the = currently deployed infrastructures are ready for it today. Maybe ICE = support will improve across vendors and it'll be more widely adopted if = RTCweb mandates it, we'll see :-) -- Sa=FAl Ibarra Corretg=E9 AG Projects From harald@alvestrand.no Tue Sep 27 01:12: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 4634A21F85EF for ; Tue, 27 Sep 2011 01:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.938 X-Spam-Level: X-Spam-Status: No, score=-108.938 tagged_above=-999 required=5 tests=[AWL=1.661, 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 q4PUrCk4yslA for ; Tue, 27 Sep 2011 01:12:08 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 947BA21F84BB for ; Tue, 27 Sep 2011 01:12:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E36AC39E0E7 for ; Tue, 27 Sep 2011 10:14:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsNEnA5F3k+R for ; Tue, 27 Sep 2011 10:14:52 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 83ABA39E051 for ; Tue, 27 Sep 2011 10:14:52 +0200 (CEST) Message-ID: <4E8185FC.8000906@alvestrand.no> Date: Tue, 27 Sep 2011 10:14:52 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 08:12:09 -0000 On 09/26/11 20:48, Roman Shpount wrote: > You can determine that end point is not behind symmetric NAT using > older STUN specification and list discovered IP as a default contact > address in SDP, if you are not behind NAT, you can list the relayed > address of the TURN server as the default address. If you do this, > together with the offer that lists ICE candidates, you would be able > to traverse NAT and communicate with non-ICE end points. > > I think discussion in this thread is not whether ICE needs to be > supported or implemented. I would say that ICE without a doubt should > be supported. It is about changing ICE specification as it stands > right now, and force the RTC end point only to communicate with end > points that respond with ICE compliant answer and complete ICE hand > shake. This is actually against the ICE specification as it is defined > in RFC 5245, where answerer actually can refuse to support ICE but > still establish a call. Roman, Which part of RFC 5245 are you referring to with this statement? Please describe the sections you think will be invoked when an SDP OFFER contains ICE candidates, the answerer does not want to use ICE, what the OFFER and ANSWER would look like, and which section of RFC 5245 is invoked when processing the ANSWER. Details are good. Harald From jim.mceachern@genband.com Tue Sep 27 06:51: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 056A021F8CF2 for ; Tue, 27 Sep 2011 06:51:21 -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 avnaFI8Uvf+c for ; Tue, 27 Sep 2011 06:51:20 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id ABEE921F8CC7 for ; Tue, 27 Sep 2011 06:51:15 -0700 (PDT) Received: from mail.genband.com ([63.149.188.88]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKToHVeA1geIhtfBFyWNxIRSihzGb+uPaM@postini.com; Tue, 27 Sep 2011 06:54:06 PDT Received: from owa.genband.com ([172.16.21.97]) by mail.genband.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Sep 2011 08:53:58 -0500 Received: from GBPLMAIL03.genband.com ([fe80::81ee:2d58:ca01:fb9a]) by GBEX01.genband.com ([fe80::a0a8:7818:e701:2f58%13]) with mapi id 14.01.0289.001; Tue, 27 Sep 2011 08:53:57 -0500 From: Jim McEachern To: Harald Alvestrand Thread-Topic: [rtcweb] draft-ietf-rtcweb-use-cases-and-requirements-05 addition around IPv6 only and dualstack Thread-Index: AQHMfBZpfda93khJGUCE1n3c760LNpVfwRsAgAGAhjE= Date: Tue, 27 Sep 2011 13:53:57 +0000 Message-ID: References: <4E801CFE.4030504@ericsson.com>,<4E804C96.1090701@alvestrand.no> In-Reply-To: <4E804C96.1090701@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Sep 2011 13:53:58.0887 (UTC) FILETIME=[E7D3B770:01CC7D1C] X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.500.1024-18410.007 X-TM-AS-Result: No--23.394800-5.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-use-cases-and-requirements-05 addition around IPv6 only and dualstack X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 13:51:21 -0000 I like the idea of a general considerations section applicable to all use c= ases, and I think this proposed list would be a good start. Jim=20 On Sep 26, 2011, at 5:57 AM, "Harald Alvestrand" wro= te: > On 09/26/11 08:34, Magnus Westerlund wrote: >> Hi, >>=20 >> (as individual) >>=20 >> I would suggest that some section for general requirements that aren't >> use case specific is created and at least one such requirement is added. >>=20 >> The requirement is the need to support IPv4 only, IPv6 only and >> dual-stack deployments as required by our charter. I think this should >> be added into the use-case and requirement document for two reasons. >> First, that is located next to the other requirements, secondly because >> W3C has decided to use our document also, I think it is important that >> such a general requirement both on protocols and any address field in >> the API handling both address families are covered. > I support adding those requirements. >=20 > I think that it can also be instantiated within the specific use cases, s= uch as: > - Point to point call: One endpoint on IPv4, the other endpoint on IPv6 > - Multipoint call (with and without central server): One user on IPv4, on= e user on IPv6 >=20 > This is a limitation of the use-case-based model; it gets messy to shoeho= rn all the "permutations" of situations into a single set of use cases, wit= hout the list of use cases growing impossibly long or the use cases' descri= ption expanding into incomprehensibility. >=20 > On balance, I think having a "considerations applicable to all scenarios"= section saying: >=20 > - Clients can be on IPv4-only > - Clients can be on IPv6-only > - Clients can be on dual-stack > - Clients can be on wideband (10s of Mbits/sec) > - Clients can be on narrowband (10s to 100s of Kbits/sec) > - Clients can be on variable-media-quality networks (wireless) > - Clients can be on congested networks > - Clients can be on firewalled networks with no UDP allowed > - Clients can be on networks with cone NAT > - Clients can be on networks with symmetric NAT >=20 > might be a good way to go forward. >=20 > A particular query on v4/v6 interoperation: Should we make it a requireme= nt that dual-stack to IPv4 always use the IPv4 native path rather than a ga= teway functionality (and the converse for IPv6), or should we just be silen= t about it? > I think it may affect some tuning of the ICE address selection algorithm,= in particular if we encounter 6to4 addresses. There might be RFCs we can c= ite already. >=20 >=20 >> Cheers >>=20 >> Magnus Westerlund >>=20 >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From roman@telurix.com Tue Sep 27 07:38: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 8A9B921F8D5F for ; Tue, 27 Sep 2011 07:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=0.350, 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 RmH2jeD2U2vL for ; Tue, 27 Sep 2011 07:38:12 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id D687221F8D5A for ; Tue, 27 Sep 2011 07:38:11 -0700 (PDT) Received: by yic13 with SMTP id 13so6377154yic.31 for ; Tue, 27 Sep 2011 07:40:57 -0700 (PDT) Received: by 10.236.116.103 with SMTP id f67mr21898766yhh.34.1317134457217; Tue, 27 Sep 2011 07:40:57 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id x12sm33983210yhi.10.2011.09.27.07.40.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 07:40:55 -0700 (PDT) Received: by ywa6 with SMTP id 6so6721301ywa.31 for ; Tue, 27 Sep 2011 07:40:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.11.138 with SMTP id q10mr37107491pbb.37.1317134454864; Tue, 27 Sep 2011 07:40:54 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 27 Sep 2011 07:40:54 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> Date: Tue, 27 Sep 2011 10:40:54 -0400 Message-ID: From: Roman Shpount To: Bernard Aboba Content-Type: multipart/alternative; boundary=bcaec5314ad14dbb2b04aded43d0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 14:38:12 -0000 --bcaec5314ad14dbb2b04aded43d0 Content-Type: text/plain; charset=ISO-8859-1 Bernard, What about 500M Skype users? Skype for SIP does not support SRTP or ICE.What about 2 billion wireless subscribers? Despite what you think number of phones and phone numbers is growing, and a wast majority of these phones are dumb wireless phones. _____________ Roman Shpount On Mon, Sep 26, 2011 at 11:44 PM, Bernard Aboba wrote: > > > And "interoperability with SIP-PSTN providers" is only relevant if you > > are trying to turn the browser into another phone. We have enough > > phones. What we don't have are new real-time communication experiences > > that can only be created within this environment. > > [BA] I think you may be on to something here. POTS lines are dropping so > rapidly > that wireline service won't even exist in some countries within a few > years. While > PSTN interop may have been a key scenario in the early days of SIP, I have > serious > doubts as to how much attention we should pay to this in RTCWEB. Ability > to > make a call to an E.164 number? Probably. Support for every potential > corner > case? Not necessarily. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --bcaec5314ad14dbb2b04aded43d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bernard,

What about 500M Skype users? Skype for SIP does not support= SRTP or ICE.What about 2 billion wireless subscribers? Despite what you th= ink number of phones and phone numbers is growing, and a wast majority of t= hese phones are dumb wireless phones.
_____________
Roman Shpount


On Mon, Sep 26, 2011 at 11:44 PM, Bernar= d Aboba <= bernard_aboba@hotmail.com> wrote:

> And "interoperability with SIP-PSTN pr= oviders" is only relevant if you
> are trying to turn the browse= r into another phone. We have enough
> phones. What we don't have= are new real-time communication experiences
> that can only be created within this environment.

[BA] I = think you may be on to something here.=A0 POTS lines are dropping so rapidl= y
that wireline service won't even exist in some countries within a = few years.=A0 While
PSTN interop may have been a key scenario in the early days of SIP, I have = serious
doubts as to how much attention we should pay to this in RTCWEB.= =A0 Ability to
make a call to an E.164 number?=A0 Probably.=A0 Support f= or every potential corner
case?=A0 Not necessarily.

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


--bcaec5314ad14dbb2b04aded43d0-- From roman@telurix.com Tue Sep 27 07:43: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 7FA1121F8CB1 for ; Tue, 27 Sep 2011 07:43:44 -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.338, 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 kudnDtyDw9ad for ; Tue, 27 Sep 2011 07:43:44 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id E5C1621F8CA7 for ; Tue, 27 Sep 2011 07:43:43 -0700 (PDT) Received: by pzk37 with SMTP id 37so18701443pzk.9 for ; Tue, 27 Sep 2011 07:46:29 -0700 (PDT) Received: by 10.68.17.193 with SMTP id q1mr28384956pbd.98.1317134789532; Tue, 27 Sep 2011 07:46:29 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by mx.google.com with ESMTPS id ml4sm85221456pbc.0.2011.09.27.07.46.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 07:46:29 -0700 (PDT) Received: by pzk37 with SMTP id 37so18701350pzk.9 for ; Tue, 27 Sep 2011 07:46:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.36.232 with SMTP id t8mr37689328pbj.54.1317134787264; Tue, 27 Sep 2011 07:46:27 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 27 Sep 2011 07:46:27 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> Date: Tue, 27 Sep 2011 10:46:27 -0400 Message-ID: From: Roman Shpount To: Tim Panton Content-Type: multipart/alternative; boundary=bcaec520e8171dc15204aded5784 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 14:43:44 -0000 --bcaec520e8171dc15204aded5784 Content-Type: text/plain; charset=ISO-8859-1 > > > I am confused. Which phones today connect directly to a SIP to PSTN gateway > ? I'd guess none. > Almost all of them go through some registrar and/or proxy. > > We are not talking about SIP proxy here. We are talking about media proxy. These have a tendency to consume wast quantities of CPU and bandwidth, since they need to resend every media packet. There is no doubt that we need a proxy for signaling but it will not require as much resources. > No, HTTP today does not let me probe the innards of your network ( inside > your firewall) just by sending > a legal but evil payload. If you permit webRTC without ICE, then the > browser can be told to fake up UDP packets > and send them to anywhere on your inner LAN. DOS-city. > > Tim. > How real or big do you think this problem is going to be? None of the current SIP/VoIP clients address this now, and we have quite a number of them out there. I understand that this is an attack vector but how big of an attack vector is this going to be if we ask for user confirmation? _____________ Roman Shpount --bcaec520e8171dc15204aded5784 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I am confused. Which phones today connect= directly to a SIP to PSTN gateway ? I'd guess none.=A0
Almost all of them go through some registrar and/or proxy. =A0

We are not talking about SIP proxy here= . We are talking about media proxy. These have a tendency to consume wast q= uantities of CPU and bandwidth, since they need to resend every media packe= t. There is no doubt that we need a proxy for signaling but it will not req= uire as much resources.

=A0
No, HTTP today does not let me = probe the innards of your network ( inside your firewall) just by sending= =A0
a legal but evil payload. If you permit webRTC without ICE, then the b= rowser can be told to fake up UDP packets
and send them to anywhe= re on your inner LAN. DOS-city.

Tim.=A0

How real or big do you thin= k this problem is going to be? None of the current SIP/VoIP clients address= this now, and we have quite a number of them out there. I understand that = this is an attack vector but how big of an attack vector is this going to b= e if we ask for user confirmation?
_____________
Roman Shpount
--bcaec520e8171dc15204aded5784-- From roman@telurix.com Tue Sep 27 07:46: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 531E021F8D39 for ; Tue, 27 Sep 2011 07:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.327, 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 CLKKl1k9Tas8 for ; Tue, 27 Sep 2011 07:46:44 -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 879E321F8D23 for ; Tue, 27 Sep 2011 07:46:44 -0700 (PDT) Received: by vws5 with SMTP id 5so8250860vws.31 for ; Tue, 27 Sep 2011 07:49:30 -0700 (PDT) Received: by 10.52.97.227 with SMTP id ed3mr7685893vdb.499.1317134969959; Tue, 27 Sep 2011 07:49:29 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by mx.google.com with ESMTPS id l4sm20456906vdv.4.2011.09.27.07.49.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 07:49:29 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so5323225vcb.31 for ; Tue, 27 Sep 2011 07:49:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.4.170 with SMTP id l10mr37201558pbl.3.1317134968260; Tue, 27 Sep 2011 07:49:28 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 27 Sep 2011 07:49:28 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> Date: Tue, 27 Sep 2011 10:49:28 -0400 Message-ID: From: Roman Shpount To: Bernard Aboba Content-Type: multipart/alternative; boundary=bcaec5215f35e7878404aded6102 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 14:46:45 -0000 --bcaec5215f35e7878404aded6102 Content-Type: text/plain; charset=ISO-8859-1 Sorry, correcting myself, there are over 5 billion mobile phones worldwide. Are you sure we don't need to talk to them. _____________ Roman Shpount On Tue, Sep 27, 2011 at 10:40 AM, Roman Shpount wrote: > Bernard, > > What about 500M Skype users? Skype for SIP does not support SRTP or > ICE.What about 2 billion wireless subscribers? Despite what you think number > of phones and phone numbers is growing, and a wast majority of these phones > are dumb wireless phones. > _____________ > Roman Shpount > > > On Mon, Sep 26, 2011 at 11:44 PM, Bernard Aboba > wrote: > >> >> > And "interoperability with SIP-PSTN providers" is only relevant if you >> > are trying to turn the browser into another phone. We have enough >> > phones. What we don't have are new real-time communication experiences >> > that can only be created within this environment. >> >> [BA] I think you may be on to something here. POTS lines are dropping so >> rapidly >> that wireline service won't even exist in some countries within a few >> years. While >> PSTN interop may have been a key scenario in the early days of SIP, I have >> serious >> doubts as to how much attention we should pay to this in RTCWEB. Ability >> to >> make a call to an E.164 number? Probably. Support for every potential >> corner >> case? Not necessarily. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > --bcaec5215f35e7878404aded6102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry, correcting myself, there are over 5 billion mobile phones worldwide.= Are you sure we don't need to talk to them.
________= _____
Roman Shpount


On Tue, Sep 27, 2011 at 10:40 AM, Roman = Shpount <roman@te= lurix.com> wrote:
Bernard,

What about 500M Skype users? Skype for SIP does not support= SRTP or ICE.What about 2 billion wireless subscribers? Despite what you th= ink number of phones and phone numbers is growing, and a wast majority of t= hese phones are dumb wireless phones.
_____________
Roman Shpount


On Mon, Sep 26, 2011 at 11:44 PM, Bernar= d Aboba <bernard_aboba@hotmail.com> wrote:

> And "interoperability with SIP-PSTN providers"= is only relevant if you
> are trying to turn the browser into anothe= r phone. We have enough
> phones. What we don't have are new real= -time communication experiences
> that can only be created within this environment.

[BA] I = think you may be on to something here.=A0 POTS lines are dropping so rapidl= y
that wireline service won't even exist in some countries within a = few years.=A0 While
PSTN interop may have been a key scenario in the early days of SIP, I have = serious
doubts as to how much attention we should pay to this in RTCWEB.= =A0 Ability to
make a call to an E.164 number?=A0 Probably.=A0 Support f= or every potential corner
case?=A0 Not necessarily.

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



--bcaec5215f35e7878404aded6102-- From juberti@google.com Tue Sep 27 07:57: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 2E8CA21F8E0E for ; Tue, 27 Sep 2011 07:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.565 X-Spam-Level: X-Spam-Status: No, score=-105.565 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HY1mMkKjvVcA for ; Tue, 27 Sep 2011 07:57:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4A821F8E08 for ; Tue, 27 Sep 2011 07:57:57 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p8RF0fFJ005172 for ; Tue, 27 Sep 2011 08:00:42 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317135642; bh=fCY9eLrtmqPq17BlJKYqXOFXyOI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=iL/J+68Xb7nZ1rSiqVuPhjCb/IX/AT8ptIi+eqAiCnKKnSTGbL+0AbTtBMCUgcwU9 hS1qvgxIhi8woJqiwEBCA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=XbjiXkroDVaJDworvMdVqM6ffkv1OwhtcFaMLfM0Xcw8YIxE/V0S257K/QPahi0Ww MfjBUYB6jATesq7b/d//w== Received: from qyl38 (qyl38.prod.google.com [10.241.83.230]) by wpaz5.hot.corp.google.com with ESMTP id p8RExrpA015110 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 27 Sep 2011 08:00:40 -0700 Received: by qyl38 with SMTP id 38so1215851qyl.14 for ; Tue, 27 Sep 2011 08:00:40 -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; bh=zNxlKGevWvNRzxMj6m/LLBdW4b8FTd5SNHCQPma0gck=; b=S7WmtKjXmETo3G/Dfj/N0Y/+dRE18OR1fD8R8NUmoHXWBXPrFq+x6fIDRmtezbBsbc yM416MCO9mIDWlaLlfGw== Received: by 10.224.211.3 with SMTP id gm3mr5973428qab.111.1317135640228; Tue, 27 Sep 2011 08:00:40 -0700 (PDT) Received: by 10.224.211.3 with SMTP id gm3mr5973423qab.111.1317135640109; Tue, 27 Sep 2011 08:00:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.34.1 with HTTP; Tue, 27 Sep 2011 07:55:34 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> From: Justin Uberti Date: Tue, 27 Sep 2011 10:55:34 -0400 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=20cf30051272f3226604aded8932 X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 14:57:58 -0000 --20cf30051272f3226604aded8932 Content-Type: text/plain; charset=UTF-8 We can still talk to them via a media gateway, which robust telephony services will already provide for the reasons I mentioned previously. On Tue, Sep 27, 2011 at 10:49 AM, Roman Shpount wrote: > Sorry, correcting myself, there are over 5 billion mobile phones worldwide. > Are you sure we don't need to talk to them. > _____________ > Roman Shpount > > > > On Tue, Sep 27, 2011 at 10:40 AM, Roman Shpount wrote: > >> Bernard, >> >> What about 500M Skype users? Skype for SIP does not support SRTP or >> ICE.What about 2 billion wireless subscribers? Despite what you think number >> of phones and phone numbers is growing, and a wast majority of these phones >> are dumb wireless phones. >> _____________ >> Roman Shpount >> >> >> On Mon, Sep 26, 2011 at 11:44 PM, Bernard Aboba < >> bernard_aboba@hotmail.com> wrote: >> >>> >>> > And "interoperability with SIP-PSTN providers" is only relevant if you >>> > are trying to turn the browser into another phone. We have enough >>> > phones. What we don't have are new real-time communication experiences >>> > that can only be created within this environment. >>> >>> [BA] I think you may be on to something here. POTS lines are dropping so >>> rapidly >>> that wireline service won't even exist in some countries within a few >>> years. While >>> PSTN interop may have been a key scenario in the early days of SIP, I >>> have serious >>> doubts as to how much attention we should pay to this in RTCWEB. Ability >>> to >>> make a call to an E.164 number? Probably. Support for every potential >>> corner >>> case? Not necessarily. >>> >>> _______________________________________________ >>> 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 > > --20cf30051272f3226604aded8932 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We can still talk to them via a media gateway, which robust telephony servi= ces will already provide for the reasons I mentioned previously.

On Tue, Sep 27, 2011 at 10:49 AM, Roman Shpount <roman@telurix.com<= /a>> wrote:
Sorry, correcting myself, there are over 5 = billion mobile phones worldwide. Are you sure we don't need to talk to = them.
_____________
Roman Shpou= nt



On Tue, Sep 27, 2011 at 10:40 AM, Roman = Shpount <roman@telurix.com> wrote:
Bernard,

What about 500M Skype users? Skype for SIP does not support= SRTP or ICE.What about 2 billion wireless subscribers? Despite what you th= ink number of phones and phone numbers is growing, and a wast majority of t= hese phones are dumb wireless phones.
_____________
Roman Shpount


On Mon, Sep 26, 2011 at 11:44 PM, Bernar= d Aboba <bernard_aboba@hotmail.com> wrote:

> And "interoperability with SIP-PSTN providers"= is only relevant if you
> are trying to turn the browser into anothe= r phone. We have enough
> phones. What we don't have are new real= -time communication experiences
> that can only be created within this environment.

[BA] I = think you may be on to something here.=C2=A0 POTS lines are dropping so rap= idly
that wireline service won't even exist in some countries within= a few years.=C2=A0 While
PSTN interop may have been a key scenario in the early days of SIP, I have = serious
doubts as to how much attention we should pay to this in RTCWEB.= =C2=A0 Ability to
make a call to an E.164 number?=C2=A0 Probably.=C2=A0 = Support for every potential corner
case?=C2=A0 Not necessarily.

_______________________________________________
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


--20cf30051272f3226604aded8932-- From roman@telurix.com Tue Sep 27 08:03: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 58BF921F8E3D for ; Tue, 27 Sep 2011 08:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zlrji05rlGVE for ; Tue, 27 Sep 2011 08:03:43 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8382F21F8DF8 for ; Tue, 27 Sep 2011 08:03:43 -0700 (PDT) Received: by yxt33 with SMTP id 33so6738569yxt.31 for ; Tue, 27 Sep 2011 08:06:28 -0700 (PDT) Received: by 10.236.157.229 with SMTP id o65mr7566830yhk.73.1317135988666; Tue, 27 Sep 2011 08:06:28 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id z15sm34030807yhg.21.2011.09.27.08.06.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 08:06:26 -0700 (PDT) Received: by ywa6 with SMTP id 6so6753159ywa.31 for ; Tue, 27 Sep 2011 08:06:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.22.105 with SMTP id c9mr37131799pbf.88.1317135986166; Tue, 27 Sep 2011 08:06:26 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 27 Sep 2011 08:06:26 -0700 (PDT) In-Reply-To: <4E8185FC.8000906@alvestrand.no> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E8185FC.8000906@alvestrand.no> Date: Tue, 27 Sep 2011 11:06:26 -0400 Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=bcaec52154c5938e4504aded9edc Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 15:03:44 -0000 --bcaec52154c5938e4504aded9edc Content-Type: text/plain; charset=ISO-8859-1 Let's see: 4.1.4. Choosing Default Candidates A candidate is said to be default if it would be the target of media from a non-ICE peer; that target is called the DEFAULT DESTINATION. If the default candidates are not selected by the ICE algorithm when communicating with an ICE-aware peer, an updated offer/answer will be required after ICE processing completes in order to "fix up" the SDP so that the default destination for media matches the candidates selected by ICE. If ICE happens to select the default candidates, no updated offer/answer is required. An agent MUST choose a set of candidates, one for each component of each in-use media stream, to be default. 5.1. Verifying ICE Support If this condition is not met, the agent MUST process the SDP based on normal RFC 3264 procedures, without using any of the ICE mechanisms described in the remainder of this specification... 6.1. Verifying ICE Support The logic at the offerer is identical to that of the answerer as described in Section 5.1, with the exception that an offerer would not ever generate a=ice-mismatch attributes in an SDP. My interpretation of this always was that ICE enabled end point MUST generate an offer that will be understood by a non-ICE end point, properly process on offer from a non-ICE enabled end point, and properly process an answer from a non-ICE end point. So if we want RTC to be ICE complaint we should be able to communicate with non-ICE end points, or define a new specification. _____________ Roman Shpount On Tue, Sep 27, 2011 at 4:14 AM, Harald Alvestrand wrote: > On 09/26/11 20:48, Roman Shpount wrote: > >> You can determine that end point is not behind symmetric NAT using older >> STUN specification and list discovered IP as a default contact address in >> SDP, if you are not behind NAT, you can list the relayed address of the TURN >> server as the default address. If you do this, together with the offer that >> lists ICE candidates, you would be able to traverse NAT and communicate with >> non-ICE end points. >> >> I think discussion in this thread is not whether ICE needs to be supported >> or implemented. I would say that ICE without a doubt should be supported. It >> is about changing ICE specification as it stands right now, and force the >> RTC end point only to communicate with end points that respond with ICE >> compliant answer and complete ICE hand shake. This is actually against the >> ICE specification as it is defined in RFC 5245, where answerer actually can >> refuse to support ICE but still establish a call. >> > Roman, > > Which part of RFC 5245 are you referring to with this statement? > > Please describe the sections you think will be invoked when an SDP OFFER > contains ICE candidates, the answerer does not want to use ICE, what the > OFFER and ANSWER would look like, and which section of RFC 5245 is invoked > when processing the ANSWER. > > Details are good. > > Harald > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --bcaec52154c5938e4504aded9edc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Let's see:

4.1.4. Choosing Default Candidates

A candid= ate is said to be default if it would be the target of media
from a n= on-ICE peer; that target is called the DEFAULT DESTINATION.
If the de= fault candidates are not selected by the ICE algorithm when
communicating with an ICE-aware peer, an updated offer/answer will be required after ICE processing completes in order to "fix up" = the SDP
so that the default destination for media matches the candida= tes
selected by ICE. If ICE happens to select the default candidates, no updated offer/answer is required.

An agent MUST choose a set = of candidates, one for each component of
each in-use media stream, to= be default.

5.1. Verifying ICE Support

If this condition is not met, the= agent MUST process the SDP based on
normal RFC 3264 procedures, with= out using any of the ICE mechanisms
described in the remainder of thi= s specification...

6.1. Verifying ICE Support

The logic at the offerer is identica= l to that of the answerer as described in Section 5.1, with the exception t= hat an offerer would not ever generate a=3Dice-mismatch attributes in an SD= P.

My interpretation of this always was that ICE enabled end point MUST ge= nerate an offer that will be understood by a non-ICE end point, properly pr= ocess on offer from a non-ICE enabled end point, and properly process an an= swer from a non-ICE end point. So if we want RTC to be ICE complaint we sho= uld be able to communicate with non-ICE end points, or define a new specifi= cation.
_____________
Roman Shpount


On Tue, Sep 27, 2011 at 4:14 AM, Harald = Alvestrand <ha= rald@alvestrand.no> wrote:
On 09/26/11 20:48, Roman Shpount wrote:
You can determine that end point is not behind symmetric NAT using older ST= UN specification and list discovered IP as a default contact address in SDP= , if you are not behind NAT, you can list the relayed address of the TURN s= erver as the default address. If you do this, together with the offer that = lists ICE candidates, you would be able to traverse NAT and communicate wit= h non-ICE end points.

I think discussion in this thread is not whether ICE needs to be supported = or implemented. I would say that ICE without a doubt should be supported. I= t is about changing ICE specification as it stands right now, and force the= RTC end point only to communicate with end points that respond with ICE co= mpliant answer and complete ICE hand shake. This is actually against the IC= E specification as it is defined in RFC 5245, where answerer actually can r= efuse to support ICE but still establish a call.
Roman,

Which part of RFC 5245 are you referring to with this statement?

Please describe the sections you think will be invoked when an SDP OFFER co= ntains ICE candidates, the answerer does not want to use ICE, what the OFFE= R and ANSWER would look like, and which section of RFC 5245 is invoked when= processing the ANSWER.

Details are good.

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

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

--bcaec52154c5938e4504aded9edc-- From roman@telurix.com Tue Sep 27 08:09: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 1379221F8DBA for ; Tue, 27 Sep 2011 08:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[AWL=-0.648, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 xGXfWBlFALoL for ; Tue, 27 Sep 2011 08:09:41 -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 59AC421F8DAD for ; Tue, 27 Sep 2011 08:09:35 -0700 (PDT) Received: by gyd12 with SMTP id 12so6590092gyd.31 for ; Tue, 27 Sep 2011 08:12:21 -0700 (PDT) Received: by 10.68.55.73 with SMTP id q9mr770536pbp.92.1317136340521; Tue, 27 Sep 2011 08:12:20 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by mx.google.com with ESMTPS id i2sm85383630pbt.3.2011.09.27.08.12.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 08:12:19 -0700 (PDT) Received: by pzk37 with SMTP id 37so18761701pzk.9 for ; Tue, 27 Sep 2011 08:12:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.33.130 with SMTP id r2mr37321145pbi.71.1317136338437; Tue, 27 Sep 2011 08:12:18 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 27 Sep 2011 08:12:18 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> Date: Tue, 27 Sep 2011 11:12:18 -0400 Message-ID: From: Roman Shpount To: Justin Uberti Content-Type: multipart/alternative; boundary=bcaec520f61192c48a04adedb303 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 15:09:42 -0000 --bcaec520f61192c48a04adedb303 Content-Type: text/plain; charset=ISO-8859-1 I am sorry, but can you name "robust telephony services" that currently provide ICE and SRTP support in US? AFAK Verizon, Qwest, Level3, Global Crossing, Paetec, XO do not provide this. _____________ Roman Shpount On Tue, Sep 27, 2011 at 10:55 AM, Justin Uberti wrote: > We can still talk to them via a media gateway, which robust telephony > services will already provide for the reasons I mentioned previously. > > On Tue, Sep 27, 2011 at 10:49 AM, Roman Shpount wrote: > >> Sorry, correcting myself, there are over 5 billion mobile phones >> worldwide. Are you sure we don't need to talk to them. >> _____________ >> Roman Shpount >> >> >> >> On Tue, Sep 27, 2011 at 10:40 AM, Roman Shpount wrote: >> >>> Bernard, >>> >>> What about 500M Skype users? Skype for SIP does not support SRTP or >>> ICE.What about 2 billion wireless subscribers? Despite what you think number >>> of phones and phone numbers is growing, and a wast majority of these phones >>> are dumb wireless phones. >>> _____________ >>> Roman Shpount >>> >>> >>> On Mon, Sep 26, 2011 at 11:44 PM, Bernard Aboba < >>> bernard_aboba@hotmail.com> wrote: >>> >>>> >>>> > And "interoperability with SIP-PSTN providers" is only relevant if you >>>> > are trying to turn the browser into another phone. We have enough >>>> > phones. What we don't have are new real-time communication experiences >>>> > that can only be created within this environment. >>>> >>>> [BA] I think you may be on to something here. POTS lines are dropping >>>> so rapidly >>>> that wireline service won't even exist in some countries within a few >>>> years. While >>>> PSTN interop may have been a key scenario in the early days of SIP, I >>>> have serious >>>> doubts as to how much attention we should pay to this in RTCWEB. >>>> Ability to >>>> make a call to an E.164 number? Probably. Support for every potential >>>> corner >>>> case? Not necessarily. >>>> >>>> _______________________________________________ >>>> 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 >> >> > --bcaec520f61192c48a04adedb303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am sorry, but can you name "robust telephony services" that cur= rently provide ICE and SRTP support in US? AFAK Verizon, Qwest, Level3, Glo= bal Crossing, Paetec, XO do not provide this.
____________= _
Roman Shpount


On Tue, Sep 27, 2011 at 10:55 AM, Justin= Uberti <juberti= @google.com> wrote:
We can still talk to them via a media gateway, which robust telephony servi= ces will already provide for the reasons I mentioned previously.
<= /div>

On Tue, Sep 27, = 2011 at 10:49 AM, Roman Shpount <roman@telurix.com> wrote:
Sorry, correcting myself, there are over 5 b= illion mobile phones worldwide. Are you sure we don't need to talk to t= hem.
_____________
Roman Shpount<= div>



On Tue, Sep 27, 2011 at 10:40 AM, Roman = Shpount <roman@telurix.com> wrote:
Bernard,

What about 500M Skype users? Skype for SIP does not support= SRTP or ICE.What about 2 billion wireless subscribers? Despite what you th= ink number of phones and phone numbers is growing, and a wast majority of t= hese phones are dumb wireless phones.
_____________
Roman Shpount


On Mon, Sep 26, 2011 at 11:44 PM, Bernar= d Aboba <bernard_aboba@hotmail.com> wrote:

> And "interoperability with SIP-PSTN providers"= is only relevant if you
> are trying to turn the browser into anothe= r phone. We have enough
> phones. What we don't have are new real= -time communication experiences
> that can only be created within this environment.

[BA] I = think you may be on to something here.=A0 POTS lines are dropping so rapidl= y
that wireline service won't even exist in some countries within a = few years.=A0 While
PSTN interop may have been a key scenario in the early days of SIP, I have = serious
doubts as to how much attention we should pay to this in RTCWEB.= =A0 Ability to
make a call to an E.164 number?=A0 Probably.=A0 Support f= or every potential corner
case?=A0 Not necessarily.

_______________________________________________
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



--bcaec520f61192c48a04adedb303-- From matthew.kaufman@skype.net Tue Sep 27 08:14: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 6B90821F8DB6 for ; Tue, 27 Sep 2011 08:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.413 X-Spam-Level: X-Spam-Status: No, score=-5.413 tagged_above=-999 required=5 tests=[AWL=1.186, 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 vitqERX3ycUt for ; Tue, 27 Sep 2011 08:14:17 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id A8BD621F8C6E for ; Tue, 27 Sep 2011 08:14:17 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 5D1B316F7; Tue, 27 Sep 2011 17:17:02 +0200 (CEST) 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=wbxpSav+Xj5bh4 wgyYWCXsQ3VLc=; b=WseKctSl0/ELm5PO1jU6YqZoxf4Ms/VCSiRVRHz60cIuRW MdNNDsGN3FjbAQoTEtqsqqUPDfqlsGl6PbPlXlmU8YW9TEVpwF2AmRSd6Q8G8AHV 2ug9ai+XFpIO4j/OSZAtkyMOc6EoZA1AbvxxMlSnn8wDEUicRyZHDics0xK94= 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=Q+VLiQ0fLMB34MxA50oCi+ CvOCbuhWFrquS6/BDgJT4C9lkewuXXyh6mDlzXKyED+WGqzE45MBftFCLaweJanP mk4bBQBs0pNaNEUVEOXJEfkhQy6PhItO10pPDwcoP5nCFQutd1YzfmnUsvAPAEUp u8x/Vsqlg4ZkUYpqBVWgA= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 5B08E7F8; Tue, 27 Sep 2011 17:17:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 3506D1672682; Tue, 27 Sep 2011 17:17:02 +0200 (CEST) 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 pPm0OCNQvIQE; Tue, 27 Sep 2011 17:17:01 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id B8D361672683; Tue, 27 Sep 2011 17:17:00 +0200 (CEST) Message-ID: <4E81E8AB.2080404@skype.net> Date: Tue, 27 Sep 2011 08:15:55 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Roman Shpount References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 15:14:18 -0000 On 9/27/2011 7:46 AM, Roman Shpount wrote: > > How real or big do you think this problem is going to be? None of the > current SIP/VoIP clients address this now, and we have quite a number > of them out there. I understand that this is an attack vector but how > big of an attack vector is this going to be if we ask for user > confirmation? > There is no plan to ask for user confirmation to open a connection, receive media, or send and receive data. The only user confirmation that is expected would be for camera and/or microphone access. I've seen a dozen messages from you arguing that the requirement for a STUN connectivity check is a barrier and should be removed, but I have not yet seen an alternative proposal that meets the requirements of browser authors with regard to preventing attacks on behind-firewall infrastructure from the browser platform. Matthew Kaufman From christer.holmberg@ericsson.com Tue Sep 27 08:18: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 55F9A21F8B13 for ; Tue, 27 Sep 2011 08:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.698 X-Spam-Level: X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBbeWuQTSztV for ; Tue, 27 Sep 2011 08:18:04 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id DC61021F8DEE for ; Tue, 27 Sep 2011 08:18:03 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a8-4e81e9d00313 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4C.A5.20773.0D9E18E4; Tue, 27 Sep 2011 17:20:48 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 27 Sep 2011 17:20:38 +0200 From: Christer Holmberg To: Roman Shpount , Harald Alvestrand Date: Tue, 27 Sep 2011 17:20:37 +0200 Thread-Topic: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE for RTC calls) Thread-Index: Acx9Jwt3HG9q88SrSzKIKQVNnduBbwAATJ/A Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233FFBC40@ESESSCMS0356.eemea.ericsson.se> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E8185FC.8000906@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852233FFBC40ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 15:18:05 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852233FFBC40ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I don't think the question is about changing the ICE spec. You are correct in that ICE as such allows establishment of sessions with n= on-ICE peers, but I don't think anyone is questioning that. The question is whether we shall specify that the browser must use "Require= :ICE" (speaking in SIP terms :), in order to fulful some security requireme= nt. So, in my opinion we shall focus on the requirement, and whether we need to= mandate the usage of some mechanism (ICE or something else) in order to so= lve that requirement. ...or whether the requirement should be dropped or relaxed. Regards, Christer ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= Roman Shpount Sent: 27. syyskuuta 2011 18:06 To: Harald Alvestrand Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE for RTC ca= lls) Let's see: 4.1.4. Choosing Default Candidates A candidate is said to be default if it would be the target of media from a non-ICE peer; that target is called the DEFAULT DESTINATION. If the default candidates are not selected by the ICE algorithm when communicating with an ICE-aware peer, an updated offer/answer will be required after ICE processing completes in order to "fix up" the SDP so that the default destination for media matches the candidates selected by ICE. If ICE happens to select the default candidates, no updated offer/answer is required. An agent MUST choose a set of candidates, one for each component of each in-use media stream, to be default. 5.1. Verifying ICE Support If this condition is not met, the agent MUST process the SDP based on normal RFC 3264 procedures, without using any of the ICE mechanisms described in the remainder of this specification... 6.1. Verifying ICE Support The logic at the offerer is identical to that of the answerer as described = in Section 5.1, with the exception that an offerer would not ever generate = a=3Dice-mismatch attributes in an SDP. My interpretation of this always was that ICE enabled end point MUST genera= te an offer that will be understood by a non-ICE end point, properly proces= s on offer from a non-ICE enabled end point, and properly process an answer= from a non-ICE end point. So if we want RTC to be ICE complaint we should = be able to communicate with non-ICE end points, or define a new specificati= on. _____________ Roman Shpount On Tue, Sep 27, 2011 at 4:14 AM, Harald Alvestrand > wrote: On 09/26/11 20:48, Roman Shpount wrote: You can determine that end point is not behind symmetric NAT using older ST= UN specification and list discovered IP as a default contact address in SDP= , if you are not behind NAT, you can list the relayed address of the TURN s= erver as the default address. If you do this, together with the offer that = lists ICE candidates, you would be able to traverse NAT and communicate wit= h non-ICE end points. I think discussion in this thread is not whether ICE needs to be supported = or implemented. I would say that ICE without a doubt should be supported. I= t is about changing ICE specification as it stands right now, and force the= RTC end point only to communicate with end points that respond with ICE co= mpliant answer and complete ICE hand shake. This is actually against the IC= E specification as it is defined in RFC 5245, where answerer actually can r= efuse to support ICE but still establish a call. Roman, Which part of RFC 5245 are you referring to with this statement? Please describe the sections you think will be invoked when an SDP OFFER co= ntains ICE candidates, the answerer does not want to use ICE, what the OFFE= R and ANSWER would look like, and which section of RFC 5245 is invoked when= processing the ANSWER. Details are good. Harald _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_7F2072F1E0DE894DA4B517B93C6A05852233FFBC40ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I don't think the question is about ch= anging=20 the ICE spec.
 
You are correct in that ICE as such allows=20 establishment of sessions with non-ICE peers, but I don't think anyone= is=20 questioning that.
 
The question is whether we shall specify that th= e=20 browser must use "Require:ICE" (speaking in SIP terms :), in order to fulfu= l=20 some security requirement.
 
So, in my opinion we shall focus on the requirem= ent,=20 and whether we need to mandate the usage of some mechanism (ICE or somethin= g=20 else) in order to solve that requirement.
 
...or whether the requirement should be dropped = or=20 relaxed.
 
Regards,
 
Christer
 
 
 

From: rtcweb-bounces@ietf.org=20 [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman=20 Shpount
Sent: 27. syyskuuta 2011 18:06
To: Harald=20 Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] = RFC=20 5245 interpretation (Re: Requiring ICE for RTC calls)

Let's see:

4.1.4. Choosing Default Candidates

A= =20 candidate is said to be default if it would be the target of media
fro= m a=20 non-ICE peer; that target is called the DEFAULT DESTINATION.
If the de= fault=20 candidates are not selected by the ICE algorithm when
communicating wi= th an=20 ICE-aware peer, an updated offer/answer will be
required after ICE=20 processing completes in order to "fix up" the SDP
so that the default= =20 destination for media matches the candidates
selected by ICE. If ICE=20 happens to select the default candidates, no
updated offer/answer is=20 required.

An agent MUST choose a set of candidates, one for each=20 component of
each in-use media stream, to be default.

5.1. Veri= fying=20 ICE Support

If this condition is not met, the agent MUST process t= he=20 SDP based on
normal RFC 3264 procedures, without using any of the ICE= =20 mechanisms
described in the remainder of this specification...

= 6.1.=20 Verifying ICE Support

The logic at the offerer is identical to tha= t of=20 the answerer as described in Section 5.1, with the exception that an offe= rer=20 would not ever generate a=3Dice-mismatch attributes in an SDP.

My= =20 interpretation of this always was that ICE enabled end point MUST generat= e an=20 offer that will be understood by a non-ICE end point, properly process on= =20 offer from a non-ICE enabled end point, and properly process an answer fr= om a=20 non-ICE end point. So if we want RTC to be ICE complaint we should be abl= e to=20 communicate with non-ICE end points, or define a new=20 specification.
_____________
Roman Shpount


On Tue, Sep 27, 2011 at 4:14 AM, Harald Alvestra= nd=20 <harald@alvestrand.no>= =20 wrote:
On=20 09/26/11 20:48, Roman Shpount wrote:
You=20 can determine that end point is not behind symmetric NAT using older = STUN=20 specification and list discovered IP as a default contact address in = SDP,=20 if you are not behind NAT, you can list the relayed address of the TU= RN=20 server as the default address. If you do this, together with the offe= r=20 that lists ICE candidates, you would be able to traverse NAT and=20 communicate with non-ICE end points.

I think discussion in thi= s=20 thread is not whether ICE needs to be supported or implemented. I wou= ld=20 say that ICE without a doubt should be supported. It is about changin= g ICE=20 specification as it stands right now, and force the RTC end point onl= y to=20 communicate with end points that respond with ICE compliant answer an= d=20 complete ICE hand shake. This is actually against the ICE specificati= on as=20 it is defined in RFC 5245, where answerer actually can refuse to supp= ort=20 ICE but still establish a call.
Roman,

Which p= art of=20 RFC 5245 are you referring to with this statement?

Please descri= be=20 the sections you think will be invoked when an SDP OFFER contains ICE=20 candidates, the answerer does not want to use ICE, what the OFFER and A= NSWER=20 would look like, and which section of RFC 5245 is invoked when processi= ng=20 the ANSWER.

Details are good.

       = =20      =20  Harald

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

--_000_7F2072F1E0DE894DA4B517B93C6A05852233FFBC40ESESSCMS0356e_-- From bernard_aboba@hotmail.com Tue Sep 27 08:21: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 50F5C21F8E62 for ; Tue, 27 Sep 2011 08:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.329 X-Spam-Level: X-Spam-Status: No, score=-102.329 tagged_above=-999 required=5 tests=[AWL=0.269, 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 Pz3phXbm+akq for ; Tue, 27 Sep 2011 08:21:05 -0700 (PDT) Received: from blu0-omc1-s1.blu0.hotmail.com (blu0-omc1-s1.blu0.hotmail.com [65.55.116.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8F01221F8E4D for ; Tue, 27 Sep 2011 08:21:04 -0700 (PDT) Received: from BLU152-W29 ([65.55.116.9]) by blu0-omc1-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Sep 2011 08:23:27 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_6dfc72bf-3002-45b1-989e-14e51028f8ac_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: , Date: Tue, 27 Sep 2011 08:23:26 -0700 Importance: Normal In-Reply-To: References: , , , <4E80984A.903@skype.net>, , <4E809EE6.2050702@skype.net>, <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com>, , , , , MIME-Version: 1.0 X-OriginalArrivalTime: 27 Sep 2011 15:23:27.0848 (UTC) FILETIME=[67FA2680:01CC7D29] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 15:21:06 -0000 --_6dfc72bf-3002-45b1-989e-14e51028f8ac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm not going to use this mailing list as an advertising medium=2C but ther= e do exist products that support both ICE and SRTP=2C and some of the compa= nies you name below have deployed those products to *thousands* of their em= ployees.=20 Date: Tue=2C 27 Sep 2011 11:12:18 -0400 Subject: Re: [rtcweb] Requiring ICE for RTC calls From: roman@telurix.com To: juberti@google.com CC: bernard_aboba@hotmail.com=3B rtcweb@ietf.org I am sorry=2C but can you name "robust telephony services" that currently p= rovide ICE and SRTP support in US? AFAK Verizon=2C Qwest=2C Level3=2C Globa= l Crossing=2C Paetec=2C XO do not provide this._____________ Roman Shpount = --_6dfc72bf-3002-45b1-989e-14e51028f8ac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm not going to use this mailing list as an advertising medium=2C but ther= e do exist products that support both ICE and SRTP=2C and some of the compa= nies you name below have deployed those products to *thousands* of their em= ployees.

Date: Tue=2C 27 Sep 2011 11:1= 2:18 -0400
Subject: Re: [rtcweb] Requiring ICE for RTC calls
From: ro= man@telurix.com
To: juberti@google.com
CC: bernard_aboba@hotmail.com= =3B rtcweb@ietf.org

I am sorry=2C but can you name "robust telephony= services" that currently provide ICE and SRTP support in US? AFAK Verizon= =2C Qwest=2C Level3=2C Global Crossing=2C Paetec=2C XO do not provide this.=
_____________
Roman Shpount


= --_6dfc72bf-3002-45b1-989e-14e51028f8ac_-- From tim@phonefromhere.com Tue Sep 27 08:22: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 3BB7B21F85F1 for ; Tue, 27 Sep 2011 08:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CB20FH6Fq9Cw for ; Tue, 27 Sep 2011 08:22:02 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 9C05A21F8538 for ; Tue, 27 Sep 2011 08:21:50 -0700 (PDT) Received: from [192.168.0.106] (udp089063uds.ucsf.edu [169.230.111.60]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 0977637A902; Tue, 27 Sep 2011 16:37:23 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: Date: Tue, 27 Sep 2011 08:24:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <84254826-C357-4FB5-810D-C453A2D1304C@phonefromhere.com> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> To: Roman Shpount X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 15:22:04 -0000 On 27 Sep 2011, at 07:49, Roman Shpount wrote: > Sorry, correcting myself, there are over 5 billion mobile phones = worldwide. Are you sure we don't need to talk to them.=20 > _____________ > Roman Shpount Not a _single_one_ of those mobile phones is running SIP/RTP or supports = G.711 - if you follow that argument, we should be requiring GSM610 support and deriving a version of the GSM = media protocol. Tim.= From tim@phonefromhere.com Tue Sep 27 08:25: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 5714821F8D5C for ; Tue, 27 Sep 2011 08:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 m3NEfcz-uKtU for ; Tue, 27 Sep 2011 08:25:02 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED9F21F8D83 for ; Tue, 27 Sep 2011 08:25:02 -0700 (PDT) Received: from [192.168.0.106] (udp089063uds.ucsf.edu [169.230.111.60]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 5A72037A902; Tue, 27 Sep 2011 16:40:41 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_104D4D70-81A2-4CCD-BB7E-394C6B430942" From: Tim Panton In-Reply-To: Date: Tue, 27 Sep 2011 08:27:48 -0700 Message-Id: <92A2BA22-46D6-441E-BD5B-2387A025F37A@phonefromhere.com> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> To: Roman Shpount X-Mailer: Apple Mail (2.1244.3) Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 15:25:03 -0000 --Apple-Mail=_104D4D70-81A2-4CCD-BB7E-394C6B430942 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 27 Sep 2011, at 07:46, Roman Shpount wrote: >=20 > How real or big do you think this problem is going to be? None of the = current SIP/VoIP clients address this now, and we have quite a number of = them out there. I understand that this is an attack vector but how big = of an attack vector is this going to be if we ask for user confirmation?=20= > _____________ > Roman Shpount It actually doesn't matter what I think. We have to do something here = that the browser makers are prepared to deploy. What question would you = ask the user that would satisfy them? Tim.= --Apple-Mail=_104D4D70-81A2-4CCD-BB7E-394C6B430942 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On 27 Sep 2011, at 07:46, Roman Shpount wrote:

How real or big do you think this problem is going to be? None of the current SIP/VoIP clients address this now, and we have quite a number of them out there. I understand that this is an attack vector but how big of an attack vector is this going to be if we ask for user confirmation?
_____________
Roman Shpount

It actually doesn't matter what I think. We have to do something here that the browser makers are prepared to deploy. What question would you ask the user that would satisfy them?

Tim.
--Apple-Mail=_104D4D70-81A2-4CCD-BB7E-394C6B430942-- From dzonatas@gmail.com Tue Sep 27 08:32: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 E6CC721F8E42 for ; Tue, 27 Sep 2011 08:32:47 -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=-1.188, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 FzU+slj473X9 for ; Tue, 27 Sep 2011 08:32: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 6E64221F8E3F for ; Tue, 27 Sep 2011 08:32:47 -0700 (PDT) Received: by gyd12 with SMTP id 12so6618280gyd.31 for ; Tue, 27 Sep 2011 08:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=mqrBy9JJHByAsp1Y/zjLZlZr/yWL7WLsu5E0N1cTQCo=; b=B1SFS/gDefkMM/vQ0V4AM9thsuNis+AJYzQWxxNArwlH7RbzijADNdc0Zcscox4FT6 0FA9w13I1d6xY+BOsHSYsHXP1efltvBGIdsEtqp4+z/glvnNdAZbtcQW0Ke0PunGTJoA tmvJbcdGJ2eeUjuRWvHMqxzzubPcYbnwsnN3w= Received: by 10.236.192.231 with SMTP id i67mr48440460yhn.87.1317137730012; Tue, 27 Sep 2011 08:35:30 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id p68sm34147484yhj.16.2011.09.27.08.35.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 08:35:29 -0700 (PDT) Message-ID: <4E81EDCF.6040406@gmail.com> Date: Tue, 27 Sep 2011 08:37:51 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: , , , <4E80984A.903@skype.net>, , <4E809EE6.2050702@skype.net>, <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com>, , , , , In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 15:32:48 -0000 Maybe if we narrow down that selection to those that can update car drivers to those that have met standards (and maybe ahhh "Class E" licensed software upload). On 09/27/2011 08:23 AM, Bernard Aboba wrote: > I'm not going to use this mailing list as an advertising medium, but > there do exist products that support both ICE and SRTP, and some of > the companies you name below have deployed those products to > *thousands* of their employees. > > ------------------------------------------------------------------------ > Date: Tue, 27 Sep 2011 11:12:18 -0400 > Subject: Re: [rtcweb] Requiring ICE for RTC calls > From: roman@telurix.com > To: juberti@google.com > CC: bernard_aboba@hotmail.com; rtcweb@ietf.org > > I am sorry, but can you name "robust telephony services" that > currently provide ICE and SRTP support in US? AFAK Verizon, Qwest, > Level3, Global Crossing, Paetec, XO do not provide this. > _____________ > Roman Shpount > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- --- The wheel. From roman@telurix.com Tue Sep 27 08:49: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 90A5F21F8DC8 for ; Tue, 27 Sep 2011 08:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=0.352, 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 QosTwmxpVjTm for ; Tue, 27 Sep 2011 08:49:21 -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 05EDA21F8DBF for ; Tue, 27 Sep 2011 08:49:20 -0700 (PDT) Received: by ywa6 with SMTP id 6so6814110ywa.31 for ; Tue, 27 Sep 2011 08:52:06 -0700 (PDT) Received: by 10.68.40.234 with SMTP id a10mr37707346pbl.120.1317138726495; Tue, 27 Sep 2011 08:52:06 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by mx.google.com with ESMTPS id 4sm85671393pbk.5.2011.09.27.08.52.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 08:52:05 -0700 (PDT) Received: by pzk37 with SMTP id 37so18858675pzk.9 for ; Tue, 27 Sep 2011 08:52:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.33.130 with SMTP id r2mr37545128pbi.71.1317138724210; Tue, 27 Sep 2011 08:52:04 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 27 Sep 2011 08:52:03 -0700 (PDT) In-Reply-To: <84254826-C357-4FB5-810D-C453A2D1304C@phonefromhere.com> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <84254826-C357-4FB5-810D-C453A2D1304C@phonefromhere.com> Date: Tue, 27 Sep 2011 11:52:03 -0400 Message-ID: From: Roman Shpount To: Tim Panton Content-Type: multipart/alternative; boundary=bcaec520f611c6c6cc04adee415e Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 15:49:21 -0000 --bcaec520f611c6c6cc04adee415e Content-Type: text/plain; charset=ISO-8859-1 > Not a _single_one_ of those mobile phones is running SIP/RTP or supports > G.711 - if you follow that argument, > we should be requiring GSM610 support and deriving a version of the GSM > media protocol. > > Tim. It does not matter what they run. Quite a few of them do not run GSM, but I can cost effectively call every one of them using SIP/G.711, and that's what very important. It will take some amount of time to upgrade this infrastructure to support SRTP and ICE. _____________ Roman Shpount --bcaec520f611c6c6cc04adee415e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Not a _single_on= e_ of those mobile phones is running SIP/RTP or supports G.711 - if you fol= low that argument,
we should be requiring GSM610 support and deriving a version of the GSM med= ia protocol.

Tim.

It does not matter what they run. Quite a= few of them do not run GSM, but I can cost effectively call every one of t= hem using SIP/G.711, and that's what very important. It will take some = amount of time to upgrade this infrastructure to support SRTP and ICE.
_____________
Roman Shpount

--bcaec520f611c6c6cc04adee415e-- From bernard_aboba@hotmail.com Tue Sep 27 09:00: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 342C021F8BE9 for ; Tue, 27 Sep 2011 09:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.333 X-Spam-Level: X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=0.265, 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 yQEPbtQKBI5d for ; Tue, 27 Sep 2011 09:00:36 -0700 (PDT) Received: from blu0-omc1-s1.blu0.hotmail.com (blu0-omc1-s1.blu0.hotmail.com [65.55.116.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5FA21F8BCD for ; Tue, 27 Sep 2011 09:00:36 -0700 (PDT) Received: from BLU152-W64 ([65.55.116.8]) by blu0-omc1-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Sep 2011 09:03:22 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_aeb086f7-8616-496b-b0f1-59815d9f8ba0_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: Date: Tue, 27 Sep 2011 09:03:21 -0700 Importance: Normal In-Reply-To: References: , , , <4E80984A.903@skype.net>, , <4E809EE6.2050702@skype.net>, <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com>, , , , <84254826-C357-4FB5-810D-C453A2D1304C@phonefromhere.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 27 Sep 2011 16:03:22.0722 (UTC) FILETIME=[FB6EEC20:01CC7D2E] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 16:00:37 -0000 --_aeb086f7-8616-496b-b0f1-59815d9f8ba0_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roman Shpount said: "It does not matter what they run. Quite a few of them do not run GSM=2C bu= t I can cost effectively call every one of them using SIP/G.711=2C and that= 's what very important. It will take some amount of time to upgrade this in= frastructure to support SRTP and ICE." [BA] Why would it be necessary to upgrade wireless carrier infrastructure? = Presumably a service that wants to make calls to E.164 numbers will instal= l a gateway that enables this. Wireless carriers wouldn't have to upgrade. = --_aeb086f7-8616-496b-b0f1-59815d9f8ba0_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Roman Shpount said:

"It does not matter what they run. Quite a = few of them do not run GSM=2C but I can cost effectively call every one of = them using SIP/G.711=2C and that's what very important. It will take some a= mount of time to upgrade this infrastructure to support SRTP and ICE."
<= br>[BA] Why would it be necessary to upgrade wireless carrier infrastructur= e? =3B Presumably a service that wants to make calls to E.164 numbers w= ill install a gateway that enables this. =3B Wireless carriers wouldn't= have to upgrade.
= --_aeb086f7-8616-496b-b0f1-59815d9f8ba0_-- From roman@telurix.com Tue Sep 27 09:01: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 C878C21F8BE9 for ; Tue, 27 Sep 2011 09:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kz0wrLtxJptg for ; Tue, 27 Sep 2011 09:01:38 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C05821F8BCD for ; Tue, 27 Sep 2011 09:01:37 -0700 (PDT) Received: by wwf22 with SMTP id 22so4959027wwf.13 for ; Tue, 27 Sep 2011 09:04:23 -0700 (PDT) Received: by 10.227.112.137 with SMTP id w9mr8074289wbp.3.1317139463272; Tue, 27 Sep 2011 09:04:23 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by mx.google.com with ESMTPS id i29sm301104wbp.22.2011.09.27.09.04.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 09:04:22 -0700 (PDT) Received: by wwf22 with SMTP id 22so4958998wwf.13 for ; Tue, 27 Sep 2011 09:04:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.31.4 with SMTP id w4mr9110760pbh.20.1317139460898; Tue, 27 Sep 2011 09:04:20 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 27 Sep 2011 09:04:20 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> Date: Tue, 27 Sep 2011 12:04:20 -0400 Message-ID: From: Roman Shpount To: Bernard Aboba Content-Type: multipart/alternative; boundary=bcaec520f27dafbe6704adee6dcd Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 16:01:38 -0000 --bcaec520f27dafbe6704adee6dcd Content-Type: text/plain; charset=ISO-8859-1 What I meant is that not a single one of those companies offers either SRTP or ICE in their SIP trunking products, and that's the product you will need to interop with if you would want to connect RTC to traditional PSTN. What those companies use for their employees or residential line customers is less relevant. _____________ Roman Shpount On Tue, Sep 27, 2011 at 11:23 AM, Bernard Aboba wrote: > I'm not going to use this mailing list as an advertising medium, but there > do exist products that support both ICE and SRTP, and some of the companies > you name below have deployed those products to *thousands* of their > employees. > > ------------------------------ > Date: Tue, 27 Sep 2011 11:12:18 -0400 > Subject: Re: [rtcweb] Requiring ICE for RTC calls > From: roman@telurix.com > To: juberti@google.com > CC: bernard_aboba@hotmail.com; rtcweb@ietf.org > > > I am sorry, but can you name "robust telephony services" that currently > provide ICE and SRTP support in US? AFAK Verizon, Qwest, Level3, Global > Crossing, Paetec, XO do not provide this. > _____________ > Roman Shpount > > > --bcaec520f27dafbe6704adee6dcd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What I meant is that not a single one of those companies offers either SRTP= or ICE in their SIP trunking products, and that's the product you will= need to interop with if you would want to connect RTC to traditional PSTN.= What those companies use for their employees or residential line customers= is less relevant.
_____________
Roman Shpount


On Tue, Sep 27, 2011 at 11:23 AM, Bernar= d Aboba <= bernard_aboba@hotmail.com> wrote:
I'm not going to use this mailing list as an advertising medium, but th= ere do exist products that support both ICE and SRTP, and some of the compa= nies you name below have deployed those products to *thousands* of their em= ployees.

Date: Tue, 27 Sep 20= 11 11:12:18 -0400
Subject: Re: [rtcweb] Requiring ICE for RTC calls
F= rom: roman@telurix.c= om
To: juberti@google.= com
CC: bernard_aboba@hotmail.com; rtcweb@ietf.org


I am sorry, but can you name "robust telepho= ny services" that currently provide ICE and SRTP support in US? AFAK V= erizon, Qwest, Level3, Global Crossing, Paetec, XO do not provide this.
_____________
Roman Shpount



--bcaec520f27dafbe6704adee6dcd-- From roman@telurix.com Tue Sep 27 09:06: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 C5F4C21F8E7A for ; Tue, 27 Sep 2011 09:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhCPh2gPxbhh for ; Tue, 27 Sep 2011 09:06:07 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 39AD821F8E70 for ; Tue, 27 Sep 2011 09:06:07 -0700 (PDT) Received: by pzk37 with SMTP id 37so18902739pzk.9 for ; Tue, 27 Sep 2011 09:08:53 -0700 (PDT) Received: by 10.68.7.166 with SMTP id k6mr22905798pba.128.1317139733041; Tue, 27 Sep 2011 09:08:53 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by mx.google.com with ESMTPS id y5sm85807595pbe.6.2011.09.27.09.08.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 09:08:52 -0700 (PDT) Received: by pzk37 with SMTP id 37so18902700pzk.9 for ; Tue, 27 Sep 2011 09:08:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.34.138 with SMTP id z10mr37699603pbi.105.1317139731799; Tue, 27 Sep 2011 09:08:51 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 27 Sep 2011 09:08:51 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <84254826-C357-4FB5-810D-C453A2D1304C@phonefromhere.com> Date: Tue, 27 Sep 2011 12:08:51 -0400 Message-ID: From: Roman Shpount To: Bernard Aboba Content-Type: multipart/alternative; boundary=bcaec5216303d5604104adee7d8e Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 16:06:07 -0000 --bcaec5216303d5604104adee7d8e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 27, 2011 at 12:03 PM, Bernard Aboba wrote: > Roman Shpount said: > > "It does not matter what they run. Quite a few of them do not run GSM, but > I can cost effectively call every one of them using SIP/G.711, and that's > what very important. It will take some amount of time to upgrade this > infrastructure to support SRTP and ICE." > > [BA] Why would it be necessary to upgrade wireless carrier infrastructure? > Presumably a service that wants to make calls to E.164 numbers will install > a gateway that enables this. Wireless carriers wouldn't have to upgrade. > No, we do not need to upgrade wireless carriers. The only people really affected are the SIP trunking providers, and they are also often the slowest in introducing new features. What I meant that by supporting SIP/G.711 we get an a existing, cost effective way to access 5 billion wireless subscribers, as well as 500M Skype subscribers, millions of corporate customers. Calling using SIP/G.711 through a SIP trunk provider is not only about wireline PSTN, it is about a much larger universe of people. _____________ Roman Shpount --bcaec5216303d5604104adee7d8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 27, 2011 at 12:03 PM, Bernard Ab= oba <bern= ard_aboba@hotmail.com> wrote:
Roman Shpount said:

"It does not matter = what they run. Quite a few of them do not run GSM, but I can cost effective= ly call every one of them using SIP/G.711, and that's what very importa= nt. It will take some amount of time to upgrade this infrastructure to supp= ort SRTP and ICE."

[BA] Why would it be necessary to upgrade wireless carrier infras= tructure?=A0 Presumably a service that wants to make calls to E.164 numbers= will install a gateway that enables this.=A0 Wireless carriers wouldn'= t have to upgrade.

No, we do not need to upgrade wireless carriers. The= only people really affected are the SIP trunking providers, and they are a= lso often the slowest in introducing new features.

What I meant tha= t by supporting SIP/G.711 we get an a existing, cost effective way to acces= s 5 billion wireless subscribers, as well as 500M Skype subscribers, millio= ns of corporate customers. Calling using SIP/G.711 through a SIP trunk prov= ider is not only about wireline PSTN, it is about a much larger universe of= people.
_____________
Roman Shpount


--bcaec5216303d5604104adee7d8e-- From roman@telurix.com Tue Sep 27 09:28: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 4A60021F8E24 for ; Tue, 27 Sep 2011 09:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 oeJeIvn-E3Hr for ; Tue, 27 Sep 2011 09:28:15 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E26D21F8C89 for ; Tue, 27 Sep 2011 09:28:15 -0700 (PDT) Received: by ywa6 with SMTP id 6so6859742ywa.31 for ; Tue, 27 Sep 2011 09:31:01 -0700 (PDT) Received: by 10.150.171.4 with SMTP id t4mr7273939ybe.408.1317141060967; Tue, 27 Sep 2011 09:31:00 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id z6sm80029724anf.22.2011.09.27.09.30.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 09:31:00 -0700 (PDT) Received: by gyd12 with SMTP id 12so6682746gyd.31 for ; Tue, 27 Sep 2011 09:30:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.31.4 with SMTP id w4mr9259452pbh.20.1317141059169; Tue, 27 Sep 2011 09:30:59 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 27 Sep 2011 09:30:59 -0700 (PDT) In-Reply-To: <4E81E8AB.2080404@skype.net> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <4E81E8AB.2080404@skype.net> Date: Tue, 27 Sep 2011 12:30:59 -0400 Message-ID: From: Roman Shpount To: Matthew Kaufman Content-Type: multipart/alternative; boundary=bcaec520f27df36f3a04adeecc95 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 16:28:16 -0000 --bcaec520f27df36f3a04adeecc95 Content-Type: text/plain; charset=ISO-8859-1 Matthew, One possible solution would be to have a slow rate RTP start, if remote end point does not indicate ICE support. Instead of sending real media, RTC end point will send no-media RTP packets at the rate of 2-3 per second for 10-15 seconds. If it receives a valid RTP packet back from the destination IP, it will consider RTP flow verified and switch to sending media at normal rate, otherwise media stream is terminated. We can have a better timing mechanism for RTP packets to match the number of packets in the initial STUN handshake in ICE, but the general idea is to get interoperability with existing networks at the cost of 20 packet handshake. I do realize that the problem with this that the RTP packets can be spoofed to force the web end point to transmit, but this is the best solution I see so far. If we do decide that ICE is a requirement, we can also have a local policy, web site can be specified for which the calls are allowed without ICE. Independently from all of this, SRTP should be optional. It does present privacy concerns, but they are no different then privacy concerns over HTTP. _____________ Roman Shpount On Tue, Sep 27, 2011 at 11:15 AM, Matthew Kaufman wrote: > On 9/27/2011 7:46 AM, Roman Shpount wrote: > >> >> How real or big do you think this problem is going to be? None of the >> current SIP/VoIP clients address this now, and we have quite a number of >> them out there. I understand that this is an attack vector but how big of an >> attack vector is this going to be if we ask for user confirmation? >> >> > There is no plan to ask for user confirmation to open a connection, receive > media, or send and receive data. The only user confirmation that is expected > would be for camera and/or microphone access. > > I've seen a dozen messages from you arguing that the requirement for a STUN > connectivity check is a barrier and should be removed, but I have not yet > seen an alternative proposal that meets the requirements of browser authors > with regard to preventing attacks on behind-firewall infrastructure from the > browser platform. > > Matthew Kaufman > --bcaec520f27df36f3a04adeecc95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Matthew,

One possible solution would be to have a slow rate RTP star= t, if remote end point does not indicate ICE support. Instead of sending re= al media, RTC end point will send no-media RTP packets at the rate of 2-3 p= er second for 10-15 seconds. If it receives a valid RTP packet back from th= e destination IP, it will consider RTP flow verified and switch to sending = media at normal rate, otherwise media stream is terminated. We can have a b= etter timing mechanism for RTP packets to match the number of packets in th= e initial STUN handshake in ICE, but the general idea is to get interoperab= ility with existing networks at the cost of 20 packet handshake. I do reali= ze that the problem with this that the RTP packets can be spoofed to force = the web end point to transmit, but this is the best solution I see so far.<= br>
If we do decide that ICE is a requirement, we can also have a local pol= icy,=A0 web site can be specified for which the calls are allowed without I= CE.

Independently from all of this, SRTP should be optional. It does= present privacy concerns, but they are no different then privacy concerns = over HTTP.
_____________
Roman Shpount


On Tue, Sep 27, 2011 at 11:15 AM, Matthe= w Kaufman <matthew.kaufman@skype.net> wrote:
On 9/27/2011 7:46 AM, Roman Shpount wrote:

How real or big do you think this problem is going to be? None of the curre= nt SIP/VoIP clients address this now, and we have quite a number of them ou= t there. I understand that this is an attack vector but how big of an attac= k vector is this going to be if we ask for user confirmation?


There is no plan to ask for user confirmation to open a connection, receive= media, or send and receive data. The only user confirmation that is expect= ed would be for camera and/or microphone access.

I've seen a dozen messages from you arguing that the requirement for a = STUN connectivity check is a barrier and should be removed, but I have not = yet seen an alternative proposal that meets the requirements of browser aut= hors with regard to preventing attacks on behind-firewall infrastructure fr= om the browser platform.

Matthew Kaufman

--bcaec520f27df36f3a04adeecc95-- From ibc@aliax.net Tue Sep 27 09:35: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 A629D21F8EE8 for ; Tue, 27 Sep 2011 09:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=-0.259, 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 B3LufI5AAydT for ; Tue, 27 Sep 2011 09:35:19 -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 2CCDF21F8ED6 for ; Tue, 27 Sep 2011 09:35:19 -0700 (PDT) Received: by vws5 with SMTP id 5so8407719vws.31 for ; Tue, 27 Sep 2011 09:38:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.23.4 with SMTP id i4mr7566132vdf.514.1317141484842; Tue, 27 Sep 2011 09:38:04 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 27 Sep 2011 09:38:04 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <4E81E8AB.2080404@skype.net> Date: Tue, 27 Sep 2011 18:38:04 +0200 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: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 16:35:19 -0000 2011/9/27 Roman Shpount : > If we do decide that ICE is a requirement, we can also have a local polic= y, > web site can be specified for which the calls are allowed without ICE. I agree. Somebody would reply now that the provider could be malicious, but nothing prevents a malicious provider to establish a valid and secure SRTP+ICE video session with a web visitor and later publish the video in Youtube. > Independently from all of this, SRTP should be optional. It does present > privacy concerns, but they are no different then privacy concerns over HT= TP. The privacy concerns of RTP are the same that those present in HTTP, SMTP, FTP, SIP, XMPP or whatever application level protocol. But none of those specifications require TLS. Of course a service provider could decide to impose TLS, but the specification (rtcweb here) should not mandate so much (IMHO). --=20 I=C3=B1aki Baz Castillo From juberti@google.com Tue Sep 27 09:58: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 740CE21F8E71 for ; Tue, 27 Sep 2011 09:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.64 X-Spam-Level: X-Spam-Status: No, score=-105.64 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJpDQrRD7OAj for ; Tue, 27 Sep 2011 09:58:43 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAC221F8E70 for ; Tue, 27 Sep 2011 09:58:42 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p8RH1NII003792 for ; Tue, 27 Sep 2011 10:01:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317142884; bh=Zl52KpaP+sbXdDGBMDNsm5KyH60=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=F3yLyA/27id1DyJM6IxhTPE7+Q4BR/1AGVIEjq1KdII3GC2239MFim3p1jZJmNdOB O8AXzK8Z/OgNg6t+b3nxQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=ccyDsjGYV8zuAwwWCpvMPrQXjUnPF4Y6t7J4kayznOkTjHKYd346t6jiWsxcbdHdN mDibWBeHuccFoDsGuM9Pg== Received: from qyc1 (qyc1.prod.google.com [10.241.81.129]) by hpaq13.eem.corp.google.com with ESMTP id p8RGslwa019794 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 27 Sep 2011 10:01:22 -0700 Received: by qyc1 with SMTP id 1so1318292qyc.11 for ; Tue, 27 Sep 2011 10:01:22 -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; bh=k2ymFhSOI4EsKCwzT9M4V3TchYwgU8bp8oAPFO5/tm0=; b=uVfsSKWFeLLoYcgRUjqMvO/v6xSecNtxwYK4g+HoPpqK7gXQjwJ1eXii0vEi5503aX fQrSCfRYy/7wAmtK41jQ== Received: by 10.224.218.194 with SMTP id hr2mr5507345qab.61.1317142882285; Tue, 27 Sep 2011 10:01:22 -0700 (PDT) Received: by 10.224.218.194 with SMTP id hr2mr5507337qab.61.1317142882082; Tue, 27 Sep 2011 10:01:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.165.212 with HTTP; Tue, 27 Sep 2011 10:01:02 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> From: Justin Uberti Date: Tue, 27 Sep 2011 13:01:02 -0400 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=20cf3005dc829ae09004adef391a X-System-Of-Record: true Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 16:58:44 -0000 --20cf3005dc829ae09004adef391a Content-Type: text/plain; charset=UTF-8 Neither Google Voice nor Skype (both fairly popular services) send raw RTP directly from the client to a PSTN terminator. I can't speak for Skype, but Google Voice uses a media gateway for the quality-related reasons I mentioned earlier. Since these large-scale services can deploy media gateways, it's clear that this is not a significant impediment. PSTN calling is a paid-for service, after all. On Tue, Sep 27, 2011 at 11:12 AM, Roman Shpount wrote: > I am sorry, but can you name "robust telephony services" that currently > provide ICE and SRTP support in US? AFAK Verizon, Qwest, Level3, Global > Crossing, Paetec, XO do not provide this. > _____________ > Roman Shpount > > > > On Tue, Sep 27, 2011 at 10:55 AM, Justin Uberti wrote: > >> We can still talk to them via a media gateway, which robust telephony >> services will already provide for the reasons I mentioned previously. >> >> On Tue, Sep 27, 2011 at 10:49 AM, Roman Shpount wrote: >> >>> Sorry, correcting myself, there are over 5 billion mobile phones >>> worldwide. Are you sure we don't need to talk to them. >>> _____________ >>> Roman Shpount >>> >>> >>> >>> On Tue, Sep 27, 2011 at 10:40 AM, Roman Shpount wrote: >>> >>>> Bernard, >>>> >>>> What about 500M Skype users? Skype for SIP does not support SRTP or >>>> ICE.What about 2 billion wireless subscribers? Despite what you think number >>>> of phones and phone numbers is growing, and a wast majority of these phones >>>> are dumb wireless phones. >>>> _____________ >>>> Roman Shpount >>>> >>>> >>>> On Mon, Sep 26, 2011 at 11:44 PM, Bernard Aboba < >>>> bernard_aboba@hotmail.com> wrote: >>>> >>>>> >>>>> > And "interoperability with SIP-PSTN providers" is only relevant if >>>>> you >>>>> > are trying to turn the browser into another phone. We have enough >>>>> > phones. What we don't have are new real-time communication >>>>> experiences >>>>> > that can only be created within this environment. >>>>> >>>>> [BA] I think you may be on to something here. POTS lines are dropping >>>>> so rapidly >>>>> that wireline service won't even exist in some countries within a few >>>>> years. While >>>>> PSTN interop may have been a key scenario in the early days of SIP, I >>>>> have serious >>>>> doubts as to how much attention we should pay to this in RTCWEB. >>>>> Ability to >>>>> make a call to an E.164 number? Probably. Support for every potential >>>>> corner >>>>> case? Not necessarily. >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >> > --20cf3005dc829ae09004adef391a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Neither Google Voice nor Skype (both fairly popular services) send raw RTP = directly from the client to a PSTN terminator. I can't speak for Skype,= but Google Voice uses a media gateway for the quality-related reasons I me= ntioned earlier.=C2=A0

Since these large-scale services can deploy media gateways, = it's clear that this is not a significant impediment. PSTN calling is a= paid-for service, after all.

On Tue, Sep= 27, 2011 at 11:12 AM, Roman Shpount <roman@telurix.com> wrote:
I am sorry, but can you name "robust t= elephony services" that currently provide ICE and SRTP support in US? = AFAK Verizon, Qwest, Level3, Global Crossing, Paetec, XO do not provide thi= s.
_____________
Roman Shpount



On Tue, Sep 27, 2011 at 10:55 AM, Justin= Uberti <juberti@google.com> wrote:
We can still talk to them via a media gateway, which robust telephony servi= ces will already provide for the reasons I mentioned previously.
<= /div>

On Tue, Sep 27, 2011 at 10:49= AM, Roman Shpount <roman@telurix.com> wrote:
Sorry, correcting myself, there are over 5 b= illion mobile phones worldwide. Are you sure we don't need to talk to t= hem.
_____________
Roman Shpount<= div>



On Tue, Sep 27, 2011 at 10:40 AM, Roman = Shpount <roman@telurix.com> wrote:
Bernard,

What about 500M Skype users? Skype for SIP does not support= SRTP or ICE.What about 2 billion wireless subscribers? Despite what you th= ink number of phones and phone numbers is growing, and a wast majority of t= hese phones are dumb wireless phones.
_____________
Roman Shpount


On Mon, Sep 26, 2011 at 11:44 PM, Bernar= d Aboba <bernard_aboba@hotmail.com> wrote:

> And "interoperability with SIP-PSTN providers"= is only relevant if you
> are trying to turn the browser into anothe= r phone. We have enough
> phones. What we don't have are new real= -time communication experiences
> that can only be created within this environment.

[BA] I = think you may be on to something here.=C2=A0 POTS lines are dropping so rap= idly
that wireline service won't even exist in some countries within= a few years.=C2=A0 While
PSTN interop may have been a key scenario in the early days of SIP, I have = serious
doubts as to how much attention we should pay to this in RTCWEB.= =C2=A0 Ability to
make a call to an E.164 number?=C2=A0 Probably.=C2=A0 = Support for every potential corner
case?=C2=A0 Not necessarily.

_______________________________________________
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




--20cf3005dc829ae09004adef391a-- From matthew.kaufman@skype.net Tue Sep 27 10:22: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 0226E21F8BAC for ; Tue, 27 Sep 2011 10:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 tagged_above=-999 required=5 tests=[AWL=0.852, 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 a6pJVhTEEUp6 for ; Tue, 27 Sep 2011 10:22:44 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id C882C21F8BAA for ; Tue, 27 Sep 2011 10:22:43 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id E7AC016F7; Tue, 27 Sep 2011 19:25:19 +0200 (CEST) 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=HyDdtbwI+K1ywl c7C2mtnJN6gP0=; b=lY5a43VNfpwgGSvB8RTAMrHX1B2btQeu83OliP2OrLNxvr X9Gut4bZY+zHr9iN9201ADb6Oo0NFojhWmVN+5PJGiUIEfA55a6fhL9ptG0YC8O3 WR1vOloJjU3Mi5v3W/oAU9pIxynK2Y5gJ66hytUXPzWlzWBxBp7q+XK7AMaYg= 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=tCaJCaNW7XIQgpdQevCery EZuBY764Uk0cbBHaKG+p7ppCHQKa3jCvB9iBHEqa5mIsTRH/0yVs2uqsqmhy0Idd UqjWeMnUgwHBSj5UWfus7Q+Iu/ptadOm1r0hkl9wn0JSsK/+vkLYFgpXJH1vliD+ An+vBqkDFICdKrFRAYYAw= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id E62327F8; Tue, 27 Sep 2011 19:25:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id B93A91672681; Tue, 27 Sep 2011 19:25:19 +0200 (CEST) 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 YeRaxIgdaN-p; Tue, 27 Sep 2011 19:25:19 +0200 (CEST) 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 4DC441672682; Tue, 27 Sep 2011 19:25:17 +0200 (CEST) Message-ID: <4E8206FB.6060208@skype.net> Date: Tue, 27 Sep 2011 10:25:15 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Roman Shpount References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <4E81E8AB.2080404@skype.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 17:22:45 -0000 On 9/27/11 9:30 AM, Roman Shpount wrote: > Matthew, > > One possible solution would be to have a slow rate RTP start, ... I do > realize that the problem with this that the RTP packets can be spoofed > to force the web end point to transmit, but this is the best solution > I see so far. You are correct that an attacker can spoof RTP packets to override this mechanism. Thus it is not sufficient. RTCP is also not sufficient, as we've been through this before: http://www.ietf.org/mail-archive/web/rtcweb/current/msg00500.html > > Independently from all of this, SRTP should be optional. It does > present privacy concerns, but they are no different then privacy > concerns over HTTP. The difference is that knowing whether your media is using SRTP or not is more difficult than knowing that the content was delivered over HTTPS or HTTP, without significantly more browser chrome. Matthew Kaufman From matthew.kaufman@skype.net Tue Sep 27 10:27: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 8B63021F8ED1 for ; Tue, 27 Sep 2011 10:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.778 X-Spam-Level: X-Spam-Status: No, score=-5.778 tagged_above=-999 required=5 tests=[AWL=0.821, 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 K-3rs-S-Ckai for ; Tue, 27 Sep 2011 10:27:36 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id EA52721F8DE0 for ; Tue, 27 Sep 2011 10:27:35 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id B437116F7; Tue, 27 Sep 2011 19:30:17 +0200 (CEST) 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=dPfN2t1efoynyL ge0ml+k+ycrIY=; b=K9ed/N7musAYhtQGdB1WoVP0JmcTz3f3uS+GnM1ynu5tqA 2vu3HtqX8XkxZNeeF98zn8zlTmxD4keU83N/9zx4RsDkMb5mgdYhV7HofLGy673l CHFVE9UIkEzA+/o8ZTTcMiRTosemiSlW/jHZK1NYPgTcllocFcr/EWwZdXTFE= 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=UHsqK34gSNJr3fzQTzeumU Emyb3gxf+vBolKx1E1pxL94F2XrBND0PhxVuizfU7ZrcixW28nbHD4A/uypuqc+J OYmCt1ggLxWXeUz9U9YRU/lSyVZeMqCqC6bg4L2mhdp3PrBrrNYAFDFF5m+jnKA9 /5OnF+k9NGafQ3I4LB3f0= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id B2BBA7F6; Tue, 27 Sep 2011 19:30:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 7C0A91672683; Tue, 27 Sep 2011 19:30:17 +0200 (CEST) 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 ZU-k2EyOVZ1w; Tue, 27 Sep 2011 19:30:16 +0200 (CEST) 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 006511672682; Tue, 27 Sep 2011 19:30:15 +0200 (CEST) Message-ID: <4E820825.9090101@skype.net> Date: Tue, 27 Sep 2011 10:30:13 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Justin Uberti References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 17:27:36 -0000 On 9/27/11 10:01 AM, Justin Uberti wrote: > Neither Google Voice nor Skype (both fairly popular services) send raw > RTP directly from the client to a PSTN terminator. True. > I can't speak for Skype, but Google Voice uses a media gateway for the > quality-related reasons I mentioned earlier. I can't speak for Skype either, but this is a good guess. > > Since these large-scale services can deploy media gateways, it's clear > that this is not a significant impediment. Agree. I'm not at all sure what the argument is that we need existing-PSTN-gateway-compatible RTP (without SRTP or ICE). If there is demand, these gateways will be upgraded to support RTCWeb. If there is not, service providers can run intermediate gateways. Matthew Kaufman From ted.ietf@gmail.com Tue Sep 27 11:30: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 EB0DE21F8F33 for ; Tue, 27 Sep 2011 11:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[AWL=-0.551, 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 j2oBlqyXz2l0 for ; Tue, 27 Sep 2011 11:30:55 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id C48F021F8F30 for ; Tue, 27 Sep 2011 11:30:54 -0700 (PDT) Received: by yic13 with SMTP id 13so6641846yic.31 for ; Tue, 27 Sep 2011 11:33:40 -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=LMsidN6ONOZCwjCmcnLg+5BPPSrnnzC6l3CPkpozbPA=; b=sR3RldVEAyVZcymcNl4QH2Mqlup09/AE8aOh/Hr2bnCEEq4opXln+A14Ze+yNc6WC+ ICbNznGP9k7DOzJp6gaNT0Mn5aZSfmzLwdcSEmYApWiRMtKL4J0VjH8HAPV+YgcUpSiX WTu01OKL22Tx6/F58JCcYbs+lTjTCTuQw+zD8= MIME-Version: 1.0 Received: by 10.236.191.71 with SMTP id f47mr49573059yhn.125.1317148418954; Tue, 27 Sep 2011 11:33:38 -0700 (PDT) Received: by 10.236.108.35 with HTTP; Tue, 27 Sep 2011 11:33:38 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Sep 2011 11:33:38 -0700 Message-ID: From: Ted Hardie To: Bernard Aboba Content-Type: multipart/alternative; boundary=20cf303f6496a0d5cb04adf0835b Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB and emergency services X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 18:30:56 -0000 --20cf303f6496a0d5cb04adf0835b Content-Type: text/plain; charset=ISO-8859-1 Hi Bernard, Some comments in-line. On Sun, Sep 25, 2011 at 5:13 PM, Bernard Aboba wrote: > I'm putting together a draft on the subject of RTCWEB and emergency > services. However, before submitting this, it seemed useful to get some > feedback from the group on the general direction of the document. > > 1. The overall requirements for emergency services support will vary by > jurisdiction and are likely to change. Therefore the document, while > citing ongoing regulatory proceedings within the US and EU, does not attempt > to provide legal advice or offer a definitive statement of the regulatory > requirements. Instead, the document cites documents from the ECRIT WG, > such as the ECRIT Framework and Phone-BCP documents which provide guidance > on best current or future practices. > > 2. The overall requirements for emergency services support also vary by > the type of service that is being implemented. For example, adding > support for real-time conferencing to a social networking service or a game > (e.g. non-interconnected VoIP) will result in different requirements than > say, implementing a phone dialing service that can both make outgoing calls > and take incoming calls from E.164 numbers (e.g. interconnected VoIP). > > It should therefore be understood that the burden for implementation of > emergency services falls principally upon the operator of the service, and > that the role of the RTCWEB implementer is to deliver basic capabilities and > to enable an operator to add to this functionality, rather than providing > for every possible need natively ("I want a pony"). > > Do I understand you correctly to be saying "The emergency service must stand up an RTCWEB server which provides downloadable javascript applications, rather than presuming that other javascript applications provide this functionality."? > 3. The emergency services capabilities of the browser are comprised of the > functionality that is implemented in the browser, as well functionality that > can be added via Javascript libraries. In some circumstances, it may be > viable to supplement functionality with plugins. For example, a "webphone" > intended for use with an IP PBX, whose firmware is controlled by the IP PBX > vendor, could include within its code load plugins to provide additional > functionality, including signaling protocols and codecs. As a result, it is > not required for an RTCWEB implementation to natively satisfy every > requirement of ECRIT Phone-BCP. Examples of requirements which may not be > satisfiable without plugins include some of the endpoint media requirements > of PhoneBCP Section 14, such as ED-77 (video codec support). However, it > would appear that some of the requirements of that section such as ED-71 > (RTP Support) and ED-73 (G.711 support) are appropriate. > > 4. With respect to location capabilities, the W3C Location APIs and > associated Location-Based Services are not adequate in terms of their > support for emergency services location. This gap exists in part because > the requirements and scenarios for Location-Based Services (LBS) are > different from those of Location Information Services (LISes) used for > emergency purposes. While in the long-term it may be possible to close the > gaps, in the short term the gaps may be addressed via Javascript libraries > implementing elements of the ECRIT architecture such as HELD, or even > LoST. > > > It doesn't make sense to use LoST alone in the case you've described, at least if I understood you. LoST takes a desired service and a location as inputs and discovers the service provider associated with that location. If we're presuming that someone starts at a particular server, LoST must run prior to reaching that server. So you'd need some sort of libraries provided prior to that server being reached to run LoST. If you start from a known server that provides javascript libraries for discovering location (by pulling from DHCP or HELD, for example) and running LoST, you could then get to the Emergency Service Provider's RTCWEB server, but it would be pretty fragile. regards, Ted > > > > > In addition, in some scenarios, it is quite feasible for this > > 2. Similarly, the requirements for native browser functionality will vary > according to the scenario. > > 2. In some scenarios, > > > In meeting the requirements for emergency services support, the important > question to answer is what functionality MUST be present natively within the > browser > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --20cf303f6496a0d5cb04adf0835b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Bernard,

Some comments in-line.


On Sun, Sep 25, 2011 a= t 5:13 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
I'm putting together a draft on the subject of RTCWEB = and emergency services.=A0 However, before submitting this, it seemed usefu= l to get some feedback from the group on the general direction of the docum= ent.

1. The overall requirements for emergency services support will vary by= jurisdiction and are likely to change.=A0=A0 Therefore the document, while= citing ongoing regulatory proceedings within the US and EU, does not attem= pt to provide legal advice or offer a definitive statement of the regulator= y requirements.=A0 Instead, the document cites=A0 documents from the ECRIT = WG, such as the ECRIT Framework and Phone-BCP documents which provide guida= nce on best current or future practices. =A0

2.=A0 The overall requirements for emergency services support also vary= by the type of service that is being implemented.=A0=A0 For example,=A0 ad= ding support for real-time conferencing to a social networking service or a= game (e.g. non-interconnected VoIP) will result in different requirements = than say, implementing a phone dialing service that can both make outgoing = calls and take incoming calls from E.164 numbers (e.g. interconnected VoIP)= .=A0=A0

It should therefore be understood that the burden for implementation of= emergency services falls principally upon the operator of the service, and= that the role of the RTCWEB implementer is to deliver basic capabilities a= nd to enable an operator to add to this functionality, rather than providin= g for every possible need natively ("I want a pony").=A0=A0


Do I understand you correctly t= o be saying "The emergency service must stand up an RTCWEB server whic= h provides downloadable javascript applications, rather than presuming that= other javascript applications provide this functionality."?

=A0
3.=A0 The emergency services capabilitie= s of the browser are comprised of the functionality that is implemented in = the browser, as well functionality that can be added via Javascript librari= es.=A0=A0 In some circumstances, it may be viable to supplement functionali= ty with plugins.=A0 For example, a "webphone" intended for use wi= th an IP PBX, whose firmware is controlled by the IP PBX vendor,=A0 could i= nclude within its code load plugins to provide additional functionality, in= cluding signaling protocols and codecs.=A0 As a result, it is not required = for an RTCWEB implementation to natively satisfy every requirement of ECRIT= Phone-BCP.=A0=A0=A0 Examples of requirements which may not be satisfiable = without plugins include some of the endpoint media requirements of PhoneBCP= Section 14, such as ED-77 (video codec support).=A0=A0 However, it would a= ppear that some of the requirements of that section such as ED-71 (RTP Supp= ort) and ED-73 (G.711 support) are appropriate.=A0

4. With respect t= o location capabilities, the W3C Location APIs and associated Location-Base= d Services are not adequate in terms of their support for emergency service= s=20 location.=A0 This gap exists in part because the requirements and scenarios= for=A0 Location-Based Services (LBS) are different from those of Location = Information Services (LISes) used for emergency purposes.=A0=A0 While in th= e long-term it may be possible to close the gaps,=A0 in the short term the = gaps may be addressed via Javascript libraries implementing elements of the= ECRIT=20 architecture such as HELD, or even LoST.=A0=A0



It doesn't make sense t= o use LoST alone in the case you've described, at least if I understood= you.=A0 LoST takes a desired service and a location as inputs and discover= s the service provider associated with that location.=A0 If we're presu= ming that someone starts at a particular server, LoST must run prior to rea= ching that server.=A0 So you'd need some sort of libraries provided pri= or to that server being reached to run LoST.=A0 If you start from a known s= erver that provides javascript libraries for discovering location (by pulli= ng from DHCP or HELD, for example) and running LoST, you could then get to = the Emergency Service Provider's RTCWEB server, but it would be pretty = fragile.


regards,

Ted



In addition, in some scenarios, it is quite feasible for this

2.=A0 Similarly, the requirements for native browser functionality will= vary according to the scenario.=A0

2. In some scenarios,

<= br>=A0In meeting the requirements for emergency services support, the impor= tant question to answer is what functionality MUST be present natively with= in the browser



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


--20cf303f6496a0d5cb04adf0835b-- From pravindran@sonusnet.com Tue Sep 27 11:32: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 51CBD21F8B2D for ; Tue, 27 Sep 2011 11:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.102, 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 MtaCDDXQp01Q for ; Tue, 27 Sep 2011 11:32:08 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 41BD421F8A64 for ; Tue, 27 Sep 2011 11:32:04 -0700 (PDT) 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 p8RIZHXc003161; Tue, 27 Sep 2011 14:35:17 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Sep 2011 14:34:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC7D44.18E120A9" Date: Wed, 28 Sep 2011 00:04:29 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F111F@sonusinmail02.sonusnet.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233FFBC40@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE forRTC calls) Thread-Index: Acx9Jwt3HG9q88SrSzKIKQVNnduBbwAATJ/AAAXUNhA= References: <4E80984A.903@skype.net><4E809EE6.2050702@skype.net><2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com><4E8185FC.8000906@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233FFBC40@ESESSCMS0356.eemea.ericsson.se> From: "Ravindran Parthasarathi" To: "Christer Holmberg" , "Roman Shpount" , "Harald Alvestrand" X-OriginalArrivalTime: 27 Sep 2011 18:34:34.0579 (UTC) FILETIME=[1AAE7230:01CC7D44] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE forRTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 18:32:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC7D44.18E120A9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roman, =20 My understanding is same as Christer. In case your aim is to interop with PSTN gateway, Umpteen number of changes has to be done in current RTCWeb and we may end-up in SIP with current standard for IP based real-time interaction. IMO, ICE selection is not the only stopping factor for PSTN interop and anyhow, you need RTCWeb server to PSTN gateway which shall perform media gateway functionality as well. So, Please don't reject ICE for PSTN or SIP trunk interop. =20 =20 In the another mail thread, there is a discussion that lot of operators and Enterprise SIP implementation does not support ICE and so, RTCWeb should support interop with non-ICE peer. The point to be noted is that the default media destination is known in specific deployment, ICE process shall be skipped. Lot of the deployment will not have NAT before Customer premise Equipment and so, ICE is overhead . Also, SBC handles NAT issue in a smarter way than ICE for few deployment. So, ICE is not required in lot of existing deployment.=20 =20 Depreciated STUN RFC has lot of loss end which results in the current STUN, TURN, and ICE. Current STUN Indication may solve couple of NAT issues but not all. =20 NAT and security consideration of RTCWeb forces us to look for mandating ICE. In case you have alternative mechanism or any other technical reason for not to mandate ICE, Please let us know. =20 Thanks Partha =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Tuesday, September 27, 2011 8:51 PM To: Roman Shpount; Harald Alvestrand Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE forRTC calls) =20 Hi, =20 I don't think the question is about changing the ICE spec. =20 You are correct in that ICE as such allows establishment of sessions with non-ICE peers, but I don't think anyone is questioning that. =20 The question is whether we shall specify that the browser must use "Require:ICE" (speaking in SIP terms :), in order to fulful some security requirement. =20 So, in my opinion we shall focus on the requirement, and whether we need to mandate the usage of some mechanism (ICE or something else) in order to solve that requirement. =20 ...or whether the requirement should be dropped or relaxed. =20 Regards, =20 Christer =20 =20 =20 =20 ________________________________ From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount Sent: 27. syyskuuta 2011 18:06 To: Harald Alvestrand Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE for RTC calls) Let's see: =09 4.1.4. Choosing Default Candidates =09 A candidate is said to be default if it would be the target of media from a non-ICE peer; that target is called the DEFAULT DESTINATION. If the default candidates are not selected by the ICE algorithm when communicating with an ICE-aware peer, an updated offer/answer will be required after ICE processing completes in order to "fix up" the SDP so that the default destination for media matches the candidates selected by ICE. If ICE happens to select the default candidates, no updated offer/answer is required. =09 An agent MUST choose a set of candidates, one for each component of each in-use media stream, to be default. =09 5.1. Verifying ICE Support =09 If this condition is not met, the agent MUST process the SDP based on normal RFC 3264 procedures, without using any of the ICE mechanisms described in the remainder of this specification... =09 6.1. Verifying ICE Support =09 The logic at the offerer is identical to that of the answerer as described in Section 5.1, with the exception that an offerer would not ever generate a=3Dice-mismatch attributes in an SDP. =09 My interpretation of this always was that ICE enabled end point MUST generate an offer that will be understood by a non-ICE end point, properly process on offer from a non-ICE enabled end point, and properly process an answer from a non-ICE end point. So if we want RTC to be ICE complaint we should be able to communicate with non-ICE end points, or define a new specification. _____________ Roman Shpount =09 =09 On Tue, Sep 27, 2011 at 4:14 AM, Harald Alvestrand wrote: On 09/26/11 20:48, Roman Shpount wrote: You can determine that end point is not behind symmetric NAT using older STUN specification and list discovered IP as a default contact address in SDP, if you are not behind NAT, you can list the relayed address of the TURN server as the default address. If you do this, together with the offer that lists ICE candidates, you would be able to traverse NAT and communicate with non-ICE end points. =09 I think discussion in this thread is not whether ICE needs to be supported or implemented. I would say that ICE without a doubt should be supported. It is about changing ICE specification as it stands right now, and force the RTC end point only to communicate with end points that respond with ICE compliant answer and complete ICE hand shake. This is actually against the ICE specification as it is defined in RFC 5245, where answerer actually can refuse to support ICE but still establish a call. Roman, =09 Which part of RFC 5245 are you referring to with this statement? =09 Please describe the sections you think will be invoked when an SDP OFFER contains ICE candidates, the answerer does not want to use ICE, what the OFFER and ANSWER would look like, and which section of RFC 5245 is invoked when processing the ANSWER. =09 Details are good. =09 Harald =09 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------_=_NextPart_001_01CC7D44.18E120A9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roman,

 

My understanding is same as Christer.  In case your = aim is to interop with PSTN gateway, Umpteen number of changes has to be done = in current RTCWeb and we may end-up in SIP with current standard for IP = based real-time interaction. IMO, ICE selection is not the only stopping = factor for PSTN interop and anyhow, you need RTCWeb server to PSTN gateway which = shall perform media gateway functionality as well. So, Please don’t = reject ICE for PSTN or SIP trunk interop.  

 

In the another mail thread, there is a discussion that = lot of operators and Enterprise SIP implementation does not support ICE and so, = RTCWeb should support interop with non-ICE peer. The point to be noted is that = the default media destination is known in specific deployment, ICE process = shall be skipped. Lot of the deployment will not have NAT before Customer premise = Equipment and so, ICE is overhead . Also, SBC handles NAT issue in a smarter way = than ICE for few deployment.  So, ICE is not required in lot of existing = deployment.

 

Depreciated STUN RFC has lot of loss end which results in = the current STUN, TURN, and ICE. Current STUN Indication may solve couple of NAT = issues but not all.

 

NAT and security consideration of RTCWeb forces us to = look for mandating ICE. In case you have alternative mechanism or any other = technical reason for not to mandate ICE, Please let us know.

 

Thanks

Partha

 

From:= = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer = Holmberg
Sent: Tuesday, September 27, 2011 8:51 PM
To: Roman Shpount; Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE = forRTC calls)

 

Hi,

 

I don't think the question is about changing the = ICE spec.

 

You are correct in that ICE as such allows establishment of sessions with non-ICE peers, but I don't think anyone is = questioning that.

 

The question is whether we shall specify that the browser = must use "Require:ICE" (speaking in SIP terms :), in order to fulful = some security requirement.

 

So, in my opinion we shall focus on the requirement, and = whether we need to mandate the usage of some mechanism (ICE or something else) in = order to solve that requirement.

 

...or whether the requirement should be dropped or = relaxed.

 

Regards,

 

Christer

 

 

 

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: 27. syyskuuta 2011 18:06
To: Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE = for RTC calls)

Let's see:

4.1.4. Choosing Default Candidates

A candidate is said to be default if it would be the target of media
from a non-ICE peer; that target is called the DEFAULT DESTINATION.
If the default candidates are not selected by the ICE algorithm when
communicating with an ICE-aware peer, an updated offer/answer will = be
required after ICE processing completes in order to "fix up" = the SDP
so that the default destination for media matches the candidates
selected by ICE. If ICE happens to select the default candidates, no
updated offer/answer is required.

An agent MUST choose a set of candidates, one for each component of
each in-use media stream, to be default.

5.1. Verifying ICE Support

If this condition is not met, the agent MUST process the SDP based = on
normal RFC 3264 procedures, without using any of the ICE mechanisms
described in the remainder of this specification...

6.1. Verifying ICE Support

The logic at the offerer is identical to that of the answerer as = described in Section 5.1, with the exception that an offerer would not ever generate a=3Dice-mismatch attributes in an SDP.

My interpretation of this always was that ICE enabled end point MUST = generate an offer that will be understood by a non-ICE end point, properly = process on offer from a non-ICE enabled end point, and properly process an answer = from a non-ICE end point. So if we want RTC to be ICE complaint we should be = able to communicate with non-ICE end points, or define a new specification.
_____________
Roman Shpount

On Tue, Sep 27, 2011 at 4:14 AM, Harald Alvestrand = <harald@alvestrand.no> = wrote:

On 09/26/11 20:48, Roman Shpount = wrote:

You can determine that end point is not behind = symmetric NAT using older STUN specification and list discovered IP as a default = contact address in SDP, if you are not behind NAT, you can list the relayed = address of the TURN server as the default address. If you do this, together with = the offer that lists ICE candidates, you would be able to traverse NAT and = communicate with non-ICE end points.

I think discussion in this thread is not whether ICE needs to be = supported or implemented. I would say that ICE without a doubt should be supported. = It is about changing ICE specification as it stands right now, and force the = RTC end point only to communicate with end points that respond with ICE = compliant answer and complete ICE hand shake. This is actually against the ICE specification as it is defined in RFC 5245, where answerer actually can = refuse to support ICE but still establish a call.

Roman,

Which part of RFC 5245 are you referring to with this statement?

Please describe the sections you think will be invoked when an SDP OFFER contains ICE candidates, the answerer does not want to use ICE, what the = OFFER and ANSWER would look like, and which section of RFC 5245 is invoked = when processing the ANSWER.

Details are good.

               Harald

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

 

------_=_NextPart_001_01CC7D44.18E120A9-- From roman@telurix.com Tue Sep 27 11:35: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 B302621F8F42 for ; Tue, 27 Sep 2011 11:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[AWL=-0.626, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 fhOVLk+K8tjP for ; Tue, 27 Sep 2011 11:35:44 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A892921F8F3E for ; Tue, 27 Sep 2011 11:35:44 -0700 (PDT) Received: by yxt33 with SMTP id 33so6976287yxt.31 for ; Tue, 27 Sep 2011 11:38:30 -0700 (PDT) Received: by 10.236.155.170 with SMTP id j30mr11728664yhk.19.1317148710558; Tue, 27 Sep 2011 11:38:30 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id v28sm34812005yhi.11.2011.09.27.11.38.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 11:38:30 -0700 (PDT) Received: by gyd12 with SMTP id 12so6818964gyd.31 for ; Tue, 27 Sep 2011 11:38:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.33.130 with SMTP id r2mr38401330pbi.71.1317148708087; Tue, 27 Sep 2011 11:38:28 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 27 Sep 2011 11:38:28 -0700 (PDT) In-Reply-To: <4E820825.9090101@skype.net> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> Date: Tue, 27 Sep 2011 14:38:28 -0400 Message-ID: From: Roman Shpount To: Matthew Kaufman Content-Type: multipart/alternative; boundary=bcaec520f611dca6e204adf0941d Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 18:35:45 -0000 --bcaec520f611dca6e204adf0941d Content-Type: text/plain; charset=ISO-8859-1 What about intranet applications that would want to locally call existing IP phones within the same enterprise? Should we force them to go through a media gateway as well or should we allow to overwrite this using a policy? As far as SRTP is concerned, once again we should at least provide a local policy. Otherwise it would be a real problem to test and debug this. _____________ Roman Shpount On Tue, Sep 27, 2011 at 1:30 PM, Matthew Kaufman wrote: > On 9/27/11 10:01 AM, Justin Uberti wrote: > >> Neither Google Voice nor Skype (both fairly popular services) send raw RTP >> directly from the client to a PSTN terminator. >> > > True. > > > I can't speak for Skype, but Google Voice uses a media gateway for the >> quality-related reasons I mentioned earlier. >> > > I can't speak for Skype either, but this is a good guess. > > > >> Since these large-scale services can deploy media gateways, it's clear >> that this is not a significant impediment. >> > > Agree. I'm not at all sure what the argument is that we need > existing-PSTN-gateway-**compatible RTP (without SRTP or ICE). If there is > demand, these gateways will be upgraded to support RTCWeb. If there is not, > service providers can run intermediate gateways. > > Matthew Kaufman > > --bcaec520f611dca6e204adf0941d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What about intranet applications that would want to locally call existing I= P phones within the same enterprise? Should we force them to go through a m= edia gateway as well or should we allow to overwrite this using a policy?
As far as SRTP is concerned, once again we should at least provide a lo= cal policy. Otherwise it would be a real problem to test and debug this._____________
Roman Shpount


On Tue, Sep 27, 2011 at 1:30 PM, Matthew= Kaufman <matthew.kaufman@skype.net> wrote:
On 9/27/11 10:01 AM, Justin Uberti wrote:
Neither Google Voice nor Skype (both fairly popular services) send raw RTP = directly from the client to a PSTN terminator.

True.


I can't speak for Skype, but Google Voice uses a media gateway for the = quality-related reasons I mentioned earlier.

I can't speak for Skype either, but this is a good guess.



Since these large-scale services can deploy media gateways, it's clear = that this is not a significant impediment.

Agree. I'm not at all sure what the argument is that we need existing-P= STN-gateway-compatible RTP (without SRTP or ICE). If there is demand= , these gateways will be upgraded to support RTCWeb. If there is not, servi= ce providers can run intermediate gateways.

Matthew Kaufman


--bcaec520f611dca6e204adf0941d-- From ibc@aliax.net Tue Sep 27 11:50: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 A820121F8ED8 for ; Tue, 27 Sep 2011 11:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnTiuBco2hD4 for ; Tue, 27 Sep 2011 11:50:27 -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 17E3F21F8ED7 for ; Tue, 27 Sep 2011 11:50:27 -0700 (PDT) Received: by vws5 with SMTP id 5so8576862vws.31 for ; Tue, 27 Sep 2011 11:53:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.177 with SMTP id bp17mr7795002vdb.447.1317149593035; Tue, 27 Sep 2011 11:53:13 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 27 Sep 2011 11:53:12 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> Date: Tue, 27 Sep 2011 20:53:12 +0200 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] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 18:50:28 -0000 2011/9/27 Roman Shpount : > What about intranet applications that would want to locally call existing= IP > phones within the same enterprise? Should we force them to go through a > media gateway as well or should we allow to overwrite this using a policy= ? +1 --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Tue Sep 27 11:52: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 4AAAB21F8EC4 for ; Tue, 27 Sep 2011 11:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.101, 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 Hb8nF4MaWpYz for ; Tue, 27 Sep 2011 11:52:31 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5D46021F8EBC for ; Tue, 27 Sep 2011 11:52:31 -0700 (PDT) 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 p8RItmc8016562; Tue, 27 Sep 2011 14:55:48 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Sep 2011 14:55:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC7D46.FD3E5C79" Date: Wed, 28 Sep 2011 00:25:11 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F1120@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Requiring ICE for RTC calls Thread-Index: Acx9RKxdtWZqVlkhRSumcfL0ddw6VwAAQNxw References: <4E80984A.903@skype.net><4E809EE6.2050702@skype.net><2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com><4E820825.9090101@skype.net> From: "Ravindran Parthasarathi" To: "Roman Shpount" , "Matthew Kaufman" X-OriginalArrivalTime: 27 Sep 2011 18:55:16.0549 (UTC) FILETIME=[FEF40750:01CC7D46] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 18:52:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC7D46.FD3E5C79 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roman, =20 RTCWeb application within Enterprise looks the reasonable argument for not mandating ICE & SRTP in RTCWeb browser because Enterprise shall be visualized as single reachable private network with no NAT & SRTP requirement. ICE & SRTP are overhead within Enterprise. =20 In case I understand you correctly, RTCWeb API should provide the mechanism to include ICE & SRTP on the need basis. =20 Thanks Partha =20 =20 =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount Sent: Wednesday, September 28, 2011 12:08 AM To: Matthew Kaufman Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls =20 What about intranet applications that would want to locally call existing IP phones within the same enterprise? Should we force them to go through a media gateway as well or should we allow to overwrite this using a policy? As far as SRTP is concerned, once again we should at least provide a local policy. Otherwise it would be a real problem to test and debug this. _____________ Roman Shpount On Tue, Sep 27, 2011 at 1:30 PM, Matthew Kaufman wrote: On 9/27/11 10:01 AM, Justin Uberti wrote: Neither Google Voice nor Skype (both fairly popular services) send raw RTP directly from the client to a PSTN terminator.=20 =20 True. =20 I can't speak for Skype, but Google Voice uses a media gateway for the quality-related reasons I mentioned earlier. =20 I can't speak for Skype either, but this is a good guess. =20 =09 Since these large-scale services can deploy media gateways, it's clear that this is not a significant impediment. =20 Agree. I'm not at all sure what the argument is that we need existing-PSTN-gateway-compatible RTP (without SRTP or ICE). If there is demand, these gateways will be upgraded to support RTCWeb. If there is not, service providers can run intermediate gateways. Matthew Kaufman =20 ------_=_NextPart_001_01CC7D46.FD3E5C79 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roman,

 

RTCWeb application within Enterprise looks the reasonable argument for not mandating ICE & SRTP in RTCWeb browser =  because Enterprise shall be visualized as single reachable private network with = no NAT & SRTP requirement. ICE & SRTP are overhead within = Enterprise.

 

In case I understand you correctly, RTCWeb API should = provide the mechanism to include ICE & SRTP on the need = basis.

 

Thanks

Partha

 

 

 

From:= rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Roman Shpount
Sent: Wednesday, September 28, 2011 12:08 AM
To: Matthew Kaufman
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Requiring ICE for RTC = calls

 

What about intranet applications that would want to locally call existing IP phones within = the same enterprise? Should we force them to go through a media gateway as well = or should we allow to overwrite this using a policy?

As far as SRTP is concerned, once again we should at least provide a = local policy. Otherwise it would be a real problem to test and debug this.
_____________
Roman Shpount

On Tue, Sep 27, 2011 at 1:30 PM, Matthew Kaufman = <matthew.kaufman@skype.net&g= t; wrote:

On 9/27/11 10:01 AM, Justin Uberti = wrote:

Neither Google Voice nor Skype (both fairly popular services) send raw RTP directly from the client to a PSTN terminator. =

 

True.

 

I can't speak for Skype, but Google Voice uses a = media gateway for the quality-related reasons I mentioned earlier.

 

I can't speak for Skype either, but this is a good = guess.

 


Since these large-scale services can deploy media gateways, it's clear = that this is not a significant impediment.

 

Agree. I'm not at = all sure what the argument is that we need existing-PSTN-gateway-compatible RTP = (without SRTP or ICE). If there is demand, these gateways will be upgraded to support = RTCWeb. If there is not, service providers can run intermediate gateways.

Matthew Kaufman

 

------_=_NextPart_001_01CC7D46.FD3E5C79-- From ekr@rtfm.com Tue Sep 27 11:57: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 38EDE21F8CED for ; Tue, 27 Sep 2011 11:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=0.076, 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 soZmXY1+G2rV for ; Tue, 27 Sep 2011 11:56:59 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D9C2421F8CF4 for ; Tue, 27 Sep 2011 11:56:58 -0700 (PDT) Received: by wyh21 with SMTP id 21so6059749wyh.31 for ; Tue, 27 Sep 2011 11:59:44 -0700 (PDT) Received: by 10.227.201.133 with SMTP id fa5mr8097706wbb.91.1317149984352; Tue, 27 Sep 2011 11:59:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.196.83 with HTTP; Tue, 27 Sep 2011 11:59:04 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F1120@sonusinmail02.sonusnet.com> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1120@sonusinmail02.sonusnet.com> From: Eric Rescorla Date: Tue, 27 Sep 2011 11:59:04 -0700 Message-ID: To: Ravindran Parthasarathi Content-Type: multipart/alternative; boundary=0015174c40aaeeebb704adf0e052 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 18:57:00 -0000 --0015174c40aaeeebb704adf0e052 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 27, 2011 at 11:55 AM, Ravindran Parthasarathi < pravindran@sonusnet.com> wrote: > Hi Roman,**** > > ** ** > > RTCWeb application within Enterprise looks the reasonable argument for not > mandating ICE & SRTP in RTCWeb browser because Enterprise shall be > visualized as single reachable private network with no NAT & SRTP > requirement. ICE & SRTP are overhead within Enterprise.**** > > Setting aside the question of whether SRTP is useful within an enterprise, remember that ICE is being used here for consent verification as well as NAT traversal. Consent verification is more important, not less, when the user's machine is in an enterprise environment, because failure to verify consent can result in firewall traversal by the attacker. -Ekr > In case I understand you correctly, RTCWeb API should provide the mechanism > to include ICE & SRTP on the need basis.**** > > ** ** > > Thanks**** > > Partha**** > > ** ** > > **** > > ** ** > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Roman Shpount > *Sent:* Wednesday, September 28, 2011 12:08 AM > *To:* Matthew Kaufman > *Cc:* rtcweb@ietf.org > > *Subject:* Re: [rtcweb] Requiring ICE for RTC calls**** > > ** ** > > What about intranet applications that would want to locally call existing > IP phones within the same enterprise? Should we force them to go through a > media gateway as well or should we allow to overwrite this using a policy? > > > As far as SRTP is concerned, once again we should at least provide a local > policy. Otherwise it would be a real problem to test and debug this. > _____________ > Roman Shpount > > **** > > On Tue, Sep 27, 2011 at 1:30 PM, Matthew Kaufman < > matthew.kaufman@skype.net> wrote:**** > > On 9/27/11 10:01 AM, Justin Uberti wrote:**** > > Neither Google Voice nor Skype (both fairly popular services) send raw RTP > directly from the client to a PSTN terminator. **** > > ** ** > > True.**** > > ** ** > > I can't speak for Skype, but Google Voice uses a media gateway for the > quality-related reasons I mentioned earlier.**** > > ** ** > > I can't speak for Skype either, but this is a good guess.**** > > ** ** > > > Since these large-scale services can deploy media gateways, it's clear that > this is not a significant impediment.**** > > ** ** > > Agree. I'm not at all sure what the argument is that we need > existing-PSTN-gateway-compatible RTP (without SRTP or ICE). If there is > demand, these gateways will be upgraded to support RTCWeb. If there is not, > service providers can run intermediate gateways. > > Matthew Kaufman**** > > ** ** > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --0015174c40aaeeebb704adf0e052 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Sep 27, 2011 at 11:55 AM, Ravind= ran Parthasarathi <pravindran@sonusnet.com> wrote:

Hi Ro= man,

=A0

RTCWe= b application within Enterprise looks the reasonable argument for not mandating ICE & SRTP in RTCWeb browser =A0because Enterprise shall be visualized as single reachable private network with no = NAT & SRTP requirement. ICE & SRTP are overhead within Enterprise.


Set= ting aside the question of whether SRTP is useful within an enterprise,=A0<= /div>
remember that ICE is being used here for consent verification as = well
as NAT traversal. Consent verification is more important, not less,
when the user's machine is in an enterprise environment, becaus= e
failure to verify consent can result in firewall traversal by t= he attacker.

-Ekr

=A0

In ca= se I understand you correctly, RTCWeb API should provide the mechanism to include ICE & SRTP on the need basis.

=A0

Thank= s

Parth= a

=A0

=A0

=A0

From:= rtcweb-bounces= @ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: Wednesday, September 28, 2011 12:08 AM
To: Matthew Kaufman
Cc: rtcweb@ietf= .org


Subject: Re: [rtcweb] Requiring ICE for RTC calls

=A0

What about intranet applications that would want to locally call existing IP phones within the = same enterprise? Should we force them to go through a media gateway as well or should we allow to overwrite this using a policy?



As far as SRTP is concerned, once again we should at least provide a local policy. Otherwise it would be a real problem to test and debug this.
_____________
Roman Shpount

On Tue, Sep 27, 2011 at 1:30 PM, Matthew Kaufman <= ;matthew.kau= fman@skype.net> wrote:

On 9/27/11 10:01 AM, Justin Uberti wrote:<= /u>

Neither Google Voice nor Skype (both fairly popular services) send raw RTP directly from the client to a PSTN terminator.

=A0

True.

=A0

I can't speak for Skype, but Google Voice uses a= media gateway for the quality-related reasons I mentioned earlier.

=A0

I can't speak for Skype either, but this is a go= od guess.

=A0


Since these large-scale services can deploy media gateways, it's clear = that this is not a significant impediment.

=A0

Agree. I'm not at= all sure what the argument is that we need existing-PSTN-gateway-compatible RTP (without = SRTP or ICE). If there is demand, these gateways will be upgraded to support RTC= Web. If there is not, service providers can run intermediate gateways.

Matthew Kaufman

=A0


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


--0015174c40aaeeebb704adf0e052-- From bernard_aboba@hotmail.com Tue Sep 27 11:57: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 D1C2621F8D22 for ; Tue, 27 Sep 2011 11:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.722 X-Spam-Level: X-Spam-Status: No, score=-101.722 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zddxn0Fnj55t for ; Tue, 27 Sep 2011 11:57:11 -0700 (PDT) Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by ietfa.amsl.com (Postfix) with ESMTP id F2B3C21F8C8E for ; Tue, 27 Sep 2011 11:57:10 -0700 (PDT) Received: from BLU152-W39 ([65.55.111.71]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Sep 2011 11:59:56 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_f4437325-14ed-4b27-a145-b79a3fcd84a3_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: Date: Tue, 27 Sep 2011 11:59:55 -0700 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 27 Sep 2011 18:59:56.0462 (UTC) FILETIME=[A5CB5CE0:01CC7D47] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB and emergency services X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 18:57:12 -0000 --_f4437325-14ed-4b27-a145-b79a3fcd84a3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It should therefore be understood that the burden for implementation of eme= rgency services falls principally upon the operator of the service=2C and t= hat the role of the RTCWEB implementer is to deliver basic capabilities and= to enable an operator to add to this functionality=2C rather than providin= g for every possible need natively ("I want a pony"). =20 Ted Hardie said: "Do I understand you correctly to be saying "The emergency service must sta= nd up an RTCWEB server which provides downloadable javascript applications= =2C rather than presuming that other javascript applications provide this f= unctionality."? " [BA] I'm saying that the provider of the RTCWEB service is ultimately respo= nsible for satisfying the regulatory requirements=2C which may vary by the = location and functionality of the service. If they utilize Javascript li= braries=2C they need to make sure that those libraries can provide the requ= ired functionality. For example=2C there are various location libraries th= at support the W3C Location APIs as well as potentially other Location APIs= . However=2C in general those libraries and underlying services were built= to provide "Location Based Services" and not a "Location Information Servi= ce" in the sense that the term is used in IETF=2C NENA and other emergency = services specifications. However=2C there may be other libraries that *ar= e* built to support emergency services (e.g. a library that supports HELD).= Also=2C there may be APIs available (such as the WebAPI proposed by Moz= illa=2C see http://hacks.mozilla.org/2011/08/introducing-webapi/) that can = enable an HTML5 application to access the underlying telephony capabilities= of the device on which the browser runs (e.g. a mobile handset that is cap= able of making emergency calls with location). The service provider needs= to understand their responsibilities and utilize the right APIs and librar= ies to satisfy them. =20 --------------------------------------- While in the long-term it may be possible to close the gaps=2C in the shor= t term the gaps may be addressed via Javascript libraries implementing elem= ents of the ECRIT=20 architecture such as HELD=2C or even LoST. =20 Ted Hardie also said: "It doesn't make sense to use LoST alone in the case you've described=2C at= least if I understood you. LoST takes a desired service and a location as= inputs and discovers the service provider associated with that location. = If we're presuming that someone starts at a particular server=2C LoST must = run prior to reaching that server. So you'd need some sort of libraries pr= ovided prior to that server being reached to run LoST. If you start from a= known server that provides javascript libraries for discovering location (= by pulling from DHCP or HELD=2C for example) and running LoST=2C you could = then get to the Emergency Service Provider's RTCWEB server=2C but it would = be pretty fragile." [BA] Richard Barnes has been developing an ECRIT client that runs in the br= owser=2C so I suspect he will have some observations on how LoST functional= ity could be provided. My main point was that just because something is a = requirement in ECRIT PhoneBCP doesn't necessarily imply that it needs to be= provided natively in the browser. Before making that determination we nee= d to understand if the functionality could be viably provided another way -= - such as in Javascript=2C via a plugin=2C or maybe even via server-side fu= nctionality. =20 = --_f4437325-14ed-4b27-a145-b79a3fcd84a3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


It should therefore be understood that the burden for implementation of= emergency services falls principally upon the operator of the service=2C a= nd that the role of the RTCWEB implementer is to deliver basic capabilities= and to enable an operator to add to this functionality=2C rather than prov= iding for every possible need natively ("I want a pony"). =3B =3B <= br>

Ted Hardie said:
"Do I understand you correctly to be saying "The emergency service mus= t stand up an RTCWEB server which provides downloadable javascript applicat= ions=2C rather than presuming that other javascript applications provide th= is functionality."? "

[BA] I'm saying that the provider of the RTCWE= B service is ultimately responsible for satisfying the regulatory requireme= nts=2C which may vary by the location and functionality of the service.&nbs= p=3B =3B =3B If they utilize Javascript libraries=2C they need to m= ake sure that those libraries can provide the required functionality. = =3B For example=2C there are various location libraries that support the W3= C Location APIs as well as potentially other Location APIs. =3B However= =2C in general those libraries and underlying services were built to provid= e "Location Based Services" and not a "Location Information Service" in the= sense that the term is used in IETF=2C NENA and other emergency services s= pecifications.  =3B However=2C there may be other libraries that *are* = built to support emergency services (e.g. a library that supports HELD).&nb= sp=3B =3B =3B Also=2C there may be APIs available (such as the WebA= PI proposed by Mozilla=2C see http://hacks.mozilla.org/2011/08/introducing-= webapi/) that can enable an HTML5 application to access the underlying tele= phony capabilities of the device on which the browser runs (e.g. a mobile h= andset that is capable of making emergency calls with location). =3B&nb= sp=3B The service provider needs to understand their responsibilities and u= tilize the right APIs and libraries to satisfy them. =3B

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

While in the long-term it may be p= ossible to close the gaps=2C =3B in the short term the gaps may be addr= essed via Javascript libraries implementing elements of the ECRIT=20 architecture such as HELD=2C or even LoST. =3B =3B


Ted Hard= ie also said:

"It doesn't make sense to use LoST alone in the case y= ou've described=2C at least if I understood you. =3B LoST takes a desir= ed service and a location as inputs and discovers the service provider asso= ciated with that location. =3B If we're presuming that someone starts a= t a particular server=2C LoST must run prior to reaching that server. = =3B So you'd need some sort of libraries provided prior to that server bein= g reached to run LoST. =3B If you start from a known server that provid= es javascript libraries for discovering location (by pulling from DHCP or H= ELD=2C for example) and running LoST=2C you could then get to the Emergency= Service Provider's RTCWEB server=2C but it would be pretty fragile."
[BA] Richard Barnes has been developing an ECRIT client that runs in the = browser=2C so I suspect he will have some observations on how LoST function= ality could be provided. =3B My main point was that just because someth= ing is a requirement in ECRIT PhoneBCP doesn't necessarily imply that it ne= eds to be provided natively in the browser. =3B Before making that dete= rmination we need to understand if the functionality could be viably provid= ed another way -- such as in Javascript=2C via a plugin=2C or maybe even vi= a server-side functionality.  =3B =3B

=
= --_f4437325-14ed-4b27-a145-b79a3fcd84a3_-- From harald@alvestrand.no Tue Sep 27 12:02: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 DD09221F8AF5 for ; Tue, 27 Sep 2011 12:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.425 X-Spam-Level: X-Spam-Status: No, score=-109.425 tagged_above=-999 required=5 tests=[AWL=0.874, 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 2tbDUC8Y3QKI for ; Tue, 27 Sep 2011 12:02:14 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4924121F8B81 for ; Tue, 27 Sep 2011 12:01:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BF09239E0CD; Tue, 27 Sep 2011 21:04:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEuTeNqseb4c; Tue, 27 Sep 2011 21:04:39 +0200 (CEST) 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 3348B39E051; Tue, 27 Sep 2011 21:04:39 +0200 (CEST) Message-ID: <4E821E47.4080205@alvestrand.no> Date: Tue, 27 Sep 2011 21:04:39 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: rtcweb@ietf.org Subject: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 19:02:15 -0000 The current assumption is that browsers will get Javascript from multiple sources, some of which will be malicious. Malicious sources cannot be allowed to initiate sessions without ICE, for all the reasons given in the "security" I-D. Before we can even consider relaxing the ICE requirement, we need to see a trust model formulated for who gets to decide, for a particular piece of Javascript, if it's allowed to operate within a relaxed trust model. So far, I have seen no such proposals. Can you who argue for this solution please go away and write a draft that describes one, instead of repeating "+1" without any new solutions? On 09/27/2011 08:53 PM, Iñaki Baz Castillo wrote: > 2011/9/27 Roman Shpount: >> What about intranet applications that would want to locally call existing IP >> phones within the same enterprise? Should we force them to go through a >> media gateway as well or should we allow to overwrite this using a policy? > +1 > From ted.ietf@gmail.com Tue Sep 27 12:22: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 59F6121F8C18 for ; Tue, 27 Sep 2011 12:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=-0.540, 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 Iow3zi+giJaU for ; Tue, 27 Sep 2011 12:22:05 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 24A5D21F8BF7 for ; Tue, 27 Sep 2011 12:21:51 -0700 (PDT) Received: by yxt33 with SMTP id 33so7023915yxt.31 for ; Tue, 27 Sep 2011 12:24:37 -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=IpRMaSlQ637Jk7BPrWtLOer8XTPYexquhhKnVbG6j20=; b=U4qMOqI2bd0IPtjBa6FdmPRpXDRHSxp8j5o1j0qG/zFA8V8X5vZfMdh0VSbsOABwut NVUS7GumnslkiSYamNH/XxGFmX2BTBJ5zXsLJRXzaTJUZoCFPxjk3HHWceYpK4OKmO6g gM3CF0zRolkp4XyHnxS7VyJVlaTjm8NADGMKI= MIME-Version: 1.0 Received: by 10.236.127.144 with SMTP id d16mr16331794yhi.40.1317151477269; Tue, 27 Sep 2011 12:24:37 -0700 (PDT) Received: by 10.236.108.35 with HTTP; Tue, 27 Sep 2011 12:24:37 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Sep 2011 12:24:37 -0700 Message-ID: From: Ted Hardie To: Bernard Aboba Content-Type: multipart/alternative; boundary=20cf3010e3c5eb046404adf139ca Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB and emergency services X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 19:22:06 -0000 --20cf3010e3c5eb046404adf139ca Content-Type: text/plain; charset=ISO-8859-1 In-line. On Tue, Sep 27, 2011 at 11:59 AM, Bernard Aboba wrote: > > > It should therefore be understood that the burden for implementation of > emergency services falls principally upon the operator of the service, and > that the role of the RTCWEB implementer is to deliver basic capabilities and > to enable an operator to add to this functionality, rather than providing > for every possible need natively ("I want a pony"). > > > Ted Hardie said: > > "Do I understand you correctly to be saying "The emergency service must > stand up an RTCWEB server which provides downloadable javascript > applications, rather than presuming that other javascript applications > provide this functionality."? " > > [BA] I'm saying that the provider of the RTCWEB service > I think where we diverged was in my interpretation of your statement "operator of the service"; I assumed you meant emergence service. You, however, are seeing RTC Web sites as if it they provide a voice service. Speaking personally, I don't think that is the right model. I can see an emergency service provider providing an RTCWeb service as part of its efforts, just as it may accept IMs, text messages, and other non-traditional communications. But assuming that any provider of an RTCWeb application must provide a method to reach emergency services does not make sense to me. It takes the "voice is a service" vs. "voice is an application" discussion back a dozen years. Downloaded javascript from a system presumed to be malicious is not how you want to make your 911/112 calls. Imagine the poker site example. Can the poker site require that emergency services folks have a login to its system in monitor state in order to provide this service? Probably not even for one jurisdiction, much less many. The only other way to accomplish that in a closed-system approach like the poker site is to have every site have a gateway capable of reaching emergency services, and a break-out method to "dial an emergency number". Even this will fail for sites that provide rendezvous but do not remain part of the calling infrastructure post facto. In the dating site example, two members may initiate calling via a web site. Once the peer-to-peer flows are set-up, they can continue chatting *even if they lose reachability to the rendezvous web site*. Unlike the poker site, there is no necessary access to the rest of the application. Despite our re-use, it is vitally important to remember that these applications are not phones. I could set up a WebRTC applications called "Subtitle" (after the old improv game) in which I get video from one player and audio from another in order to mash them up and show the results to a third parties. There would not necessarily even be a facility in such an application to get audio and video from the same party--since that would be contrary to the point of the game. If you must describe in the terms of telephony, please circumscribe your terms--"For RTCWeb applications intended to provide telephony services, the following considerations apply...." But generalizing the whole application space to telephony, even for the benefit of emergency services, is not where I think we ought to go. Speaking personally and without hats, Ted > is ultimately responsible for satisfying the regulatory requirements, which > may vary by the location and functionality of the service. If they > utilize Javascript libraries, they need to make sure that those libraries > can provide the required functionality. For example, there are various > location libraries that support the W3C Location APIs as well as potentially > other Location APIs. However, in general those libraries and underlying > services were built to provide "Location Based Services" and not a "Location > Information Service" in the sense that the term is used in IETF, NENA and > other emergency services specifications. However, there may be other > libraries that *are* built to support emergency services (e.g. a library > that supports HELD). Also, there may be APIs available (such as the > WebAPI proposed by Mozilla, see > http://hacks.mozilla.org/2011/08/introducing-webapi/) that can enable an > HTML5 application to access the underlying telephony capabilities of the > device on which the browser runs (e.g. a mobile handset that is capable of > making emergency calls with location). The service provider needs to > understand their responsibilities and utilize the right APIs and libraries > to satisfy them. > > --------------------------------------- > > > While in the long-term it may be possible to close the gaps, in the short > term the gaps may be addressed via Javascript libraries implementing > elements of the ECRIT architecture such as HELD, or even LoST. > > > Ted Hardie also said: > > "It doesn't make sense to use LoST alone in the case you've described, at > least if I understood you. LoST takes a desired service and a location as > inputs and discovers the service provider associated with that location. If > we're presuming that someone starts at a particular server, LoST must run > prior to reaching that server. So you'd need some sort of libraries > provided prior to that server being reached to run LoST. If you start from > a known server that provides javascript libraries for discovering location > (by pulling from DHCP or HELD, for example) and running LoST, you could then > get to the Emergency Service Provider's RTCWEB server, but it would be > pretty fragile." > > [BA] Richard Barnes has been developing an ECRIT client that runs in the > browser, so I suspect he will have some observations on how LoST > functionality could be provided. My main point was that just because > something is a requirement in ECRIT PhoneBCP doesn't necessarily imply that > it needs to be provided natively in the browser. Before making that > determination we need to understand if the functionality could be viably > provided another way -- such as in Javascript, via a plugin, or maybe even > via server-side functionality. > > --20cf3010e3c5eb046404adf139ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In-line.

On Tue, Sep 27, 2011 at 11:59 AM, Bernard Aboba <bernard_aboba@hot= mail.com> wrote:


It should therefore be understood that the burden for implementation of= emergency services falls principally upon the operator of the service, and= that the role of the RTCWEB implementer is to deliver basic capabilities a= nd to enable an operator to add to this functionality, rather than providin= g for every possible need natively ("I want a pony").=A0=A0


Ted Hardie said:

"Do I understand you correctly to be sayi= ng "The emergency service must stand up an RTCWEB server which provide= s downloadable javascript applications, rather than presuming that other ja= vascript applications provide this functionality."? "

[BA] I'm saying that the provider of the RTCWEB service

I think where we diverged wa= s in my interpretation of your statement "operator of the service"= ;; I assumed you meant emergence service.=A0 You, however, are seeing RTC W= eb sites as if it they provide a voice service.

Speaking personally, I don't think that is the right model.=A0 I ca= n see an emergency service provider providing an RTCWeb service as part of = its efforts, just as it may accept IMs, text messages, and other non-tradit= ional communications.=A0 But assuming that any provider of an RTCWeb applic= ation must provide a method to reach emergency services does not make sense= to me.=A0=A0 It takes the "voice is a service" vs. "voice i= s an application" discussion back a dozen years.=A0 Downloaded javascr= ipt from a system presumed to be malicious is not how you want to make your= 911/112 calls.

Imagine the poker site example.=A0 Can the poker site require that emer= gency services folks have a login to its system in monitor state in order t= o provide this service?=A0 Probably not even for one jurisdiction, much les= s many. =A0 The only other way to accomplish that in a closed-system approa= ch like the poker site is to have every site have a gateway capable of reac= hing emergency services, and a break-out method to "dial an emergency = number".

Even this will fail for sites that provide rendezvous but do not remain= part of the calling infrastructure post facto.=A0 In the dating site examp= le, two members may initiate calling via a web site.=A0 Once the peer-to-pe= er flows are set-up, they can continue chatting *even if they lose reachabi= lity to the rendezvous web site*.=A0=A0 Unlike the poker site, there is no = necessary access to the rest of the application.

Despite our re-use, it is vitally important to remember that these appl= ications are not phones.=A0 I could set up a WebRTC applications called &qu= ot;Subtitle" (after the old improv game) in which I get video from one= player and audio from another in order to mash them up and show the result= s to a third parties.=A0 There would not necessarily even be a facility in = such an application to get audio and video from the same party--since that = would be contrary to the point of the game.

If you must describe in the terms of telephony, please circumscribe you= r terms--"For RTCWeb applications intended to provide telephony servic= es, the following considerations apply...."=A0 But generalizing the wh= ole application space to telephony, even for the benefit of emergency servi= ces, is not where I think we ought to go.

Speaking personally and without hats,

Ted

=A0
<= div>
is ultimately responsible for satisfying the regulato= ry requirements, which may vary by the location and functionality of the se= rvice.=A0=A0=A0 If they utilize Javascript libraries, they need to make sur= e that those libraries can provide the required functionality.=A0 For examp= le, there are various location libraries that support the W3C Location APIs= as well as potentially other Location APIs.=A0 However, in general those l= ibraries and underlying services were built to provide "Location Based= Services" and not a "Location Information Service" in the s= ense that the term is used in IETF, NENA and other emergency services speci= fications. =A0 However, there may be other libraries that *are* built to su= pport emergency services (e.g. a library that supports HELD).=A0=A0=A0 Also= , there may be APIs available (such as the WebAPI proposed by Mozilla, see = http://hacks.mozilla.org/2011/08/introducing-webapi/) that can = enable an HTML5 application to access the underlying telephony capabilities= of the device on which the browser runs (e.g. a mobile handset that is cap= able of making emergency calls with location).=A0=A0 The service provider n= eeds to understand their responsibilities and utilize the right APIs and li= braries to satisfy them.=A0

---------------------------------------


While = in the long-term it may be possible to close the gaps,=A0 in the short term= the gaps may be addressed via Javascript libraries implementing elements o= f the ECRIT=20 architecture such as HELD, or even LoST.=A0=A0


Ted Hardi= e also said:

"It doesn't make sense to use LoST alone in th= e case you've described, at least if I understood you.=A0 LoST takes a = desired service and a location as inputs and discovers the service provider= associated with that location.=A0 If we're presuming that someone star= ts at a particular server, LoST must run prior to reaching that server.=A0 = So you'd need some sort of libraries provided prior to that server bein= g reached to run LoST.=A0 If you start from a known server that provides ja= vascript libraries for discovering location (by pulling from DHCP or HELD, = for example) and running LoST, you could then get to the Emergency Service = Provider's RTCWEB server, but it would be pretty fragile."

[BA] Richard Barnes has been developing an ECRIT client that runs= in the browser, so I suspect he will have some observations on how LoST fu= nctionality could be provided.=A0 My main point was that just because somet= hing is a requirement in ECRIT PhoneBCP doesn't necessarily imply that = it needs to be provided natively in the browser.=A0 Before making that dete= rmination we need to understand if the functionality could be viably provid= ed another way -- such as in Javascript, via a plugin, or maybe even via se= rver-side functionality. =A0=A0


--20cf3010e3c5eb046404adf139ca-- From ibc@aliax.net Tue Sep 27 12:45: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 436DE21F8FF2 for ; Tue, 27 Sep 2011 12:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOgB3pBiUOXl for ; Tue, 27 Sep 2011 12:45:33 -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 A2A4021F8FEB for ; Tue, 27 Sep 2011 12:45:33 -0700 (PDT) Received: by vws5 with SMTP id 5so8643356vws.31 for ; Tue, 27 Sep 2011 12:48:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.23.4 with SMTP id i4mr7782450vdf.514.1317152899468; Tue, 27 Sep 2011 12:48:19 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 27 Sep 2011 12:48:19 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Sep 2011 21:48:19 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB and emergency services X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 19:45:34 -0000 2011/9/27 Ted Hardie : > If you must describe in the terms of telephony, please circumscribe your > terms--"For RTCWeb applications intended to provide telephony services, t= he > following considerations apply...."=C2=A0 But generalizing the whole appl= ication > space to telephony, even for the benefit of emergency services, is not wh= ere > I think we ought to go. I agree. I don't know where this topic comes from, but IMHO it makes no sense to consider a WebRTC provider a "usual" PSTN operator. It would be a show-stopper. --=20 I=C3=B1aki Baz Castillo From oej@edvina.net Tue Sep 27 13:01: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 CC52321F8F35 for ; Tue, 27 Sep 2011 13:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHLgUEPsvCuM for ; Tue, 27 Sep 2011 13:01:35 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 4707E21F8F30 for ; Tue, 27 Sep 2011 13:01:35 -0700 (PDT) Received: from [IPv6:2001:470:1f15:d79:b443:14e6:b6e3:a547] (unknown [IPv6:2001:470:1f15:d79:b443:14e6:b6e3:a547]) by smtp7.webway.se (Postfix) with ESMTPA id E027D754BCE4; Tue, 27 Sep 2011 20:04:17 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_9A722DA3-E5FE-4DC2-912B-8CC9DE73DA24" From: "Olle E. Johansson" In-Reply-To: Date: Tue, 27 Sep 2011 22:04:37 +0200 Message-Id: <69C442D8-0B6E-4EC8-814E-52CDC8DB578B@edvina.net> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <84254826-C357-4FB5-810D-C453A2D1304C@phonefromhere.com> To: Roman Shpount X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 20:01:35 -0000 --Apple-Mail=_9A722DA3-E5FE-4DC2-912B-8CC9DE73DA24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 27 sep 2011 kl. 18:08 skrev Roman Shpount: > What I meant that by supporting SIP/G.711 we get an a existing, cost = effective way to access 5 billion wireless subscribers, as well as 500M = Skype subscribers, millions of corporate customers. Calling using = SIP/G.711 through a SIP trunk provider is not only about wireline PSTN, = it is about a much larger universe of people. Well, when SIP was developed you could have argued that there are = millions of users that can only be reached by using ISDN - so why = disregard this user base and invent something that did not interop = properly? Sometimes we need to move forward. After many years of insecure calls = having issues with traversing NATs everywhere, I think enough is enough = and it's time to provide a better solution. /O= --Apple-Mail=_9A722DA3-E5FE-4DC2-912B-8CC9DE73DA24 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
What I meant = that by supporting SIP/G.711 we get an a existing, cost effective way to = access 5 billion wireless subscribers, as well as 500M Skype = subscribers, millions of corporate customers. Calling using SIP/G.711 = through a SIP trunk provider is not only about wireline PSTN, it is = about a much larger universe of = people.

Well, when SIP was developed = you could have argued that there are millions of users that can only be = reached by using ISDN - so why disregard this user base and invent = something that did not interop = properly?

Sometimes we need to move forward. = After many years of insecure calls having issues with traversing NATs = everywhere, I think enough is enough and it's time to provide a better = solution.

/O
= --Apple-Mail=_9A722DA3-E5FE-4DC2-912B-8CC9DE73DA24-- From ibc@aliax.net Tue Sep 27 13:02: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 AE98621F8F6D for ; Tue, 27 Sep 2011 13:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=-0.259, 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 Z7IdbFVgMFZV for ; Tue, 27 Sep 2011 13:02:26 -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 B8B0721F8F6B for ; Tue, 27 Sep 2011 13:02:26 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so5726387vcb.31 for ; Tue, 27 Sep 2011 13:05:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.120.12 with SMTP id b12mr2378003vcr.111.1317153912632; Tue, 27 Sep 2011 13:05:12 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 27 Sep 2011 13:05:12 -0700 (PDT) In-Reply-To: <4E821E47.4080205@alvestrand.no> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> Date: Tue, 27 Sep 2011 22:05:12 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 20:02:27 -0000 2011/9/27 Harald Alvestrand : > The current assumption is that browsers will get Javascript from multiple > sources, some of which will be malicious. Malicious sources cannot be > allowed to initiate sessions without ICE, for all the reasons given in th= e > "security" I-D. > > Before we can even consider relaxing the ICE requirement, we need to see = a > trust model formulated for who gets to decide, for a particular piece of > Javascript, if it's allowed to operate within a relaxed trust model. > > So far, I have seen no such proposals. Can you who argue for this solutio= n > please go away and write a draft that describes one, instead of repeating > "+1" without any new solutions? Hi Harald. Don't take me wrong, I understand the security requeriments and I agree with them. But I think that it would be a bit sad that WebRTC model cannot interoperate with most of the current SIP deployments. Anyhow, I also think that this is the price that people involved in SIP must pay for our laziness implementing security specifications *already* standarized for SIP and RTP protocols. The fact is that SIP is mostly deployed in the following scenarios: - In local networks with an internal SIP PBX and SIP phones. - In SIP-PSTN SIP providers. - In operators internal infrastructure and intercommunication with other operators. All these scenarios can be considered "trusted" (more or less) as the user does never talk SIP with an external unknown user. So they are mostly "wallen gardens". Of course this is not the case in pure Internet in which most of the WebRTC deployments will exist, so I agree that security is more important than compatibility with legacy SIP networks, even more when those legacy SIP networks have no cared about security. Anyhow, I still think that local policy (rather than mandating SRTP+ICE in the spec) could make sense. As I've said in some other thread, a malicious provider could invite the user (the web visitor) to make a call to some "number" or "destination" controlled by the malicious provider. The destination could implement SRTP+ICE so the communication "seems secure", but nothing prevents the malicious provider to record the video session and upload it to Youtube. It's more or less than expecting that HTTPS solves Phishing problem in the web (it does not). In the same way, web browsers could come pre-configured with an enabled checkbox: [X] don't allow unsecure calls The user could disable such checkbox. Anyhow, when a call is being established and the WebRTC stack realizes that the peer does not support ICE and/or SRTP, it could warn the user by showing something like a pop-up ("This call is not secure"), also providing a button "Don't show again for this site". I don't know if this could be enough. Regards. --=20 I=C3=B1aki Baz Castillo From oej@edvina.net Tue Sep 27 13:07: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 69DAA21F8FB8 for ; Tue, 27 Sep 2011 13:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xF35+vZ1gHG1 for ; Tue, 27 Sep 2011 13:07:25 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 0D72121F8F9B for ; Tue, 27 Sep 2011 13:07:23 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id EAD7B754BCE4; Tue, 27 Sep 2011 20:10:07 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_77799375-F79F-408D-B372-32C96E7806DC" From: "Olle E. Johansson" In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F1120@sonusinmail02.sonusnet.com> Date: Tue, 27 Sep 2011 22:10:28 +0200 Message-Id: References: <4E80984A.903@skype.net><4E809EE6.2050702@skype.net><2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com><4E820825.9090101@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1120@sonusinmail02.sonusnet.com> To: "Ravindran Parthasarathi" X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 20:07:26 -0000 --Apple-Mail=_77799375-F79F-408D-B372-32C96E7806DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 27 sep 2011 kl. 20:55 skrev Ravindran Parthasarathi: > Hi Roman, > =20 > RTCWeb application within Enterprise looks the reasonable argument for = not mandating ICE & SRTP in RTCWeb browser because Enterprise shall be = visualized as single reachable private network with no NAT & SRTP = requirement. ICE & SRTP are overhead within Enterprise. We need to consider the dual stack need for ICE as well. It's not only = NAT. And this may happen within the enterprise. /O > =20 > In case I understand you correctly, RTCWeb API should provide the = mechanism to include ICE & SRTP on the need basis. > =20 > Thanks > Partha > =20 > =20 > =20 > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Roman Shpount > Sent: Wednesday, September 28, 2011 12:08 AM > To: Matthew Kaufman > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Requiring ICE for RTC calls > =20 > What about intranet applications that would want to locally call = existing IP phones within the same enterprise? Should we force them to = go through a media gateway as well or should we allow to overwrite this = using a policy? >=20 > As far as SRTP is concerned, once again we should at least provide a = local policy. Otherwise it would be a real problem to test and debug = this. > _____________ > Roman Shpount >=20 >=20 > On Tue, Sep 27, 2011 at 1:30 PM, Matthew Kaufman = wrote: > On 9/27/11 10:01 AM, Justin Uberti wrote: > Neither Google Voice nor Skype (both fairly popular services) send raw = RTP directly from the client to a PSTN terminator. > =20 > True. > =20 >=20 > I can't speak for Skype, but Google Voice uses a media gateway for the = quality-related reasons I mentioned earlier. > =20 > I can't speak for Skype either, but this is a good guess. > =20 >=20 >=20 > Since these large-scale services can deploy media gateways, it's clear = that this is not a significant impediment. > =20 > Agree. I'm not at all sure what the argument is that we need = existing-PSTN-gateway-compatible RTP (without SRTP or ICE). If there is = demand, these gateways will be upgraded to support RTCWeb. If there is = not, service providers can run intermediate gateways. >=20 > Matthew Kaufman >=20 > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden --Apple-Mail=_77799375-F79F-408D-B372-32C96E7806DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
27 sep 2011 kl. 20:55 skrev Ravindran = Parthasarathi:

Hi = Roman,
In = case I understand you correctly, RTCWeb API should provide the mechanism = to include ICE & SRTP on the need basis.
 rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.o= rg] On Behalf = Of Roman = Shpount
Sent: Wednesday, September 28, = 2011 12:08 AM
To: Matthew = Kaufman
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Requiring ICE = for RTC calls
What about = intranet applications that would want to locally call existing IP phones = within the same enterprise? Should we force them to go through a media = gateway as well or should we allow to overwrite this using a = policy?

As far as SRTP is concerned, once again we should at = least provide a local policy. Otherwise it would be a real problem to = test and debug this.
_____________
Roman = Shpount

 

* Cell phone = +46 70 593 68 51, Office +46 8 96 40 20, Sweden



= --Apple-Mail=_77799375-F79F-408D-B372-32C96E7806DC-- From ibc@aliax.net Tue Sep 27 13:24: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 CD3C921F9029 for ; Tue, 27 Sep 2011 13:24:44 -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 Bp7CDk3kGg2T for ; Tue, 27 Sep 2011 13:24:44 -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 EC9F821F902B for ; Tue, 27 Sep 2011 13:24:43 -0700 (PDT) Received: by vws5 with SMTP id 5so8689010vws.31 for ; Tue, 27 Sep 2011 13:27:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.177 with SMTP id bp17mr7888055vdb.447.1317155249977; Tue, 27 Sep 2011 13:27:29 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Tue, 27 Sep 2011 13:27:29 -0700 (PDT) In-Reply-To: <69C442D8-0B6E-4EC8-814E-52CDC8DB578B@edvina.net> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <84254826-C357-4FB5-810D-C453A2D1304C@phonefromhere.com> <69C442D8-0B6E-4EC8-814E-52CDC8DB578B@edvina.net> Date: Tue, 27 Sep 2011 22:27:29 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 20:24:45 -0000 2011/9/27 Olle E. Johansson : > Sometimes we need to move forward. After many years of insecure calls hav= ing > issues with traversing NATs everywhere, I think enough is enough and it's > time to provide a better solution. I also agree. The IETF has produced lot of security specifications for SIP but vendors have implemented nothing (or just a few of them). SIP is mostly deployed in islands, and each island defines its own security constrains (usually no security at all as the island itself is a secure wallen garden). Rtcweb is like a new island (a very big island), and it will also become the island with major number of malicious users and site providers. So let's add all the security constrains we can in order to make it secure. Legacy SIP vendors/providers/manufactures should react if they want to offer services on top of rtcweb. --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Tue Sep 27 13: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 7A4FD21F8BBB for ; Tue, 27 Sep 2011 13:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.475 X-Spam-Level: X-Spam-Status: No, score=-1.475 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 PotV5-Ys+TwW for ; Tue, 27 Sep 2011 13:49:36 -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 B61AC21F8486 for ; Tue, 27 Sep 2011 13:49:36 -0700 (PDT) Received: by gyd12 with SMTP id 12so6954580gyd.31 for ; Tue, 27 Sep 2011 13:52:23 -0700 (PDT) Received: by 10.68.26.161 with SMTP id m1mr39437058pbg.82.1317156742693; Tue, 27 Sep 2011 13:52:22 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by mx.google.com with ESMTPS id ji3sm148851pbc.2.2011.09.27.13.52.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 13:52:22 -0700 (PDT) Received: by pzk37 with SMTP id 37so19535068pzk.9 for ; Tue, 27 Sep 2011 13:52:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.4.170 with SMTP id l10mr39110174pbl.3.1317156741274; Tue, 27 Sep 2011 13:52:21 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 27 Sep 2011 13:52:21 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <84254826-C357-4FB5-810D-C453A2D1304C@phonefromhere.com> <69C442D8-0B6E-4EC8-814E-52CDC8DB578B@edvina.net> Date: Tue, 27 Sep 2011 16:52:21 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=bcaec5215f35ad5b4004adf27377 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 20:49:37 -0000 --bcaec5215f35ad5b4004adf27377 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would reluctantly have to agree that we should by default require ICE, since this is the only way to work around the security problems associated with SIP. I am not sure SRTP has to be required but if ICE is required, SRT= P is an easy requirement to satisfy (if you are putting a media proxy or an SBC upgrade for one feature, you might as well place it for two). I still think there should be a way to disable requiring ICE and SRTP through a local policy, but I am not sure this should be a requirement. I guess what = I am saying that requiring ICE and SRTP should be a SHOULD and not a MUST. _____________ Roman Shpount On Tue, Sep 27, 2011 at 4:27 PM, I=F1aki Baz Castillo wrote= : > 2011/9/27 Olle E. Johansson : > > Sometimes we need to move forward. After many years of insecure calls > having > > issues with traversing NATs everywhere, I think enough is enough and it= 's > > time to provide a better solution. > > I also agree. The IETF has produced lot of security specifications for > SIP but vendors have implemented nothing (or just a few of them). > > SIP is mostly deployed in islands, and each island defines its own > security constrains (usually no security at all as the island itself > is a secure wallen garden). Rtcweb is like a new island (a very big > island), and it will also become the island with major number of > malicious users and site providers. So let's add all the security > constrains we can in order to make it secure. > > Legacy SIP vendors/providers/manufactures should react if they want to > offer services on top of rtcweb. > > -- > I=F1aki Baz Castillo > > --bcaec5215f35ad5b4004adf27377 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would reluctantly have to agree that we should by default require ICE, si= nce this is the only way to work around the security problems associated wi= th SIP. I am not sure SRTP has to be required but if ICE is required, SRTP = is an easy requirement to satisfy (if you are putting a media proxy or an S= BC upgrade for one feature, you might as well place it for two). I still th= ink there should be a way to disable requiring ICE and SRTP through a local= policy, but I am not sure this should be a requirement. I guess what I am = saying that requiring ICE and SRTP should be a SHOULD and not a MUST.
_____________
Roman Shpount


On Tue, Sep 27, 2011 at 4:27 PM, I=F1aki= Baz Castillo <ibc@al= iax.net> wrote:
2011/9/27 Olle E. Johansson <oej@edvin= a.net>:
> Sometimes we need to move forward. After many years = of insecure calls having
> issues with traversing NATs everywhere, I think enough is enough and i= t's
> time to provide a better solution.

I also agree. The IETF has produced lot of security specifications fo= r
SIP but vendors have implemented nothing (or just a few of them).

SIP is mostly deployed in islands, and each island defines its own
security constrains (usually no security at all as the island itself
is a secure wallen garden). Rtcweb is like a new island (a very big
island), and it will also become the island with major number of
malicious users and site providers. So let's add all the security
constrains we can in order to make it secure.

Legacy SIP vendors/providers/manufactures should react if they want to
offer services on top of rtcweb.

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

--bcaec5215f35ad5b4004adf27377-- From tim@phonefromhere.com Tue Sep 27 13:54: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 B957221F8F22 for ; Tue, 27 Sep 2011 13:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 rlOSd+t57WoQ for ; Tue, 27 Sep 2011 13:54:20 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 13C0321F8EE5 for ; Tue, 27 Sep 2011 13:54:20 -0700 (PDT) Received: from [192.168.0.103] (udp089063uds.ucsf.edu [169.230.111.60]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 99D2137A902; Tue, 27 Sep 2011 22:09:54 +0100 (BST) References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <84254826-C357-4FB5-810D-C453A2D1304C@phonefromhere.com> <69C442D8-0B6E-4EC8-814E-52CDC8DB578B@edvina.net> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <899FDFD0-F5FD-4C74-8DE9-4484AA131FE1@phonefromhere.com> X-Mailer: iPhone Mail (8J2) From: Tim Panton Date: Tue, 27 Sep 2011 13:56:57 -0700 To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 20:54:20 -0000 Sent from my iPhone On 27 Sep 2011, at 13:27, I=C3=B1aki Baz Castillo wrote: > 2011/9/27 Olle E. Johansson : >> Sometimes we need to move forward. After many years of insecure calls hav= ing >> issues with traversing NATs everywhere, I think enough is enough and it's= >> time to provide a better solution. >=20 > I also agree. The IETF has produced lot of security specifications for > SIP but vendors have implemented nothing (or just a few of them). >=20 > SIP is mostly deployed in islands, and each island defines its own > security constrains (usually no security at all as the island itself > is a secure wallen garden). Rtcweb is like a new island (a very big > island), and it will also become the island with major number of > malicious users and site providers. So let's add all the security > constrains we can in order to make it secure. >=20 > Legacy SIP vendors/providers/manufactures should react if they want to > offer services on top of rtcweb. >=20 > --=20 > I=C3=B1aki Baz Castillo But it is worth remembering that many of those SIP deployments have the phon= es on a separate (V)LAN from which the browsers would be firewalled. So it w= ouldn't be a simple drop in case even if the browser did have a 100% SIP des= kphone emulation.=20 Tim.=20= From ekr@rtfm.com Tue Sep 27 14:53: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 C38A121F8EF9 for ; Tue, 27 Sep 2011 14:53:53 -0700 (PDT) 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.075, 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 FzIsaY1llo59 for ; Tue, 27 Sep 2011 14:53:52 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 84D8A21F8EF6 for ; Tue, 27 Sep 2011 14:53:52 -0700 (PDT) Received: by wyh21 with SMTP id 21so6232584wyh.31 for ; Tue, 27 Sep 2011 14:56:38 -0700 (PDT) Received: by 10.227.10.139 with SMTP id p11mr413369wbp.61.1317160598442; Tue, 27 Sep 2011 14:56:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.196.83 with HTTP; Tue, 27 Sep 2011 14:55:58 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> From: Eric Rescorla Date: Tue, 27 Sep 2011 14:55:58 -0700 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=002215974dfa95135b04adf3599a Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 21:53:53 -0000 --002215974dfa95135b04adf3599a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Sep 27, 2011 at 1:05 PM, I=F1aki Baz Castillo wrote= : > > In the same way, web browsers could come pre-configured with an > enabled checkbox: > > [X] don't allow unsecure calls > > The user could disable such checkbox. Anyhow, when a call is being > established and the WebRTC stack realizes that the peer does not > support ICE and/or SRTP, it could warn the user by showing something > like a pop-up ("This call is not secure"), also providing a button > "Don't show again for this site". > Again, the reason for ICE is the threat to other people using the browser a= s a vector. For this reason, allowing the user to disable the security feature is quite problematic. -Ekr --002215974dfa95135b04adf3599a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Sep 27, 2011 at 1:05 PM, I=F1aki= Baz Castillo <ibc@al= iax.net> wrote:
In the same way, web browsers could come pre-configured with an
enabled checkbox:

=A0[X] don't allow unsecure calls

The user could disable such checkbox. Anyhow, when a call is being
established and the WebRTC stack realizes that the peer does not
support ICE and/or SRTP, it could warn the user by showing something
like a pop-up ("This call is not secure"), also providing a butto= n
"Don't show again for this site".

Again, the reason for ICE is the threat to other people using the = browser as a vector.
For this reason, allowing the user to disabl= e the security feature is quite problematic.

-Ekr
--002215974dfa95135b04adf3599a-- From bernard_aboba@hotmail.com Tue Sep 27 15:00: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 14BE921F8F01 for ; Tue, 27 Sep 2011 15:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.070, 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 ZG2pGVcc8E3Y for ; Tue, 27 Sep 2011 15:00:02 -0700 (PDT) Received: from blu0-omc2-s25.blu0.hotmail.com (blu0-omc2-s25.blu0.hotmail.com [65.55.111.100]) by ietfa.amsl.com (Postfix) with ESMTP id 778DC21F8D4C for ; Tue, 27 Sep 2011 15:00:00 -0700 (PDT) Received: from BLU152-W61 ([65.55.111.72]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Sep 2011 15:02:47 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_24853ae6-2b57-47a5-a00d-f3b8a080be09_" X-Originating-IP: [131.107.0.72] From: Bernard Aboba To: Date: Tue, 27 Sep 2011 15:02:46 -0700 Importance: Normal In-Reply-To: References: , , , MIME-Version: 1.0 X-OriginalArrivalTime: 27 Sep 2011 22:02:47.0167 (UTC) FILETIME=[30D818F0:01CC7D61] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB and emergency services X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 22:00:03 -0000 --_24853ae6-2b57-47a5-a00d-f3b8a080be09_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ted Hardie said:=20 "Speaking personally=2C I don't think that is the right model. I can see a= n emergency service provider providing an RTCWeb service as part of its eff= orts=2C just as it may accept IMs=2C text messages=2C and other non-traditi= onal communications. But assuming that any provider of an RTCWeb applicati= on must provide a method to reach emergency services does not make sense to= me. " [BA] I believe that is what I said in my original message. The obligations= of the RTCWeb application will depend on what it is doing=2C as well as th= e country/state and possibly the device it is running on. Some applicatio= ns (e.g. realtime enablement of a game or social network) may not have an e= mergency service obligation. Others (such as service enabling phone calls = to and from the PSTN) may have such an obligation. YMMV. =20 An emergency service provider or PSAP could also use RTCWeb as part of thei= r efforts=2C of course. Dispatcher workstations often do support browsers= =2C although the sites that can be accessed may be controlled for security = reasons. That is definitely worth mentioning.=20 Ted Hardie also said:=20 "Downloaded javascript from a system presumed to be malicious is not how yo= u want to make your 911/112 calls." [BA] Indeed=2C this does raise potential issues=2C given concerns over atta= cks such as "swatting". Currently this kind of attack isn't covered in th= e RTCWEB security document. In addition to the malicious Javascript concer= n=2C there is experience with SIM-less calls=2C for example=2C which indica= tes that lack of authentication tends to lead to an increase in prank calls= . =20 Ted Hardie said: "Can the poker site require that emergency services folks have a login to i= ts system in monitor state in order to provide this service?" [BA] I'm not aware of any jurisdiction which currently imposes an emergency= services obligation on an online game. Is this a real use case? Ted Hardie said: "Despite our re-use=2C it is vitally important to remember that these appli= cations are not phones." [BA] We've already seen a demo of a handset utilizing RTCWEB technology. = However=2C just because some applications *are* phones doesn't imply that *= all* RTCWeb applications will have emergency service obligations=2C that an= RTCWeb-enabled browser needs to natively support every potential emergency= service scenario=2C or even that RTCWeb needs to handle all the obligation= s that do arise. After all=2C many of the major issues in emergency servi= ces (like location determination) don't have that much to do with RTCWeb=2C= and there are other APIs (such as the Mozilla WebAPI proposal) that could = provide emergency services functionality based on the underlying telephony = platform=2C distinct from RTCWeb. Ted Hardie said: "If you must describe in the terms of telephony=2C please circumscribe your= terms--"For RTCWeb applications intended to provide telephony services=2C = the following considerations apply...." =20 [BA] I would prefer not to give advice as to what applications do and do no= t have emergency service obligations. Given some of the proceedings now in= progress that is a complex subject and I'm not a lawyer. But we can say "= For those RTCWeb applications that have emergency services obligations=2C t= he following considerations apply.... " leaving it up to the reader (and t= heir lawyer) to parse through the existing and future regulations to figure= out what their obligations might be.=20 = --_24853ae6-2b57-47a5-a00d-f3b8a080be09_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ted Hardie said:

"Speaking personally=2C I don't think that is the right model. =3B = I can see an emergency service provider providing an RTCWeb service as part= of its efforts=2C just as it may accept IMs=2C text messages=2C and other = non-traditional communications. =3B But assuming that any provider of a= n RTCWeb application must provide a method to reach emergency services does= not make sense to me. "

[BA] I believe that is what I said in my or= iginal message. =3B The obligations of the RTCWeb application will depe= nd on what it is doing=2C as well as the country/state and possibly the dev= ice it is running on. =3B =3B Some applications (e.g. realtime enab= lement of a game or social network) may not have an emergency service oblig= ation. =3B Others (such as service enabling phone calls to and from the= PSTN) may have such an obligation. =3B YMMV. =3B

An emerge= ncy service provider or PSAP could also use RTCWeb as part of their efforts= =2C of course. =3B =3B Dispatcher workstations often do support bro= wsers=2C although the sites that can be accessed may be controlled for secu= rity reasons. =3B That is definitely worth mentioning.

Ted Hard= ie also said:

"Downloaded javascript from a system presumed to be m= alicious is not how you want to make your 911/112 calls."

[BA] Indee= d=2C this does raise potential issues=2C given concerns over attacks such a= s "swatting". =3B =3B Currently this kind of attack isn't covered i= n the RTCWEB security document. =3B In addition to the malicious Javasc= ript concern=2C there is experience with SIM-less calls=2C for example=2C w= hich indicates that lack of authentication tends to lead to an increase in = prank calls. =3B

Ted Hardie said:

"Can the poker site require that emergency serv= ices folks have a login to its system in monitor state in order to provide = this service?"

[BA] I'm not aware of any jurisdiction which currentl= y imposes an emergency services obligation on an online game. =3B Is th= is a real use case?

Ted Hardie said:

"Despite our re-use=2C i= t is vitally important to remember that these applications are not phones."=

[BA] We've already seen a demo of a handset utilizing RTCWEB techno= logy. =3B =3B However=2C just because some applications *are* phone= s doesn't imply that *all* RTCWeb applications will have emergency service = obligations=2C that an RTCWeb-enabled browser needs to natively support eve= ry potential emergency service scenario=2C or even that RTCWeb needs to han= dle all the obligations that do arise. =3B =3B After all=2C many of= the major issues in emergency services (like location determination) don't= have that much to do with RTCWeb=2C and there are other APIs (such as the = Mozilla WebAPI proposal) that could provide emergency services functionalit= y based on the underlying telephony platform=2C distinct from RTCWeb.
Ted Hardie said:

"If you must describe in the terms of telephony=2C please circumscribe = your terms--"For RTCWeb applications intended to provide telephony services= =2C the following considerations apply...." =3B

[BA] I would pr= efer not to give advice as to what applications do and do not have emergenc= y service obligations. =3B Given some of the proceedings now in progres= s that is a complex subject and I'm not a lawyer. =3B But we can say "F= or those RTCWeb applications that have emergency services obligations=2C th= e following considerations apply.... " =3B leaving it up to the reader = (and their lawyer) to parse through the existing and future regulations to = figure out what their obligations might be.
=
= --_24853ae6-2b57-47a5-a00d-f3b8a080be09_-- From roman@telurix.com Tue Sep 27 15:10: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 0FD5121F9025 for ; Tue, 27 Sep 2011 15:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 yFkOnYuQkqJq for ; Tue, 27 Sep 2011 15:10:51 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id F113221F901D for ; Tue, 27 Sep 2011 15:10:50 -0700 (PDT) Received: by yic13 with SMTP id 13so6852873yic.31 for ; Tue, 27 Sep 2011 15:13:28 -0700 (PDT) Received: by 10.236.78.200 with SMTP id g48mr52763553yhe.12.1317161607984; Tue, 27 Sep 2011 15:13:27 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id t23sm25397802yhd.3.2011.09.27.15.13.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 15:13:27 -0700 (PDT) Received: by gyd12 with SMTP id 12so7027109gyd.31 for ; Tue, 27 Sep 2011 15:13:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.34.138 with SMTP id z10mr39584935pbi.105.1317161606678; Tue, 27 Sep 2011 15:13:26 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 27 Sep 2011 15:13:26 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> Date: Tue, 27 Sep 2011 18:13:26 -0400 Message-ID: From: Roman Shpount To: Eric Rescorla Content-Type: multipart/alternative; boundary=bcaec5216303ad8a1a04adf39574 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 22:10:52 -0000 --bcaec5216303ad8a1a04adf39574 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Eric, I would suggest we should have an ability to disable ICE/SRTP in browser settings altogether for debugging purposes and have an ability to add a web site to browser settings (or assign it to intranet zone), which would enabl= e this web site to setup calls without ICE/SRTP. This way a developer can disable these protocols to test things, and user can take an action to say that it trust a certain web site and allows it to place calls anywhere. I would think browser settings are outside of the standards document, but we at least should have requirements for ICE-required and SRTP as SHOULD, not MUST. _____________ Roman Shpount On Tue, Sep 27, 2011 at 5:55 PM, Eric Rescorla wrote: > > > On Tue, Sep 27, 2011 at 1:05 PM, I=F1aki Baz Castillo wro= te: >> >> In the same way, web browsers could come pre-configured with an >> enabled checkbox: >> >> [X] don't allow unsecure calls >> >> The user could disable such checkbox. Anyhow, when a call is being >> established and the WebRTC stack realizes that the peer does not >> support ICE and/or SRTP, it could warn the user by showing something >> like a pop-up ("This call is not secure"), also providing a button >> "Don't show again for this site". >> > > Again, the reason for ICE is the threat to other people using the browser > as a vector. > For this reason, allowing the user to disable the security feature is qui= te > problematic. > > -Ekr > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --bcaec5216303ad8a1a04adf39574 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Eric,

I would suggest we should have an ability to disable ICE/SRTP = in browser settings altogether for debugging purposes and have an ability t= o add a web site to browser settings (or assign it to intranet zone), which= would enable this web site to setup calls without ICE/SRTP. This way a dev= eloper can disable these protocols to test things, and user can take an act= ion to say that it trust a certain web site and allows it to place calls an= ywhere. I would think browser settings are outside of the standards documen= t, but we at least should have requirements for ICE-required and SRTP as SH= OULD, not MUST.
_____________
Roman Shpount


On Tue, Sep 27, 2011 at 5:55 PM, Eric Re= scorla <ekr@rtfm.com> wrote:


On Tue, Sep 27, 2011 at 1:05 PM, I=F1aki= Baz Castillo <ibc@aliax.net> wrote:
In the same way, web browsers could come pre-configured with an
enabled checkbox:

=A0[X] don't allow unsecure calls

The user could disable such checkbox. Anyhow, when a call is being
established and the WebRTC stack realizes that the peer does not
support ICE and/or SRTP, it could warn the user by showing something
like a pop-up ("This call is not secure"), also providing a butto= n
"Don't show again for this site".

Again, the reason for ICE is the threat to other people using the = browser as a vector.
For this reason, allowing the user to disabl= e the security feature is quite problematic.

-Ekr

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


--bcaec5216303ad8a1a04adf39574-- From bernard_aboba@hotmail.com Tue Sep 27 15:16: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 3697321F9068 for ; Tue, 27 Sep 2011 15:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.065, 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 uMA+wpp4tN8L for ; Tue, 27 Sep 2011 15:16:32 -0700 (PDT) Received: from blu0-omc2-s36.blu0.hotmail.com (blu0-omc2-s36.blu0.hotmail.com [65.55.111.111]) by ietfa.amsl.com (Postfix) with ESMTP id A01A621F9067 for ; Tue, 27 Sep 2011 15:16:32 -0700 (PDT) Received: from BLU152-W28 ([65.55.111.73]) by blu0-omc2-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Sep 2011 15:19:16 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_f3d64b8f-bab2-4379-a54b-012786b74b36_" X-Originating-IP: [131.107.0.72] From: Bernard Aboba To: , Date: Tue, 27 Sep 2011 15:19:15 -0700 Importance: Normal In-Reply-To: References: , , , , MIME-Version: 1.0 X-OriginalArrivalTime: 27 Sep 2011 22:19:16.0319 (UTC) FILETIME=[7E6CB6F0:01CC7D63] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB and emergency services X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 22:16:33 -0000 --_f3d64b8f-bab2-4379-a54b-012786b74b36_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I agree. I don't know where this topic comes from=2C but IMHO it makes > no sense to consider a WebRTC provider a "usual" PSTN operator. It > would be a show-stopper. [BA] Agree. Not sure where this topic comes from either=2C since I didn'= t suggest this in my original post (in fact=2C I specifically noted that em= ergency obligations would not apply to many RTCWeb applications).=20 For example=2C a WebRTC application that does not provide the ability to ma= ke or=20 receive calls from the PSTN would not be classified as an "inter-connected = VoIP"=20 provider and AFAIK would not currently have an obligation to provide emerge= ncy services (at least within the US).=20 = --_f3d64b8f-bab2-4379-a54b-012786b74b36_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B I agree. I don't know where this topic comes from=2C but IMHO it mak= es
>=3B no sense to consider a WebRTC provider a "usual" PSTN ope= rator. It
>=3B would be a show-stopper.

[BA] Agree. =3B&nbs= p=3B =3B Not sure where this topic comes from either=2C since I didn't = suggest this in my original post (in fact=2C I specifically noted that emer= gency obligations would not apply to many RTCWeb applications).

For= example=2C a WebRTC application that does not provide the ability to make = or=20 receive calls from the PSTN would not be classified as an "inter-connected = VoIP"=20 provider and AFAIK would not currently have an obligation to provide emerge= ncy services (at least within the US).

= --_f3d64b8f-bab2-4379-a54b-012786b74b36_-- From ekr@rtfm.com Tue Sep 27 15:31: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 139C621F8F19 for ; Tue, 27 Sep 2011 15:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=0.076, 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 fsqHtwGXX+do for ; Tue, 27 Sep 2011 15:31:02 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4384221F8EF9 for ; Tue, 27 Sep 2011 15:31:02 -0700 (PDT) Received: by wyh21 with SMTP id 21so6259737wyh.31 for ; Tue, 27 Sep 2011 15:33:48 -0700 (PDT) Received: by 10.227.11.194 with SMTP id u2mr423623wbu.76.1317162828202; Tue, 27 Sep 2011 15:33:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.196.83 with HTTP; Tue, 27 Sep 2011 15:33:08 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> From: Eric Rescorla Date: Tue, 27 Sep 2011 15:33:08 -0700 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=002215974c5e7c855604adf3de2d Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 22:31:03 -0000 --002215974c5e7c855604adf3de2d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 27, 2011 at 3:13 PM, Roman Shpount wrote: > Eric, > > I would suggest we should have an ability to disable ICE/SRTP in browser > settings altogether for debugging purposes and have an ability to add a web > site to browser settings (or assign it to intranet zone), which would enable > this web site to setup calls without ICE/SRTP. This way a developer can > disable these protocols to test things, and user can take an action to say > that it trust a certain web site and allows it to place calls anywhere. I > would think browser settings are outside of the standards document, but we > at least should have requirements for ICE-required and SRTP as SHOULD, not > MUST. > It's really a mistake to conflate ICE and SRTP here. If the user opets not to use SRTP, he's primarily hurting himself. If he opts not to use ICE, he's potentially allowing his browser to be used as an attack platform. These are not the same thing. As for what's convenient for developers... I'm a developer, and while it might be useful to allow a setting to disable ICE and/or SRTP, that doesn't mean I need to expose that setting to the user. I really don't understand the virtue of a user-visible setting to disable the ICE requirement. -Ekr --002215974c5e7c855604adf3de2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Sep 27, 2011 at 3:13 PM, Roman S= hpount <roman@tel= urix.com> wrote:
Eric,

I would suggest we should have an ability to disable ICE/SRTP = in browser settings altogether for debugging purposes and have an ability t= o add a web site to browser settings (or assign it to intranet zone), which= would enable this web site to setup calls without ICE/SRTP. This way a dev= eloper can disable these protocols to test things, and user can take an act= ion to say that it trust a certain web site and allows it to place calls an= ywhere. I would think browser settings are outside of the standards documen= t, but we at least should have requirements for ICE-required and SRTP as SH= OULD, not MUST.

It's really a mistake to conflate ICE = and SRTP here. If the user opets not to use SRTP,
he's primar= ily hurting himself. If he opts not to use ICE, he's potentially allowi= ng his
browser to be used as an attack platform. These are not the same thing= .

As for what's convenient for developers... I= 'm a developer, and while it might be useful
to allow a setti= ng to disable ICE and/or SRTP, that doesn't mean I need to expose that<= /div>
setting to the user. I really don't understand the virtue of a use= r-visible setting to
disable the ICE requirement.

<= /div>
-Ekr
=A0
--002215974c5e7c855604adf3de2d-- From roman@telurix.com Tue Sep 27 15:47: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 7038121F8B30 for ; Tue, 27 Sep 2011 15:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 zzHMghw4YtRr for ; Tue, 27 Sep 2011 15:47:36 -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 C81CC21F8B2B for ; Tue, 27 Sep 2011 15:47:35 -0700 (PDT) Received: by gyd12 with SMTP id 12so7058469gyd.31 for ; Tue, 27 Sep 2011 15:50:22 -0700 (PDT) Received: by 10.150.69.26 with SMTP id r26mr5639263yba.322.1317163822184; Tue, 27 Sep 2011 15:50:22 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id 5sm1044259anu.23.2011.09.27.15.50.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 15:50:21 -0700 (PDT) Received: by gyd12 with SMTP id 12so7058432gyd.31 for ; Tue, 27 Sep 2011 15:50:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.36.232 with SMTP id t8mr40274156pbj.54.1317163820267; Tue, 27 Sep 2011 15:50:20 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 27 Sep 2011 15:50:20 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> Date: Tue, 27 Sep 2011 18:50:20 -0400 Message-ID: From: Roman Shpount To: Eric Rescorla Content-Type: multipart/alternative; boundary=bcaec520e8179e38f804adf41982 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 22:47:36 -0000 --bcaec520e8179e38f804adf41982 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 27, 2011 at 6:33 PM, Eric Rescorla wrote: > > It's really a mistake to conflate ICE and SRTP here. If the user opets not > to use SRTP, > he's primarily hurting himself. If he opts not to use ICE, he's potentially > allowing his > browser to be used as an attack platform. These are not the same thing. > > We are not disabling SRTP and ICE. We stop requiring them for the call and allow to process offers and answers without ICE or SAVP. Offer generated by RTC should still include "crypto" attributes and ICE candidates. But offers and answers without "crypto" and ICE candidates should be processed for an application distributed by this site. We can separate those two settings but this is primarily the function of use trusting the site vs. not trusting it. > As for what's convenient for developers... I'm a developer, and while it > might be useful > to allow a setting to disable ICE and/or SRTP, that doesn't mean I need to > expose that > setting to the user. I really don't understand the virtue of a user-visible > setting to > disable the ICE requirement. > > -Ekr > > Same reason we allow to add exception for an invalid SSL certificate. This will allow us to work with end points that are currently available vs just other RTC clients. BTW, mechanism similar to SSL certificate exceptions is probably the best way to implement this. First time an application from a web site gets an answer without ICE or SRTP, we can show the dialog box and ask user if this application should be stopped, allowed for current session or allowed always. _____________ Roman Shpount --bcaec520e8179e38f804adf41982 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 27, 2011 at 6:33 PM, Eric Rescor= la <ekr@rtfm.com&g= t; wrote:

It's really a mistake to conflate I= CE and SRTP here. If the user opets not to use SRTP,
he's pri= marily hurting himself. If he opts not to use ICE, he's potentially all= owing his
browser to be used as an attack platform. These are not the same thing= .


We are not disabling SRTP= and ICE. We stop requiring them for the call=20 and allow to process offers and answers without ICE or SAVP. Offer generate= d by RTC should still include "crypto" attributes and ICE candida= tes. But offers and answers without "crypto" and ICE candidates s= hould be processed for an application distributed by this site. We can sepa= rate those two settings but this is primarily the function of use trusting = the site vs. not trusting it.
=A0
As for what's convenient for develo= pers... I'm a developer, and while it might be useful
to allow a setting to disable ICE and/or SRTP, that doesn't mean I= need to expose that
setting to the user. I really don't understand the virtue of a use= r-visible setting to
disable the ICE requirement.

<= /div>
-Ekr
=A0
=A0
Sa= me reason we allow to add exception for an invalid SSL certificate. This wi= ll allow us to work with end points that are currently available vs just ot= her RTC clients.

BTW, mechanism similar to SSL certificate exceptions is probably the be= st way to implement this. First time an application from a web site gets an= answer without ICE or SRTP, we can show the dialog box and ask user if thi= s application should be stopped, allowed for current session or allowed alw= ays.
_____________
Roman Shpount


--bcaec520e8179e38f804adf41982-- From ekr@rtfm.com Tue Sep 27 15:52: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 1719921F8DA8 for ; Tue, 27 Sep 2011 15:52:11 -0700 (PDT) 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 Xu8j206ah66o for ; Tue, 27 Sep 2011 15:52:10 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0D64921F8DA7 for ; Tue, 27 Sep 2011 15:52:09 -0700 (PDT) Received: by wwf22 with SMTP id 22so5355709wwf.13 for ; Tue, 27 Sep 2011 15:54:56 -0700 (PDT) Received: by 10.227.11.212 with SMTP id u20mr8122030wbu.106.1317164096067; Tue, 27 Sep 2011 15:54:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.196.83 with HTTP; Tue, 27 Sep 2011 15:54:16 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> From: Eric Rescorla Date: Tue, 27 Sep 2011 15:54:16 -0700 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=002618876a160e98e204adf42aa4 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 22:52:11 -0000 --002618876a160e98e204adf42aa4 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 27, 2011 at 3:50 PM, Roman Shpount wrote: > > On Tue, Sep 27, 2011 at 6:33 PM, Eric Rescorla wrote: > >> >> It's really a mistake to conflate ICE and SRTP here. If the user opets not >> to use SRTP, >> he's primarily hurting himself. If he opts not to use ICE, he's >> potentially allowing his >> browser to be used as an attack platform. These are not the same thing. >> >> > We are not disabling SRTP and ICE. We stop requiring them for the call and > allow to process offers and answers without ICE or SAVP. Offer generated by > RTC should still include "crypto" attributes and ICE candidates. But offers > and answers without "crypto" and ICE candidates should be processed for an > application distributed by this site. We can separate those two settings but > this is primarily the function of use trusting the site vs. not trusting it. > > I'm sorry, but I think you're still missing the point: requiring ICE *is* the security feature. > As for what's convenient for developers... I'm a developer, and while it >> might be useful >> to allow a setting to disable ICE and/or SRTP, that doesn't mean I need to >> expose that >> setting to the user. I really don't understand the virtue of a >> user-visible setting to >> disable the ICE requirement. >> >> -Ekr >> >> > > Same reason we allow to add exception for an invalid SSL certificate. This > will allow us to work with end points that are currently available vs just > other RTC clients. > > BTW, mechanism similar to SSL certificate exceptions is probably the best > way to implement this. First time an application from a web site gets an > answer without ICE or SRTP, we can show the dialog box and ask user if this > application should be stopped, allowed for current session or allowed > always. > The problem is that users inevitably click through such dialogs and when they do their browsers become an attack platform. That's why this isn't comparable. -Ekr --002618876a160e98e204adf42aa4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Sep 27, 2011 at 3:50 PM, Roman S= hpount <roman@tel= urix.com> wrote:

On Tue, Sep 27, 2011 at 6:= 33 PM, Eric Rescorla <ekr@rtfm.com> wrote:

It's really a mistake to conflate I= CE and SRTP here. If the user opets not to use SRTP,
he's pri= marily hurting himself. If he opts not to use ICE, he's potentially all= owing his
browser to be used as an attack platform. These are not the same thing= .


We are not disablin= g SRTP and ICE. We stop requiring them for the call=20 and allow to process offers and answers without ICE or SAVP. Offer generate= d by RTC should still include "crypto" attributes and ICE candida= tes. But offers and answers without "crypto" and ICE candidates s= hould be processed for an application distributed by this site. We can sepa= rate those two settings but this is primarily the function of use trusting = the site vs. not trusting it.
=A0

I'm sorry, but I think= you're still missing the point: requiring ICE *is* the security
<= div>feature.

=A0
As for what's convenient for developers... I'm a developer, and = while it might be useful
to allow a setting to disable ICE and/or SRTP, that doesn't mean I= need to expose that
setting to the user. I really don't understand the virtue of a use= r-visible setting to
disable the ICE requirement.

<= /div>
-Ekr
=A0
=A0
Same reason we allow to add exception for an invalid SSL certificate. This = will allow us to work with end points that are currently available vs just = other RTC clients.

BTW, mechanism similar to SSL certificate exceptions is probably the be= st way to implement this. First time an application from a web site gets an= answer without ICE or SRTP, we can show the dialog box and ask user if thi= s application should be stopped, allowed for current session or allowed alw= ays.

The problem is that users inevitably click= through such dialogs and when they do their
browsers become an a= ttack platform. That's why this isn't comparable.=A0

-Ekr
=A0
--002618876a160e98e204adf42aa4-- From roman@telurix.com Tue Sep 27 16:18: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 CDAD321F8FA8 for ; Tue, 27 Sep 2011 16:18:07 -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.421, 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 G2UKAwKeQlO4 for ; Tue, 27 Sep 2011 16:18: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 DE14E21F8F91 for ; Tue, 27 Sep 2011 16:18:00 -0700 (PDT) Received: by ywa6 with SMTP id 6so7258562ywa.31 for ; Tue, 27 Sep 2011 16:20:47 -0700 (PDT) Received: by 10.236.79.72 with SMTP id h48mr53151235yhe.4.1317165647420; Tue, 27 Sep 2011 16:20:47 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by mx.google.com with ESMTPS id o7sm15897997anp.18.2011.09.27.16.20.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 16:20:44 -0700 (PDT) Received: by yic13 with SMTP id 13so6907954yic.31 for ; Tue, 27 Sep 2011 16:20:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.36.232 with SMTP id t8mr40446037pbj.54.1317165643511; Tue, 27 Sep 2011 16:20:43 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 27 Sep 2011 16:20:43 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> Date: Tue, 27 Sep 2011 19:20:43 -0400 Message-ID: From: Roman Shpount To: Eric Rescorla Content-Type: multipart/alternative; boundary=bcaec520e8174ab93804adf48656 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 23:18:07 -0000 --bcaec520e8174ab93804adf48656 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 27, 2011 at 6:54 PM, Eric Rescorla wrote: > I'm sorry, but I think you're still missing the point: requiring ICE *is* > the security > feature. > > I'm sorry, but it I do get the point: ICE is security. My point is, if you have a trust relationship with a site, ICE validation can be bypassed, i.e. if you trust the application on the site you trust it not to do something malicious with your media. You point is that you do not trust the user with the decision to turn off ICE or trust the website, since unlike with all the other security decisions this can be used to hurt other people vs. just users themselves. So, unless we can invent a robust mechanism to set trust agreements with specific web sites, we would be better off forcing ICE for everybody. Is this correct description of the problem? _____________ Roman Shpount --bcaec520e8174ab93804adf48656 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 27, 2011 at 6:54 P= M, Eric Rescorla <ekr@= rtfm.com> wrote:
I'm sorry, but I think you're still missing the point: requiring IC= E *is* the security
feature.


I'm sorry, but= it I do get the point: ICE is security. My point is, if you have a trust r= elationship with a site, ICE validation can be bypassed, i.e. if you trust = the application on the site you trust it not to do something malicious with= your media.=A0 You point is that you do not trust the user with the decisi= on to turn off ICE or trust the website, since unlike with all the other se= curity decisions this can be used to hurt other people vs. just users thems= elves. So, unless we can invent a robust mechanism to set trust agreements = with specific web sites, we would be better off forcing ICE for everybody. = Is this correct description of the problem?
_____________
Roman Shpount

--bcaec520e8174ab93804adf48656-- From ekr@rtfm.com Tue Sep 27 16:28: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 2A39421F8F4C for ; Tue, 27 Sep 2011 16:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.074, 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 nZtKOeDi+AYR for ; Tue, 27 Sep 2011 16:28:07 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD9A21F8F1D for ; Tue, 27 Sep 2011 16:28:07 -0700 (PDT) Received: by wwf22 with SMTP id 22so5378090wwf.13 for ; Tue, 27 Sep 2011 16:30:53 -0700 (PDT) Received: by 10.227.11.194 with SMTP id u2mr476351wbu.76.1317166253169; Tue, 27 Sep 2011 16:30:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.196.83 with HTTP; Tue, 27 Sep 2011 16:30:13 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> From: Eric Rescorla Date: Tue, 27 Sep 2011 16:30:13 -0700 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=002215974c5ea15c9a04adf4aa9f Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 27 Sep 2011 23:28:08 -0000 --002215974c5ea15c9a04adf4aa9f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 27, 2011 at 4:20 PM, Roman Shpount wrote: > > On Tue, Sep 27, 2011 at 6:54 PM, Eric Rescorla wrote: > >> I'm sorry, but I think you're still missing the point: requiring ICE *is* >> the security >> feature. >> >> > I'm sorry, but it I do get the point: ICE is security. My point is, if you > have a trust relationship with a site, ICE validation can be bypassed, i.e. > if you trust the application on the site you trust it not to do something > malicious with your media. You point is that you do not trust the user with > the decision to turn off ICE or trust the website, since unlike with all the > other security decisions this can be used to hurt other people vs. just > users themselves. So, unless we can invent a robust mechanism to set trust > agreements with specific web sites, we would be better off forcing ICE for > everybody. Is this correct description of the problem? > I don't know what "trust agreements with specific web sites" means. The basic situation here is that browser vendors do not want to ship browsers which can be used as an attack platform. And since the victim is not the user but rather the recipient of the traffic, that's why WebSockets and CORS require that the server (i.e., the recipient of the traffic) confirm its willingness to receive the traffic, as opposed to having the user agree to it. I don't see how any trust mechanism that doesn't involve the recipient can have the right security properties. -Ekr --002215974c5ea15c9a04adf4aa9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Sep 27, 2011 at 4:20 PM, Roman S= hpount <roman@tel= urix.com> wrote:

On Tue, Sep = 27, 2011 at 6:54 PM, Eric Rescorla <ekr@rtfm.com> wrote:
I'm sorry, but I think you're still missing the point: requiring IC= E *is* the security
feature.
=

I'm sorry, but it I d= o get the point: ICE is security. My point is, if you have a trust relation= ship with a site, ICE validation can be bypassed, i.e. if you trust the app= lication on the site you trust it not to do something malicious with your m= edia.=A0 You point is that you do not trust the user with the decision to t= urn off ICE or trust the website, since unlike with all the other security = decisions this can be used to hurt other people vs. just users themselves. = So, unless we can invent a robust mechanism to set trust agreements with sp= ecific web sites, we would be better off forcing ICE for everybody. Is this= correct description of the problem?

I don't know what "tr= ust agreements with specific web sites" means.

The basic situation here is that browser vendors do not want to ship brow= sers
which can be used as an attack platform. And since the victim is not t= he user
but rather the recipient of the traffic, that's why W= ebSockets and CORS
require that the server (i.e., the recipient o= f the traffic) confirm its willingness
to receive the traffic, as opposed to having the user agree to it. I d= on't see
how any trust mechanism that doesn't involve the= recipient can have the
right security properties.

-Ekr


--002215974c5ea15c9a04adf4aa9f-- From matthew.kaufman@skype.net Tue Sep 27 17:08: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 A5ECB21F8F25 for ; Tue, 27 Sep 2011 17:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.452 X-Spam-Level: X-Spam-Status: No, score=-5.452 tagged_above=-999 required=5 tests=[AWL=1.147, 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 74pFxbmVaYWi for ; Tue, 27 Sep 2011 17:08:20 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2D98221F8F21 for ; Tue, 27 Sep 2011 17:08:20 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 13FA516FC; Wed, 28 Sep 2011 02:11:06 +0200 (CEST) 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=de2gwOJB3MBoi1 sQOvbREL/Xer8=; b=mJCj4VTQm2XIfLS6eAWU+yirsdxJoeGRDqEsxAQllHypsS Wk7Sl0765KyiPBpLfeSpZ+Wj7erBqtj8WZxVCWTuegwF7keskI0uMQWCYohN9bLD /QfqLAUoaDAU7h1+o+mJsNigO+AY5fM7I3HGbqS4Ax8OirKU8uERNYgz3oMDo= 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=GHcnBqjEQ3uXQXBjdmrplp sZpYlkDR4gPKpF35U99H/nnqtOzg/DpIByX/p/oZc1HT8ofcw3dgtweW/17EbUdc rZXJulXwbgfdU9j77wDvLoc79otOo6BbgnZxO0r3fDGmlZK4LbMQqulHPcq0foCq hnHHFmWu4k/nZIPfWx9tc= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 1283A7F8; Wed, 28 Sep 2011 02:11:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id E57253506F32; Wed, 28 Sep 2011 02:11:05 +0200 (CEST) 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 3SL44Fo1zQbu; Wed, 28 Sep 2011 02:11:05 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 141F93506F12; Wed, 28 Sep 2011 02:11:03 +0200 (CEST) Message-ID: <4E8265D3.5020809@skype.net> Date: Tue, 27 Sep 2011 17:09:55 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Roman Shpount References: <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> <4E821E47.4080205@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] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 00:08:24 -0000 On 9/27/2011 3:13 PM, Roman Shpount wrote: > Eric, > > I would suggest we should have an ability to disable ICE/SRTP in > browser settings altogether for debugging purposes No idea why that would be helpful. If you really want cleartext traffic, allow a null SRTP cipher, not plain RTP. And disabling ICE doesn't help anything. > and have an ability to add a web site to browser settings (or assign > it to intranet zone), which would enable this web site to setup calls > without ICE/SRTP. Bad idea. > This way a developer can disable these protocols to test things, and > user can take an action to say that it trust a certain web site and > allows it to place calls anywhere. Yes, and the same way a malicious site can say "if you want to browse our free porn collection, you must click 'yes' on the next dialog" and then proceed to attack at will. Totally unacceptable. > I would think browser settings are outside of the standards document, > but we at least should have requirements for ICE-required and SRTP as > SHOULD, not MUST. ICE needs to be a MUST. Debate is still going on support (or not) for plain RTP. Matthew Kaufman From matthew.kaufman@skype.net Tue Sep 27 17: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 17AB821F8FB3 for ; Tue, 27 Sep 2011 17:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTqvfo3NntBX for ; Tue, 27 Sep 2011 17:15:40 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0E821F8FAC for ; Tue, 27 Sep 2011 17:15:40 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 602AF16FC; Wed, 28 Sep 2011 02:18:26 +0200 (CEST) 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; s=mx; bh=FzHsJ9U8QOoWakWtlWYj1WfaNqM=; b=ap9HS6bCO ieZf55ozmRXsuC6JFchucseEUX0ElGBz77CbP1BBKPZsMLBJ8jfCoQfeat2k/CPC WO/BopNUhOAVPSSskN8IE23OMyHLx5We84fBJ+Nw2zEF49MM9FNgr0YVHerwQ3+k ZBW/zeXxO9vVz/FDzgydDAuz7/nqOuQCnM= 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; q=dns; s=mx; b=Ob6arh3++TNs7gJGXGV6/ym+85iD99FSe+YpZyvZg37hs7eM 4PvjlnDzWjs/OI/+IrdzFsnrmP2mhaMOVs9lJ9b/vIe5URWm6SX7Frlik38tHaLU T9yFGZWCFFvreNMbPxhcynA6Vl3F8n2ui65RoUU5y1TimYoEOMtYol8JJ1s= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 5E76C7F8; Wed, 28 Sep 2011 02:18:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 239793506F4B; Wed, 28 Sep 2011 02:18:26 +0200 (CEST) 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 a+HWNT5ESOq2; Wed, 28 Sep 2011 02:18:25 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 693A93506F49; Wed, 28 Sep 2011 02:18:24 +0200 (CEST) Message-ID: <4E82678E.6060304@skype.net> Date: Tue, 27 Sep 2011 17:17:18 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Roman Shpount References: <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030106070704020903040607" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 00:15:41 -0000 This is a multi-part message in MIME format. --------------030106070704020903040607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/27/2011 4:20 PM, Roman Shpount wrote: > > On Tue, Sep 27, 2011 at 6:54 PM, Eric Rescorla > wrote: > > I'm sorry, but I think you're still missing the point: requiring > ICE *is* the security > feature. > > > I'm sorry, but it I do get the point: ICE is security. My point is, if > you have a trust relationship with a site, ICE validation can be > bypassed, i.e. if you trust the application on the site you trust it > not to do something malicious with your media. You point is that you > do not trust the user with the decision to turn off ICE or trust the > website, since unlike with all the other security decisions this can > be used to hurt other people vs. just users themselves. So, unless we > can invent a robust mechanism to set trust agreements with specific > web sites, we would be better off forcing ICE for everybody. Is this > correct description of the problem? No. This is not a correct description of the problem. ICE isn't about "trusting the site to not do something malicious with your media". ICE is about "trusting your browser to not attack other devices on your local network or the Internet". The browser must, without asking the user, be able to prove that the far end wishes to receive a stream of media. The standard we have available for that is a STUN connectivity check with short-term credentials, using a transaction ID that can neither be set from Javascript nor inspected from Javascript (to prevent spoofing of the reply). This is basically how ICE tests connectivity. Note that the consent must use the same protocol and port you will be sending media on. So for RTP or SRTP over UDP, the consent request must be sent and received over that same UDP port. Matthew Kaufman --------------030106070704020903040607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/27/2011 4:20 PM, Roman Shpount wrote:

On Tue, Sep 27, 2011 at 6:54 PM, Eric Rescorla <ekr@rtfm.com> wrote:
I'm sorry, but I think you're still missing the point: requiring ICE *is* the security
feature.


I'm sorry, but it I do get the point: ICE is security. My point is, if you have a trust relationship with a site, ICE validation can be bypassed, i.e. if you trust the application on the site you trust it not to do something malicious with your media.  You point is that you do not trust the user with the decision to turn off ICE or trust the website, since unlike with all the other security decisions this can be used to hurt other people vs. just users themselves. So, unless we can invent a robust mechanism to set trust agreements with specific web sites, we would be better off forcing ICE for everybody. Is this correct description of the problem?

No. This is not a correct description of the problem.

ICE isn't about "trusting the site to not do something malicious with your media". ICE is about "trusting your browser to not attack other devices on your local network or the Internet".

The browser must, without asking the user, be able to prove that the far end wishes to receive a stream of media. The standard we have available for that is a STUN connectivity check with short-term credentials, using a transaction ID that can neither be set from Javascript nor inspected from Javascript (to prevent spoofing of the reply). This is basically how ICE tests connectivity.

Note that the consent must use the same protocol and port you will be sending media on. So for RTP or SRTP over UDP, the consent request must be sent and received over that same UDP port.

Matthew Kaufman

--------------030106070704020903040607-- From roman@telurix.com Tue Sep 27 17:36: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 0CBCE21F8F5B for ; Tue, 27 Sep 2011 17:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.410, 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 HW5Ki1f4x8wm for ; Tue, 27 Sep 2011 17:36:20 -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 5A51421F8D3B for ; Tue, 27 Sep 2011 17:36:20 -0700 (PDT) Received: by gyd12 with SMTP id 12so7140503gyd.31 for ; Tue, 27 Sep 2011 17:39:07 -0700 (PDT) Received: by 10.236.185.228 with SMTP id u64mr52049053yhm.91.1317170346712; Tue, 27 Sep 2011 17:39:06 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id x12sm36035957yhi.10.2011.09.27.17.39.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 17:39:06 -0700 (PDT) Received: by ywa6 with SMTP id 6so7316270ywa.31 for ; Tue, 27 Sep 2011 17:39:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.4.170 with SMTP id l10mr40356652pbl.3.1317170345295; Tue, 27 Sep 2011 17:39:05 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 27 Sep 2011 17:39:05 -0700 (PDT) In-Reply-To: <4E82678E.6060304@skype.net> References: <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> <4E82678E.6060304@skype.net> Date: Tue, 27 Sep 2011 20:39:05 -0400 Message-ID: From: Roman Shpount To: Matthew Kaufman Content-Type: multipart/alternative; boundary=bcaec5215f358a40af04adf59e0c Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 00:36:21 -0000 --bcaec5215f358a40af04adf59e0c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 27, 2011 at 8:17 PM, Matthew Kaufman wrote: > No. This is not a correct description of the problem. > > ICE isn't about "trusting the site to not do something malicious with your > media". ICE is about "trusting your browser to not attack other devices on > your local network or the Internet". > > The browser must, without asking the user, be able to prove that the far > end wishes to receive a stream of media. The standard we have available for > that is a STUN connectivity check with short-term credentials, using a > transaction ID that can neither be set from Javascript nor inspected from > Javascript (to prevent spoofing of the reply). This is basically how ICE > tests connectivity. > > Note that the consent must use the same protocol and port you will be > sending media on. So for RTP or SRTP over UDP, the consent request must be > sent and received over that same UDP port. > > Matthew Kaufman > > You just repeated the same thing that I said, just a bit more clearly. I guess we are making a conscientious not to be able to communicate with any of the existing VoIP infrastructure including IP phones and SIP trunking providers and expect them to implement ICE support. Until this happens RTC end points will have to rely on some sort of media proxy to communicate with existing infrastructure. Is this correct? Do we have anybody in this list who has real life experience with deploying large scale ICE based solutions over public internet? I just want to make sure that we are not putting all of our eggs in the basket that no one ever used. _____________ Roman Shpount --bcaec5215f358a40af04adf59e0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 27, 2011 at 8:17 P= M, Matthew Kaufman <matthew.kaufman@skype.net> wrote:
=20 =20 =20
No. This is not a correct description of the problem.

ICE isn't about "trusting the site to not do something malicio= us with your media". ICE is about "trusting your browser to not = attack other devices on your local network or the Internet".

The browser must, without asking the user, be able to prove that the far end wishes to receive a stream of media. The standard we have available for that is a STUN connectivity check with short-term credentials, using a transaction ID that can neither be set from Javascript nor inspected from Javascript (to prevent spoofing of the reply). This is basically how ICE tests connectivity.

Note that the consent must use the same protocol and port you will be sending media on. So for RTP or SRTP over UDP, the consent request must be sent and received over that same UDP port.

Matthew Kaufman


You just repeated the same thing that I said, just a= bit more clearly.

I guess we are making a conscientious not to be = able to communicate with any of the existing VoIP infrastructure including = IP phones and SIP trunking providers and expect them to implement ICE suppo= rt. Until this happens RTC end points will have to rely on some sort of med= ia proxy to communicate with existing infrastructure. Is this correct?

Do we have anybody in this list who has real life experience with deplo= ying large scale ICE based solutions over public internet? I just want to m= ake sure that we are not putting all of our eggs in the basket that no one = ever used.
_____________
Roman Shpount


--bcaec5215f358a40af04adf59e0c-- From matthew.kaufman@skype.net Tue Sep 27 18:33: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 B900021F8DDF for ; Tue, 27 Sep 2011 18:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.523 X-Spam-Level: X-Spam-Status: No, score=-5.523 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfFLtw5KTv57 for ; Tue, 27 Sep 2011 18:33:05 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id B88FD21F8DDB for ; Tue, 27 Sep 2011 18:33:00 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id EDA9016FC; Wed, 28 Sep 2011 03:35:45 +0200 (CEST) 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; s=mx; bh=U+0Unp9++oJLvI6gG0z1DHnZJYI=; b=iJC3aDSxr bfj7SUK/DvMrhc3MHiKk778qg/AdSrXEngumFECI3taictFyCGVVo5T1N8y6x3o3 16BOg9F3FmUywSqKT8Ppk878Tb1W4CCgZRv6Sy2wnH93pw90ndJ0OXdm8kP0FMd+ zMzEXbpBZgJ+KlyxG919IW1OfpkaqU87v8= 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; q=dns; s=mx; b=jPbTqZLGf1iwSBXLM5Ny2Wxi903a6FlXWGA+hhRMq8d1wA/p xj/JbO1Z5PQhkRwy+AAeocdK93yExoHAdQI6xmW3RH1WBFUQr+LFQINwV5ZtalGW U4kPC0Mc0N2/YPH8wZAHvu2dzcQPROnxqwy+a7u+bH4/qktN1Td+qwH6VPc= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id EBDED7F8; Wed, 28 Sep 2011 03:35:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id C9BD13506E25; Wed, 28 Sep 2011 03:35:45 +0200 (CEST) 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 EKVLSBLeav14; Wed, 28 Sep 2011 03:35:44 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 7BDD33506DEA; Wed, 28 Sep 2011 03:35:43 +0200 (CEST) Message-ID: <4E8279AD.6030409@skype.net> Date: Tue, 27 Sep 2011 18:34:37 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Roman Shpount References: <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> <4E82678E.6060304@skype.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060403020406030300070603" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 01:33:06 -0000 This is a multi-part message in MIME format. --------------060403020406030300070603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/27/2011 5:39 PM, Roman Shpount wrote: > > On Tue, Sep 27, 2011 at 8:17 PM, Matthew Kaufman > > wrote: > > No. This is not a correct description of the problem. > > ICE isn't about "trusting the site to not do something malicious > with your media". ICE is about "trusting your browser to not > attack other devices on your local network or the Internet". > > The browser must, without asking the user, be able to prove that > the far end wishes to receive a stream of media. The standard we > have available for that is a STUN connectivity check with > short-term credentials, using a transaction ID that can neither be > set from Javascript nor inspected from Javascript (to prevent > spoofing of the reply). This is basically how ICE tests connectivity. > > Note that the consent must use the same protocol and port you will > be sending media on. So for RTP or SRTP over UDP, the consent > request must be sent and received over that same UDP port. > > Matthew Kaufman > > > You just repeated the same thing that I said, just a bit more clearly. If you say so. > > I guess we are making a conscientious not to be able to communicate > with any of the existing VoIP infrastructure including IP phones and > SIP trunking providers and expect them to implement ICE support. Unfortunately that appears to be necessary. > Until this happens RTC end points will have to rely on some sort of > media proxy to communicate with existing infrastructure. Is this correct? Yes. Of course there's numerous examples of this working well already. > > Do we have anybody in this list who has real life experience with > deploying large scale ICE based solutions over public internet? I just > want to make sure that we are not putting all of our eggs in the > basket that no one ever used. Good question, but I believe Google has a fair bit of ICE experience. Matthew Kaufman --------------060403020406030300070603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/27/2011 5:39 PM, Roman Shpount wrote:

On Tue, Sep 27, 2011 at 8:17 PM, Matthew Kaufman <matthew.kaufman@skype.net> wrote:
No. This is not a correct description of the problem.

ICE isn't about "trusting the site to not do something malicious with your media". ICE is about "trusting your browser to not attack other devices on your local network or the Internet".

The browser must, without asking the user, be able to prove that the far end wishes to receive a stream of media. The standard we have available for that is a STUN connectivity check with short-term credentials, using a transaction ID that can neither be set from Javascript nor inspected from Javascript (to prevent spoofing of the reply). This is basically how ICE tests connectivity.

Note that the consent must use the same protocol and port you will be sending media on. So for RTP or SRTP over UDP, the consent request must be sent and received over that same UDP port.

Matthew Kaufman


You just repeated the same thing that I said, just a bit more clearly.

If you say so.


I guess we are making a conscientious not to be able to communicate with any of the existing VoIP infrastructure including IP phones and SIP trunking providers and expect them to implement ICE support.

Unfortunately that appears to be necessary.

Until this happens RTC end points will have to rely on some sort of media proxy to communicate with existing infrastructure. Is this correct?

Yes. Of course there's numerous examples of this working well already.


Do we have anybody in this list who has real life experience with deploying large scale ICE based solutions over public internet? I just want to make sure that we are not putting all of our eggs in the basket that no one ever used.

Good question, but I believe Google has a fair bit of ICE experience.

Matthew Kaufman

--------------060403020406030300070603-- From randell-ietf@jesup.org Tue Sep 27 21:51: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 9660D21F8CB4 for ; Tue, 27 Sep 2011 21:51:45 -0700 (PDT) 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 qq7DqWb33Srh for ; Tue, 27 Sep 2011 21:51:45 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0A19821F8CAD for ; Tue, 27 Sep 2011 21:51:44 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R8mAB-0005if-TU for rtcweb@ietf.org; Tue, 27 Sep 2011 23:54:31 -0500 Message-ID: <4E82A7A8.7060308@jesup.org> Date: Wed, 28 Sep 2011 00:50:48 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E820825.9090101@skype.net> <4E821E47.4080205@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] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 04:51:45 -0000 I've been staying out of this one, but one comment: On 9/27/2011 7:30 PM, Eric Rescorla wrote: > I don't know what "trust agreements with specific web sites" means. > > The basic situation here is that browser vendors do not want to ship > browsers > which can be used as an attack platform. And since the victim is not > the user > but rather the recipient of the traffic, that's why WebSockets and CORS > require that the server (i.e., the recipient of the traffic) confirm > its willingness > to receive the traffic, as opposed to having the user agree to it. I > don't see > how any trust mechanism that doesn't involve the recipient can have the > right security properties. Is there any way we could leverage something similar to CORS to allow destinations to specify they're willing to take traffic in some manner other than per-connection ICE? This could be a lot simpler for PBXes, gateways, and the like to implement than ICE/SRTP/etc. The general idea would be to try ICE, and if the other side doesn't do ICE, check a CORS-equivalent at the same same address on a port (the port could be specified in DNS SRV records perhaps, or even an alternate address to use to check). If it says it's willing to accept webrtc traffic without verification, great. (This could be additionally secured by requiring the server to mark the app/service as known to be acceptable in the CORS data.) -- Randell Jesup randell-ietf@jesup.org From igor.faynberg@alcatel-lucent.com Tue Sep 27 23: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 26CF421F8C45 for ; Tue, 27 Sep 2011 23:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.602 X-Spam-Level: X-Spam-Status: No, score=-6.602 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrKpBI5SeNzT for ; Tue, 27 Sep 2011 23:34:49 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8299121F8C6F for ; Tue, 27 Sep 2011 23:34:49 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p8S6baV8005755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 28 Sep 2011 01:37:36 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8S6bZbX018141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 28 Sep 2011 01:37:36 -0500 Received: from [135.244.19.225] (faynberg.lra.lucent.com [135.244.19.225]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p8S6bZVp007677; Wed, 28 Sep 2011 01:37:35 -0500 (CDT) Message-ID: <4E82C0AF.8050204@alcatel-lucent.com> Date: Wed, 28 Sep 2011 02:37:35 -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: <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030706070003030604090506" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 06:34:50 -0000 This is a multi-part message in MIME format. --------------030706070003030604090506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit +1! Igor On 9/27/2011 5:55 PM, Eric Rescorla wrote: > > > On Tue, Sep 27, 2011 at 1:05 PM, Iaki Baz Castillo > wrote: > > In the same way, web browsers could come pre-configured with an > enabled checkbox: > > [X] don't allow unsecure calls > > The user could disable such checkbox. Anyhow, when a call is being > established and the WebRTC stack realizes that the peer does not > support ICE and/or SRTP, it could warn the user by showing something > like a pop-up ("This call is not secure"), also providing a button > "Don't show again for this site". > > > Again, the reason for ICE is the threat to other people using the > browser as a vector. > For this reason, allowing the user to disable the security feature is > quite problematic. > > -Ekr > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------030706070003030604090506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1!

Igor

On 9/27/2011 5:55 PM, Eric Rescorla wrote:


On Tue, Sep 27, 2011 at 1:05 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
In the same way, web browsers could come pre-configured with an
enabled checkbox:

 [X] don't allow unsecure calls

The user could disable such checkbox. Anyhow, when a call is being
established and the WebRTC stack realizes that the peer does not
support ICE and/or SRTP, it could warn the user by showing something
like a pop-up ("This call is not secure"), also providing a button
"Don't show again for this site".

Again, the reason for ICE is the threat to other people using the browser as a vector.
For this reason, allowing the user to disable the security feature is quite problematic.

-Ekr

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--------------030706070003030604090506-- From harald@alvestrand.no Tue Sep 27 23:58: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 1E18B21F8C79 for ; Tue, 27 Sep 2011 23:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.615 X-Spam-Level: X-Spam-Status: No, score=-109.615 tagged_above=-999 required=5 tests=[AWL=0.983, 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 2Qco7GOmDcyw for ; Tue, 27 Sep 2011 23:58:11 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 65D8221F8C72 for ; Tue, 27 Sep 2011 23:57:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1D3C339E072; Wed, 28 Sep 2011 09:00:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGduCwbXBs29; Wed, 28 Sep 2011 09:00:43 +0200 (CEST) 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 BD5E539E051; Wed, 28 Sep 2011 09:00:43 +0200 (CEST) Message-ID: <4E82C61B.3070900@alvestrand.no> Date: Wed, 28 Sep 2011 09:00:43 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Bernard Aboba References: , , , , In-Reply-To: Content-Type: multipart/alternative; boundary="------------020508050509050700010606" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB and emergency services X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 06:58:12 -0000 This is a multi-part message in MIME format. --------------020508050509050700010606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm waiting for the draft to read in context, but what I hear Bernard saying is: "IF the RTCweb service falls within the scope of 911 regulations THEN here are some things it needs to consider...." Some RTCWeb services will certainly not fall within the scope of 911 regulations. If someone creates a service where it does matter (sets out to emulate a phone perfectly in the browser, for instance) they may very well find themselves in a situation where they do become subject to regulation, and in that case, the implementor may have benefit from reading Bernard's draft (or the document that eventually results from it). All other service implementors can disregard it. I hope.... On 09/28/2011 12:19 AM, Bernard Aboba wrote: > > I agree. I don't know where this topic comes from, but IMHO it makes > > no sense to consider a WebRTC provider a "usual" PSTN operator. It > > would be a show-stopper. > > [BA] Agree. Not sure where this topic comes from either, since I > didn't suggest this in my original post (in fact, I specifically noted > that emergency obligations would not apply to many RTCWeb applications). > > For example, a WebRTC application that does not provide the ability to > make or receive calls from the PSTN would not be classified as an > "inter-connected VoIP" provider and AFAIK would not currently have an > obligation to provide emergency services (at least within the US). > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------020508050509050700010606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm waiting for the draft to read in context, but what I hear Bernard saying is:

"IF the RTCweb service falls within the scope of 911 regulations
THEN here are some things it needs to consider...."

Some RTCWeb services will certainly not fall within the scope of 911 regulations.
If someone creates a service where it does matter (sets out to emulate a phone perfectly in the browser, for instance) they may very well find themselves in a situation where they do become subject to regulation, and in that case, the implementor may have benefit from reading Bernard's draft (or the document that eventually results from it).

All other service implementors can disregard it.

I hope....

On 09/28/2011 12:19 AM, Bernard Aboba wrote:
> I agree. I don't know where this topic comes from, but IMHO it makes
> no sense to consider a WebRTC provider a "usual" PSTN operator. It
> would be a show-stopper.

[BA] Agree.    Not sure where this topic comes from either, since I didn't suggest this in my original post (in fact, I specifically noted that emergency obligations would not apply to many RTCWeb applications).

For example, a WebRTC application that does not provide the ability to make or receive calls from the PSTN would not be classified as an "inter-connected VoIP" provider and AFAIK would not currently have an obligation to provide emergency services (at least within the US). 


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

--------------020508050509050700010606-- From harald@alvestrand.no Wed Sep 28 00:02: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 C7E9A21F8B1C for ; Wed, 28 Sep 2011 00:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.658 X-Spam-Level: X-Spam-Status: No, score=-109.658 tagged_above=-999 required=5 tests=[AWL=0.941, 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 WWb70rNmE4h5 for ; Wed, 28 Sep 2011 00:02:11 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3751B21F8B0C for ; Wed, 28 Sep 2011 00:02:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6A5C139E072; Wed, 28 Sep 2011 09:04:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4pcinWQA1Rd; Wed, 28 Sep 2011 09:04:58 +0200 (CEST) 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 09CDB39E051; Wed, 28 Sep 2011 09:04:58 +0200 (CEST) Message-ID: <4E82C719.3070709@alvestrand.no> Date: Wed, 28 Sep 2011 09:04:57 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Roman Shpount References: <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> <4E82678E.6060304@skype.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: [rtcweb] ICE deployment experience (Re: Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls)) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 07:02:11 -0000 On 09/28/2011 02:39 AM, Roman Shpount wrote: > > > Do we have anybody in this list who has real life experience with > deploying large scale ICE based solutions over public internet? I just > want to make sure that we are not putting all of our eggs in the > basket that no one ever used. Yes. Google Talk Video, Google Voice and Google+ Hangouts all use ICE. From ibc@aliax.net Wed Sep 28 01:33: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 E3C4421F8CC4 for ; Wed, 28 Sep 2011 01:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgy-XSjVJPDZ for ; Wed, 28 Sep 2011 01:33:28 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E982721F8B06 for ; Wed, 28 Sep 2011 01:33:27 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so6257035vcb.31 for ; Wed, 28 Sep 2011 01:36:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.23.4 with SMTP id i4mr8303865vdf.514.1317198974432; Wed, 28 Sep 2011 01:36:14 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 28 Sep 2011 01:36:14 -0700 (PDT) In-Reply-To: <4E8265D3.5020809@skype.net> References: <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> <4E8265D3.5020809@skype.net> Date: Wed, 28 Sep 2011 10:36:14 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Matthew Kaufman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 08:33:29 -0000 2011/9/28 Matthew Kaufman : > ICE needs to be a MUST. Debate is still going on support (or not) for pla= in > RTP. After all these threads, now I strongly consider that ICE should be a MUST. But I don't think the same for SRTP. I don't consider that content carried via plain RTP is more important than content carried via HTTP, and AFAIK HTTPS is not a requirement in RFC 2616, neither in any web browser. --=20 I=C3=B1aki Baz Castillo From stefan.lk.hakansson@ericsson.com Wed Sep 28 01:53: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 C519621F8BE4 for ; Wed, 28 Sep 2011 01:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.22 X-Spam-Level: X-Spam-Status: No, score=-6.22 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: 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+ii7n7bBSa3 for ; Wed, 28 Sep 2011 01:53:54 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 015E121F8BD5 for ; Wed, 28 Sep 2011 01:53:53 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ae-4e82e139323a Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.115.81]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 73.A9.20773.931E28E4; Wed, 28 Sep 2011 10:56:25 +0200 (CEST) Received: from [150.132.141.36] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 28 Sep 2011 10:56:25 +0200 Message-ID: <4E82E138.4090406@ericsson.com> Date: Wed, 28 Sep 2011 10:56:24 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Two more reqs X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 08:53:54 -0000 All, I'm in the process of making a slight update of the use-case&req document (I will include the list of "Considerations applicable to all scenarios" Harald suggested that seem to be uncontroversial). I would in the same update like to add to the "multiparty without a server" use-case a sentence saying something like: "The application highlights the video window of the current speaker", and derive two new requirements: Fn: The browser MUST be able to determine the level of activity in audio streams. An: The Web API MUST provide means for informing the application about the level of activity in audio streams. My motivation is of course that user indication in multiparty sessions is something you would like to see, but allowing the application to monitor the levels of audio signals can also be useful for adjusting levels, for telling people that they generate a lot of noise etc. Stefan From internet-drafts@ietf.org Wed Sep 28 05:02: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 492FF21F8D1C; Wed, 28 Sep 2011 05:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 RRwzpJYV4R0R; Wed, 28 Sep 2011 05:02:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F8821F8BBF; Wed, 28 Sep 2011 05:02:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110928120252.1943.33125.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2011 05:02:52 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-02.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 12:02:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : Overview: Real Time Protocols for Brower-based Applicati= ons Author(s) : Harald T. Alvestrand Filename : draft-ietf-rtcweb-overview-02.txt Pages : 18 Date : 2011-09-28 This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This work is an attempt to synthesize the input of many people, but makes no claims to fully represent the views of any of them. All parts of the document should be regarded as open for discussion, unless the RTCWEB chairs have declared consensus on an item. This document is a work item of the RTCWEB working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-overview-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-overview-02.txt From harald@alvestrand.no Wed Sep 28 05:06: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 9CC8721F8726 for ; Wed, 28 Sep 2011 05:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.96 X-Spam-Level: X-Spam-Status: No, score=-108.96 tagged_above=-999 required=5 tests=[AWL=1.639, 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 g26loL-50tgv for ; Wed, 28 Sep 2011 05:06:59 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0904721F8634 for ; Wed, 28 Sep 2011 05:06:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CD92D39E072 for ; Wed, 28 Sep 2011 14:09:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkIhakHhZ6jJ for ; Wed, 28 Sep 2011 14:09:46 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 7423339E051 for ; Wed, 28 Sep 2011 14:09:46 +0200 (CEST) Message-ID: <4E830E89.3050400@alvestrand.no> Date: Wed, 28 Sep 2011 14:09:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] New version of -overview posted X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 12:06:59 -0000 I've just posted version -02 of the -overview document. I'll just paste the change log from the document here: > A.6. Changes from draft-ietf-rtcweb-overview -01 to -02 > > Added pointers to use cases, security and rtp-usage drafts (now WG > drafts). > > Changed description of SRTP from mandatory-to-use to mandatory-to- > implement. > > Added the "3 principles of negotiation" to the connection management > section. > > Added an explicit statement that ICE is required for both NAT and > consent-to-receive. Comments are always welcome, and version numbers are cheap! A note on making the finding of such easy: When I prepare a new version of a draft, I'll go back to the mailing list and search for subjects containing the draft name, or some subset of that ("overview" in this case), and dated between the previous version and this version. Starting the subject line with "ISSUE:" or "CHANGE:" is also good for catching my attention when I'm trying to re-locate those comments. Suggestions for changes that occur deep within a thread on other topics have a high chance of getting lost in this process, unfortunately. Enjoy the reading! Harald From randell-ietf@jesup.org Wed Sep 28 07:34: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 0903121F8D56 for ; Wed, 28 Sep 2011 07:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 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 H2B8OaSo4iac for ; Wed, 28 Sep 2011 07:34:17 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 3F73421F8C9C for ; Wed, 28 Sep 2011 07:34:17 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R8vFx-0006tu-Cu for rtcweb@ietf.org; Wed, 28 Sep 2011 09:37:05 -0500 Message-ID: <4E833031.3060008@jesup.org> Date: Wed, 28 Sep 2011 10:33:21 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: , , , , <4E82C61B.3070900@alvestrand.no> In-Reply-To: <4E82C61B.3070900@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] RTCWEB and emergency services X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 14:34:18 -0000 On 9/28/2011 3:00 AM, Harald Alvestrand wrote: > I'm waiting for the draft to read in context, but what I hear Bernard > saying is: > > "IF the RTCweb service falls within the scope of 911 regulations > THEN here are some things it needs to consider...." > > Some RTCWeb services will certainly not fall within the scope of 911 > regulations. > If someone creates a service where it does matter (sets out to emulate > a phone perfectly in the browser, for instance) they may very well > find themselves in a situation where they do become subject to > regulation, and in that case, the implementor may have benefit from > reading Bernard's draft (or the document that eventually results from it). > > All other service implementors can disregard it. > > I hope.... I hope too. I'll note that in the US the FCC has a history of changing the rules on 911 compliance (and other legal requirements like intercept (CALEA)). VoIP was originally excluded; then it was included only for calls to the PSTN, then it was included for all calls if your "network" was attached to the PSTN (even if the call was totally on-net). (This refers to CALEA.) There's even been talk of extending it to non-PSTN-connected networks like XBox Live. So I wouldn't assume that there won't (now or in the future) be a requirement for application developers to support either 911 or CALEA (in the US) or the equivalent in other countries. And the requirement already exists for anyone who wants to connect an WebRTC client to the PSTN in the US. As far as *we're* concerned, I think it just means we should make sure some basic functionalities are available to the applications so *they* can comply - and I think that's what Bernard is addressing. For example, see http://paranoia.dubfire.net/2011/02/deconstructing-calea-hearing.html (Good article, BTW) Voice services that do not connect to the public telephone network. Google and Facebook both offer in-network audio chat to their users (Google also offers video). Microsoft's XBox 360 service, Blizzard and several other online video game platforms allow users to insult each other chat while they play against other users online. At least from published information, I'm not aware of any one of these companies offering interception capabilities -- and so law enforcement agencies almost certainly want access to this I'll also note that browser<->browser WebRTC communication currently won't be covered by the CALEA requirement-to-decrypt even if the service provider's network attaches to the PSTN because (if we're using DTLS) the keys aren't known to the provider (or the app). -- Randell Jesup randell-ietf@jesup.org From fluffy@cisco.com Wed Sep 28 07:38: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 1F99721F8D9E for ; Wed, 28 Sep 2011 07:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.077 X-Spam-Level: X-Spam-Status: No, score=-103.077 tagged_above=-999 required=5 tests=[AWL=-0.478, 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 E4jrqA6960dJ for ; Wed, 28 Sep 2011 07:38:37 -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 A2FCA21F8D88 for ; Wed, 28 Sep 2011 07:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=617; q=dns/txt; s=iport; t=1317220886; x=1318430486; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=XrBoqcG6jUzAreVshwQMpoHduVXKRJfcDYxYF7zV10o=; b=XJrSBpitJ4RE2y/9ebKbCiHo1KV/jIGozZU4krL8LFw8AnYUb6Q9/Ekz uCQ3BET/fsN2nQe3hYu19f4ASN/v91aBvwAdyfp4evUdHlyue5uDjDtyV Ah9bNhV1x3MBZHDEGD+QARjR86Y4eI7vbBeNe+wLmlSqGhjfXHDqnxKKT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANkxg06rRDoJ/2dsb2JhbABBqAl4gVMBAQEBAgESASc0AgkFCwtGVwY1h1aaEAGeJIYrYQSHcotjhSKMMg X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="4777814" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 28 Sep 2011 14:41:25 +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 p8SEfO1k027876; Wed, 28 Sep 2011 14:41:24 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 28 Sep 2011 08:41:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <59D7159A-422E-4F8B-B0E3-EA89594601C9@cisco.com> References: , , , <4E80984A.903@skype.net>, , <4E809EE6.2050702@skype.net>, <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com>, , , , , To: Bernard Aboba X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 14:38:38 -0000 On Sep 27, 2011, at 9:23 AM, Bernard Aboba wrote: > I'm not going to use this mailing list as an advertising medium, but = there do exist products that support both ICE and SRTP, and some of the = companies you name below have deployed those products to *thousands* of = their employees.=20 I'd just like to +1 Bernard on this - a bunch of the stuff that I read = on this list just not seem to match what I see shipping. Sure lots of = stuff does not support ICE, or does not support SRTP, but vendors build = what the market needs and where there is a need for these, vendors are = building them.=20 From fluffy@cisco.com Wed Sep 28 07:39: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 427E621F8BAB for ; Wed, 28 Sep 2011 07:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.073 X-Spam-Level: X-Spam-Status: No, score=-103.073 tagged_above=-999 required=5 tests=[AWL=-0.474, 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 LmNgwb9sQK+r for ; Wed, 28 Sep 2011 07:39:21 -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 B74D521F84BC for ; Wed, 28 Sep 2011 07:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2607; q=dns/txt; s=iport; t=1317220930; x=1318430530; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=qxw8WiP3YJP8nqocK2A+OHmOPqZECs4ko0x84dQgOTs=; b=YwAeLak0JZOmB69M6NCKH1PaH1OzXS7Lc8iM20fLE4/ubUgBrnV4l8TS qhCYNU9KpKu7HdhP/SWee8PcrKofTWnn3O5HqyX+yh+KpcoXiguiKYotx 90VnPBe7cnQ/SdJEGPLB0VFxLb7n7XHVhLEMkVZE/nrdR7UOyHJ/qnst9 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACAxg06rRDoJ/2dsb2JhbABBqAl4gVMBAQEBAgEBAQEPASc0CwULCw4KLicwBhMih1YGmgoBniEDhithBIdyi2OFIotoSg X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="4780209" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 28 Sep 2011 14:42:10 +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 p8SEfO1l027876; Wed, 28 Sep 2011 14:42:09 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 28 Sep 2011 08:42:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> To: Justin Uberti X-Mailer: Apple Mail (2.1084) Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 14:39:22 -0000 On Sep 26, 2011, at 11:36 PM, Justin Uberti wrote: > Yes, most PSTN providers don't support ICE. They also often don't = support SRTP, RTCP, RTP over TCP, or even jitter buffers. uh, that's probably not right for most of the vendors but not sure it = changes your point .... > To run a robust telephony service, you will need to frontend that = traffic with a media gateway of some sort, and that gateway can easily = support ICE. Many service providers front end their services with an SBC for a wide = variety of reasons - and that is the place they would likely run ICE = Lite (note it's not even full ICE they need).=20 >=20 > On Tue, Sep 27, 2011 at 12:49 AM, Tim Panton = wrote: >=20 > On 26 Sep 2011, at 09:26, Roman Shpount wrote: >=20 >>=20 >> On Mon, Sep 26, 2011 at 11:48 AM, Matthew Kaufman = wrote: >> And "interoperability with SIP-PSTN providers" is only relevant if = you are trying to turn the browser into another phone. We have enough = phones. What we don't have are new real-time communication experiences = that can only be created within this environment. >>=20 >> Are we deliberately creating an island? To be honest, I actually = wanted to put RTC in the phone, instead of SIP. I think it would be a = great idea to have desktop phone which runs a webkit browser with RTC = and serves as an advanced display phone for a PBX. If RTC would not = support no-ICE non-RTP calls, my only option would be to ignore the = standard. So, in a sense we do not have enough phones. >=20 > I am confused. Which phones today connect directly to a SIP to PSTN = gateway ? I'd guess none.=20 > Almost all of them go through some registrar and/or proxy. =20 >=20 >>=20 >> I think you point in a lot of ways is similar to the argument that we = should disable HTTP and leave only HTTPS since it is the only secure way = to communicate and everything else would be an attack vector. >=20 > No, HTTP today does not let me probe the innards of your network ( = inside your firewall) just by sending=20 > a legal but evil payload. If you permit webRTC without ICE, then the = browser can be told to fake up UDP packets > and send them to anywhere on your inner LAN. DOS-city. >=20 > Tim.=20 >=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 From fluffy@cisco.com Wed Sep 28 07:40: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 CBF9821F8DA2 for ; Wed, 28 Sep 2011 07:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.069 X-Spam-Level: X-Spam-Status: No, score=-103.069 tagged_above=-999 required=5 tests=[AWL=-0.470, 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 spbsqbsjYzKH for ; Wed, 28 Sep 2011 07:40:31 -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 16AA321F8DA1 for ; Wed, 28 Sep 2011 07:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1419; q=dns/txt; s=iport; t=1317220999; x=1318430599; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=wPHP/BZZTBTapSBbGlcLYmeVTww6UagAT6zrf+FXzyI=; b=iWHcfwB59nvOrggt3oj1b2l66VDlSF4hN5yfthRqzCrJQQlEK6a0acea nSMab9zyXIqVVOsuq2quXaxQVft+OP7hiOcPGw35NVzdUf/ptUEiGTTmX QCFdDK4JTnMHbj+lmnnvs7kt9+xFL38KIGpc1zYHWq9PoM8rp+NaC279R E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFIyg06rRDoG/2dsb2JhbABBqAl4gVMBAQEBAgESASc/EAtGVwY1h1aaDwGOLI94hithBIdyi2OFIowy X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="4780377" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 28 Sep 2011 14:43:19 +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 p8SEhIgN017595; Wed, 28 Sep 2011 14:43:19 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 28 Sep 2011 08:43:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9790CEA7-59E6-4E14-9D5D-F9669E95036E@cisco.com> References: <4E80984A.903@skype.net>, <4E809EE6.2050702@skype.net>, <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 14:40:31 -0000 On Sep 26, 2011, at 9:44 PM, Bernard Aboba wrote: >=20 > > And "interoperability with SIP-PSTN providers" is only relevant if = you > > are trying to turn the browser into another phone. We have enough > > phones. What we don't have are new real-time communication = experiences > > that can only be created within this environment. >=20 > [BA] I think you may be on to something here. POTS lines are dropping = so rapidly > that wireline service won't even exist in some countries within a few = years. While > PSTN interop may have been a key scenario in the early days of SIP, I = have serious > doubts as to how much attention we should pay to this in RTCWEB. = Ability to > make a call to an E.164 number? Probably. Support for every = potential corner > case? Not necessarily.=20 I wish I could agree but I think we have a long, long, way to go here. I = will point out that the only way Microsoft can phone Cisco is over the = PSTN and that is two of the most pro VoIP companies in the world. = Thought I agree with rate of land lines is dropping in some countries, = the rate of what VoIP reaches via the PSTN, which is land lines + = mobile phones, is growing in every country I have stats for. Now of = course, I'd love to see the PSTN replaced with something better but I = think it is highly unrealistic to think that is going to happen in less = than 10 years.=20 From fluffy@cisco.com Wed Sep 28 08:00: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 66B4111E8086 for ; Wed, 28 Sep 2011 08:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.066 X-Spam-Level: X-Spam-Status: No, score=-103.066 tagged_above=-999 required=5 tests=[AWL=-0.467, 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 lf32i20PTHfZ for ; Wed, 28 Sep 2011 08:00:10 -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 ADF0721F8B22 for ; Wed, 28 Sep 2011 08:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2576; q=dns/txt; s=iport; t=1317222179; x=1318431779; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=H2GkFQbbUQgc9tT0YupiCi1g8r1cN0cPV2dfz0HJRYw=; b=QvIytNn2G5xKFbO4x6XHrs/3wRi2tHYotgs09zZN/22tX+tvi8w+C4q+ RHIAldsugx7umDUZWTLUnI6JctUvSS5Qz7M9WvK53GdUXAbzaXtutoCIf WQRc2Z26p/BNU82+d+daiBH9zwN0DeqkRdAJYFXD1rVYyXxuMunZA48os I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALk2g06rRDoH/2dsb2JhbABBqAl4gVMBAQEBAgEBAQEPASc0CwULCxguJzAGExsHh1YGmhgBnh4DhithBIdyi2OFIowy X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="4784731" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 28 Sep 2011 15:02:59 +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 p8SF2wUZ002230; Wed, 28 Sep 2011 15:02:58 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E82A7A8.7060308@jesup.org> Date: Wed, 28 Sep 2011 09:02:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> <4E82A7A8.7060308@j esup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 15:00:11 -0000 On Sep 27, 2011, at 10:50 PM, Randell Jesup wrote: > I've been staying out of this one, but one comment: >=20 >=20 > On 9/27/2011 7:30 PM, Eric Rescorla wrote: >> I don't know what "trust agreements with specific web sites" means. >>=20 >> The basic situation here is that browser vendors do not want to ship = browsers >> which can be used as an attack platform. And since the victim is not = the user >> but rather the recipient of the traffic, that's why WebSockets and = CORS >> require that the server (i.e., the recipient of the traffic) confirm = its willingness >> to receive the traffic, as opposed to having the user agree to it. I = don't see >> how any trust mechanism that doesn't involve the recipient can have = the >> right security properties. >=20 >=20 > Is there any way we could leverage something similar to CORS to allow > destinations to specify they're willing to take traffic in some manner > other than per-connection ICE? Randell, I have thought about this awhile back and what I come up with = is something that has very close to the same messages as ICE. In = addition, this new thing would have to be deployed on all the end points = - so it would be even hard to get deployed than ICE and I doubt it would = end up being any easier - and that just to solve the security problem. = You still have to solve the nat traversal problem and things like = transition to v6. So, I'd be happy to talk about ideas on this, but when = I drew the "boxes and arrows" diagram for something like CORS for RTP, = it did not come out looking any easier than ICE, and in fact it looked = awfully close to the "boxes and arrows" for ICE. Give it a try on a = napkin and see if you come to the roughly the same conclusion.=20 >=20 > This could be a lot simpler for PBXes, gateways, and the like to > implement than ICE/SRTP/etc. >=20 > The general idea would be to try ICE, and if the other side doesn't > do ICE, check a CORS-equivalent at the same same address on a port > (the port could be specified in DNS SRV records perhaps, or even an > alternate address to use to check). If it says it's willing to > accept webrtc traffic without verification, great. (This could be > additionally secured by requiring the server to mark the app/service > as known to be acceptable in the CORS data.) >=20 >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From cb.list6@gmail.com Wed Sep 28 08:07: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 B28FE21F8C99 for ; Wed, 28 Sep 2011 08:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.263 X-Spam-Level: X-Spam-Status: No, score=-3.263 tagged_above=-999 required=5 tests=[AWL=0.035, 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 Uqruqb9ODtu0 for ; Wed, 28 Sep 2011 08:07:33 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id EBBAB21F8C92 for ; Wed, 28 Sep 2011 08:07:32 -0700 (PDT) Received: by yic13 with SMTP id 13so7685430yic.31 for ; Wed, 28 Sep 2011 08:10:21 -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=w4lbZAXYIDtz8lYSmqXlMZ7RD9R6ZTGBBr/PdcG/gGg=; b=GajuggF1HhGdjFAOMT9nLlgAlsA1+KeHiBXxB2ChyPQ7PmlhmGRomWscOXs31S+mRl 8Sn2et97aTSe3PtxJ10U5tjFtXlfIsMOgsvnclMAu6n2VkiJtosKk/wasZcReqGtXDjT 2e81XyFFUA+JyogVFBFt4PYAbf9IpWpw41kDc= MIME-Version: 1.0 Received: by 10.68.71.193 with SMTP id x1mr44555733pbu.132.1317222620055; Wed, 28 Sep 2011 08:10:20 -0700 (PDT) Received: by 10.142.89.1 with HTTP; Wed, 28 Sep 2011 08:10:19 -0700 (PDT) Received: by 10.142.89.1 with HTTP; Wed, 28 Sep 2011 08:10:19 -0700 (PDT) In-Reply-To: References: <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> <4E8265D3.5020809@skype.net> Date: Wed, 28 Sep 2011 08:10:19 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=bcaec544f0985bc73004ae01ca84 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 15:07:33 -0000 --bcaec544f0985bc73004ae01ca84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sep 28, 2011 1:36 AM, "I=F1aki Baz Castillo" wrote: > > 2011/9/28 Matthew Kaufman : > > ICE needs to be a MUST. Debate is still going on support (or not) for plain > > RTP. > > After all these threads, now I strongly consider that ICE should be a MUST. > > But I don't think the same for SRTP. I don't consider that content > carried via plain RTP is more important than content carried via HTTP, > and AFAIK HTTPS is not a requirement in RFC 2616, neither in any web > browser. > Everytime we design a new voip product or concept, I am always told by the product management people that users expect security with voice calls on th= e internet or any public access network. Examples include gsm, umts, gan, uma= , skype and the various sip implementations for IMS over the internet... granted, not all public sip services are secure. The end result is that users may not require it upfront, but they will be shocked and angry when some blog post shows how anyone on a public WLAN can effortlessly wiretap their calls, and possibly intercept personal credit card and medical information that is commonly shared on a voice call. In this day and age, I think it has been proven, to me at least, that end t= o end encryption is always required and we would be simply negligent to not require encyption of the media and signalling. Cb > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --bcaec544f0985bc73004ae01ca84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 28, 2011 1:36 AM, "I=F1aki Baz Castillo" <ibc@aliax.net> wrote:
>
> 2011/9/28 Matthew Kaufman <matthew.kaufman@skype.net>:
> > ICE needs to be a MUST. Debate is still going on support (or not)= for plain
> > RTP.
>
> After all these threads, now I strongly consider that ICE should be a = MUST.
>
> But I don't think the same for SRTP. I don't consider that con= tent
> carried via plain RTP is more important than content carried via HTTP,=
> and AFAIK HTTPS is not a requirement in RFC 2616, neither in any web > browser.
>

Everytime we design a new voip product or concept, I am always told by t= he product management people that users expect security with voice calls on= the internet or any public access network. Examples include gsm, umts, gan= , uma, skype and the various sip implementations for IMS over the internet.= .. granted, not all public sip services are secure.

The end result is that users may not require it upfront, but they will b= e shocked and angry when some blog post shows how anyone on a public WLAN c= an effortlessly wiretap their calls, and possibly intercept personal credit= card and medical information that is commonly shared on a voice call.

In this day and age, I think it has been proven, to me at least, that en= d to end encryption is always required and we would be simply negligent to = not require encyption of the media and signalling.

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

--bcaec544f0985bc73004ae01ca84-- From fluffy@cisco.com Wed Sep 28 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 4121C1F0C69 for ; Wed, 28 Sep 2011 08:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlcvOsN902ny for ; Wed, 28 Sep 2011 08:38:31 -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 531991F0C68 for ; Wed, 28 Sep 2011 08:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=7737; q=dns/txt; s=iport; t=1317224480; x=1318434080; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=TKm3/du94uzvAcStu8LEu/xJ0eooc+BNde8NswQfOcU=; b=fNoSQIWvSmDoX0IJ3IpEM2h0PYO6wSjs1sL8XlmdjmeiX+FnqktzhTdt L7RzlsZ5+UuRdTPImVcAPtA3yoYjm1lJJk3/42LMuxEfeRk67kBrlPhHc mhgl16rvTX46Aml5osBsZm0Bb4B8+NLpgmweqwz9i1+frViTRkuGkbFy8 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAOo/g06rRDoI/2dsb2JhbABCpWqCIHiBUwEBAQECAQEBAQ8BJzQLBQsLEjQnIg4GExgBAQEHh1YGmisBniSGK2EEh3KLY4UijDI X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="4790412" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 28 Sep 2011 15:41:19 +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 p8SFfIPN013726; Wed, 28 Sep 2011 15:41:18 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 28 Sep 2011 09:41:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2579F4E0-9595-4ABB-9596-1FD39C91FABF@cisco.com> References: To: Bernard Aboba X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB and emergency services X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 15:38:32 -0000 Bernard, great to hear you are doing this. Look forward to reading it. On Sep 25, 2011, at 6:13 PM, Bernard Aboba wrote: > I'm putting together a draft on the subject of RTCWEB and emergency = services. However, before submitting this, it seemed useful to get some = feedback from the group on the general direction of the document.=20 >=20 > 1. The overall requirements for emergency services support will vary = by jurisdiction and are likely to change. Therefore the document, = while citing ongoing regulatory proceedings within the US and EU, does = not attempt to provide legal advice or offer a definitive statement of = the regulatory requirements. Instead, the document cites documents = from the ECRIT WG, such as the ECRIT Framework and Phone-BCP documents = which provide guidance on best current or future practices. =20 Some people in the WG are probably concerned about meeting various = regulations but the way I will probably look at this is would that = suggestions in the draft be likely to help save lives if they were = widely available. For example, I'm meant people in PSAPs that personally = have been involved in situations where they feel that turning off VAD on = emergency calls help save a life - in this case the life of an emergency = responder. Some other things might seem to me like just artifacts of the = past that might be regulatory required in some places but are not the = optimal way to solve the problem at this time. I'm also high interested = in things that are likely to deploy for reasons other than 911 - no one = makes money on 911 so hard to justify features that only work for that = and they are poorly tested and operated unless they are a a key code = path that gets used ever day. So, for the most part, I hope the things = in your draft that we want for E911 are things that we want for all = kinds of other reasons too.=20 >=20 > 2. The overall requirements for emergency services support also vary = by the type of service that is being implemented. For example, adding = support for real-time conferencing to a social networking service or a = game (e.g. non-interconnected VoIP) will result in different = requirements than say, implementing a phone dialing service that can = both make outgoing calls and take incoming calls from E.164 numbers = (e.g. interconnected VoIP). =20 Sure and the goal here should be to make sure that if someone was = providing a Skype like service using RTCWeb, that they have enough = support in the browser to do a good job of E911 calls.=20 >=20 > It should therefore be understood that the burden for implementation = of emergency services falls principally upon the operator of the = service, and that the role of the RTCWEB implementer is to deliver basic = capabilities and to enable an operator to add to this functionality, = rather than providing for every possible need natively ("I want a = pony"). =20 So in the case of me using a Skype like service that then calls a PSAP. = Operator could refer to the Telephony Service Provider (TSP), which was = Skype in my example here or the PSAP where the emergency operators are = (as Ted points out). My take is that the PSAP will forever be behind = the times technology wise and underfunded. There are a bunch of reason = for this best discussed over beer but the combination of budgeting, and = a safety and approval process for things like PSAP software and air = traffic control systems ensures that there is a very long deployment = cycle and thus they lag leading edge technology - sometimes by 20 years = or more. So consider a case like = http://www.theglobeandmail.com/news/national/article682611.ece - The = headline could have been "Baby dies after Comwave sends ambulance to = wrong city". As a a TSP, you don't want to see headlines like that - = it's bad for business and seriously, no one at the TSP ever wanted = anyone to get hurt. So the end result is the TSP are going to be the = ones that end up dealing with making sure that they do whatever they = need to get the right info to the PSAP. It won't be the PSAP leading = here. It might be technologically easier if they did, but given how the = financial incentives work, I believe we have to define a solutions where = the TSP can deal with the hard parts of this.=20 >=20 > 3. The emergency services capabilities of the browser are comprised = of the functionality that is implemented in the browser, as well = functionality that can be added via Javascript libraries. In some = circumstances, it may be viable to supplement functionality with = plugins. I would not even bother considering what can or can not be done with = plugins - anything can be done with a plugin and more and more they are = impossible to deploy. For the things that you can't do in a browser = without a plugin, I jus say int he context of RTCWeb, you can't do = theses - sorry - out of scope.=20 > For example, a "webphone" intended for use with an IP PBX, whose = firmware is controlled by the IP PBX vendor, could include within its = code load plugins to provide additional functionality, including = signaling protocols and codecs. I agree one could do that - but they could do anything and that is well = context of this. I's just ignore all that stuff. And I think it is fine = if there are things in phone BCP that you end up saying, sorry, can't do = that with RTCWeb - would need something else.=20 > As a result, it is not required for an RTCWEB implementation to = natively satisfy every requirement of ECRIT Phone-BCP. Examples of = requirements which may not be satisfiable without plugins include some = of the endpoint media requirements of PhoneBCP Section 14, such as ED-77 = (video codec support). However, it would appear that some of the = requirements of that section such as ED-71 (RTP Support) and ED-73 = (G.711 support) are appropriate. =20 >=20 > 4. With respect to location capabilities, the W3C Location APIs and = associated Location-Based Services are not adequate in terms of their = support for emergency services location. +1 -=20 > This gap exists in part because the requirements and scenarios for = Location-Based Services (LBS) are different from those of Location = Information Services (LISes) used for emergency purposes. =20 > While in the long-term it may be possible to close the gaps, in the = short term the gaps may be addressed via Javascript libraries = implementing elements of the ECRIT architecture such as HELD, or even = LoST. =20 Hmm, I think your draft will lead to some interesting discussion on = this. Browser JS is a surprisingly limited environment. It may be that = your draft raises some addition requirements that the OS needs to reveal = to the browser and the browser needs to expose to the JS. I'm thinking = of things like information that came in DHCP options, and doing things = like finding the browser location *before* bringing up a VPN.=20 >=20 >=20 >=20 > In addition, in some scenarios, it is quite feasible for this=20 >=20 > 2. Similarly, the requirements for native browser functionality will = vary according to the scenario. =20 >=20 > 2. In some scenarios,=20 >=20 >=20 > In meeting the requirements for emergency services support, the = important question to answer is what functionality MUST be present = natively within the browser +1.=20 And last but not least, thank you for tackling this thorny topic.=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From bernard_aboba@hotmail.com Wed Sep 28 08:42: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 66BB721F8BAD for ; Wed, 28 Sep 2011 08:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[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 hikb2cDTNmp6 for ; Wed, 28 Sep 2011 08:42:45 -0700 (PDT) Received: from blu0-omc4-s14.blu0.hotmail.com (blu0-omc4-s14.blu0.hotmail.com [65.55.111.153]) by ietfa.amsl.com (Postfix) with ESMTP id 2283621F8512 for ; Wed, 28 Sep 2011 08:42:45 -0700 (PDT) Received: from BLU152-W4 ([65.55.111.136]) by blu0-omc4-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Sep 2011 08:45:30 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_3d93d776-d596-4a49-940a-b320e325235f_" X-Originating-IP: [98.237.179.165] From: Bernard Aboba To: , Date: Wed, 28 Sep 2011 08:45:29 -0700 Importance: Normal In-Reply-To: <4E833031.3060008@jesup.org> References: , , , , , , , , , , <4E82C61B.3070900@alvestrand.no>, <4E833031.3060008@jesup.org> MIME-Version: 1.0 X-OriginalArrivalTime: 28 Sep 2011 15:45:30.0220 (UTC) FILETIME=[A695DAC0:01CC7DF5] Subject: Re: [rtcweb] RTCWEB and emergency services X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 15:42:46 -0000 --_3d93d776-d596-4a49-940a-b320e325235f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Randall said:=20 > I hope too. I'll note that in the US the FCC has a history of changing=20 > the rules on 911 compliance (and other legal requirements like intercept= =20 > (CALEA)). [BA] The draft isn't going to cover CALEA=2C and won't provide guidelines o= n when an RTCWEB application would or would not be subject to emergency services obligations. =20 Although the draft can cite some existing rules and the rulemakings now in = progress=2C=20 trying to summarize the situation globally is difficult even for existing r= ules=2C let alone future ones.=20 > VoIP was originally excluded=3B then it was included only for calls to th= e=20 > PSTN=2C then it was included for all calls if your "network" was attached= =20 > to the PSTN (even if the call was totally on-net). (This refers to=20 > CALEA.) There's even been talk of extending it to non-PSTN-connected=20 > networks like XBox Live. [BA] As you say=2C the rules change over time=2C which is a good reason no= t to try to summarize them in an IETF document. At best=2C the document could summarize them accurately prior to publication=2C after which the rules wou= ld change and the document would become out of date and misleading. =20 > So I wouldn't assume that there won't (now or in the future) be a=20 > requirement for application developers to support either 911 or CALEA=20 > (in the US) or the equivalent in other countries.=20 [BA] Predicting the future is always challenging=2C which is a good reason = to avoid doing so in an IETF document.=20 > And the requirement already exists for anyone who wants to connect an Web= RTC client to the=20 > PSTN in the US. [BA] The exact nature of this requirement may potentially change=2C so even for this case=2C it is probably best to avoid making statements. For examp= le=2C=20 see the questions relating to an amendment to the definition of "interconne= cted VoIP" included in the Location NPRM: http://transition.fcc.gov/Daily_Releases/Daily_Business/2011/db0713/FCC-11-= 107A1.pdf Also=2C note the questions relating to accessibility in the NG911 NPRM: http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-11-134A1.pdf > As far as *we're* concerned=2C I think it just means we should make sure= =20 > some basic functionalities are available to the applications so *they*=20 > can comply - and I think that's what Bernard is addressing. > > For example=2C see > http://paranoia.dubfire.net/2011/02/deconstructing-calea-hearing.html > (Good article=2C BTW) [BA] Yes=2C that is the question -- but I'm only planning to address emerge= ncy services issues=2C not CALEA.=20 = --_3d93d776-d596-4a49-940a-b320e325235f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Randall said:


>=3B I hope too. I'll note that in the US= the FCC has a history of changing
>=3B the rules on 911 compliance (= and other legal requirements like intercept
>=3B (CALEA)).

[BA= ] The draft isn't going to cover CALEA=2C and won't provide guidelines onwhen an RTCWEB application would or would not be subject to emergency
= services obligations. =3B

Although the draft can cite some exis= ting rules and the rulemakings now in progress=2C
trying to summarize t= he situation globally is difficult even for existing rules=2C let alone
= future ones.

>=3B VoIP was originally excluded=3B then it was inc= luded only for calls to the
>=3B PSTN=2C then it was included for all= calls if your "network" was attached
>=3B to the PSTN (even if the c= all was totally on-net). (This refers to
>=3B CALEA.) There's even = been talk of extending it to non-PSTN-connected
>=3B networks like XB= ox Live.

[BA] =3B As you say=2C the rules change over time=2C wh= ich is a good reason not to
try to summarize them in an IETF document.&n= bsp=3B At best=2C the document could
summarize them accurately prior to = publication=2C after which the rules would
change and the document would= become out of date and misleading. =3B

>=3B So I wouldn't as= sume that there won't (now or in the future) be a
>=3B requirement fo= r application developers to support either 911 or CALEA
>=3B (in the = US) or the equivalent in other countries.

[BA] Predicting the futur= e is always challenging=2C which is a good reason to
avoid doing so in a= n IETF document.

>=3B And the requirement already exists for anyo= ne who wants to connect an WebRTC client to the
>=3B PSTN in the US.<= br>
[BA] The exact nature of this requirement may potentially change=2C = so even
for this case=2C it is probably best to avoid making statements.=  =3B For example=2C
see the questions relating to an amendment to t= he definition of "interconnected
VoIP" included in the Location NPRM:http://transition.fcc.gov/Daily_Releases/Daily_Business/2011/db0713/FCC-11= -107A1.pdf

Also=2C note the questions relating to accessibility in t= he NG911 NPRM:
http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-11-= 134A1.pdf


>=3B As far as *we're* concerned=2C I think it just = means we should make sure
>=3B some basic functionalities are availab= le to the applications so *they*
>=3B can comply - and I think that's= what Bernard is addressing.
>=3B
>=3B For example=2C see
>= =3B http://paranoia.dubfire.net/2011/02/deconstructing-calea-hearing.html>=3B (Good article=2C BTW)

[BA] Yes=2C that is the question -- b= ut I'm only planning to address emergency
services issues=2C not CALEA. =

= --_3d93d776-d596-4a49-940a-b320e325235f_-- From tim@phonefromhere.com Wed Sep 28 08:57: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 5CCFF21F8C44 for ; Wed, 28 Sep 2011 08:57:03 -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=[AWL=0.000, 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 TSvlPikhqjuT for ; Wed, 28 Sep 2011 08:57:02 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 8739821F8C69 for ; Wed, 28 Sep 2011 08:57:01 -0700 (PDT) Received: from [10.10.3.66] (unknown [216.38.153.2]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 549DD37A902 for ; Wed, 28 Sep 2011 17:12:38 +0100 (BST) From: Tim Panton Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Sep 2011 08:59:38 -0700 Message-Id: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> To: rtcweb@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [rtcweb] Low Level Javascript API Proposal avail on the webrtc list X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 15:57:03 -0000 I just want to ask folks to take a look at a proposal Neil Stratford = wrote for the Low Level Javascript API and sent to the webrtc list. It is based on his and my experience of web based audio plugins and on = a proposal of Cullen's a while back. http://lists.w3.org/Archives/Public/public-webrtc/2011Sep/0106.html We'd appreciate any feedback either here or on the webrtc list as = appropriate. Tim. From roman@telurix.com Wed Sep 28 08:59: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 0AAFB11E80B2 for ; Wed, 28 Sep 2011 08:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.401, 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 MVMsdKBq1Arr for ; Wed, 28 Sep 2011 08:59:04 -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 E62B621F8C92 for ; Wed, 28 Sep 2011 08:59:02 -0700 (PDT) Received: by ywa6 with SMTP id 6so8095053ywa.31 for ; Wed, 28 Sep 2011 09:01:51 -0700 (PDT) Received: by 10.68.14.129 with SMTP id p1mr38057545pbc.35.1317225711164; Wed, 28 Sep 2011 09:01:51 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by mx.google.com with ESMTPS id u1sm8888273pbr.9.2011.09.28.09.01.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Sep 2011 09:01:50 -0700 (PDT) Received: by pzk37 with SMTP id 37so21773536pzk.9 for ; Wed, 28 Sep 2011 09:01:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.36.232 with SMTP id t8mr45706326pbj.54.1317225708706; Wed, 28 Sep 2011 09:01:48 -0700 (PDT) Received: by 10.68.43.229 with HTTP; Wed, 28 Sep 2011 09:01:48 -0700 (PDT) In-Reply-To: <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> Date: Wed, 28 Sep 2011 12:01:48 -0400 Message-ID: From: Roman Shpount To: Cullen Jennings Content-Type: multipart/alternative; boundary=bcaec520e81774dcd104ae028280 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 15:59:05 -0000 --bcaec520e81774dcd104ae028280 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 28, 2011 at 10:42 AM, Cullen Jennings wrote: > Many service providers front end their services with an SBC for a wide > variety of reasons - and that is the place they would likely run ICE Lite > (note it's not even full ICE they need). > I understand that this can be considered advertisement on the forum, but does ACME, Sonus and Genband SBC support ICE or ICE lite? As far as I know they do not. If I am wrong and they do, how long did they have this support? If they do not, does anybody know what their plans are? Sorry for such direct line of questioning, but dealing with SIP trunk providers in US, you interface to an SBC from one of those vendors. So, if these vendors support ICE, most of the SIP trunk providers would be able to support ICE. Even with this covered, we still have an issue of supporting ICE by PBXs and IP Phones. As far as I know (and my information can be outdated), Polycom and Cisco phones do not support ICE. I am not sure about the others, but from what I've generally seen hardware phones in vast majority do not support ICE. Please correct me if I am wrong about any of this. I am mostly trying to determine the level of current market support for ICE. _____________ Roman Shpount --bcaec520e81774dcd104ae028280 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 28, 2011 at 10:42 = AM, Cullen Jennings <fluffy@cisco.com> wrote:
_____________
Roman Shpount


On Wed, Sep 28, 2011 at 11:59 AM, Tim Pa= nton <tim@pho= nefromhere.com> wrote:
I just want to ask folks to take a look at a proposal Neil Stratford wrote = for the
Low Level Javascript API and sent to the webrtc list.

It =A0is based on his and my experience of web based audio plugins and on a=
proposal of Cullen's a while back.

http://lists.w3.org/Archives/Public/public-webrtc/20= 11Sep/0106.html

We'd appreciate any feedback either here or on the webrtc list as appro= priate.

Tim.

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

--bcaec5314ad1ffe8f404ae02a92e-- From ibc@aliax.net Wed Sep 28 09:15: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 90FC721F8D47 for ; Wed, 28 Sep 2011 09:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aj+RMF3Mdqz9 for ; Wed, 28 Sep 2011 09:15:44 -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 049AE21F8D3C for ; Wed, 28 Sep 2011 09:15:43 -0700 (PDT) Received: by vws5 with SMTP id 5so9692838vws.31 for ; Wed, 28 Sep 2011 09:18:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.177 with SMTP id bp17mr8862833vdb.447.1317226712054; Wed, 28 Sep 2011 09:18:32 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 28 Sep 2011 09:18:31 -0700 (PDT) In-Reply-To: <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> Date: Wed, 28 Sep 2011 18:18:31 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 16:15:44 -0000 2011/9/28 Cullen Jennings : > Many service providers front end their services with an SBC for a wide va= riety of reasons - and that is the place they would likely run ICE Lite (no= te it's not even full ICE they need). Just to add information about ICE Lite: http://tools.ietf.org/html/draft-rescorla-mmusic-ice-lite-00 -------------- During the design of ICE, many implementors expressed concern about the complexity of the protocol and the difficulty of implementing it. This draft specifies a compatible simplified subset of ICE called "ICE Lite" which is suitable for implementations which will always be operated with public IP addresses. One particular environment where ICE Lite is intended to be useful is in SIP-PSTN gateways which are generally directly connected to the Internet. -------------- --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Sep 28 09:19: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 9A13911E8098 for ; Wed, 28 Sep 2011 09:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It5WfTOR2Q1K for ; Wed, 28 Sep 2011 09:19:08 -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 D83501F0C47 for ; Wed, 28 Sep 2011 09:19:07 -0700 (PDT) Received: by vws5 with SMTP id 5so9697359vws.31 for ; Wed, 28 Sep 2011 09:21:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.34.171 with SMTP id a11mr8029309vdj.313.1317226915806; Wed, 28 Sep 2011 09:21:55 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 28 Sep 2011 09:21:55 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> Date: Wed, 28 Sep 2011 18:21:55 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 16:19:08 -0000 2011/9/28 I=C3=B1aki Baz Castillo : > Just to add information about ICE Lite: > > http://tools.ietf.org/html/draft-rescorla-mmusic-ice-lite-00 However such draft is expired. Shouldn't it be considered nowadays in which, finally, we see the *real* requirements of ICE? --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Wed Sep 28 09: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 2ECDD11E80D6 for ; Wed, 28 Sep 2011 09:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.232, 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 nqBiuLcVzsFk for ; Wed, 28 Sep 2011 09:24:10 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id A280D11E80D4 for ; Wed, 28 Sep 2011 09:24:10 -0700 (PDT) Received: by pzk37 with SMTP id 37so21830784pzk.9 for ; Wed, 28 Sep 2011 09:26:59 -0700 (PDT) Received: by 10.68.32.133 with SMTP id j5mr45968930pbi.68.1317227218281; Wed, 28 Sep 2011 09:26:58 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by mx.google.com with ESMTPS id u1sm9081523pbr.9.2011.09.28.09.26.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Sep 2011 09:26:57 -0700 (PDT) Received: by pzk37 with SMTP id 37so21830673pzk.9 for ; Wed, 28 Sep 2011 09:26:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.34.138 with SMTP id z10mr45299129pbi.105.1317227215950; Wed, 28 Sep 2011 09:26:55 -0700 (PDT) Received: by 10.68.43.229 with HTTP; Wed, 28 Sep 2011 09:26:55 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> Date: Wed, 28 Sep 2011 12:26:55 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=bcaec52163034b926e04ae02dcbe Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 16:24:11 -0000 --bcaec52163034b926e04ae02dcbe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Inaki, ICE Lite is defined in RFC 5245 were procedures for lite implementation are defined side-by-side with regular one. _____________ Roman Shpount On Wed, Sep 28, 2011 at 12:21 PM, I=F1aki Baz Castillo wrot= e: > 2011/9/28 I=F1aki Baz Castillo : > > Just to add information about ICE Lite: > > > > http://tools.ietf.org/html/draft-rescorla-mmusic-ice-lite-00 > > However such draft is expired. Shouldn't it be considered nowadays in > which, finally, we see the *real* requirements of ICE? > > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec52163034b926e04ae02dcbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Inaki,

ICE Lite is defined in RFC 5245 were procedures for lite impl= ementation are defined side-by-side with regular one.
____= _________
Roman Shpount


On Wed, Sep 28, 2011 at 12:21 PM, I=F1ak= i Baz Castillo <ibc@a= liax.net> wrote:
2011/9/28 I=F1aki Baz Castillo <ibc@ali= ax.net>:
> Just to add information about ICE Lite:
>
> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-l= ite-00

However such draft is expired. Shouldn't it be considered nowaday= s in
which, finally, we see the *real* requirements of ICE?

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

--bcaec52163034b926e04ae02dcbe-- From ekr@rtfm.com Wed Sep 28 09:25: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 4AE7C1F0C6E for ; Wed, 28 Sep 2011 09:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.753 X-Spam-Level: X-Spam-Status: No, score=-102.753 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 dt7C-HfHhpT1 for ; Wed, 28 Sep 2011 09:25:06 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id F3F8F1F0C4E for ; Wed, 28 Sep 2011 09:25:02 -0700 (PDT) Received: by wwf22 with SMTP id 22so6158340wwf.13 for ; Wed, 28 Sep 2011 09:27:51 -0700 (PDT) Received: by 10.227.27.165 with SMTP id i37mr4593556wbc.106.1317227270925; Wed, 28 Sep 2011 09:27:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.196.83 with HTTP; Wed, 28 Sep 2011 09:27:08 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> From: Eric Rescorla Date: Wed, 28 Sep 2011 09:27:08 -0700 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=002215470fc2926c8504ae02df79 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 16:25:07 -0000 --002215470fc2926c8504ae02df79 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All the relevant material here was supposed to be merged into 5245. Some of it is in fact there though I can't vouch for all of it. -Ekr On Wed, Sep 28, 2011 at 9:21 AM, I=F1aki Baz Castillo wrote= : > 2011/9/28 I=F1aki Baz Castillo : > > Just to add information about ICE Lite: > > > > http://tools.ietf.org/html/draft-rescorla-mmusic-ice-lite-00 > > However such draft is expired. Shouldn't it be considered nowadays in > which, finally, we see the *real* requirements of ICE? > > -- > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --002215470fc2926c8504ae02df79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All the relevant material here was supposed to be merged into 5245. Some of= it
is in fact there though I can't vouch for all of it.
=
-Ekr


On Wed, Se= p 28, 2011 at 9:21 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2011/9/28 I=F1aki Baz Castillo <ibc@aliax.net>:
> Just to add information about ICE Lite:
>
> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-l= ite-00

However such draft is expired. Shouldn't it be considered nowaday= s in
which, finally, we see the *real* requirements of ICE?

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

--002215470fc2926c8504ae02df79-- From bernard_aboba@hotmail.com Wed Sep 28 09: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 649731F0C80 for ; Wed, 28 Sep 2011 09:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[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 2Hi2XRYNqXKk for ; Wed, 28 Sep 2011 09:28:40 -0700 (PDT) Received: from blu0-omc4-s2.blu0.hotmail.com (blu0-omc4-s2.blu0.hotmail.com [65.55.111.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED6B1F0C69 for ; Wed, 28 Sep 2011 09:28:40 -0700 (PDT) Received: from BLU152-W65 ([65.55.111.135]) by blu0-omc4-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Sep 2011 09:31:29 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_a6f532e0-1944-4e66-b976-a107e1c0389a_" X-Originating-IP: [98.237.179.165] From: Bernard Aboba To: Date: Wed, 28 Sep 2011 09:31:28 -0700 Importance: Normal In-Reply-To: <2579F4E0-9595-4ABB-9596-1FD39C91FABF@cisco.com> References: , <2579F4E0-9595-4ABB-9596-1FD39C91FABF@cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 28 Sep 2011 16:31:29.0152 (UTC) FILETIME=[13097800:01CC7DFC] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWEB and emergency services X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 16:28:41 -0000 --_a6f532e0-1944-4e66-b976-a107e1c0389a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cullen said: > Sure and the goal here should be to make sure that if someone was providi= ng a Skype like service using RTCWeb=2C that they have enough support in th= e browser to do a good job of E911 calls.=20 [BA] The key question is what exactly needs to be natively implemented in t= he browser=2C versus in Javascript libraries and even plugins. =20 For example=2C the results from W3C Location APIs (or other Javascript loca= tion APIs=2C for that matter) appear to vary greatly depending on the devic= e=2C browser and location. While in some circumstances the location accur= acy provided by a Location API could be better than that provided from say= =2C cellular Phase II=2C depending on the browser used=2C the device and t= he location=2C the Location API may not provide location or will return an = accuracy that is much worse. In some cases=2C even the country could be w= rong. As a result=2C it is probably prudent to advise applications implem= enting emergency services support to consider alternatives=2C which might i= nclude: 1. Use of Javascript libraries developed specifically to support location d= etermination for emergency purposes=3B=20 2. APIs which provide browser applications with access to the underlying te= lephony platform (such as the Mozilla WebAPI) > My take is that the PSAP will forever be behind the times technology wise= and underfunded.=20 [BA] Looking at the fiscal situation in most countries=2C and the current = funding models=2C that's probably a reasonable conclusion. =20 > > For example=2C a "webphone" intended for use with an IP PBX=2C whose f= irmware is controlled by the IP PBX vendor=2C could include within its cod= e load plugins to provide additional functionality=2C including signaling p= rotocols and codecs. >=20 > I agree one could do that - but they could do anything and that is well c= ontext of this. I's just ignore all that stuff. And I think it is fine if t= here are things in phone BCP that you end up saying=2C sorry=2C can't do th= at with RTCWeb - would need something else.=20 [BA] There a number of potential requirements in PhoneBCP that could be co= nsidered onerous to implement natively. An example is ED-77=2C which rela= tes to video codecs. A limited set of RTCWeb applications will require th= e ability to send video to a PSAP. Should every RTCWeb-enabled browser be= required to natively support requirements like this? I would suggest that= the answer is no. Where applications are implemented on a dedicated device=2C it might be qu= ite reasonable for the required codec support to be provided in a plugin. = Also=2C there might be situations where having a mandatory-to-implement vid= eo codec of any kind would be sufficient to provide interoperability. For= example=2C consider an application which connects a caller to an ASL inter= preter so as to implement a browser-based Video Relay Service (VRS). In th= at application=2C there is no need to satisfy ED-77=2C if the caller and th= e interpreter implement a common video codec. =20 > Hmm=2C I think your draft will lead to some interesting discussion on thi= s. Browser JS is a surprisingly limited environment. It may be that your dr= aft raises some addition requirements that the OS needs to reveal to the br= owser and the browser needs to expose to the JS. I'm thinking of things lik= e information that came in DHCP options=2C and doing things like finding th= e browser location *before* bringing up a VPN.=20 [BA] Yes=2C this is one of the key aspects that we need to talk about. Ric= hard Barnes has done some work that may be relevant here.=20 = --_a6f532e0-1944-4e66-b976-a107e1c0389a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Cullen said:

>=3B Sure and the goal here should be to make su= re that if someone was providing a Skype like service using RTCWeb=2C that = they have enough support in the browser to do a good job of E911 calls.
[BA] The key question is what exactly needs to be natively implemented= in the browser=2C versus in Javascript libraries and even plugins. =3B=

For example=2C the results from W3C Location APIs (or other Javasc= ript location APIs=2C for that matter) appear to vary greatly depending on = the device=2C browser and location.  =3B While in some circumstances th= e location accuracy provided by a Location API could be better than that pr= ovided from say=2C cellular Phase II=2C =3B depending on the browser us= ed=2C the device and the location=2C the Location API may not provide locat= ion or will return an accuracy that is much worse. =3B =3B In some = cases=2C even the country could be wrong. =3B =3B As a result=2C it= is probably prudent to advise applications implementing emergency services= support to consider alternatives=2C which might include:

1. Use of = Javascript libraries developed specifically to support location determinati= on for emergency purposes=3B
2. APIs which provide browser applications= with access to the underlying telephony platform (such as the Mozilla WebA= PI)

>=3B My take is that the PSAP will forever be behind the times= technology wise and underfunded.

[BA] =3B Looking at the fisca= l situation in most countries=2C and the current funding models=2C that's p= robably a reasonable conclusion. =3B

>=3B >=3B For example= =2C a "webphone" intended for use with an IP PBX=2C whose firmware is contr= olled by the IP PBX vendor=2C could include within its code load plugins t= o provide additional functionality=2C including signaling protocols and cod= ecs.
>=3B
>=3B I agree one could do that - but they could do any= thing and that is well context of this. I's just ignore all that stuff. And= I think it is fine if there are things in phone BCP that you end up saying= =2C sorry=2C can't do that with RTCWeb - would need something else.
[BA] =3B There a number of potential requirements in PhoneBCP that cou= ld be considered onerous to implement natively.  =3B An example is ED-7= 7=2C which relates to video codecs. =3B =3B A limited set of RTCWeb= applications will require the ability to send video to a PSAP. =3B&nbs= p=3B Should every RTCWeb-enabled browser be required to natively support re= quirements like this? =3B I would suggest that the answer is no.
Where applications are implemented on a dedicated device=2C =3B it mig= ht be quite reasonable for the required codec support to be provided in a p= lugin. =3B Also=2C there might be situations where having a mandatory-t= o-implement video codec of any kind would be sufficient to provide =3B = interoperability. =3B For example=2C consider an application which conn= ects a caller to an ASL interpreter so as to implement a browser-based Vide= o Relay Service (VRS). =3B In that application=2C there is no need to s= atisfy ED-77=2C if the caller and the interpreter implement a common video = codec. =3B

>=3B Hmm=2C I think your draft will lead to some i= nteresting discussion on this. Browser JS is a surprisingly limited environ= ment. It may be that your draft raises some addition requirements that the = OS needs to reveal to the browser and the browser needs to expose to the JS= . I'm thinking of things like information that came in DHCP options=2C and = doing things like finding the browser location *before* bringing up a VPN. =

[BA] Yes=2C this is one of the key aspects that we need to talk abo= ut. =3B Richard Barnes has done some work that may be relevant here.
= --_a6f532e0-1944-4e66-b976-a107e1c0389a_-- From harald@alvestrand.no Wed Sep 28 09:28: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 EE0FC1F0C83 for ; Wed, 28 Sep 2011 09:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.853 X-Spam-Level: X-Spam-Status: No, score=-108.853 tagged_above=-999 required=5 tests=[AWL=1.446, 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 6JmLvCNUYHsQ for ; Wed, 28 Sep 2011 09:28:49 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 41DC61F0C82 for ; Wed, 28 Sep 2011 09:28:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 868FD39E0BB; Wed, 28 Sep 2011 18:31:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQihE-e7cux0; Wed, 28 Sep 2011 18:31:37 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 1458239E051; Wed, 28 Sep 2011 18:31:37 +0200 (CEST) Message-ID: <4E834BE8.9060303@alvestrand.no> Date: Wed, 28 Sep 2011 18:31:36 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 16:28:50 -0000 On 09/28/11 18:21, Iñaki Baz Castillo wrote: > 2011/9/28 Iñaki Baz Castillo: >> Just to add information about ICE Lite: >> >> http://tools.ietf.org/html/draft-rescorla-mmusic-ice-lite-00 > However such draft is expired. Shouldn't it be considered nowadays in > which, finally, we see the *real* requirements of ICE? > Browsers have to implement full ICE. ICE-Lite is described in RFC 5245 - section 2.7, 4.2, 7.2.2 may be particularly relevant. There's an introduction to the subject in appendix A of the RFC. Seriously, if you want to discuss ICE, it helps to read the RFC. Harald From ibc@aliax.net Wed Sep 28 09:30: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 A49B31F0C69 for ; Wed, 28 Sep 2011 09:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fn+B8enDu-Ri for ; Wed, 28 Sep 2011 09:30: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 11EE61F0C81 for ; Wed, 28 Sep 2011 09:30:04 -0700 (PDT) Received: by vws5 with SMTP id 5so9711794vws.31 for ; Wed, 28 Sep 2011 09:32:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.186.134 with SMTP id fk6mr1428605vdc.380.1317227573263; Wed, 28 Sep 2011 09:32:53 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Wed, 28 Sep 2011 09:32:53 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> Date: Wed, 28 Sep 2011 18:32:53 +0200 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: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 16:30:05 -0000 2011/9/28 Roman Shpount : > ICE Lite is defined in RFC 5245 were procedures for lite implementation a= re > defined side-by-side with regular one. Thanks for the explanation. --=20 I=C3=B1aki Baz Castillo From fluffy@cisco.com Wed Sep 28 10: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 A963A1F0C5E for ; Wed, 28 Sep 2011 10:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.054 X-Spam-Level: X-Spam-Status: No, score=-103.054 tagged_above=-999 required=5 tests=[AWL=-0.455, 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 waSMZi6Uux7B for ; Wed, 28 Sep 2011 10:01:27 -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 2AF601F0C56 for ; Wed, 28 Sep 2011 10:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3009; q=dns/txt; s=iport; t=1317229456; x=1318439056; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=PNY+90/xejHZG//8OW40XGmRTGwdc9GNDuZVSnvTHG8=; b=BwpXOthp0qFnO0lyd+C2b2V5kGObiT7bfJIoyeSIrrosbZyY6ew7QVQ2 kxH0a665+XoPwcMWM7XJRZBgSI2nyNiZ9xM9pixVjw5xRqVLLlqKy1Qqc X3BrGlfPRKdyjmhunxspMFyCxh/TM8zH35HfrZ92yHEWP0pkwyDt9MkGR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABlTg06rRDoH/2dsb2JhbABCqAp4gVMBAQEBAgESASc/EAsYLlcGExsHh1aaKQGeK4YrYQSHcotjhSKMMg X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="4809371" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 28 Sep 2011 17:04:15 +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 p8SH4D8v006473; Wed, 28 Sep 2011 17:04:14 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 28 Sep 2011 11:04:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> To: Roman Shpount X-Mailer: Apple Mail (2.1084) Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 17:01:27 -0000 On Sep 28, 2011, at 10:01 AM, Roman Shpount wrote: >=20 > On Wed, Sep 28, 2011 at 10:42 AM, Cullen Jennings = wrote: > Many service providers front end their services with an SBC for a wide = variety of reasons - and that is the place they would likely run ICE = Lite (note it's not even full ICE they need). >=20 > I understand that this can be considered advertisement on the forum, = but does ACME, Sonus and Genband SBC support ICE or ICE lite? As far as = I know they do not. If I am wrong and they do, how long did they have = this support? If they do not, does anybody know what their plans are? I'll note some vendors have both SBC and endpoints that do ICE but = clearly not all of them - only the ones where there was a market for it. = My experience with ACME and Sonus has been they will provide what the = market needs. Today the "SIP Trunking" is used in situation where no ICE = is needed and keep in mind most the SBC vendors have other solutions for = the pure NAT traversal part of the problem that predate ICE.=20 When a single large voice provider asked it's sip trunking providers to = add iLBC, they asked the gateway providers to add it. Pretty much every = major gateway vendor added it - for a single voice service provider - = and that was probably harder than adding ICE. Vendors don't build = something because the IETF made an RFC - they build it because it meets = a customer need. If we could solve this problem without ICE, or = something about the same, clearly we would, but if we can't, vendors = will build the minimum they need to meet market needs. The fact they = will build the minimum is why VoIP, and the internet, just barely works. = There no point in doing more than that. >=20 > Sorry for such direct line of questioning, but dealing with SIP trunk = providers in US, you interface to an SBC from one of those vendors. So, = if these vendors support ICE, most of the SIP trunk providers would be = able to support ICE. >=20 > Even with this covered, we still have an issue of supporting ICE by = PBXs and IP Phones. As far as I know (and my information can be = outdated), Polycom and Cisco phones do not support ICE. I am not sure = about the others, but from what I've generally seen hardware phones in = vast majority do not support ICE. I agree with you point that the majority of deployed phones don't = support ICE. But so what, what do you propose to do. One thing that is = not going to happen is browser vendors do something which makes browsers = such a security threat that the browsers are banned from every corporate = network. Solutions like CORS solve the problem but short of something = like that, I don't see browser vendors deciding that remove same origin = policy is a good idea.=20 >=20 > Please correct me if I am wrong about any of this. I am mostly trying = to determine the level of current market support for ICE. > _____________ > Roman Shpount >=20 From tim@phonefromhere.com Wed Sep 28 11: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 04D0E21F8C0F for ; Wed, 28 Sep 2011 11:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7gLJ54WFA6o for ; Wed, 28 Sep 2011 11:07:39 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF5521F8C0C for ; Wed, 28 Sep 2011 11:07:33 -0700 (PDT) Received: from [10.10.10.149] (70-36-236-129.dsl.static.sonic.net [70.36.236.129]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id A800437A902; Wed, 28 Sep 2011 19:23:09 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_E127057F-3B1C-4B80-A9E4-13756EE4681F" From: Tim Panton In-Reply-To: Date: Wed, 28 Sep 2011 11:09:25 -0700 Message-Id: <9C0BD967-A31E-4ABF-AB6F-CD635E53B82C@phonefromhere.com> References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> To: Roman Shpount X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Low Level Javascript API Proposal avail on the webrtc list X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 18:07:40 -0000 --Apple-Mail=_E127057F-3B1C-4B80-A9E4-13756EE4681F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 28 Sep 2011, at 09:12, Roman Shpount wrote: > Few questions that I have in regard to this: (Neil seems to be having trouble posting to this list - so I'm = forwarding his reply): Answers inline: > 1. How can you get local codec capabilities to implement something = like > SIP OPTIONS? The local codecs and capabilities can be queried at any time, returned as a json object to the javascript. This is really just asking the browser what codecs it supports, which we have separated out from SDP negotiation. > 2. Can you specify multiple stun/turn/turns servers? If you do what is > the candidate generation process? On the same note why do we provide > both stun and turn relays? Isn't turn server is normally stun server = as > well? I believe that you should be able to specify multiple servers if you wanted to and that all candidates would be generated and tested based on priorities etc. One relay may be in a better physical location for instance than another for a given pair of users. There may be cases when you want to specify both a stun and turn relay even if the turn server can serve both purposes, for example as a = backup. > 3. How do you process multiple answers for the same dialog? > 4. What do we do with multiple answers from a forked dialog? Is it = even > supported? The intention is that we leave that to the javascript (library) developer to decide how best to handle it. Forking presents some interesting challenges. > 5. What is the process for synchronizing audio and video streams? We have the concept of a synchronization group as an attribute that can be applied to streams, the intention being that those streams in the same group should be synchronized by the lower layers if possible using whatever mechanism they can. > On Wed, Sep 28, 2011 at 11:59 AM, Tim Panton = wrote: > I just want to ask folks to take a look at a proposal Neil Stratford = wrote for the > Low Level Javascript API and sent to the webrtc list. >=20 > It is based on his and my experience of web based audio plugins and = on a > proposal of Cullen's a while back. >=20 > http://lists.w3.org/Archives/Public/public-webrtc/2011Sep/0106.html >=20 > We'd appreciate any feedback either here or on the webrtc list as = appropriate. >=20 > Tim. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --Apple-Mail=_E127057F-3B1C-4B80-A9E4-13756EE4681F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Few = questions that I have in regard to this:
(Neil seems to = be having trouble posting to this list - so I'm forwarding his = reply):

Answers inline:

1. How can you get local codec capabilities to implement = something like
SIP = OPTIONS?

The local codecs and capabilities can be = queried at any time, returned
as a json object to the javascript. = This is really just asking the
browser what codecs it supports, which = we have separated out from SDP
negotiation.

2. Can you specify multiple stun/turn/turns servers? If = you do what is
the candidate = generation process? On the same note why do we = provide
both stun and turn = relays? Isn't turn server is normally stun server = as
well?

I = believe that you should be able to specify multiple servers if = you
wanted to and that all candidates would be generated and tested = based on
priorities etc. One relay may be in a better physical = location for
instance than another for a given pair of = users.

There may be cases when you want to specify both a stun = and turn relay
even if the turn server can serve both purposes, for = example as a backup.

3. How do you = process multiple answers for the same = dialog?
4. What do we do with = multiple answers from a forked dialog? Is it = even
supported?

The intention is that we = leave that to the javascript (library)
developer to decide how best = to handle it. Forking presents some
interesting = challenges.

5. What is the process for = synchronizing audio and video streams?

We have the = concept of a synchronization group as an attribute that can
be = applied to streams, the intention being that those streams in = the
same group should be synchronized by the lower layers if possible = using
whatever mechanism they = can.


On Wed, Sep 28, 2011 at 11:59 = AM, Tim Panton <tim@phonefromhere.com>= wrote:
I just want to ask folks to take a look at a proposal Neil Stratford = wrote for the
Low Level Javascript API and sent to the webrtc list.

It  is based on his and my experience of web based audio plugins = and on a
proposal of Cullen's a while back.

http://lists.w3.org/Archives/Public/public-webrtc/2011Se= p/0106.html

We'd appreciate any feedback either here or on the webrtc list as = appropriate.

Tim.

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


= --Apple-Mail=_E127057F-3B1C-4B80-A9E4-13756EE4681F-- From oej@edvina.net Wed Sep 28 11:59: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 0A22721F8DC8 for ; Wed, 28 Sep 2011 11:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKLwhv0O9gff for ; Wed, 28 Sep 2011 11:59:43 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id CB12A21F8DC9 for ; Wed, 28 Sep 2011 11:59:42 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 83608754BD14; Wed, 28 Sep 2011 19:02:28 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_DDB0E62F-631E-4EFE-BFA5-6D6E69E46025" From: "Olle E. Johansson" In-Reply-To: Date: Wed, 28 Sep 2011 21:02:54 +0200 Message-Id: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> <4E821E47.4080205@alve strand.no> To: Roman Shpount X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 18:59:44 -0000 --Apple-Mail=_DDB0E62F-631E-4EFE-BFA5-6D6E69E46025 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 28 sep 2011 kl. 01:20 skrev Roman Shpount: > My point is, if you have a trust relationship with a site, ICE = validation can be bypassed, i.e. if you trust the application on the = site you trust it not to do something malicious with your media. =20 These kind of statements may work for "you", which is us on this list, = but I do not like having to force users to have to evaluate trust in = regards to website. They will fail and the app will do bad things. I agree with Eric, I don't see a point with disabling ICE ever. It is = needed both for NAT, for IPv6/IPv4 and for consent of the media streams. = There are very many situations within a trusted network where at least = one of these functions are needed. And users can not determine when. /O= --Apple-Mail=_DDB0E62F-631E-4EFE-BFA5-6D6E69E46025 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
My point is, = if you have a trust relationship with a site, ICE validation can be = bypassed, i.e. if you trust the application on the site you trust it not = to do something malicious with your media.  

These kind of statements may work for "you", which is us on this = list, but I do not like having to force users to have to evaluate trust = in regards to website. They will fail and the app will do bad = things.

I agree with Eric, I don't see a point = with disabling ICE ever. It is needed both for NAT, for IPv6/IPv4 and = for consent of the media streams. There are very many situations within = a trusted network where at least one of these functions are needed. And = users can not determine = when.

/O
= --Apple-Mail=_DDB0E62F-631E-4EFE-BFA5-6D6E69E46025-- From oej@edvina.net Wed Sep 28 12:07: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 7319E1F0CDA for ; Wed, 28 Sep 2011 12:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 ra7drZFPNzQK for ; Wed, 28 Sep 2011 12:07:03 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6571F0C62 for ; Wed, 28 Sep 2011 12:07:02 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 06BB4754BCE4; Wed, 28 Sep 2011 19:09:46 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_12106025-1ADB-41E3-B4AE-5A60593455E7" From: "Olle E. Johansson" In-Reply-To: Date: Wed, 28 Sep 2011 21:10:12 +0200 Message-Id: <6FA62263-46BE-4019-A65F-DECE62AD98B3@edvina.net> References: <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> <4E8265D3.5020 809@skype.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 19:07:04 -0000 --Apple-Mail=_12106025-1ADB-41E3-B4AE-5A60593455E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 28 sep 2011 kl. 10:36 skrev I=F1aki Baz Castillo: > But I don't think the same for SRTP. I don't consider that content > carried via plain RTP is more important than content carried via HTTP, > and AFAIK HTTPS is not a requirement in RFC 2616, neither in any web > browser. If you look into your web browser, you will see that more and more sites = are moving to only HTTPS. There's a reason for that. Facebook, Twitter = and many others. Large sites that are not "banks", but social media or = just information sites like www.iis.se. When HTTP was written there wasn't CPU enough to handle mandatory SSL. = Now we have CPU power to handle it and encryption accelerators are much = cheaper. The world is different and comparing the situation we have now = with what was reality when RFC 2616 was written is a bad comparision = that I would not consider valid. (I=F1aki: I see that we have fun some discussions ahead of us at = Voip2day.net in Madrid next week :-) ) /O= --Apple-Mail=_12106025-1ADB-41E3-B4AE-5A60593455E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
But I = don't think the same for SRTP. I don't consider that content
carried = via plain RTP is more important than content carried via HTTP,
and = AFAIK HTTPS is not a requirement in RFC 2616, neither in any = web
browser.

If you look = into your web browser, you will see that more and more sites are moving = to only HTTPS. There's a reason for that. Facebook, Twitter and many = others. Large sites that are not "banks", but social media or just = information sites  like www.iis.se.

When = HTTP was written there wasn't CPU enough to handle mandatory SSL. Now we = have CPU power to handle it and encryption accelerators are much = cheaper. The world is different and comparing  the situation we = have now with what was reality when RFC 2616 was written is a bad = comparision that I would not consider = valid.

(I=F1aki: I see that we have fun some = discussions ahead of us at Voip2day.net in Madrid next week :-) = )
/O
= --Apple-Mail=_12106025-1ADB-41E3-B4AE-5A60593455E7-- From oej@edvina.net Wed Sep 28 12:14: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 DACDF1F0CC2 for ; Wed, 28 Sep 2011 12:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAeoIpr51gVP for ; Wed, 28 Sep 2011 12:14:10 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id F25481F0C62 for ; Wed, 28 Sep 2011 12:14:09 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 95BE0754BCE5; Wed, 28 Sep 2011 19:16:57 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_7A0E1CFF-6B02-4A40-AE63-C085F99148CD" From: "Olle E. Johansson" In-Reply-To: <4E830E89.3050400@alvestrand.no> Date: Wed, 28 Sep 2011 21:17:24 +0200 Message-Id: <3E66F9FC-C37B-41E5-ACF4-E1CDEB6E4DC6@edvina.net> References: <4E830E89.3050400@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1244.3) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] ICE for dual stacks (new topic) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 19:14:11 -0000 --Apple-Mail=_7A0E1CFF-6B02-4A40-AE63-C085F99148CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 28 sep 2011 kl. 14:09 skrev Harald Alvestrand: >> Added an explicit statement that ICE is required for both NAT and >> consent-to-receive. I would like to bring IPv4/IPv6 transition to the table in the ICE = discussion. Quoting=20 http://tools.ietf.org/html/rfc6157 - abot SIP IPv6 transition: ------------ When following the ICE procedures, in addition to local addresses, user agents may need to obtain addresses from relays; for example, an IPv6 user agent would obtain an IPv4 address from a relay. The relay would forward the traffic received on this IPv4 address to the user agent using IPv6. Such user agents MAY use any mechanism to obtain addresses in relays, but, following the recommendations in ICE, it is RECOMMENDED that user agents support STUN relay usage [6] [8] for this purpose. IPv4/IPv6 user agents SHOULD gather both IPv4 and IPv6 addresses using the ICE procedures to generate all their offers. This way, both IPv4-only and IPv6-only answerers will be able to generate a mutually acceptable answer that establishes a session (having used ICE to gather both IPv4 and IPv6 addresses in the offer reduces the session establishment time because all answerers will find the offer valid.) ----- Now, I know this has been discussed widely and there are some drafts = that discusses this. Dan Wing writes in http://tools.ietf.org/html/draft-wing-dispatch-v6-migration-00 To achieve a similar function on the media plane, SIP endpoints are expected to use connectivity checks [RFC5245] to ensure there is IPv6 (or IPv4) connectivity. ICE has an advantage over the technique currently used by web browser, in that ICE does not wait for a user- noticeable timeout before trying other addresses. However, ICE is considered overkill for the problem of migrating to IPv6 because of the overhead of timers, interaction with existing media state machines, and CPU impact of SHA1 on large devices processing many sessions and on small devices. My question is of course what the opinion is about this in regards to = our work in rtcweb? /O --Apple-Mail=_7A0E1CFF-6B02-4A40-AE63-C085F99148CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Added an explicit statement that ICE is = required for both NAT and
  consent-to-receive.

I would like to bring IPv4/IPv6 = transition to the table in the ICE discussion. = Quoting 
http://tools.ietf.org/html/rfc= 6157 - abot SIP IPv6 = transition:

------------

When following the =
ICE procedures, in addition to local addresses,
   user agents may need to obtain addresses from relays; for example, an
   IPv6 user agent would obtain an IPv4 address from a relay.  The relay
   would forward the traffic received on this IPv4 address to the user
   agent using IPv6.  Such user agents MAY use any mechanism to obtain
   addresses in relays, but, following the recommendations in ICE, it is
   RECOMMENDED that user agents support STUN relay usage [6] [8] for
   this purpose.

   IPv4/IPv6 user agents SHOULD gather both IPv4 and IPv6 addresses
   using the ICE procedures to generate all their offers.  This way,
   both IPv4-only and IPv6-only answerers will be able to generate a
   mutually acceptable answer that establishes a session (having used
   ICE to gather both IPv4 and IPv6 addresses in the offer reduces the
   session establishment time because all answerers will find the offer
   =
valid.)

-----

Now= , I know this has been discussed widely and there are some drafts that = discusses this. Dan Wing writes in

RFC5245] to ensure there is IPv6
   (or IPv4) connectivity.  ICE has an advantage over the technique
   currently used by web browser, in that ICE does not wait for a user-
   noticeable timeout before trying other addresses.  However, ICE is
   considered overkill for the problem of migrating to IPv6 because of
   the overhead of timers, interaction with existing media state
   machines, and CPU impact of SHA1 on large devices processing many
   sessions and on small =
devices.


My = question is of course what the opinion is about this in regards to our = work in = rtcweb?

/O

= --Apple-Mail=_7A0E1CFF-6B02-4A40-AE63-C085F99148CD-- From roman@telurix.com Wed Sep 28 12: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 1EC331F0CDA for ; Wed, 28 Sep 2011 12:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.377, 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 WuaNID5bVF7k for ; Wed, 28 Sep 2011 12:24:59 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B72121F8D85 for ; Wed, 28 Sep 2011 12:24:59 -0700 (PDT) Received: by qyk32 with SMTP id 32so2444717qyk.10 for ; Wed, 28 Sep 2011 12:27:47 -0700 (PDT) Received: by 10.229.2.106 with SMTP id 42mr7166678qci.12.1317238067592; Wed, 28 Sep 2011 12:27:47 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by mx.google.com with ESMTPS id du5sm29476040qab.14.2011.09.28.12.27.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Sep 2011 12:27:47 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so6993075vcb.31 for ; Wed, 28 Sep 2011 12:27:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.34.138 with SMTP id z10mr46296953pbi.105.1317238065726; Wed, 28 Sep 2011 12:27:45 -0700 (PDT) Received: by 10.68.40.197 with HTTP; Wed, 28 Sep 2011 12:27:45 -0700 (PDT) In-Reply-To: <6FA62263-46BE-4019-A65F-DECE62AD98B3@edvina.net> References: <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <4E820825.9090101@skype.net> <4E821E47.4080205@alvestrand.no> <6FA62263-46BE-4019-A65F-DECE62AD98B3@edvina.net> Date: Wed, 28 Sep 2011 15:27:45 -0400 Message-ID: From: Roman Shpount To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=bcaec5216303fe057604ae0562bc Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 19:25:00 -0000 --bcaec5216303fe057604ae0562bc Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 28, 2011 at 3:10 PM, Olle E. Johansson wrote: > If you look into your web browser, you will see that more and more sites > are moving to only HTTPS. There's a reason for that. Facebook, Twitter and > many others. Large sites that are not "banks", but social media or just > information sites like www.iis.se. > > When HTTP was written there wasn't CPU enough to handle mandatory SSL. Now > we have CPU power to handle it and encryption accelerators are much cheaper. > The world is different and comparing the situation we have now with what > was reality when RFC 2616 was written is a bad comparision that I would not > consider valid. > > This is not about CPU power -- the CPU impact of SRTP is a lot smaller then the CPU impact of a lower bitrate codec. The problem with SRTP is that debugging becomes much harder and vast majority of the current VoIP monitoring tools will stop working. You can no longer use a simple packet capture to create call logs and quality metrics for the voip call. You cannot even do it for a particular client that is experiencing problem. AFAK service provider can turn off encryption on GSM calls for troubleshooting purposes. I think RTC should be able to do the same. Doing interop, if all you have is SRTP, would become much harder, even if this is an interop between two web browsers. _____________ Roman Shpount --bcaec5216303fe057604ae0562bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Sep 28, 2011 at 3:10 PM, Olle E.= Johansson <oej@edvi= na.net> wrote:
If you look into your web browser, you = will see that more and more sites are moving to only HTTPS. There's a r= eason for that. Facebook, Twitter and many others. Large sites that are not= "banks", but social media or just information sites =A0like www.iis.se.

When HTTP was written there wasn't CPU enough to handle = mandatory SSL. Now we have CPU power to handle it and encryption accelerato= rs are much cheaper. The world is different and comparing =A0the situation = we have now with what was reality when RFC 2616 was written is a bad compar= ision that I would not consider valid.


This is not about CPU power -- the CPU imp= act of SRTP is a lot smaller then the CPU impact of a lower bitrate codec. = The problem with SRTP is that debugging becomes much harder and vast majori= ty of the current VoIP monitoring tools will stop working. You can no longe= r use a simple packet capture to create call logs and quality metrics for t= he voip call. You cannot even do it for a particular client that is experie= ncing problem. AFAK service provider can turn off encryption on GSM calls f= or troubleshooting purposes. I think RTC should be able to do the same. Doi= ng interop, if all you have is SRTP, would become much harder, even if this= is an interop between two web browsers.
_____________
Roman Shpount
--bcaec5216303fe057604ae0562bc-- From roman@telurix.com Wed Sep 28 12:28: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 C379811E80FF for ; Wed, 28 Sep 2011 12:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=0.369, 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 hsBVDyb+Ysdf for ; Wed, 28 Sep 2011 12:28:46 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 591EB11E80F6 for ; Wed, 28 Sep 2011 12:28:46 -0700 (PDT) Received: by pzk37 with SMTP id 37so22250183pzk.9 for ; Wed, 28 Sep 2011 12:31:35 -0700 (PDT) Received: by 10.68.36.166 with SMTP id r6mr46357603pbj.77.1317238295477; Wed, 28 Sep 2011 12:31:35 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by mx.google.com with ESMTPS id lh6sm3778510pbb.12.2011.09.28.12.31.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Sep 2011 12:31:34 -0700 (PDT) Received: by pzk37 with SMTP id 37so22250122pzk.9 for ; Wed, 28 Sep 2011 12:31:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.4.170 with SMTP id l10mr2241531pbl.3.1317238293867; Wed, 28 Sep 2011 12:31:33 -0700 (PDT) Received: by 10.68.40.197 with HTTP; Wed, 28 Sep 2011 12:31:33 -0700 (PDT) In-Reply-To: <3E66F9FC-C37B-41E5-ACF4-E1CDEB6E4DC6@edvina.net> References: <4E830E89.3050400@alvestrand.no> <3E66F9FC-C37B-41E5-ACF4-E1CDEB6E4DC6@edvina.net> Date: Wed, 28 Sep 2011 15:31:33 -0400 Message-ID: From: Roman Shpount To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=bcaec5215f35972e4a04ae057073 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] ICE for dual stacks (new topic) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 19:28:46 -0000 --bcaec5215f35972e4a04ae057073 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 28, 2011 at 3:17 PM, Olle E. Johansson wrote: > My question is of course what the opinion is about this in regards to our > work in rtcweb? > > If we are mandating ICE we should use it for dual network clients. It is an overkill if this is the only reason for doing it, but since we also doing for NAT traversal and peer validation, this is the best solution currently available. _____________ Roman Shpount --bcaec5215f35972e4a04ae057073 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 28, 2011 at 3:17 PM, Olle E. Joh= ansson <oej@edvina.n= et> wrote:
My question is of course what the opini= on is about this in regards to our work in rtcweb?

=A0
If we are mandating ICE we should use it for d= ual network clients. It is an overkill if this is the only reason for doing it, but since we also=20 doing for NAT traversal and peer validation, this is the best solution=20 currently available.
_____________
Roman Shpount

--bcaec5215f35972e4a04ae057073-- From roman@telurix.com Wed Sep 28 12:41: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 0D64C11E811D for ; Wed, 28 Sep 2011 12:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=0.361, 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 mmiyCQojomDH for ; Wed, 28 Sep 2011 12:41:29 -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 69E6811E80FF for ; Wed, 28 Sep 2011 12:41:29 -0700 (PDT) Received: by gyd12 with SMTP id 12so8153364gyd.31 for ; Wed, 28 Sep 2011 12:44:18 -0700 (PDT) Received: by 10.236.132.81 with SMTP id n57mr58153045yhi.47.1317239057922; Wed, 28 Sep 2011 12:44:17 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id w50sm23196533yhi.2.2011.09.28.12.44.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Sep 2011 12:44:17 -0700 (PDT) Received: by yxt33 with SMTP id 33so8308417yxt.31 for ; Wed, 28 Sep 2011 12:44:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.33.130 with SMTP id r2mr46289353pbi.71.1317239056342; Wed, 28 Sep 2011 12:44:16 -0700 (PDT) Received: by 10.68.40.197 with HTTP; Wed, 28 Sep 2011 12:44:16 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> Date: Wed, 28 Sep 2011 15:44:16 -0400 Message-ID: From: Roman Shpount To: Cullen Jennings Content-Type: multipart/alternative; boundary=bcaec520f611099e6004ae059e39 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 19:41:30 -0000 --bcaec520f611099e6004ae059e39 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 28, 2011 at 1:04 PM, Cullen Jennings wrote: > I agree with you point that the majority of deployed phones don't support > ICE. But so what, what do you propose to do. One thing that is not going to > happen is browser vendors do something which makes browsers such a security > threat that the browsers are banned from every corporate network. Solutions > like CORS solve the problem but short of something like that, I don't see > browser vendors deciding that remove same origin policy is a good idea. > > As I wrote before, you can use RTC not only in the desktop browser but also in the desktop phone. It is not unreasonable to use the same CPU platform being used in mobile phones and build a desk IP phone which primarily runs the web browser to control its screen and uses RTC to setup voice/video calls. This phone can be a much better and more extendable standard platform for building UC solutions then most of the current SIP phones. The problem is if standard requires ICE/SRTP this phone will not be able to work with most of the current enterprise phones. Once again, since this can be considered a marginal use case, we don't need to cover it in the standard and the phone vendor can just ignore that ICE requirement since it knows that the phone is located in the fully controlled network. _____________ Roman Shpount --bcaec520f611099e6004ae059e39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Sep 28, 2011 at 1:04 PM, Cullen Jenn= ings <fluffy@cisco= .com> wrote:
I agree with you point that the majority of deployed phones don't suppo= rt ICE. But so what, what do you propose to do. One thing that is not going= to happen is browser vendors do something which makes browsers such a secu= rity threat that the browsers are banned from every corporate network. Solu= tions like CORS solve the problem but short of something like that, I don&#= 39;t see browser vendors deciding that remove same origin policy is a good = idea.


As I wrote before, you can use RTC not only in t= he desktop browser but also in the desktop phone. It is not unreasonable to= use the same CPU platform being used in mobile phones and build a desk IP = phone which primarily runs the web browser to control its screen and uses R= TC to setup voice/video calls. This phone can be a much better and more ext= endable standard platform for building UC solutions then most of the curren= t SIP phones. The problem is if standard requires ICE/SRTP this phone will = not be able to work with most of the current enterprise phones. Once again,= since this can be considered a marginal use case, we don't need to cov= er it in the standard and the phone vendor can just ignore that ICE require= ment since it knows that the phone is located in the fully controlled netwo= rk.
_____________
Roman Shpount

--bcaec520f611099e6004ae059e39-- From fluffy@cisco.com Wed Sep 28 12:46: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 F3C231F0CDA for ; Wed, 28 Sep 2011 12:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.051 X-Spam-Level: X-Spam-Status: No, score=-103.051 tagged_above=-999 required=5 tests=[AWL=-0.452, 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 csOf+imWGE00 for ; Wed, 28 Sep 2011 12:46:12 -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 8A3E11F0CD3 for ; Wed, 28 Sep 2011 12:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1744; q=dns/txt; s=iport; t=1317239342; x=1318448942; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Vb2GTHWjUi+27gJo/pc5GH4mRRYYlG2fvEUR1L/SoOE=; b=gK3cGxEckYleCJuuBPMKcN6ma/FRF7LG4nB2n9recKcknHnxNFnDHl8U qNpTZJmxVYRNUFsRHTIeYVwmMCp/dLxcT3tu/vVfvsf0QRkfy9Smqk8Qh AHfEJuH2e5fOfSPR0Xq+7Tbdybw2HCvpHqPsskvSimDfN08vw5Y+tVePI M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF95g06rRDoG/2dsb2JhbABCqAd4gVMBAQEBAgESASc/EAsYLlcGExsHh1aZewGeJoYrYQSHcotjhSKMMg X-IronPort-AV: E=Sophos;i="4.68,456,1312156800"; d="scan'208";a="4851746" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 28 Sep 2011 19:49:01 +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 p8SJn03c028342; Wed, 28 Sep 2011 19:49:00 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 28 Sep 2011 13:49:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> To: Roman Shpount X-Mailer: Apple Mail (2.1084) Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 19:46:13 -0000 On Sep 28, 2011, at 1:44 PM, Roman Shpount wrote: >=20 > On Wed, Sep 28, 2011 at 1:04 PM, Cullen Jennings = wrote: > I agree with you point that the majority of deployed phones don't = support ICE. But so what, what do you propose to do. One thing that is = not going to happen is browser vendors do something which makes browsers = such a security threat that the browsers are banned from every corporate = network. Solutions like CORS solve the problem but short of something = like that, I don't see browser vendors deciding that remove same origin = policy is a good idea. >=20 >=20 > As I wrote before, you can use RTC not only in the desktop browser but = also in the desktop phone. It is not unreasonable to use the same CPU = platform being used in mobile phones and build a desk IP phone which = primarily runs the web browser to control its screen and uses RTC to = setup voice/video calls. This phone can be a much better and more = extendable standard platform for building UC solutions then most of the = current SIP phones. The problem is if standard requires ICE/SRTP this = phone will not be able to work with most of the current enterprise = phones. Once again, since this can be considered a marginal use case, we = don't need to cover it in the standard and the phone vendor can just = ignore that ICE requirement since it knows that the phone is located in = the fully controlled network. > _____________ > Roman Shpount >=20 Sure, in that sort of case, I'm sure lots of the code being open sourced = for RTCweb will will be reused to build phones and modified in ways like = you suggest - but as you say, that's outside the scope of what we want = to solve here.=20 From henry.sinnreich@gmail.com Wed Sep 28 15:57: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 6CD2911E8091 for ; Wed, 28 Sep 2011 15:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=0.371, 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 RVUayvA3mkF2 for ; Wed, 28 Sep 2011 15:57:04 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id C756811E80AD for ; Wed, 28 Sep 2011 15:57:04 -0700 (PDT) Received: by yic13 with SMTP id 13so11640yic.31 for ; Wed, 28 Sep 2011 15:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:mime-version:content-type:content-transfer-encoding; bh=BjtGwbTm0yoNcvwHAlka/KytXTawG/bo0s+icbY845I=; b=J70HgHsjXAmMjgnlYw14NqKJWPNpofn3AHcIYlslE64nQd3O7I52MSF9eUrcq4yy8g r3GP98Qi0ojKkT+UTJsIGZbooG46uL272JaodtyH6o9GHnBL3eFmv8taA2eL4mrgrx3j gCy2Zm6Pq/kv/7gTL/vqMrT8lo0HVfmHdGaqU= Received: by 10.101.85.17 with SMTP id n17mr7188289anl.88.1317250794130; Wed, 28 Sep 2011 15:59:54 -0700 (PDT) Received: from [192.168.15.2] (cpe-76-184-249-163.tx.res.rr.com. [76.184.249.163]) by mx.google.com with ESMTPS id g38sm916917ann.4.2011.09.28.15.59.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Sep 2011 15:59:50 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Wed, 28 Sep 2011 17:59:48 -0500 From: Henry Sinnreich To: Harald Alvestrand , "rtcweb@ietf.org" Message-ID: Thread-Topic: HIP option for draft-ietf-rtcweb-overview and which ICE? Thread-Index: Acx+MlI7mTF7EVbX3UG+5tBpvCdd5A== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: stiemerling@nw.neclab.eu, lars.eggert@nokia.com, quittek@nw.neclab.eu Subject: [rtcweb] HIP option for draft-ietf-rtcweb-overview and which ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 28 Sep 2011 22:57:05 -0000 > Comments are always welcome The short mention of the ICE Agent in draft-ietf-rtcweb-overview-01 may need some more explanation if SIP oriented ICE is implied and if not, the flavors of ICE for other protocols, such as Jingle which has different signaling, as mentioned in the I-D, or/and need other extensions, such as for RTSP (draft-ietf-mmusic-rtsp-nat). The draft-rosenberg-mmusic-ice-nosip from 2009 explains these issues, including the fact that not all protocols can use ICE. Since SIP may or may not be the signaling protocol, the implied meaning (or is it?) should be explained along with the issues and options. One option that comes to mind is using HIP with its own ICE solution (RFC5207) but having the advantage of working with _all_ application protocols, besides transition to IPv6, mobility and VPN-like security. For maximum flexibility and applicability IMO in environments using HIP. Some more text is desirable discussing the above. I have taken the liberty to copy the authors of RFC 5207. Thanks, Henry On 9/28/11 7:09 AM, "Harald Alvestrand" wrote: > I've just posted version -02 of the -overview document. > I'll just paste the change log from the document here: > >> A.6. Changes from draft-ietf-rtcweb-overview -01 to -02 >> >> Added pointers to use cases, security and rtp-usage drafts (now WG >> drafts). >> >> Changed description of SRTP from mandatory-to-use to mandatory-to- >> implement. >> >> Added the "3 principles of negotiation" to the connection management >> section. >> >> Added an explicit statement that ICE is required for both NAT and >> consent-to-receive. > > Comments are always welcome, and version numbers are cheap! > > A note on making the finding of such easy: > When I prepare a new version of a draft, I'll go back to the mailing > list and search for subjects containing the draft name, or some subset > of that ("overview" in this case), and dated between the previous > version and this version. > > Starting the subject line with "ISSUE:" or "CHANGE:" is also good for > catching my attention when I'm trying to re-locate those comments. > > Suggestions for changes that occur deep within a thread on other topics > have a high chance of getting lost in this process, unfortunately. > > Enjoy the reading! > > Harald > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From harald@alvestrand.no Thu Sep 29 00:21: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 D47BA21F8B89 for ; Thu, 29 Sep 2011 00:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.697 X-Spam-Level: X-Spam-Status: No, score=-109.697 tagged_above=-999 required=5 tests=[AWL=0.902, 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 sUyGZgWY3FNW for ; Thu, 29 Sep 2011 00:21:49 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 523E121F8AED for ; Thu, 29 Sep 2011 00:21:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2CD2339E08A; Thu, 29 Sep 2011 09:24:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6di3EZkZypg; Thu, 29 Sep 2011 09:24:38 +0200 (CEST) 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 3F2A739E088; Thu, 29 Sep 2011 09:24:38 +0200 (CEST) Message-ID: <4E841D36.6050802@alvestrand.no> Date: Thu, 29 Sep 2011 09:24:38 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Henry Sinnreich References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stiemerling@nw.neclab.eu, "rtcweb@ietf.org" , lars.eggert@nokia.com, quittek@nw.neclab.eu Subject: Re: [rtcweb] HIP option for draft-ietf-rtcweb-overview and which ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Sep 2011 07:21:51 -0000 On 09/29/2011 12:59 AM, Henry Sinnreich wrote: >> Comments are always welcome > The short mention of the ICE Agent in draft-ietf-rtcweb-overview-01 may need > some more explanation if SIP oriented ICE is implied and if not, the flavors > of ICE for other protocols, such as Jingle which has different signaling, as > mentioned in the I-D, or/and need other extensions, such as for RTSP > (draft-ietf-mmusic-rtsp-nat). > > The draft-rosenberg-mmusic-ice-nosip from 2009 explains these issues, > including the fact that not all protocols can use ICE. > > Since SIP may or may not be the signaling protocol, the implied meaning (or > is it?) should be explained along with the issues and options. That is good fodder for the NAT traversal draft. I think it is too detailed for the overview. > One option that comes to mind is using HIP with its own ICE solution > (RFC5207) but having the advantage of working with _all_ application > protocols, besides transition to IPv6, mobility and VPN-like security. > For maximum flexibility and applicability IMO in environments using HIP. Henry, nobody but you has argued for HIP. > Some more text is desirable discussing the above. > > I have taken the liberty to copy the authors of RFC 5207. > > Thanks, Henry > > > On 9/28/11 7:09 AM, "Harald Alvestrand" wrote: > >> I've just posted version -02 of the -overview document. >> I'll just paste the change log from the document here: >> >>> A.6. Changes from draft-ietf-rtcweb-overview -01 to -02 >>> >>> Added pointers to use cases, security and rtp-usage drafts (now WG >>> drafts). >>> >>> Changed description of SRTP from mandatory-to-use to mandatory-to- >>> implement. >>> >>> Added the "3 principles of negotiation" to the connection management >>> section. >>> >>> Added an explicit statement that ICE is required for both NAT and >>> consent-to-receive. >> Comments are always welcome, and version numbers are cheap! >> >> A note on making the finding of such easy: >> When I prepare a new version of a draft, I'll go back to the mailing >> list and search for subjects containing the draft name, or some subset >> of that ("overview" in this case), and dated between the previous >> version and this version. >> >> Starting the subject line with "ISSUE:" or "CHANGE:" is also good for >> catching my attention when I'm trying to re-locate those comments. >> >> Suggestions for changes that occur deep within a thread on other topics >> have a high chance of getting lost in this process, unfortunately. >> >> Enjoy the reading! >> >> Harald >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > From magnus.westerlund@ericsson.com Thu Sep 29 05:43: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 7D59221F8CBD for ; Thu, 29 Sep 2011 05:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.431 X-Spam-Level: X-Spam-Status: No, score=-100.431 tagged_above=-999 required=5 tests=[AWL=-6.029, BAYES_00=-2.599, FB_MAGIC_TAB=10.357, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly8Hc64nBvXB for ; Thu, 29 Sep 2011 05:43: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 470A221F8CB8 for ; Thu, 29 Sep 2011 05:43:30 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-bc-4e84688d53aa Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B0.7E.20773.D88648E4; Thu, 29 Sep 2011 14:46:05 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Thu, 29 Sep 2011 14:45:47 +0200 Message-ID: <4E846878.8030603@ericsson.com> Date: Thu, 29 Sep 2011 14:45:44 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" X-Enigmail-Version: 1.3.2 Content-Type: multipart/mixed; boundary="------------000601040000070801020800" X-Brightmail-Tracker: AAAAAA== Subject: [rtcweb] Minutes for RTCWEB Interim meeting on the 8th of September X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Sep 2011 12:43:33 -0000 --------------000601040000070801020800 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit WG, Attached is a text version of the minutes for the RTCWEB Interim meeting. If you have corrections please notify us chairs about them. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------000601040000070801020800 Content-Type: text/plain; charset="windows-1252"; name="RTCWEB-Interim-2011-09-08-minutes.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="RTCWEB-Interim-2011-09-08-minutes.txt" Minutes for RTCWEB WG Interim Meeting on the 8th of September Chairs: Magnus Westerlund, Ted Hardie, Cullen Jennings Thanks to three minutes taker: Cary Bran, Mary Barnes, and Stephan Wenger There are about 45 people on the call. List of people on call: Alan Johnston, Alissa Cooper, Allyn Romanow, Andy Hutton, Atin Banerjee, Francois Audet, Bernard Aboba, Bert Greevenbosch, Cary Bran, Charles Eckel, Christer Holmberg, Christian Schmidt, Colin Perkins, Cullen Jennings, Dan Burnett, Dan Romanescu, Daryl Malas, Dan York, Enzo (?), Eric Rescorla (EKR), Ernst Horvath, Francois Audet, Francois Daoust, Haralard Alvestrand, Jim McEachern, John Elwell, Jonathan Lennox, Justin Uberti, Keith Drage, Kevin Fleming, Krisztian Kiss, Magnus Westerlund, Markus Isomaki, Mary Barnes, Matthew Kaufman, Michael Lundbreg, Muthu Arul, Neil Straford, Olle Johansson, Parthasarathi Ravindran, pm(?), Ram Mohan, Randell Jesup, Salvatore Loreto, Sebastien Cubaud, Serge Lachapelle, Sohel Khan, Spencer Dawkins, Stefan Hakansson, Stephan Wenger, Ted Hardie, Thomas Stach, Tim Panton, Wolfgang Beck WG Chairs slides Note Well presented and applies Meeting will be recorded Agenda presented Use Cases (1 hr) ---------------- 20 minutes: On Recording (John Elwell) - There was a discussion about the architectural scheme for recording (Slide 6). No major controversies here - There was question on how common remote recording are compared local from Justin. Which could not be answered, but John commented that the need for remote is likely bigger in RTCWEB due to the lack of middleboxes to do recording in compared to SIP. - Ted asked what is the most common today, which is to record locally and then upload. The reasons for remote recording is the desire to do the recording in real-time. Ted saw three alternatives: 1) Middlebox alternative, 2) The recording server is a RTCWEB peer and performs analysis directly on received media, 3) Recording is done locally and analysis is done afterwards. Justin expressed a preference for 2, while Ted made it clear that he would prefer to avoid two streams. - Ralph Giles proposed that the API should give access to the media streams locally for local processing of the media. John Elwell asked if that really could be done in real-time in the end-point. - John E made it clear that his desire is an rtc-web architecture that do not preclude session recording in the future. - There is an underlying security question here: do you need to know the set of participants in the the rtc-web session. And are you allowed to forward the media from one participants to another participant or set of participant without their explicit consent? Will defer this question to the EKR security discussion. - Ted concluded that method 2) above can be supported assuming no security issues. And in general there seems to be nothing in the architecture beyond the security that precludes recording use cases. There will be need for text in the use case document. Action Item: John Elwell to work with use case draft owners to add the recording use case(s) to the requirements draft. Review and discussion of other use cases proposed ------------------------------------------------- (Use case draft author team). Stefan Hkansson presenting. Magnus Westerlund commented about the implications of adding more use cases results in more functionality, which means more work to complete before documents can be approved. TURN Case: Cullen presented the use case he originally proposed. There was a question of what requirements really this imposes. Magnus asked if this primarily is an implementation question allowing for local configuration of additional TURN servers, similar to how web proxies work today in browsers.? Justin asked if these could be detected. Cullen thought it is similar to socks proxies but not certain. Francois asked if this really special, isn't it similar to the other parameters that you need, in for example a SIP call? Harald commented that he hoped that there are not as many ways to detect proxies to find a TURN server. Action Item: Needs more discussion and clarification on the mailing list. E911 Case: Ted clarified that there are two different cases here. The first being you go to 911 provider web site and use it to communicate. The second being is federated case or a dial out case where a calling service reaches beyond its domain to the E911 service. Ted believes the first one is not different from a normal RTCWEB service. The second is out of scope and the client aren't really providing location information, and if something is available it is unassured data, which NENA folks don't' want. Cullen commented that he don't buy the unassured data reason. People will build services that provide PSTN like connectivity. In those cases people will call emergency services. We should not stick our head in the sand, but we also should not create requirements that no one will implement. Ted added that the service needs to know which emergency center to use, thus it needs LOST so it can provide the server with its location. From a service perspective, not terrible. There is also DoS concerns by tieing up resources at the emergency service centers. Cullen, thought the DoS angle was silly as this already easily can be done. Ted thought the issues and the use case in RTCWEB's context should be run by ECRIT. Bernard Aboba commented that there is a doc in ECRIT about this. Stephan Wenger agreed with Ted arguments. He also commented that we can look at the regulatory requirements in some cases, like Skype out. Manufactures or service providers are required to provide support for emergency services. If we rule this out of scope we are sticking our heads in the sand. Francois commented that there are large variations depending on countries or jurisdiction. We our out of our depth here. Ted supported his earlier argument that we should take this to ECRIT and look at it from their perspective first. Randall J brought up the requirement to get location data in the browser requires security and user permission issues. Stephan W commented that for 911 calls in the US the caller ID blocking is overridden. Randall clarified that is ok, but you don't want to expose the information to other services. Stefan H responded that this is already resolved as there exist a location API in W3C that gets permission from the user. Action Item: Paul and Stephan to talk to ECRIT chairs to identify subject matter expert to help with E911 use cases. Emergency access for disabled: Randall commented that this use case is not only for emergency, it will be useful in general. Bernard added that there is not a lot more in this use case than what is in the Emergency Service use case. The added functionality is conferencing support to allow an interpreter to be added into the emergency call. Action Item: Bernard to work with emergency use case proponents to add the additional requirement. CLUE Case: Magnus stated his view that he didn't see CLUE being clear enough what it meant. Mary Barnes (CLUE WG chair) commented that their timeline is similar to RTCWEB's and the use case are mostly done. Thus RTCWEB shouldn't do something that precludes CLUE use cases. Also in cases like multi-stream we should not have different solutions. Christer Holmberg commented that CLUE use cases include the requirement to support single stream end-points. So although then may not get the full experience they will be able to communicate. Cullen stated that he doesn't understand what is really required to support CLUE. Mary responded that one will need to support the data for the functionality that is being passed, and that is currently being worked on in CLUE and an interim meeting are coming up which it would be good if some RTCWEB people could attend. Markus Isomaki asked if these requirements would be on the JS application rather than the browser that implements RTCWEB? Mary say we don't quite know that, including if RTCWEB will use SDP O/A or something else. Justin commented that also RTCWEB will need to handle multiple source inside SDP. Roni Even commented that the multi-stream being talked in CLUE is multiple video streams, which is different than most of RTCWEBs use cases where there are multiple pairs of streams. Also the negotiation should not be a big issue, but we don't know that yet. Stephan Wenger's view is that as CLUE is mostly about call setup and control which appears to reside in the web application, thus the requirement is more in the reverse direction. It is more important for CLUE to consider that what they develop can be implemented in JS for a RTCWEB compliant browser. Magnus Westerlund stated the that it is very unclear what the requirements really are. Is it compatible media planes, or that interoperable applications at all can be developed. So what is this use case as we don't know in detail what CLUE is. Mary stated as neither group is far enough to real be into the details She thinks CLUE interim should add to its agenda a discussion of use case that are overlapping and see what requirements are needed in each group. It is desirable for a RTCWEB end-point to be able to participate in a telepresence conference. Stephan Wenger commented that participation is likely not an issue, what needs consideration is to provide the more rich telepresence experience in the RTCWEB context. John Elwell agreed that RTCWEB client needs to be able to get the benefits for CLUE. However, what the requirements on the API and functions are not clear. Cullen concluded the topic and pointed out the clear Action Item and future alignment discussion will be needed Action Item: Mary Barnes to allocate time at CLUE interim meeting to discuss RTC Web/CLUE inter-operability, RTC-Web representation should attend. Large Multiparty session Stefan presented the use case. The discussion on the list seems to indicate that the use case is very similar to the centralized multi-party conference that is present. The suggestion is to skip this use case. No one objected. Security camera/baby monitor Randall commented that there clearly are security discussion that needs to discussed. Justin asked if this include pan, tilt and zoom functions. Randall answered that it would be handy. Remote assistance Randall this is a common use case with installed applications, and it would be good to do this without external apps or plugin. Harald commented that this might belong in W3C space. It is primarily about being able to take the screen as input. Randall agreed that video and audio from the system is needed. Jonathan Lennox asked if there is reverse direction also, where input is transferred? Randall answered that this is possible. The data stream might not be IETF issue as all and all be an W3C defined opaque stream from IETF perspective. Clearly there is some security concerns around the control. Justin commented that this seems to imply that there is some reliable data transport between the peers. Randall agreed. Cullen Jennings are very interested in the use case, especially the screen sharing to be able to implement WEBEX in RTCWEB. The remote control aspect is less important. Stephan Wenger asked if the reverse scope really is in scope. The screen sharing clearly is a common use case. The reverse path appear to be out of scope. Randall commented that the screen may not be transported as video, but over some reliable or unreliable protocol, like VNC. General for use cases Stefan H raised the issue of how we should work around use cases in the near future. Ted presented the WG chairs thinking on the issue. The WG chair will run a series of consensus calls for the use cases. It is important that the use cases captures the requirement they have on functionality so that it is clear what impact a use case has. If that isn't present the chairs may declare that there is no consensus. Stefan Wenger objected that the is harsh demands. One can probably argue the use cases, but not be able to determine the requirements. Ted responded that we are not going to be mean. But chairs might declare that the consensus is not determined and that additional work is required before coming to consensus. Signalling (1 hr) ----------------- --15 minutes Issue Overview (Matthew Kaufmann) Presentation: What needs to be standardized 1) between browser and web server - http is already there - does anything else need to be standardized 2) media transport needs to be standardized. 3) between web servers - do we need to standardize signaling federation. There are already existing protocols - i.e., SIP, SDP O/A 4) within browsers: API between application and Javascript APIs. IETF needs to provide requirements, but this is a W3C problem. 1) Options: leave to appl developer, SIP, SIP-lite, not SIP but should be SDP O/A 2) Propose to use existing media transport protocols 3) Options: SIP, Other (e.g., XMPP Jingle), up to SPs Cullen: another option - SIP might be used but SPs could also do what they want. John E: suggest this doesn't have to be SIP but if it is SIP should be compliant. Matthew: thinks this is premature (i.e., federations). Note, this doesn't define what should be between browser and web server. 4) While this isn't an IETF problem, it may be influenced by the solutions for others (e.g., 1) - How much of calling built-in? -- 1) Based on SIP -- 2) Javascript developer gets peerConnection object. Lots of room for innovation. -- 3) Intermediate choices. - How does address selection and NAT traversal work? -- 1) Peer connection is passed SDP blob -- 2) Peer connection is passed a candidate list, etc. -- 3) Peer connection has APIs for ICE, etc. - How does codec selection work? -- 1) SDP O/A --- Javascript can manipulate SDP, thus not totally bound -- 2) Javascript APIs --- Appls can query for capabilities, allows for more complex APIS, leverages W3C APIs Direct javascripts allow the developer to query capabilities: -- can still leverage MMUSIC -- can also use SDP as a command mechanism (and not O/A) Recommendations: -- avoid solving problems out of scope -- maximize flexibility for applications - turn browser into new operating system and not just bolting on SIP phone What needs to be standardized 1) No. 2) DTLS-SRTP 3) Leave to SPs for now. Look at SIP later 4) Don't build a SIP phone into browser. Implement ICE natively. Don't build O/A into PeerConnection object. APIs for codec choice, etc. Discussion: Justin agreed with many presumptions here. However 4) is thorny. Codec selection should be done with something other than SDP. Matthew responded that we don't need to fire SDP offer out of peerConnection. Call a javascript API if you want to use O/A. This may not be in scope for IETF - should be done in W3C. Justin remarked that if one don't pass SDP blobs, then query for object of capabilities and then configure with another object, would that address the functionality Matthew wants? Matthew confirmed yes, but may reuse some of the blobs from MMUSIC. Justin then thought that in the trivial case one could ask for blob and pass that blob, which is similar to the PeerConnection model that can generate O/A. Matthew commented that is as simple as getting a JSON blob and sending to other end and taking that blob out at the other end. Cullen: What we're talking about here is what can we pull out the blob for codecs, etc. Matthew answered that we need to come up with a minimal set of reqruiements and not defining blobs. Cullen responded that you've said advertisement model allows you to do more innovative things than O/A. Thinks SDP O/A is rich enough to control this. Matthew responded that the API as currently proposed for W3C says you don't get to know capabilities until you generate an offer. Example: 10 party conference call, everyone has selected codes that work for them. What do you tell an 11th party that doesn't support those codecs. API knows all the capabilities. Thus, web server can make a more intelligent decision - e.g., switch codecs for call. Cullen responded that O/A allows you to accomplish the same. Current APIs don't work. Don't see why O/A changes innovation. Matthew believes they are mappable. Can generate an offer and deconstruct it. This is about building an O/S. This question should be answered at W3C. Thinks that either of these is equivalent. Lots of Q&As on 4) have slopped over into 1) and 3). Francois remarked that we should be thinking about how to maximize possibility that we're successful. Seems to me that we should focus on the things in our mandate - i.e., protocol for transport. Thinks for Q3, should say that federation protocol is SIP. Agree with Matthew that protocol to Web Server is to be done by W3C. They should figure out what is best. 15 minutes Offer/Answer architectural text (Cullen Jennings) ----------------------------------------------------------------------- Design principles: 1) Need SDP O/A semantics as used by SIP rather than reinvent. 2) will be possible to gateway between legacy SIP devices that support ICE 3) When a new codec is defined, JS API doesn't change. Matthew asked if you defining what goes on the wire? Cullen answered no. Matthew agrees with 2) and 3) Thinks client can choose 1) Suggest SIP as a federation protocol. But, no SIP between Web Server and Browser. SDP blobs are not enough by themselves. Prefer SIP O/A semantics and not just RFC 3264. Requirements: - able to pass SDP O/A - indicate context of passing O/A - Deal with two phase SIP - 180/200 - signal errors in SDP ... Summary: need more than just SDP. Needs to be mappable for SIP. Discussion: Francois agrees you need more than O/A. If this was all at server to server I/F, would 100% agree that is all that is need. Concerns over browser-Server I/F where we shouldn't go out of comfort zone and not mandate an implementation. Should focus on Server-Server. May not need O/A on wire. Like now when is calling from my SIP phone to Skype. Cullen responded that he knows that Skype isn't mappable to SIP directly. Yes, talking about federation protocol. But, do think that what comes in and out of API, then goes through magical protocol - that protocol must be simple and MUST be mappable. The 3 interfaces need the information - don't necessarily need SIP O/A on all those interfaces. Francois thinks this is moving in the right direction. Keith commented that SIP level doesn't have anything to do with media. Does A server need to know anything about server B. Do we need feature tags? Cullen responded that focus has been on info needed at RTP level. Justin thinks this is the right direction. Need errors, timers etc. for glare, etc. Concerned about the "much more along these lines" - that's a slippery slope. Will we pull in more SIP stuff later? Harald commented also think that if we can push away two phase media commit at API level, that would be good. SIP has spent a lot of effort getting right. Would prefer if we could with a somewhat simpler model. Cullen responded that the thing he dislikes the most about the whole SIP discussion is the slippery slope. Obviously I don't have concreate proposal. We need a proposal where we can go have a detailed debate. For example on issues like 2-phase commit, which our use case currently have canned. I am glad to have the discussion, but we need a document that describes details. Harald: Hurray! Cullen wants to get into Harald's document "Design Principles" detailed on the slide. In short, points 1) and 2) needs to be mappable to SIP O/A. Francois commented that point 1) should be soften and strengthen point 2) a little would maximize our chances to get things right. Discussion: Jonathan Lennox asked if DTLS-SRTP and SAVPF is required, or are we going to have SDP CAPNEG which everyone dislikes, and if the former does everything else need to go to media G/W? Cullen assumes that direction is that we want to negotiate secure versus insecure media. Thus we need some negotiation with limited device and the browser. Accepting that we must interop with SDP and it is not trivial. Only thing harder is to replace SDP with something that is simpler that still does what people wants. Everytime that has been attempted it has failed. And like to persuade the WG to avoid going down that road, as this is a multi-year effort. And if that happens what the WG decides will be totally irrelevant as code will have shipped a long time ago. Kevin Fleming asked if it is that SDP is hard or is some problem space where we use SDP is hard? Cullen responded that yes, it's probably the latter. Ted: need more discussion of Matthew's and Cullen's presentations (for 10 minutes after the break) Continued discussion! Ted started up the discussion after the break. There is a trade-off here. The more we have standardized below the API the simpler the JS code can become. Yes, the JS-library can attempt to cover such functionality; however they are commonly frustrating incomplete in functionality. The one place where I am quite concerned is congestion control. Multiple streams in multiple layers trying to do control across this in the javascript portion seems quite difficult. If that is the case, how can we have the thin part below the API and still have the congestion control in the browser. Has anyone thought of this? Cullen commented that both CC and security function in browser needs to have a fairly deep understanding of what the application intends. That is likely easier if the browser selects the RTP parameters. Also the more successful HTML APIs have been easy to demonstrate for people. Thus the simple stuff needs to be really simple to accomplish, and the more advanced only possible. Harald commented about congestion control (CC), that one issue is trust. If CC is implemented in the JS then we need to trust all the JS authors. If implemented in browser we need to trust the browser authors. Eric Rescorla asked if with trust Harald was concerned with malice or incompetence. Harald responded that any sufficiently advanced incompetence can't be distinguished from malice. Eric clarified that he was interesting in how strong guarantees are needed that appropriate congestion control actions are performed? Harald like the assurance from browser that independently of what mess the JS tries to create nothing truly bad will happen. Randall Jessup agreed with this. Eric Rescorla followed that up asking that is CC is implemented in the browser how is the signaling and response to congestion handled if the JS application is responsible. Ted commented that he is worried if all JS applications needs this complicated back and forth handling of events and response selection. Harald agree. Justin commented that on the positive this is a differentiating factor. If in browser it is likely we can do it correct, but there will be people that think they can do it better if they had the possibility. Randall? commented that there is a connection between application response and congestion control. But the determination is best done in the browser. Justin agrees, but in for example a conference scenario then it is the application that needs to make a decision to drop a stream. Dan York asked on how we define congestion control. Eric rescorla asked what is required to build a very basic soft phone. He thinks he understands what needed in the case of Cullen's model. There is very little JS code and quite slime server side. But has anyone tried out what Kauffman is proposing? Harald commented that he hasn't seen enough details of Kauffman proposal to build a site. I certainly can't(?) see how I build a site fulfilling Cullen's forward compatible principle. Dan York commented that they are building something that are similar to Kauffman's principles. Cullen interjected that in his discussion with Kauffman's believe what Dan Y is doing is a type example of what Kauffman hates. So there might be some confusion here. Bernard Aboba asked, but that is a JS example, not SIP in the browser? Dan York followed up saying that there are definitely people building in JS real-time stuff that has commonalities. Eric Rescorla formulated the two questions, how much code does oneself as site programmer have to write, and secondly, how much code does one have to download? Cullen is wondering if the principles presented are okay. Cullen has written several prosals, but is not willing to spend more time on writing up an offer/answer based proposal along the principles if there is sufficient agreement. I want to make progress. Parthasarathi, Ravindran? why don't we take SIP as framework, not the applications and have the browser be an UA. Cullen responded, yet that is possible. And it appears like all the demos are based on some softphone. Ted summarized that we gotten a lot of good material and discussion. Requirements for federation and browser server have clearly made progress. Have a quick round among the people driving a design principle. Then have two week consensus calls for the actual principles. Justin requested that if there is anything the other model can't do, please detail that. Ted agreed and clarified that in the input to the consensus call such input is highly desirable. Action Item: Take this up on the consensus call with the signaling design advocates, present results to mailing list. Security (1 hr) Note: new version of the security document Presentation Overview: - RTCWEB functionality is too dangerous to enable by default -users must consent - How do they consent intelligently - Objective of discussion - work through common cases. Common Themes: 1) Consent issues: - making long term grants secure - user expectations Potential long-term consent security features: a) live with it b) require user interaction with browser for all calls c) require user interaction with browser for new calls d) require JS to be delivered over HTTPs 2) Authenticating the person you are talking to (suggest this is less important than consent) Discussion: Cullen commented that EKR is phrasing consent in terms of access to camera. You've captured those options. But, if you frame it as control who your computer is sending media to and that would lead to a different set of options. Ekr exemplifies this by going to a poker site and connect to Ted (which he doesn't now, just a random guy). How do I avoid faked pokerweb to connect me to some random guy? Cullen responded that it depends on the identity provider which is pokerweb. It is another issue to separate between the real pokerweb, and the faked one. Ekr two concerns, first one that even with TLS I can't be certain that I am talking to the real pokerweb. The second is the question, do I have any protection against the real pokerweb tapping its user. Cullen thinks we will need two fundamental authentication processes. Ted asked can you talk about in terms of assurances rather than UI. Which assurance is being provided and whether it has been successfully provided. Cullen responded that wasn't saying there were two assurances - there are two groups that can be selected. Assurance where you install application like Skype is different than having a conversation with X and disallowing that thereafter. Ekr responded that after bulk auth, the amount of protection is quite limited. Not sure how to improve this without interfering with user. Minimal assurance of sites you authorize (with HTTPs). Assurance before making a call or assurance when you've made a call before. Eg., a user been on pokerweb before and already had a call with two people. If I am willing to only have calls to these then that limits what the website can do to bug the calls. This of course has UI consequences. Short-term consent: - single call to people that you have no prior relationship - Conflicting requirements; low-impact, not something users click through, can we do anything to help here. This is really a W3C issue. -- It was suggested to do like facetime and mirror the UI. - Characterization: User doesn't know who they are calling. Don't have technical means to give this kind of identity. -- Know domain and you need to figure out if it's connected to people you want to call. -- It requires a user leap to go from FQDN/user name to the company you're talking to. API impact of short-term consent: 1) show self picture 2) This implies some level of device access prior to permissions Suggests this is out of scope. What about site being visited: - should top level site get an opinion: Discussion: Sohel: Hearing problems - not solutions Ekr: proposal is to allow JS API for consent Enforcing Pseudonymity: - If you care about this use SRTP - site can enforce this - browser can support this - cryptographic continuity Verifying who you are talking to. Summary: - can't completely eliminate threats from long-term sites: -- Basic principle: trust but verify - short term consent is somewhat more secure: -- likely user will have to give consent Discussion: Jonathan asked if interface is for requesting long term or short term consent? Ekr responded it will be the web sites that decided which to use. The short term consent is happening as side effect of a JS call. The app can make call without long term permissions. The long-term consent process is something a little more heavy weight. Jonathan asked if the user is clear what they are consenting to. Ekr thinks so. Ted a question around the short term, when you consent only for this call, some long running process may be present in a Web application. How do you determine the length of a call compared to the UI interactions? Does the call end when you navigate away from tab or does it end when you quite the browser or when you close the tab? How do we manage the user expectation and consent? Ekr have no idea what the answer is. Basic requirement is that a user be aware of what and how many calls are in progress. Randall commented that this is edging into W3C side. Mozilla will be considering UI may have a Chrome indication that mic/camera are active. Likely part of the solution. Ted wonders if there is a need for an additional assurance type? Do I want to have an assurance that they have access to camera and microphone only when I am on tab containing this application. Do I have one assurance that is short term as long as this tab exist, and one that is long term. The assurance models are different. Would be hard to express to the users. At the same time having different types of assurances will be valuable. What does other believe? Cullen wants assurance that whenever end it, it truly ends. Ted stated we don't want to make this part of JS. Cullen stated that our threat model is that JS is inherently untrusted, or isn't it? Randell agrees that part of the indication is in the chrome, if you let end call be part of UI in the apple. If you hit end and you don't see that visibly in UI, you know it didn't do the right thing. That's not the whole solution, but parts of it. Ted stated that we don't appear to have a need for different assurance classes? Stefan commented we've beyond ending calls, also have recording. And as soon as you can record and send a file off the user has very little control. Ted restated this as, Is there any assurance that we would like to provide and is there any that we can provide, given that the number of participants is known. Ekr responded to that with yes and yes. There is an big importance between 0 and 1 participants, 1 and N is important, but less than 0 and 1. Browser should indicate both cases. Ted thought that was a different Q. Eg. I'm sending media to Stefan who is sharing media with recording service. Can we provide any assurance, or is simply that when your media left your device and arrived somewhere they can do anything. Randall responded, we can't really give an assurance, there's always an OS way to grab the media and forward it. Stefan stated that even if verified who I am talking to our, your application may also locally record it send it. Cullen commented we need to differentiate recording and what can happen to media when going out a speaker versus what a less than trustworthy JS application can do with the info. Handling the first case is just one bar to far. Something we can't deal with. Magnus tried to reinforce Stefan's point that local recording is possible and then can ship data off machine from JS. No Conclusion. Terminology Mapping (30 minutes) -------------------------------- Mapping WebRTC constructs to RTCWeb terms (Magnus Westerlund) Presentation Overview o Multi-media session versus RTP session o RTP related terminology o WEBRTC API terminology (MediaStream object, MediaStream Track, Label, PeerConnection) Discussion: MediaStream and Label - MediaStream track can be mapped to a SSRC in RTP session - MediaStream track has a synchronization context that can be represented by CNAME - a MediaStream sent by a PeerConnection can be presented by a list of RTP session SRTP tuples - The MediaSTream label has no matching construct: -- SDP a=label attribute labels RTP sessions, not a set of SSRCs in possibly several RTP sessions. -- label can't be CNAME Discussion: Harald haven't been able to track down a requirement for mediaStream label Magnus responded can have the same media source appear in multiple mediaStreams, which makes CNAME dubious Harald commented that multiple copies of same mediastream track used to send media in different directions. That means that it doesn't matter whether they have the same or different CNAMES because they won't end up at same receiving entity. Cullen commented that these are in different MultiMedia sessions from RTP view. Harald concluded that he don't see use case. Magnus responded that he have a use case where you might want to maintain CNAME across multiple sessions (next slide). Justin asked what do you expect application to do with mediastream label? Cullen responded with a use case where a video device is getting 3 streams. Have been told in signaling JS that you're getting Alice, Bob and Charlie - need to know how to map to media stream. Stefan added that an end-point can have multiple cameras. Cullen remarked maybe we need a label for a track and not one for a mediastream. Mediatracks need ssrc and cname. Harald disagreed. If media stream represents all that need to be coordinated. Need a label to refer to that construct. Magnus directed attention to the mixer case. Where a likely to receive a mixed audio stream, and several video streams. Harald responded that if sending audio and video, need two things, need you to know they belong to me and that they need to be synchronized which is CNAME. Why do you need another construct? How else can you refer to it? Need to map to an identifier to figure out the actual stream. Justin commented that you only need to map to a track. Stefan commented the model on application side has been to deal with stream. Justin responed that we have identified places where this breaks down - mapping to track and not stream provides more flexibility. Stefan thinks it makes it more complex. Cullen a good example: two camera views with Harald and both synced to one audio. Want to synchronize all three and different two camera views. Not proposing a solution, but this seems to be use case. Ekr asked what is application model? Either I'm in Matthew's world with a JS handle to both or in SDP browser world. Cullen responded we are talking about which JS handle that flows across the interfaces. Ekr wonder where do you envision this being signaled. In SDP according to Justin. Ekr asked what are you trying to say. Justin clarified that the application is asking for the wide angle shot, or the zoomed in. Cullen added that we are already receiving both. Want to display the wide on right hand and zoomed on left hand. Justin that works as long as you have video track tags and use url to get. Ekr was not clear on whether application does this locally or if this sent across wire. Justin and Stefan agreed that it is local operations, but Stefan added that you need information from the other side. Ekr commented that one have a JS object, why do I need another label? Cullen refered how does incoming RTP packet get sent to right JS object is the question. Justin remarked by the SSRC. Colin Perkins you would need same CNAME for synchronization. But, can easily define a new identifier/label if we need one and put it in RTCP. Conclusion: Discussion to continue on mailing list. Congestion Control (10 minutes) Harald Alvestrand Randall is in favor of this. Need to run congestion control across all streams, not just RTP. Harald remarked that he agrees and Google are experimenting with joint control, but the RTP identifiers aren't setup to make this easy. Justin remarked that we have continuous (likey to fill the pipe) as well as discontinuous traffic. What kind of assurance can you give users that their data traffic makes it? We likely need something to help their traffic getting through. Magnus commented, that it depends on what timescale you want to react. If one at least frame-level you can throttle back your video encoder to make room for the data. Justin, if media is running without saturating the pipe and the application dumps 300k of data, then it will be an RTT before we know if there was a problem or not. Randall, we likely need something like TCP slow start. The data is clearly asynchronous and may not be a new connection. We need something the details are the question. Cullen commented that in use case where data was much less than video, then no issue with data. As the spike from an I-frame is much larger than some single data packet. May be easier to solve this in some cases - e.g., low data rates. Tim Terriberry remind that a proposed use case was to do direct file transfer without relay to the server. Justin responded this argues for reliable data channel. Randall noted that the JS application may need to give indication of prioritization and e.g., percent of channel devoted to data. Justin agreed may need to request a reservation to send more data. Agree with Cullen's remark, and that implies one should avoid I-frames. Colin there is a missing requirement to not impact media flow. Issue is that what is good for the network, like slow start is bad for the media. Randell commented there are cases where timely delivery versus media quality is more important. This is an application decision. Justin agrees that QoS is something we should let applications to set. Ted concluded that draft-alvestrand-rtcweb-congestion-00 is not yet ready for WG adoption. Wants Harald to take this forward. Harald wants someone else to take on the task to write requirements for congestion. This document just documents what Google is doing. Randall was willing to cooperate on a draft. Conclusion: Randall will write up a first pass at requirements (along with Harald) and discuss on the ML. --------------000601040000070801020800-- From fluffy@cisco.com Thu Sep 29 13:24: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 5392121F8AFB for ; Thu, 29 Sep 2011 13:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 12Jd8m3OEsMA for ; Thu, 29 Sep 2011 13:24:28 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A820E21F8AF7 for ; Thu, 29 Sep 2011 13:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=259; q=dns/txt; s=iport; t=1317328041; x=1318537641; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=05CAedZ6ZiNmU2klVNN4J/4Vlfjfm/tZB9Lsb4Q0iVU=; b=lYG/hrsStgew4LEk4ROYyw7bwJ535o7yAG9B82nQk5bvHWvvzCCobh5Y HKQN+uq9xsBTPx2rLnfQq2BZNgfuTtIo1oSrXfk79A0bsyUyqzdtKkqxd 6M4RwcQz/AU5W9v+/xsWFIovI9fIMx6Xn4bcM7fMBK4ALzP2lwYbfJ/nu M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFzUhE6tJXG//2dsb2JhbABBqBp3gVMBAQEDARIBJz8FCwtGVwY1h1icawGeL4YyYQSHcotkhSOMNg X-IronPort-AV: E=Sophos;i="4.68,463,1312156800"; d="scan'208";a="25007339" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 29 Sep 2011 20:27:20 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8TKRIDD014622; Thu, 29 Sep 2011 20:27:19 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 29 Sep 2011 14:27:18 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: To: Henry Sinnreich X-Mailer: Apple Mail (2.1084) Cc: quittek@nw.neclab.eu, "rtcweb@ietf.org" , lars.eggert@nokia.com, stiemerling@nw.neclab.eu Subject: Re: [rtcweb] HIP option for draft-ietf-rtcweb-overview and which ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Sep 2011 20:24:29 -0000 On Sep 28, 2011, at 4:59 PM, Henry Sinnreich wrote: > The draft-rosenberg-mmusic-ice-nosip from 2009 explains these issues, > including the fact that not all protocols can use ICE. I'm having a hard time finding this draft. do you have a pointer... From oej@edvina.net Thu Sep 29 13:28: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 9E29E21F8C55 for ; Thu, 29 Sep 2011 13:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.015, 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 T06GIZ7WXfqE for ; Thu, 29 Sep 2011 13:28:54 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 13FC621F8C51 for ; Thu, 29 Sep 2011 13:28:54 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 963A2754BCE4; Thu, 29 Sep 2011 20:31:42 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: Date: Thu, 29 Sep 2011 22:32:16 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Cullen Jennings X-Mailer: Apple Mail (2.1244.3) Cc: stiemerling@nw.neclab.eu, quittek@nw.neclab.eu, "rtcweb@ietf.org" , lars.eggert@nokia.com Subject: Re: [rtcweb] HIP option for draft-ietf-rtcweb-overview and which ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Sep 2011 20:28:54 -0000 29 sep 2011 kl. 22:27 skrev Cullen Jennings: > > On Sep 28, 2011, at 4:59 PM, Henry Sinnreich wrote: > >> The draft-rosenberg-mmusic-ice-nosip from 2009 explains these issues, >> including the fact that not all protocols can use ICE. > > I'm having a hard time finding this draft. do you have a pointer... Maybe mispeled - this one may fit the bill: http://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip-01 Guesswork... /O From henry.sinnreich@gmail.com Thu Sep 29 13:46: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 7F44621F8DD0 for ; Thu, 29 Sep 2011 13:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.246 X-Spam-Level: X-Spam-Status: No, score=-3.246 tagged_above=-999 required=5 tests=[AWL=0.353, 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 QOMAmC++9CNx for ; Thu, 29 Sep 2011 13:46:56 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A586F21F8DCF for ; Thu, 29 Sep 2011 13:46:56 -0700 (PDT) Received: by ywa6 with SMTP id 6so1136347ywa.31 for ; Thu, 29 Sep 2011 13:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=SRjluAft82JBEiiiLEb+qaDZI+YmnBbwTrfYOGAbsXY=; b=T/T4fl9FM8hkbz5ujSmlUht8u4YwOrWpAxjHVIaRKwXMpOYQX3ivR89+w8+DAdDDd9 +uc0ZiGzUF2XuEb1UEXgGBj8ZGXAHAMg1LPp7ciJXgNV5wkKo5Uo+0isWKIwghogOOzI lYoeTbiB0n/d15fZa81grq0rUoqjaqPjOnUNo= Received: by 10.236.161.200 with SMTP id w48mr15925374yhk.28.1317329388457; Thu, 29 Sep 2011 13:49:48 -0700 (PDT) Received: from [192.168.15.2] (cpe-76-184-249-163.tx.res.rr.com. [76.184.249.163]) by mx.google.com with ESMTPS id u13sm7935845anf.14.2011.09.29.13.49.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Sep 2011 13:49:47 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 29 Sep 2011 15:49:42 -0500 From: Henry Sinnreich To: Cullen Jennings Message-ID: Thread-Topic: [rtcweb] HIP option for draft-ietf-rtcweb-overview and which ICE? Thread-Index: Acx+6U/oCpzv3Zkrn0e/59vlhzvSSg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: quittek@nw.neclab.eu, stiemerling@nw.neclab.eu, "rtcweb@ietf.org" , lars.eggert@nokia.com Subject: Re: [rtcweb] HIP option for draft-ietf-rtcweb-overview and which ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Sep 2011 20:46:57 -0000 > I'm having a hard time finding this draft. do you have a pointer... Sorry, my shortened link was not inaccurate. It is http://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip-01 I don't know if/how MMUSIC has pursued this topic. Does anyone? Jonathan? Henry On 9/29/11 3:27 PM, "Cullen Jennings" wrote: > > On Sep 28, 2011, at 4:59 PM, Henry Sinnreich wrote: > >> The draft-rosenberg-mmusic-ice-nosip from 2009 explains these issues, >> including the fact that not all protocols can use ICE. > > I'm having a hard time finding this draft. do you have a pointer... > > From fluffy@cisco.com Thu Sep 29 14: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 6F19121F8B44 for ; Thu, 29 Sep 2011 14:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.047 X-Spam-Level: X-Spam-Status: No, score=-103.047 tagged_above=-999 required=5 tests=[AWL=-0.448, 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 wbzNAjhCuniJ for ; Thu, 29 Sep 2011 14:07:15 -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 D53C621F8B40 for ; Thu, 29 Sep 2011 14:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=736; q=dns/txt; s=iport; t=1317330608; x=1318540208; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Ijo4S+TXm/gr/eP4Hc/KLR79pDTygcyvu0gfvENRMn0=; b=d3dhx4uwDO5MYkcv5NZdjiswG/qQ66MBb0Y+IeCsko/T3lu3XnCZGPbh O/p/D8YeuHdXp10X2LzoVDEO65HNZyuHFaI4iDmkurA40mICMWVgcuGJy BI5XsWXVx8KfK6iOckYGmymanDRGIP799mC2OGMJ+g5nccA5OcBpwoPbE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJXdhE6rRDoI/2dsb2JhbABBqBt3gVMBAQEDARIBJz8QCxguVwYTIodYBpxpAZ4phjJhBIdyi2SFI4w2 X-IronPort-AV: E=Sophos;i="4.68,463,1312156800"; d="scan'208";a="5092164" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 29 Sep 2011 21:10:08 +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 p8TLA69M007857; Thu, 29 Sep 2011 21:10:06 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 29 Sep 2011 15:10:06 -0600 Content-Transfer-Encoding: 7bit Message-Id: <40C8F99C-3BAA-499E-8151-8A64BB61CF7D@cisco.com> References: To: Henry Sinnreich X-Mailer: Apple Mail (2.1084) Cc: quittek@nw.neclab.eu, stiemerling@nw.neclab.eu, "rtcweb@ietf.org" , lars.eggert@nokia.com Subject: Re: [rtcweb] HIP option for draft-ietf-rtcweb-overview and which ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Sep 2011 21:07:16 -0000 thanks On Sep 29, 2011, at 2:49 PM, Henry Sinnreich wrote: >> I'm having a hard time finding this draft. do you have a pointer... > > Sorry, my shortened link was not inaccurate. It is > http://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip-01 > > I don't know if/how MMUSIC has pursued this topic. > Does anyone? Jonathan? > > Henry > > > On 9/29/11 3:27 PM, "Cullen Jennings" wrote: > >> >> On Sep 28, 2011, at 4:59 PM, Henry Sinnreich wrote: >> >>> The draft-rosenberg-mmusic-ice-nosip from 2009 explains these issues, >>> including the fact that not all protocols can use ICE. >> >> I'm having a hard time finding this draft. do you have a pointer... >> >> > > From ibc@aliax.net Thu Sep 29 14:26: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 E592B21F8E07 for ; Thu, 29 Sep 2011 14:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJYhleXbpFWk for ; Thu, 29 Sep 2011 14:26:43 -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 3D8CC21F8E02 for ; Thu, 29 Sep 2011 14:26:43 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so1261295vcb.31 for ; Thu, 29 Sep 2011 14:29:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.151.19 with SMTP id a19mr3135632vcw.6.1317331774846; Thu, 29 Sep 2011 14:29:34 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Thu, 29 Sep 2011 14:29:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Sep 2011 23:29:34 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Henry Sinnreich Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: stiemerling@nw.neclab.eu, "rtcweb@ietf.org" , lars.eggert@nokia.com, quittek@nw.neclab.eu Subject: Re: [rtcweb] HIP option for draft-ietf-rtcweb-overview and which ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Sep 2011 21:26:44 -0000 2011/9/29 Henry Sinnreich : > Sorry, my shortened link was not inaccurate. It is > http://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip-01 Abstract =C2=A0 =C2=A0Interative Connectivity Establishment (ICE) has been specified= as a =C2=A0NAT traversal mechanism for protocols based on the offer/answer exchange model. =C2=A0In practice, only the Session Initiation Protocol (SIP) has used ICE. =C2=A0This document provides guidance on how other protocols can make use of ICE. Well, "only the Session Initiation Protocol (SIP) has used ICE"... I would replace that with "ICE has been initially specified for SIP" (the usage of ICE in SIP is just anecdotal, ICE is more used in XMPP-Jingle than in SIP). --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Thu Sep 29 14:39: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 6461221F8ECA for ; Thu, 29 Sep 2011 14:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.766 X-Spam-Level: X-Spam-Status: No, score=-109.766 tagged_above=-999 required=5 tests=[AWL=0.833, 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 o6y997K53Lpf for ; Thu, 29 Sep 2011 14:39:22 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 563C621F8E0A for ; Thu, 29 Sep 2011 14:39:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CF19F39E08A; Thu, 29 Sep 2011 23:42:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMvRu0bJ6hP3; Thu, 29 Sep 2011 23:42:12 +0200 (CEST) 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 781C039E088; Thu, 29 Sep 2011 23:42:12 +0200 (CEST) Message-ID: <4E84E634.4050100@alvestrand.no> Date: Thu, 29 Sep 2011 23:42:12 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Henry Sinnreich References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: quittek@nw.neclab.eu, stiemerling@nw.neclab.eu, "rtcweb@ietf.org" , lars.eggert@nokia.com Subject: Re: [rtcweb] HIP option for draft-ietf-rtcweb-overview and which ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Sep 2011 21:39:23 -0000 On 09/29/2011 10:49 PM, Henry Sinnreich wrote: >> I'm having a hard time finding this draft. do you have a pointer... > Sorry, my shortened link was not inaccurate. It is > http://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip-01 > > I don't know if/how MMUSIC has pursued this topic. > Does anyone? Jonathan? Having an 18-page ICE draft rather than the complete > 100 page ICE spec to read was refreshing. I don't think any new technology was described here; it's mostly explanation on how to think about ICE. My personal view is that the draft does not go far enough in the separation of concerns for maximum readability; there are two concerns when using ICE as part of a protocol suite: - Whether ICE setup information can be exchanged between the endpoints. This is a matter dealt with in SIP and Jingle, but could equally well be done by writing to/reading from an Oracle database or exchanging slips of paper with IP addresses on them on a parkbench at midnight (just to be melodramatic). - Whether ICE messages can be used safely, and reliably separated from payload messages on the media link. This is a matter that concerns RTP, SCTP, DTLS and so on. Those two things are very separable concerns, and if the authors had desired, they could have been treated in completely separate documents. It might have made the packet easier to digest. Harald > Henry > > > On 9/29/11 3:27 PM, "Cullen Jennings" wrote: > >> On Sep 28, 2011, at 4:59 PM, Henry Sinnreich wrote: >> >>> The draft-rosenberg-mmusic-ice-nosip from 2009 explains these issues, >>> including the fact that not all protocols can use ICE. >> I'm having a hard time finding this draft. do you have a pointer... >> >> > > From HKaplan@acmepacket.com Thu Sep 29 14:57: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 BB65F21F8B54 for ; Thu, 29 Sep 2011 14:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 S9IIQ-yFiF8r for ; Thu, 29 Sep 2011 14:57:09 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 276F821F8B53 for ; Thu, 29 Sep 2011 14:57:08 -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, 29 Sep 2011 17:59:58 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 29 Sep 2011 17:59:59 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] Requiring ICE for RTC calls Thread-Index: AQHMfvMgbOxjs7uxAUurGYv/J5+14A== Date: Thu, 29 Sep 2011 21:59:58 +0000 Message-ID: <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@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.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Randell Jesup , "" Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Sep 2011 21:57:09 -0000 ICE-Lite is easier for gateway-type devices, but it's still got to do the S= HA-1 calc per STUN connectivity-check response packet, which is painful fro= m a performance/scale perspective (and thus cost). That's one of the things we've been arguing about in MMUSIC as being a prob= lem for IPv4/v6 since ICE is the only "official" way to handle a dual-stack= offer/answer... and the extra cost incurred for doing ICE is hard to justi= fy since IPv6 transition is an expense with no added "feature". But no one= seems to care about that there, so we've been forced to go outside the IET= F. :( -hadriel On Sep 28, 2011, at 12:18 PM, I=F1aki Baz Castillo wrote: > 2011/9/28 Cullen Jennings : >> Many service providers front end their services with an SBC for a wide v= ariety of reasons - and that is the place they would likely run ICE Lite (n= ote it's not even full ICE they need). >=20 > Just to add information about ICE Lite: >=20 > http://tools.ietf.org/html/draft-rescorla-mmusic-ice-lite-00 >=20 > -------------- > During the design of ICE, many implementors expressed concern about > the complexity of the protocol and the difficulty of implementing it. > This draft specifies a compatible simplified subset of ICE called > "ICE Lite" which is suitable for implementations which will always be > operated with public IP addresses. One particular environment where > ICE Lite is intended to be useful is in SIP-PSTN gateways which are > generally directly connected to the Internet. > -------------- >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From henry.sinnreich@gmail.com Thu Sep 29 15:01: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 1688621F8EFE for ; Thu, 29 Sep 2011 15:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.263 X-Spam-Level: X-Spam-Status: No, score=-3.263 tagged_above=-999 required=5 tests=[AWL=0.336, 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 wuFWXPRrEbTI for ; Thu, 29 Sep 2011 15:01:12 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4D421F8EFA for ; Thu, 29 Sep 2011 15:01:12 -0700 (PDT) Received: by yxt33 with SMTP id 33so1293057yxt.31 for ; Thu, 29 Sep 2011 15:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:mime-version:content-type:content-transfer-encoding; bh=g8KJu/doAeZnwXaOqZEpnNfvRh2eMmwZthXOpVtxNAY=; b=q26NbMBa3dBv+bsWWiOudnBjJKGXEb1rEwJxZKoNqJSOx+SAMwqoEoikAcQptK7D+k 5quOqeZoFiquC5MNbvVOQ9A48eTxw9A8s/puSTlSGbh5VySBFzvBa2yQX+KFKgTnQFeY 3L+fxafDz7sZhFzw///zXdWeGQOPqZY6p/0NU= Received: by 10.150.176.13 with SMTP id y13mr6046200ybe.67.1317333844285; Thu, 29 Sep 2011 15:04:04 -0700 (PDT) Received: from [192.168.15.2] (cpe-76-184-249-163.tx.res.rr.com. [76.184.249.163]) by mx.google.com with ESMTPS id q34sm668820ybl.17.2011.09.29.15.04.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Sep 2011 15:04:03 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 29 Sep 2011 17:04:00 -0500 From: Henry Sinnreich To: Harald Alvestrand Message-ID: Thread-Topic: [rtcweb] HIP option for draft-ietf-rtcweb-overview and which ICE? Thread-Index: Acx+87EV0D/LHJ7HrUOYyfpssctotA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: quittek@nw.neclab.eu, stiemerling@nw.neclab.eu, "rtcweb@ietf.org" , lars.eggert@nokia.com Subject: Re: [rtcweb] HIP option for draft-ietf-rtcweb-overview and which ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Sep 2011 22:01:13 -0000 > Having an 18-page ICE draft rather than the complete > 100 page ICE spec > to read was refreshing. I don't think any new technology was described > here; it's mostly explanation on how to think about ICE. http://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip-01 Yes, the draft helps when thinking of one end supporting SIP and the other end supporting some other signaling protocol, such as Jingle/XMPP. This may be relevant in the scenario including two web sites supporting different protocols or protocol implementations (hint, now more) :-) The high level solution seems also reasonable, as proposed in Figure 2: "Ideal Multi Protocol ICE Architecture" Unless I have missed something, this scenario has not been discussed as it relates to ICE and seems critical for interoperability. But hopefully it will be addressed in a separate I-D as you have mentioned. Thanks, Henry On 9/29/11 4:42 PM, "Harald Alvestrand" wrote: > On 09/29/2011 10:49 PM, Henry Sinnreich wrote: >>> I'm having a hard time finding this draft. do you have a pointer... >> Sorry, my shortened link was not inaccurate. It is >> http://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip-01 >> >> I don't know if/how MMUSIC has pursued this topic. >> Does anyone? Jonathan? > Having an 18-page ICE draft rather than the complete > 100 page ICE spec > to read was refreshing. I don't think any new technology was described > here; it's mostly explanation on how to think about ICE. > > My personal view is that the draft does not go far enough in the > separation of concerns for maximum readability; there are two concerns > when using ICE as part of a protocol suite: > > - Whether ICE setup information can be exchanged between the endpoints. > This is a matter dealt with in SIP and Jingle, but could equally well be > done by writing to/reading from an Oracle database or exchanging slips > of paper with IP addresses on them on a parkbench at midnight (just to > be melodramatic). > > - Whether ICE messages can be used safely, and reliably separated from > payload messages on the media link. This is a matter that concerns RTP, > SCTP, DTLS and so on. > > Those two things are very separable concerns, and if the authors had > desired, they could have been treated in completely separate documents. > It might have made the packet easier to digest. > > Harald > > >> Henry >> >> >> On 9/29/11 3:27 PM, "Cullen Jennings" wrote: >> >>> On Sep 28, 2011, at 4:59 PM, Henry Sinnreich wrote: >>> >>>> The draft-rosenberg-mmusic-ice-nosip from 2009 explains these issues, >>>> including the fact that not all protocols can use ICE. >>> I'm having a hard time finding this draft. do you have a pointer... >>> >>> >> >> > From HKaplan@acmepacket.com Thu Sep 29 15:16: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 3CEF521F8B5D for ; Thu, 29 Sep 2011 15:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, 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 Hz3-XlvVEjyL for ; Thu, 29 Sep 2011 15:16:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 384D021F8B5A for ; Thu, 29 Sep 2011 15:16:54 -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, 29 Sep 2011 18:19:45 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 29 Sep 2011 18:19:45 -0400 From: Hadriel Kaplan To: Roman Shpount Thread-Topic: [rtcweb] Requiring ICE for RTC calls Thread-Index: AQHMfvXk4XpbhPaZh0C9QPYrDhTyvQ== Date: Thu, 29 Sep 2011 22:19:44 +0000 Message-ID: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@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.0.0.30] Content-Type: multipart/alternative; boundary="_000_BC17B533F7E343FA8EA91B715BE9CC9Facmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Randell Jesup , "" Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Sep 2011 22:16:55 -0000 --_000_BC17B533F7E343FA8EA91B715BE9CC9Facmepacketcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If you built a "phone" which used an RTCWeb model, you would simply ignore = the requirement to mandate ICE. And that's ok. First, there's no protocol= police - nothing forces even Web Browsers to follow these rules, they just= will because they're concerned about their Browser's reputations. And sec= ond, presumably your phone wouldn't accept Javascript blindly from any rand= om website, but rather only from something trustworthy and verifiable by th= e phone=85 something which couldn't/wouldn't easily be subverted nor uninte= ntionally allowed by the users using the phone. -hadriel On Sep 28, 2011, at 3:44 PM, Roman Shpount wrote: On Wed, Sep 28, 2011 at 1:04 PM, Cullen Jennings > wrote: I agree with you point that the majority of deployed phones don't support I= CE. But so what, what do you propose to do. One thing that is not going to = happen is browser vendors do something which makes browsers such a security= threat that the browsers are banned from every corporate network. Solution= s like CORS solve the problem but short of something like that, I don't see= browser vendors deciding that remove same origin policy is a good idea. As I wrote before, you can use RTC not only in the desktop browser but also= in the desktop phone. It is not unreasonable to use the same CPU platform = being used in mobile phones and build a desk IP phone which primarily runs = the web browser to control its screen and uses RTC to setup voice/video cal= ls. This phone can be a much better and more extendable standard platform f= or building UC solutions then most of the current SIP phones. The problem i= s if standard requires ICE/SRTP this phone will not be able to work with mo= st of the current enterprise phones. Once again, since this can be consider= ed a marginal use case, we don't need to cover it in the standard and the p= hone vendor can just ignore that ICE requirement since it knows that the ph= one is located in the fully controlled network. _____________ Roman Shpount _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_BC17B533F7E343FA8EA91B715BE9CC9Facmepacketcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

If you built a "phone" which used an RTCWeb model, you would= simply ignore the requirement to mandate ICE.  And that's ok.  F= irst, there's no protocol police - nothing forces even Web Browsers to foll= ow these rules, they just will because they're concerned about their Browser's reputations.  And second, presumably your phone= wouldn't accept Javascript blindly from any random website, but rather onl= y from something trustworthy and verifiable by the phone=85 something which= couldn't/wouldn't easily be subverted nor unintentionally allowed by the users using the phone.  

-hadriel


On Sep 28, 2011, at 3:44 PM, Roman Shpount wrote:


On Wed, Sep 28, 2011 at 1:04 PM, Cullen Jennings= <fluffy@cisco.com> wro= te:
I agree with you point that the majority of deployed phones don't support I= CE. But so what, what do you propose to do. One thing that is not going to = happen is browser vendors do something which makes browsers such a security= threat that the browsers are banned from every corporate network. Solutions like CORS solve the problem but sh= ort of something like that, I don't see browser vendors deciding that remov= e same origin policy is a good idea.


As I wrote before, you can use RTC not only in the desktop browser but also= in the desktop phone. It is not unreasonable to use the same CPU platform = being used in mobile phones and build a desk IP phone which primarily runs = the web browser to control its screen and uses RTC to setup voice/video calls. This phone can be a much better a= nd more extendable standard platform for building UC solutions then most of= the current SIP phones. The problem is if standard requires ICE/SRTP this = phone will not be able to work with most of the current enterprise phones. Once again, since this can be consi= dered a marginal use case, we don't need to cover it in the standard and th= e phone vendor can just ignore that ICE requirement since it knows that the= phone is located in the fully controlled network.
_____________
Roman Shpount

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

--_000_BC17B533F7E343FA8EA91B715BE9CC9Facmepacketcom_-- From matthew.kaufman@skype.net Thu Sep 29 15:24: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 EEA2E21F8D66 for ; Thu, 29 Sep 2011 15:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.556 X-Spam-Level: X-Spam-Status: No, score=-5.556 tagged_above=-999 required=5 tests=[AWL=1.043, 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 qSCPA+7wJioq for ; Thu, 29 Sep 2011 15:24:06 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA2021F8D65 for ; Thu, 29 Sep 2011 15:24:06 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 3D9AE16E2; Fri, 30 Sep 2011 00:26:57 +0200 (CEST) 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=FS0b/uG3x0djZb eNqctFV5y5Kng=; b=n039cWcbDys5oSE/nFQfVZc+eSyCT+Ka5QmCix1rlZpdMZ 7YnBOV7MxzeTEMVu9t1iL+Rf7/TF1on+lf3cDHNoqn3+0gucNtq+XYnSvGxcg5CX 7AXw+4dQUmjDaDfj87wfvAuiyZLqRRcS4g/niqdBlgmJMDDkjEOcucn0Xl3ZY= 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=C2fXUYTgAeZ5SFRFWfBtfg uD6cJ+Uh127ivBxWi/xXjhZHGc073z86YoC1m2lPMvvb6TNzJE6O3i7OGE9DICTb IpZtKjODtgs/Z+YIBnQfQJMKDclmXU9X1/cfdgCRlRKe4XBlEX4IllIR+7c//pK6 POWxBvrcTLvryYheDdo44= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 3C06D7F8; Fri, 30 Sep 2011 00:26:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 0E3C73507E25; Fri, 30 Sep 2011 00:26:57 +0200 (CEST) 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 pW5jlxxrRtJC; Fri, 30 Sep 2011 00:26:56 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id A51953507E20; Fri, 30 Sep 2011 00:26:55 +0200 (CEST) Message-ID: <4E84F06B.7020705@skype.net> Date: Thu, 29 Sep 2011 15:25:47 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> In-Reply-To: <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randell Jesup , "" Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Sep 2011 22:24:07 -0000 On 9/29/2011 2:59 PM, Hadriel Kaplan wrote: > ICE-Lite is easier for gateway-type devices, but it's still got to do the SHA-1 calc per STUN connectivity-check response packet, which is painful from a performance/scale perspective (and thus cost). Ridiculous. We're not talking something like one SHA-1 HMAC per packet received... this is one SHA-1 per connectivity test. That's one or two packets *per call*. No way that increases the cost/complexity of any possible device that might be terminating or transcoding media. Matthew Kaufman From richard@shockey.us Thu Sep 29 16:18: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 E580E21F899D for ; Thu, 29 Sep 2011 16:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.025 X-Spam-Level: X-Spam-Status: No, score=-100.025 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 zfJMPdZjrblc for ; Thu, 29 Sep 2011 16:18:50 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 4B94721F8906 for ; Thu, 29 Sep 2011 16:18:50 -0700 (PDT) Received: (qmail 31862 invoked by uid 0); 29 Sep 2011 23:21:42 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy8.bluehost.com with SMTP; 29 Sep 2011 23:21:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=kPaodpr8CSKT+UaJrrel6hVs9bO13bbckyfo2MhP2+4=; b=WumaOJySsXBthnEcf2cwJSB/f2SDoRGSBo5rHP6kj1w2PgN3n0qiWEsbTpVGMZ6s+sFzk1t/cdD32ko34N+Ehoq99yKEMqrQ2v+D2KBgROeieSXIvUa9hFgoqbE0O0Ln; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1R9PvB-0008FO-Na; Thu, 29 Sep 2011 17:21:41 -0600 From: "Richard Shockey" To: "'Cullen Jennings'" , "'Bernard Aboba'" References: <4E80984A.903@skype.net>, <4E809EE6.2050702@skype.net>, <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <9790CEA7-59E6-4E14-9D5D-F9669E95036E@cisco.com> In-Reply-To: <9790CEA7-59E6-4E14-9D5D-F9669E95036E@cisco.com> Date: Thu, 29 Sep 2011 19:21:39 -0400 Message-ID: <02f701cc7efe$8b44b2f0$a1ce18d0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acx97Pj96CQk/MCxSFWzTJwePro+oABEG6wg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 29 Sep 2011 23:18:51 -0000 > [BA] I think you may be on to something here. POTS lines are dropping so rapidly > that wireline service won't even exist in some countries within a few years. While > PSTN interop may have been a key scenario in the early days of SIP, I have serious > doubts as to how much attention we should pay to this in RTCWEB. Ability to > make a call to an E.164 number? Probably. Support for every potential corner > case? Not necessarily. I wish I could agree but I think we have a long, long, way to go here. I will point out that the only way Microsoft can phone Cisco is over the PSTN and that is two of the most pro VoIP companies in the world. Thought I agree with rate of land lines is dropping in some countries, the rate of what VoIP reaches via the PSTN, which is land lines + mobile phones, is growing in every country I have stats for. Now of course, I'd love to see the PSTN replaced with something better but I think it is highly unrealistic to think that is going to happen in less than 10 years. RS> And at the rate this discussion is going it is reasonable to assume that it might be 10 years before RTCWEB might be able to reach consensus. But for what it's worth the end of POTS/PSTN is under active discussion. If for no other reason than the backplanes of the 5E's and DMS 500's are literally cracking at a increasing pace. Remember 3G mobile networks still use TDM Switches. Bernard's point is well taken RTCWEB shouldn't worry about interconnection some gateway or border element will normalize that problem in some way shape or form. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From HKaplan@acmepacket.com Thu Sep 29 17:15: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 CEEDB21F8D2F for ; Thu, 29 Sep 2011 17:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 h93+TUZudjQ0 for ; Thu, 29 Sep 2011 17:15:21 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id DA9C421F8D29 for ; Thu, 29 Sep 2011 17:15:20 -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, 29 Sep 2011 20:18:10 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 29 Sep 2011 20:18:11 -0400 From: Hadriel Kaplan To: Matthew Kaufman Thread-Topic: [rtcweb] Requiring ICE for RTC calls Thread-Index: AQHMfwZv3sQD2WlxHkGGIlcaHaSlxA== Date: Fri, 30 Sep 2011 00:18:10 +0000 Message-ID: <2C381E05-59C5-4678-A431-CFDAC1098050@acmepacket.com> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> <4E84F06B.7020705@skype.net> In-Reply-To: <4E84F06B.7020705@skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Randell Jesup , "" Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 00:15:21 -0000 On Sep 29, 2011, at 6:25 PM, Matthew Kaufman wrote: > Ridiculous. We're not talking something like one SHA-1 HMAC per packet re= ceived... this is one SHA-1 per connectivity test. That's one or two packet= s *per call*. No way that increases the cost/complexity of any possible dev= ice that might be terminating or transcoding media. Not as far as I know; the SHA-1 hash is calculated on every single STUN req= uest and response packet, because it covers the STUN header which includes = the transaction-id, which is unique per request; and the request has differ= ent content than the response. So per ICE-pair connectivity check, it coul= d be two STUN requests and two responses (for the "normal" mode). And sinc= e I'm assuming v4/v6 dual-stack, that's potentially double that number.=20 And yes while 8 SHA-1's per call isn't a lot compared to transcoding or ter= minating media, I wasn't talking about this being done in the PSTN TDM-faci= ng gateways themselves, but rather in the "media-plane gateway" interworkin= g RTCWeb with the legacy SIP world. (ie, SBCs) At least I assumed that's w= hat people here meant by "media gateways" - it's not like real PSTN-TDM gat= eways are eager to do ICE... nor are MTAs, voicemail servers, announcement = servers, conference servers, IVRs, etc. And note that I was responding to the emails which made it sound like "all"= the SBC has to do is ICE-Lite, and since it has the word "Lite" in it it m= ust therefor be easy/free. And my point was it's fewer calories, not zero = calories. :) -hadriel p.s. I should note the arguments in MMUSIC are about this burden for SBCs a= nd v4/v6 transition - not for plain IPv4 and PSTN gateways... not many peop= le expect real PSTN gateways to be involved with ICE, afaict. From HKaplan@acmepacket.com Thu Sep 29 17: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 DD95B21F8B17 for ; Thu, 29 Sep 2011 17:37:27 -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=[AWL=-0.074, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEDpMOEser2B for ; Thu, 29 Sep 2011 17:37:27 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E836421F8B05 for ; Thu, 29 Sep 2011 17:37:26 -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, 29 Sep 2011 20:40:17 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 29 Sep 2011 20:40:18 -0400 From: Hadriel Kaplan To: Richard Shockey Thread-Topic: [rtcweb] Requiring ICE for RTC calls Thread-Index: AQHMfwmGBJpjUg7wrk6AbHnaTx82fQ== Date: Fri, 30 Sep 2011 00:40:17 +0000 Message-ID: <9723F40D-0889-4DCF-B44D-99E05A3EDC69@acmepacket.com> References: <4E80984A.903@skype.net>, <4E809EE6.2050702@skype.net>, <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <9790CEA7-59E6-4E14-9D5D-F9669E95036E@cisco.com> <02f701cc7efe$8b44b2f0$a1ce18d0$@us> In-Reply-To: <02f701cc7efe$8b44b2f0$a1ce18d0$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <4B6F367E73B9DA45B5C021CADFB8858B@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 00:37:28 -0000 On Sep 29, 2011, at 7:21 PM, Richard Shockey wrote: > RS> And at the rate this discussion is going it is reasonable to assume t= hat > it might be 10 years before RTCWEB might be able to reach consensus. But = for > what it's worth the end of POTS/PSTN is under active discussion. If for n= o > other reason than the backplanes of the 5E's and DMS 500's are literally > cracking at a increasing pace. Remember 3G mobile networks still use TDM > Switches. Bernard's point is well taken RTCWEB shouldn't worry about > interconnection some gateway or border element will normalize that proble= m > in some way shape or form.=20 But it's not "POTS" that's really the point - it's the "PSTN". From the pe= rspective of this group, the "PSTN" is everything reachable through SIP ser= vice providers: every cell/mobile phone, DSL/Cablemodem MTA, PRI trunk, SIP= Enterprise trunk, POTS landline, etc. There are more of those right now t= han there are devices on the Internet.[1] And way more of those than numbe= r of users and Web Browsers on the Internet.[2] -hadriel [1] Based on several sources which claim approx 5 Billion mobile phones, 1.= 2 Billion POTS lines, and hundreds of millions of MTAs, and untold number o= f PRI and SIP trunks; which I'm guesstimating totals about 7 Billion. Comp= ared to approx 5 Billion current devices on the Internet, according to www.= imsresearch.com. (though they include things like printers and cameras in t= heir counts) [2] Based on ~2 Billion users, from www.internetworldstats.com and data.wor= ldbank.org. From richard@shockey.us Thu Sep 29 18:20: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 821A321F8BD5 for ; Thu, 29 Sep 2011 18:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.895 X-Spam-Level: X-Spam-Status: No, score=-99.895 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxpRZiUlhv5g for ; Thu, 29 Sep 2011 18:20:15 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 7598321F8BD3 for ; Thu, 29 Sep 2011 18:20:14 -0700 (PDT) Received: (qmail 12065 invoked by uid 0); 30 Sep 2011 01:23:07 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 30 Sep 2011 01:23:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=N0rAx2pn04EF78mcfDaPnwgvOmD4rcl1m2NyXt+DE+s=; b=Wj5/H5Fjb24ePSxPGGQqkxeu9FfBrrfEuylbFIgXTCiGH75+WUyRhJDtuSzWRcOR9QZVKKM/YOtj1cLFLV642oTuNX0VLBBN2a0QK7HyPxVTqaSzJQRQwd3ynTLM45Gn; Received: from pool-71-178-24-118.washdc.fios.verizon.net ([71.178.24.118] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1R9Rog-0000qj-NS; Thu, 29 Sep 2011 19:23:06 -0600 From: "Richard Shockey" To: "'Hadriel Kaplan'" References: <4E80984A.903@skype.net>, <4E809EE6.2050702@skype.net>, <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <9790CEA7-59E6-4E14-9D5D-F9669E95036E@cisco.com> <02f701cc7efe$8b44b2f0$a1ce18d0$@us> <9723F40D-0889-4DCF-B44D-99E05A3EDC69@acmepacket.com> In-Reply-To: <9723F40D-0889-4DCF-B44D-99E05A3EDC69@acmepacket.com> Date: Thu, 29 Sep 2011 21:23:04 -0400 Message-ID: <030f01cc7f0f$81704f80$8450ee80$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AQHMfwmGBJpjUg7wrk6AbHnaTx82fZVlHXvQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 71.178.24.118 authed with richard@shockey.us} Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 01:20:16 -0000 On Sep 29, 2011, at 7:21 PM, Richard Shockey wrote: > RS> And at the rate this discussion is going it is reasonable to assume that > it might be 10 years before RTCWEB might be able to reach consensus. But for > what it's worth the end of POTS/PSTN is under active discussion. If for no > other reason than the backplanes of the 5E's and DMS 500's are literally > cracking at a increasing pace. Remember 3G mobile networks still use TDM > Switches. Bernard's point is well taken RTCWEB shouldn't worry about > interconnection some gateway or border element will normalize that problem > in some way shape or form. But it's not "POTS" that's really the point - it's the "PSTN". From the perspective of this group, the "PSTN" is everything reachable through SIP service providers: every cell/mobile phone, DSL/Cablemodem MTA, PRI trunk, SIP Enterprise trunk, POTS landline, etc. There are more of those right now than there are devices on the Internet.[1] And way more of those than number of users and Web Browsers on the Internet.[2] Ok but that is a distinction that is causing lots of problems in identifying the real issue. The PSTN as you put it, is essentially a national and internationally regulated business model of mandated interconnection for realtime communications that uses E.164 addressing. It's a policy construct. It's a set of national specific rules, regulations, emergency services and cost recovery models. POTS, as I would prefer it to be defined, is the technical underpinning of everything in the PSTN reachable through SIP service providers etc and that's what we are ultimately talking about. And yes you are right there are more POTS end points out there than devices on the Internet, until we get rid of POTS and fold them into the "greater good" of IP and that process is progressing very well as far as I can tell. Confusing the two is going to cause everyone a lot of grief. -hadriel [1] Based on several sources which claim approx 5 Billion mobile phones, 1.2 Billion POTS lines, and hundreds of millions of MTAs, and untold number of PRI and SIP trunks; which I'm guesstimating totals about 7 Billion. Compared to approx 5 Billion current devices on the Internet, according to www.imsresearch.com. (though they include things like printers and cameras in their counts) [2] Based on ~2 Billion users, from www.internetworldstats.com and data.worldbank.org. From ekr@rtfm.com Thu Sep 29 19:35: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 0427321F8EC6 for ; Thu, 29 Sep 2011 19:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.074, 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 J4GbuSSt3vYx for ; Thu, 29 Sep 2011 19:35:28 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04F5721F8EC5 for ; Thu, 29 Sep 2011 19:35:27 -0700 (PDT) Received: by wyh21 with SMTP id 21so679130wyh.31 for ; Thu, 29 Sep 2011 19:38:20 -0700 (PDT) Received: by 10.227.10.139 with SMTP id p11mr1932055wbp.61.1317350300091; Thu, 29 Sep 2011 19:38:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.196.83 with HTTP; Thu, 29 Sep 2011 19:37:40 -0700 (PDT) In-Reply-To: <2C381E05-59C5-4678-A431-CFDAC1098050@acmepacket.com> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> <4E84F06B.7020705@skype.net> <2C381E05-59C5-4678-A431-CFDAC1098050@acmepacket.com> From: Eric Rescorla Date: Thu, 29 Sep 2011 19:37:40 -0700 Message-ID: To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=002215974dfaae843104ae1f84ba Cc: Randell Jesup , "" Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 02:35:29 -0000 --002215974dfaae843104ae1f84ba Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 29, 2011 at 5:18 PM, Hadriel Kaplan wrote: > > On Sep 29, 2011, at 6:25 PM, Matthew Kaufman wrote: > > > Ridiculous. We're not talking something like one SHA-1 HMAC per packet > received... this is one SHA-1 per connectivity test. That's one or two > packets *per call*. No way that increases the cost/complexity of any > possible device that might be terminating or transcoding media. > > Not as far as I know; the SHA-1 hash is calculated on every single STUN > request and response packet, because it covers the STUN header which > includes the transaction-id, which is unique per request; and the request > has different content than the response. So per ICE-pair connectivity > check, it could be two STUN requests and two responses (for the "normal" > mode). And since I'm assuming v4/v6 dual-stack, that's potentially double > that number. > > And yes while 8 SHA-1's per call isn't a lot compared to transcoding or > terminating media, I wasn't talking about this being done in the PSTN > TDM-facing gateways themselves, but rather in the "media-plane gateway" > interworking RTCWeb with the legacy SIP world. (ie, SBCs) At least I > assumed that's what people here meant by "media gateways" - it's not like > real PSTN-TDM gateways are eager to do ICE... nor are MTAs, voicemail > servers, announcement servers, conference servers, IVRs, etc. > Absent some measurements, I tend to agree with Matthew here. My Macbook Air can do roughly 3x10^3 SHA-1 operations per second on a single core. In order for this to be 10% of your load, you would need to be processing on the order of 75K STUN requests/sec/core. How many total calls/second can you do/core w/o STUN? -Ekr --002215974dfaae843104ae1f84ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Sep 29, 2011 at 5:18 PM, Hadriel= Kaplan <HKa= plan@acmepacket.com> wrote:

On Sep 29, 2011, at 6:25 PM, Matthew Kaufman wrote:

> Ridiculous. We're not talking something like one SHA-1 HMAC per pa= cket received... this is one SHA-1 per connectivity test. That's one or= two packets *per call*. No way that increases the cost/complexity of any p= ossible device that might be terminating or transcoding media.

Not as far as I know; the SHA-1 hash is calculated on every single ST= UN request and response packet, because it covers the STUN header which inc= ludes the transaction-id, which is unique per request; and the request has = different content than the response. =A0So per ICE-pair connectivity check,= it could be two STUN requests and two responses (for the "normal"= ; mode). =A0And since I'm assuming v4/v6 dual-stack, that's potenti= ally double that number.

And yes while 8 SHA-1's per call isn't a lot compared to transcodin= g or terminating media, I wasn't talking about this being done in the P= STN TDM-facing gateways themselves, but rather in the "media-plane gat= eway" interworking RTCWeb with the legacy SIP world. (ie, SBCs) =A0At = least I assumed that's what people here meant by "media gateways&q= uot; - it's not like real PSTN-TDM gateways are eager to do ICE... nor = are MTAs, voicemail servers, announcement servers, conference servers, IVRs= , etc.

Absent some measurements, I tend to agree = with Matthew here.=A0
My Macbook Air can do roughly=A03x10^3 SHA-= 1 operations per
second on a single core. In order for this to be= 10% of your load,
you would need to be processing on the order of=A0
75K STUN = requests/sec/core. How many total calls/second
can you do/core w/= o STUN?

-Ekr


--002215974dfaae843104ae1f84ba-- From HKaplan@acmepacket.com Thu Sep 29 21:34: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 5501721F8B3B for ; Thu, 29 Sep 2011 21:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_52=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 JNXtcU3PkBDu for ; Thu, 29 Sep 2011 21:34:32 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id A7F0321F8B3E for ; Thu, 29 Sep 2011 21:34:32 -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, 30 Sep 2011 00:37:24 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 30 Sep 2011 00:37:24 -0400 From: Hadriel Kaplan To: Eric Rescorla Thread-Topic: [rtcweb] Requiring ICE for RTC calls Thread-Index: AQHMfyqlPbj//DVJOkK2WT5l8Yxwrg== Date: Fri, 30 Sep 2011 04:37:23 +0000 Message-ID: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> <4E84F06B.7020705@skype.net> <2C381E05-59C5-4678-A431-CFDAC1098050@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: <2A5CAB5170A93443B0981665C8F2244C@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Randell Jesup , "" Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 04:34:33 -0000 On Sep 29, 2011, at 10:37 PM, Eric Rescorla wrote: > Absent some measurements, I tend to agree with Matthew here.=20 > My Macbook Air can do roughly 3x10^3 SHA-1 operations per > second on a single core. In order for this to be 10% of your load, > you would need to be processing on the order of=20 > 75K STUN requests/sec/core. How many total calls/second > can you do/core w/o STUN? That's not the problem - the problem is "media" isn't handled in CPUs on ma= ny SBCs to begin with. There're basically two types of SBC architectures i= n common use: software-based and hardware-based. The software-based ones d= on't scale well in terms of concurrent call media capacity (for obvious rea= sons), so aren't usually used by service providers. The hardware-based one= s do media processing in dedicated hardware (ASICs, NPs, whatever). To dat= e, most hardware-based SBCs that I've seen couldn't possibly do SHA-1 for S= TUN messages in their base hardware without either additional hardware comp= onents (which costs more money), or they have to send the STUN messages bac= k/forth to their signaling processors on an exception path, which means the= overhead isn't just the SHA-1 alone. So to be fair I shouldn't call it so= much the overhead of SHA-1, as the overhead inflicted by going beyond what= things like NPs can easily do by themselves (which is the SHA-1 piece). And this is in the context of the IPv4/v6 debate in MMUSIC, where any addit= ional cost burden for service providers to bear to deploy IPv6 is a sunk co= st with no additional revenue and thus very hard to support. The RTCWeb mo= del is a new "service" in some ways, so the market may bear a different cos= t burden for it. =20 And I haven't been arguing against ICE for RTCWeb - I was a few weeks ago w= hen I was hoping we could get away without it, but I don't see a safe way w= ithout it - I was only arguing in this thread against the notion of ICE-Lit= e being easy/free. The bigger problem is RTCP for G.711: since many SIP devices don't do RTCP,= and there's no way to know if they do/don't from SIP signaling, having to = have the SBC's create "fake" RTCP every 5 seconds for every call is a real = ball-buster. -hadriel p.s. note, the above is based on what I know of 5 different SBC vendors' eq= uipment - there are plenty more than that many SBC vendors in the World, bu= t my assumption is they're not too dissimilar. p.p.s. some SBCs are "decomposed", meaning separate physical systems doing = SIP signaling vs. media processing, and they're usually called things like = "BGF" or "AGW" or whatever, but it's logically the same concepts. From duerst@it.aoyama.ac.jp Thu Sep 29 22:12: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 3DFEC21F8B66 for ; Thu, 29 Sep 2011 22:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.754 X-Spam-Level: X-Spam-Status: No, score=-99.754 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 yvo4OzoTHCPb for ; Thu, 29 Sep 2011 22:12:48 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 55D0021F8B65 for ; Thu, 29 Sep 2011 22:12:47 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p8U5FTgr001894 for ; Fri, 30 Sep 2011 14:15:29 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 532d_3ca0_36e2d282_eb23_11e0_9991_001d096c566a; Fri, 30 Sep 2011 14:15:29 +0900 Received: from [IPv6:::1] ([133.2.210.1]:33486) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 30 Sep 2011 14:15:31 +0900 Message-ID: <4E85506C.100@it.aoyama.ac.jp> Date: Fri, 30 Sep 2011 14:15:24 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E80984A.903@skype.net>, <4E809EE6.2050702@skype.net>, <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <9790CEA7-59E6-4E14-9D5D-F9669E95036E@cisco.com> <02f701cc7efe$8b44b2f0$a1ce18d0$@us> <9723F40D-0889-4DCF-B44D-99E05A3EDC69@acmepacket.com> In-Reply-To: <9723F40D-0889-4DCF-B44D-99E05A3EDC69@acmepacket.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 05:12:49 -0000 On 2011/09/30 9:40, Hadriel Kaplan wrote: > But it's not "POTS" that's really the point - it's the "PSTN". From the perspective of this group, the "PSTN" is everything reachable through SIP service providers: every cell/mobile phone, DSL/Cablemodem MTA, PRI trunk, SIP Enterprise trunk, POTS landline, etc. > And way more of those than number of users and Web Browsers on the Internet.[2] Just for the record: This seems to be based on the assumption that a) mobile phones don't have browsers (many of them do) and b) that each user has only one browser (many of them have installed (and use) more than one; many people don't even realize they have installed (and use) more than one because browsers and their components are used behind the scenes in all kinds of shapes and forms. Regards, Martin. > [2] Based on ~2 Billion users, from www.internetworldstats.com and data.worldbank.org. From harald@alvestrand.no Thu Sep 29 22: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 DA2F221F8C87 for ; Thu, 29 Sep 2011 22:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.497 X-Spam-Level: X-Spam-Status: No, score=-109.497 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, J_CHICKENPOX_52=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 uD6vggMsOCQI for ; Thu, 29 Sep 2011 22:16:35 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A7E1B21F8C73 for ; Thu, 29 Sep 2011 22:16:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 18F0439E0BB for ; Fri, 30 Sep 2011 07:19:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaBpfxKj9Poh for ; Fri, 30 Sep 2011 07:19:26 +0200 (CEST) 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 69B8339E098 for ; Fri, 30 Sep 2011 07:19:26 +0200 (CEST) Message-ID: <4E85515E.5020102@alvestrand.no> Date: Fri, 30 Sep 2011 07:19:26 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> <4E84F06B.7020705@skype.net> <2C381E05-59C5-4678-A431-CFDAC1098050@acmepacket.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 05:16:36 -0000 On 09/30/2011 06:37 AM, Hadriel Kaplan wrote: > On Sep 29, 2011, at 10:37 PM, Eric Rescorla wrote: > >> Absent some measurements, I tend to agree with Matthew here. >> My Macbook Air can do roughly 3x10^3 SHA-1 operations per >> second on a single core. In order for this to be 10% of your load, >> you would need to be processing on the order of >> 75K STUN requests/sec/core. How many total calls/second >> can you do/core w/o STUN? > That's not the problem - the problem is "media" isn't handled in CPUs on many SBCs to begin with. There're basically two types of SBC architectures in common use: software-based and hardware-based. The software-based ones don't scale well in terms of concurrent call media capacity (for obvious reasons), so aren't usually used by service providers. The hardware-based ones do media processing in dedicated hardware (ASICs, NPs, whatever). To date, most hardware-based SBCs that I've seen couldn't possibly do SHA-1 for STUN messages in their base hardware without either additional hardware components (which costs more money), or they have to send the STUN messages back/forth to their signaling processors on an exception path, which means the overhead isn't just the SHA-1 alone. Still, it's on the order of a few packets per call, and most hardware devices have a software processor for "exceptional processing" these days. What number of simultaneous calls per box are you envisioning? > So to be fair I shouldn't call it so much the overhead of SHA-1, as the overhead inflicted by going beyond what things like NPs can easily do by themselves (which is the SHA-1 piece). > > And this is in the context of the IPv4/v6 debate in MMUSIC, where any additional cost burden for service providers to bear to deploy IPv6 is a sunk cost with no additional revenue and thus very hard to support. The RTCWeb model is a new "service" in some ways, so the market may bear a different cost burden for it. > > And I haven't been arguing against ICE for RTCWeb - I was a few weeks ago when I was hoping we could get away without it, but I don't see a safe way without it - I was only arguing in this thread against the notion of ICE-Lite being easy/free. Time to change the subject line, then? > The bigger problem is RTCP for G.711: since many SIP devices don't do RTCP, and there's no way to know if they do/don't from SIP signaling, having to have the SBC's create "fake" RTCP every 5 seconds for every call is a real ball-buster. Let's use a different subject line for that one, too. > -hadriel > p.s. note, the above is based on what I know of 5 different SBC vendors' equipment - there are plenty more than that many SBC vendors in the World, but my assumption is they're not too dissimilar. > p.p.s. some SBCs are "decomposed", meaning separate physical systems doing SIP signaling vs. media processing, and they're usually called things like "BGF" or "AGW" or whatever, but it's logically the same concepts. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From oej@edvina.net Thu Sep 29 23:33: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 802AC21F8B95 for ; Thu, 29 Sep 2011 23:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BfsSZEWzyFA for ; Thu, 29 Sep 2011 23:33:27 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id BC8B221F8B91 for ; Thu, 29 Sep 2011 23:33:26 -0700 (PDT) Received: from [IPv6:2001:470:1f15:d79:553a:a501:5839:101a] (unknown [IPv6:2001:470:1f15:d79:553a:a501:5839:101a]) by smtp7.webway.se (Postfix) with ESMTPA id F0550754BCE4; Fri, 30 Sep 2011 06:36:15 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_9E228C8D-E7C3-4042-9394-3A477F6283BE" From: "Olle E. Johansson" In-Reply-To: Date: Fri, 30 Sep 2011 08:36:17 +0200 Message-Id: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> <4E84F06B.7020705@skype.net> <2C381E05-59C5-4678-A431-CFDAC1098050@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SBC hardware and SHA1 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 06:33:27 -0000 --Apple-Mail=_9E228C8D-E7C3-4042-9394-3A477F6283BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 30 sep 2011 kl. 06:37 skrev Hadriel Kaplan: > To date, most hardware-based SBCs that I've seen couldn't possibly do = SHA-1 for STUN messages in their base hardware without either additional = hardware components (which costs more money), or they have to send the = STUN messages back/forth to their signaling processors on an exception = path, which means the overhead isn't just the SHA-1 alone. So to be = fair I shouldn't call it so much the overhead of SHA-1, as the overhead = inflicted by going beyond what things like NPs can easily do by = themselves (which is the SHA-1 piece). Hadriel, While on the topic of the hardware, I would like to ask how these = systems handle DTLS and SRTP. /O= --Apple-Mail=_9E228C8D-E7C3-4042-9394-3A477F6283BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
To date, = most hardware-based SBCs that I've seen couldn't possibly do SHA-1 for = STUN messages in their base hardware without either additional hardware = components (which costs more money), or they have to send the STUN = messages back/forth to their signaling processors on an exception path, = which means the overhead isn't just the SHA-1 alone.  So to be fair = I shouldn't call it so much the overhead of SHA-1, as the overhead = inflicted by going beyond what things like NPs can easily do by = themselves (which is the SHA-1 = piece).

List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2011 09:34:33 -0000 WG, This is the conclusion of this call for consensus. I see a consensus for A, but there is a few individuals objecting against it. For B the is more significant push back from quite many individuals. The main arguments being security concerns and the time required to analyze the security concerns and find a solution for them. The security concerns include both consent issues and questions of control (allowing/disallowing) of the functionality within enterprises etc. Thus my determination is that A shall be included in the use case document, while B is not included. Editors of the use cases document, can you please prepare some text for the use case and any derived requirements that you see. Best Regards Magnus Westerlund WG chair On 2011-09-19 09:02, Magnus Westerlund wrote: > WG, > > There where some discussion in the Interim meeting last week about a > Screen/Application/Desktop sharing support use case. My take away from > the discussion is that this use cases is likely well enough understood > to actually start a consensus call now. However, to us WG chairs it was > clear that the use case in question actually needs to be split into two > parts. > > A) Where the RTCWEB enabled browser can use a local application window, > the whole desktop or a Screen as a media source that can be encoded and > transported over the peerConnection for displaying/playback at the peer. > > B) Where a remote peer can provide one or more input types such as mouse > and keyboard to control the local system, not only including the > browser, but also other operating system resources. This clearly can > only happen after additional consent, most likely on a per occasion > consent. > > My interpretation is that A only allows for application sharing in > conferencing contexts, like in the WEBEX session the Interim meeting was > held with where we shared slides. Where the combination of A and B is > providing for VNC/Remote desktop. > > Thus the question to the WG is the following. > > 1) Do you support or object the inclusion of use case A, B or Both in > our Use case document? > > 2) Do you have additional comments for or against either of the use cases? > > > As WG chair > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Frgatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From stefan.lk.hakansson@ericsson.com Fri Sep 30 02:48: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 4DFA521F8B21 for ; Fri, 30 Sep 2011 02:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.33 X-Spam-Level: X-Spam-Status: No, score=-6.33 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 7sWXdrMUkFPD for ; Fri, 30 Sep 2011 02:48: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 6A78821F8B1F for ; Fri, 30 Sep 2011 02:48:51 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e3-4e859130cf52 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.115.96]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9D.9F.20773.031958E4; Fri, 30 Sep 2011 11:51:44 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.112]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Fri, 30 Sep 2011 11:51:11 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Magnus Westerlund , "rtcweb@ietf.org" , "draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org" Date: Fri, 30 Sep 2011 11:50:34 +0200 Thread-Topic: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing Thread-Index: Acx/VIgQUsIuByIqSuSflxLu2oZ3pgAAd4Xe Message-ID: References: <4E76E8E8.2050102@ericsson.com>,<4E858DBF.80001@ericsson.com> In-Reply-To: <4E858DBF.80001@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] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 09:48:52 -0000 We'll draft something for A. Stefan for the Editors. ________________________________________ From: Magnus Westerlund [magnus.westerlund@ericsson.com] Sent: Friday, September 30, 2011 11:37 AM To: rtcweb@ietf.org; draft-ietf-rtcweb-use-cases-and-requirements@tools.iet= f.org Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application= /Desktop sharing WG, This is the conclusion of this call for consensus. I see a consensus for A, but there is a few individuals objecting against it. For B the is more significant push back from quite many individuals. The main arguments being security concerns and the time required to analyze the security concerns and find a solution for them. The security concerns include both consent issues and questions of control (allowing/disallowing) of the functionality within enterprises etc. Thus my determination is that A shall be included in the use case document, while B is not included. Editors of the use cases document, can you please prepare some text for the use case and any derived requirements that you see. Best Regards Magnus Westerlund WG chair On 2011-09-19 09:02, Magnus Westerlund wrote: > WG, > > There where some discussion in the Interim meeting last week about a > Screen/Application/Desktop sharing support use case. My take away from > the discussion is that this use cases is likely well enough understood > to actually start a consensus call now. However, to us WG chairs it was > clear that the use case in question actually needs to be split into two > parts. > > A) Where the RTCWEB enabled browser can use a local application window, > the whole desktop or a Screen as a media source that can be encoded and > transported over the peerConnection for displaying/playback at the peer. > > B) Where a remote peer can provide one or more input types such as mouse > and keyboard to control the local system, not only including the > browser, but also other operating system resources. This clearly can > only happen after additional consent, most likely on a per occasion > consent. > > My interpretation is that A only allows for application sharing in > conferencing contexts, like in the WEBEX session the Interim meeting was > held with where we shared slides. Where the combination of A and B is > providing for VNC/Remote desktop. > > Thus the question to the WG is the following. > > 1) Do you support or object the inclusion of use case A, B or Both in > our Use case document? > > 2) Do you have additional comments for or against either of the use cases= ? > > > As WG chair > > 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 > -- 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 ---------------------------------------------------------------------- From stefan.lk.hakansson@ericsson.com Fri Sep 30 03:04: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 9B1BC21F8BAA for ; Fri, 30 Sep 2011 03:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.329 X-Spam-Level: X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 YNRH8xWbsbJa for ; Fri, 30 Sep 2011 03:04: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 8633721F8BB1 for ; Fri, 30 Sep 2011 03:04:25 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-c9-4e8594976f99 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.115.87]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 77.B4.20773.794958E4; Fri, 30 Sep 2011 12:06:15 +0200 (CEST) Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.112]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 30 Sep 2011 12:05:54 +0200 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= , Magnus Westerlund , "rtcweb@ietf.org" , "draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org" Date: Fri, 30 Sep 2011 12:04:38 +0200 Thread-Topic: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing Thread-Index: Acx/VIgQUsIuByIqSuSflxLu2oZ3pgAAd4XeAAB9vkY= Message-ID: References: <4E76E8E8.2050102@ericsson.com>, <4E858DBF.80001@ericsson.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== Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 10:04:26 -0000 Just a note: we'll not release a new version of the use case doc this week = as discussed earlier, instead we'll incorporate this use case in a new vers= ion sometime next week. Stefan ________________________________________ From: Stefan H=E5kansson LK [stefan.lk.hakansson@ericsson.com] Sent: Friday, September 30, 2011 11:50 AM To: Magnus Westerlund; rtcweb@ietf.org; draft-ietf-rtcweb-use-cases-and-req= uirements@tools.ietf.org Subject: RE: [rtcweb] Call for Consensus on Use Case for Screen/Application= /Desktop sharing We'll draft something for A. Stefan for the Editors. ________________________________________ From: Magnus Westerlund [magnus.westerlund@ericsson.com] Sent: Friday, September 30, 2011 11:37 AM To: rtcweb@ietf.org; draft-ietf-rtcweb-use-cases-and-requirements@tools.iet= f.org Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application= /Desktop sharing WG, This is the conclusion of this call for consensus. I see a consensus for A, but there is a few individuals objecting against it. For B the is more significant push back from quite many individuals. The main arguments being security concerns and the time required to analyze the security concerns and find a solution for them. The security concerns include both consent issues and questions of control (allowing/disallowing) of the functionality within enterprises etc. Thus my determination is that A shall be included in the use case document, while B is not included. Editors of the use cases document, can you please prepare some text for the use case and any derived requirements that you see. Best Regards Magnus Westerlund WG chair On 2011-09-19 09:02, Magnus Westerlund wrote: > WG, > > There where some discussion in the Interim meeting last week about a > Screen/Application/Desktop sharing support use case. My take away from > the discussion is that this use cases is likely well enough understood > to actually start a consensus call now. However, to us WG chairs it was > clear that the use case in question actually needs to be split into two > parts. > > A) Where the RTCWEB enabled browser can use a local application window, > the whole desktop or a Screen as a media source that can be encoded and > transported over the peerConnection for displaying/playback at the peer. > > B) Where a remote peer can provide one or more input types such as mouse > and keyboard to control the local system, not only including the > browser, but also other operating system resources. This clearly can > only happen after additional consent, most likely on a per occasion > consent. > > My interpretation is that A only allows for application sharing in > conferencing contexts, like in the WEBEX session the Interim meeting was > held with where we shared slides. Where the combination of A and B is > providing for VNC/Remote desktop. > > Thus the question to the WG is the following. > > 1) Do you support or object the inclusion of use case A, B or Both in > our Use case document? > > 2) Do you have additional comments for or against either of the use cases= ? > > > As WG chair > > 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 > -- 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 ---------------------------------------------------------------------- From tim@phonefromhere.com Fri Sep 30 06:27: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 AACF121F8A6F for ; Fri, 30 Sep 2011 06:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=-0.103, 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 ruBpKkqHy5km for ; Fri, 30 Sep 2011 06:27:21 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 30ED421F86A4 for ; Fri, 30 Sep 2011 06:27:20 -0700 (PDT) Received: from [192.168.157.49] (unknown [93.89.81.113]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 4233F37A902; Fri, 30 Sep 2011 14:43:02 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: <4E85506C.100@it.aoyama.ac.jp> Date: Fri, 30 Sep 2011 14:30:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6F77A00E-997B-44DB-ADA1-CA7D313A6BD8@phonefromhere.com> References: <4E80984A.903@skype.net>, <4E809EE6.2050702@skype.net>, <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <9790CEA7-59E6-4E14-9D5D-F9669E95036E@cisco.com> <02f701cc7efe$8b44b2f0$a1ce18d0$@us> <9723F40D-0889-4DCF-B44D-99E05A3EDC69@acmepacket.com> <4E85506C.100@it.aoyama.ac.jp> To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= X-Mailer: Apple Mail (2.1244.3) Cc: "" Subject: Re: [rtcweb] Requiring ICE for RTC calls X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 13:27:21 -0000 On 30 Sep 2011, at 06:15, Martin J. D=FCrst wrote: > On 2011/09/30 9:40, Hadriel Kaplan wrote: >=20 >> But it's not "POTS" that's really the point - it's the "PSTN". =46rom = the perspective of this group, the "PSTN" is everything reachable = through SIP service providers: every cell/mobile phone, DSL/Cablemodem = MTA, PRI trunk, SIP Enterprise trunk, POTS landline, etc. >=20 >> And way more of those than number of users and Web Browsers on the = Internet.[2] >=20 > Just for the record: >=20 > This seems to be based on the assumption that a) mobile phones don't = have browsers (many of them do) and b) that each user has only one = browser (many of them have installed (and use) more than one; many = people don't even realize they have installed (and use) more than one = because browsers and their components are used behind the scenes in all = kinds of shapes and forms. c) it defines the problem space in terms of SIP reachability - then = un-surprisingly concludes that we need to reach devices via SIP. =20 Most of those users are directly reachable via the GSM Um radio = interface - but I don't see any need to add Um constructs to rtcweb. Or = looked at different way - the stated group perspective is wrong IMHO . Tim (speaking for no-one but himself).= From HKaplan@acmepacket.com Fri Sep 30 09:37: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 B5E6721F84B3 for ; Fri, 30 Sep 2011 09:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.085, 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 7kvOUezZPT54 for ; Fri, 30 Sep 2011 09:37:01 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id DE1B921F84B2 for ; Fri, 30 Sep 2011 09:37:00 -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, 30 Sep 2011 12:39:53 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 30 Sep 2011 12:39:54 -0400 From: Hadriel Kaplan To: "Olle E. Johansson" Thread-Topic: [rtcweb] SBC hardware and SHA1 Thread-Index: AQHMf4+T0nIfFzYNnUev/fZI+TeQ9w== Date: Fri, 30 Sep 2011 16:39:51 +0000 Message-ID: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> <4E84F06B.7020705@skype.net> <2C381E05-59C5-4678-A431-CFDAC1098050@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: multipart/alternative; boundary="_000_C3C7D62E6BA843F4A29DFC9AF3BE689Facmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] SBC hardware and SHA1 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 16:37:01 -0000 --_000_C3C7D62E6BA843F4A29DFC9AF3BE689Facmepacketcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sep 30, 2011, at 2:36 AM, Olle E. Johansson wrote: Hadriel, While on the topic of the hardware, I would like to ask how these systems h= andle DTLS and SRTP. Assuming you mean terminating the SRTP, I only know of one hardware-based S= BC that claims support for terminating DTLS-SRTP, but I don't know if it's = real or slideware. I know of a couple software-based ones that do. (you ca= n probably google it to find out who) But in general the most popular support by far is for SDES-based keying. T= here are a couple of off-the-shelf chip solutions for large-scale SRTP that= handle it as a bump-in-the wire, but they need to be told the keys per str= eam and don't handle DTLS inline themselves to do so, so naturally SDES mad= e it a lot easier to use them. Having said that, I do believe that more SB= C vendors in the US market will be supporting DTLS-SRTP in the future becau= se the US government has it mandated in some agency or other I've been told= . Whether other governments will do the same I don't know. (then again the= US government mandates a lot that never gets used in practice) Also, someone asked on this list if SBC vendors support SRTP to begin with.= Almost every SBC vendor I know of does support SRTP (at least with SDES k= eying), but it usually costs more to do so, because it's done in dedicated = hardware. So most deployed SBC systems don't do SRTP, because the people b= uying/deploying them have decided they don't need it and don't want to pay = for it. It's more popular in specific vertical markets, but overall it's d= efinitely a minority today. -hadriel --_000_C3C7D62E6BA843F4A29DFC9AF3BE689Facmepacketcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0C8FCC7543EABB4A8AFD99689130E5FE@acmepacket.com> Content-Transfer-Encoding: quoted-printable
On Sep 30, 2011, at 2:36 AM, Olle E. Johansson wrote:

Hadriel,
While on the topic of the hardware, I would like to ask how these syst= ems handle DTLS and SRTP.

Assuming you mean terminating the SRTP, I only know of one hardware-ba= sed SBC that claims support for terminating DTLS-SRTP, but I don't know if = it's real or slideware.  I know of a couple software-based ones that d= o. (you can probably google it to find out who)

But in general the most popular support by far is for SDES-based keyin= g.  There are a couple of off-the-shelf chip solutions for large-scale= SRTP that handle it as a bump-in-the wire, but they need to be told the ke= ys per stream and don't handle DTLS inline themselves to do so, so naturally SDES made it a lot easier to use them. &= nbsp;Having said that, I do believe that more SBC vendors in the US market = will be supporting DTLS-SRTP in the future because the US government has it= mandated in some agency or other I've been told.  Whether other governments will do the same I don't know. = (then again the US government mandates a lot that never gets used in practi= ce)

Also, someone asked on this list if SBC vendors support SRTP to begin = with.  Almost every SBC vendor I know of does support SRTP (at least w= ith SDES keying), but it usually costs more to do so, because it's done in = dedicated hardware.  So most deployed SBC systems don't do SRTP, because the people buying/deploying them have d= ecided they don't need it and don't want to pay for it.  It's more pop= ular in specific vertical markets, but overall it's definitely a minority t= oday.

-hadriel


--_000_C3C7D62E6BA843F4A29DFC9AF3BE689Facmepacketcom_-- From cb.list6@gmail.com Fri Sep 30 09:47: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 CCB9221F8BF3 for ; Fri, 30 Sep 2011 09:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 Jrd6yOSo1TyU for ; Fri, 30 Sep 2011 09:47:59 -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 35BE721F8BEE for ; Fri, 30 Sep 2011 09:47:59 -0700 (PDT) Received: by qyk33 with SMTP id 33so1866923qyk.10 for ; Fri, 30 Sep 2011 09:50:53 -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:content-transfer-encoding; bh=htrsnHvqGFK+zq9Z5IHb8bMUPRu2plr0eWV94A4UksE=; b=kI0JZkXEFzhyQabkFDnzQqjGvhYDu4GvkHootPGlToCdAnQ7T5PRsftkKM4JP+QYh0 1+xkX26c7JrvnkK1jLni1SVSVQqbN23/l3MtL6mlmCWic5i12tNq4Eh6fTdJf7vFpXG6 /9oR3/6RlP0mcrO5goXn9flnWhDN93K4uRsNw= MIME-Version: 1.0 Received: by 10.68.36.166 with SMTP id r6mr59581415pbj.77.1317401452867; Fri, 30 Sep 2011 09:50:52 -0700 (PDT) Received: by 10.143.2.8 with HTTP; Fri, 30 Sep 2011 09:50:52 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> <4E84F06B.7020705@skype.net> <2C381E05-59C5-4678-A431-CFDAC1098050@acmepacket.com> Date: Fri, 30 Sep 2011 09:50:52 -0700 Message-ID: From: Cameron Byrne To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] SBC hardware and SHA1 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 16:47:59 -0000 On Fri, Sep 30, 2011 at 9:39 AM, Hadriel Kaplan wr= ote: > > On Sep 30, 2011, at 2:36 AM, Olle E. Johansson wrote: > > Hadriel, > While on the topic of the hardware, I would like to ask how these systems > handle DTLS and SRTP. > > Assuming you mean terminating the SRTP, I only know of one hardware-based > SBC that claims support for terminating DTLS-SRTP, but I don't know if it= 's > real or slideware. =A0I know of a couple software-based ones that do. (yo= u can > probably google it to find out who) > But in general the most popular support by far is for SDES-based keying. > =A0There are a couple of off-the-shelf chip solutions for large-scale SRT= P > that handle it as a bump-in-the wire, but they need to be told the keys p= er > stream and don't handle DTLS inline themselves to do so, so naturally SDE= S > made it a lot easier to use them. =A0Having said that, I do believe that = more > SBC vendors in the US market will be supporting DTLS-SRTP in the future > because the US government has it mandated in some agency or other I've be= en > told. =A0Whether other governments will do the same I don't know. (then a= gain > the US government mandates a lot that never gets used in practice) > Also, someone asked on this list if SBC vendors support SRTP to begin wit= h. > =A0Almost every SBC vendor I know of does support SRTP (at least with SDE= S > keying), but it usually costs more to do so, because it's done in dedicat= ed > hardware. =A0So most deployed SBC systems don't do SRTP, because the peop= le > buying/deploying them have decided they don't need it and don't want to p= ay > for it. =A0It's more popular in specific vertical markets, but overall it= 's > definitely a minority today. > -hadriel > As a service provider, i cannot imagine rolling out a solution that lacks encryption. Cost of bad press and unmet user expectations is higher than a few extra boxes. If you choose not to encrypt, well... that becomes a differentiation for those that do. We have already bought and paid for SRTP in our existing IMS/SIP applications that exist on the Internet and will mandate it for anything we do with RTCWeb too, it's policy. Cameron From oej@edvina.net Fri Sep 30 11:54: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 BE73121F8A4E for ; Fri, 30 Sep 2011 11:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.014, 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 BtcYKThuq68D for ; Fri, 30 Sep 2011 11:54:12 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1D321F8880 for ; Fri, 30 Sep 2011 11:54:12 -0700 (PDT) Received: from [192.168.40.76] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 5F5B6754BCE4; Fri, 30 Sep 2011 18:57:03 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: Date: Fri, 30 Sep 2011 20:57:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <439FECD0-7F81-471E-B9FC-60C660DBE7F9@edvina.net> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> <4E84F06B.7020705@skype.net> <2C381E05-59C5-4678-A431-CFDAC1098050@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1244.3) Cc: "" Subject: Re: [rtcweb] SBC hardware and SHA1 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 18:54:12 -0000 30 sep 2011 kl. 18:39 skrev Hadriel Kaplan: >=20 > On Sep 30, 2011, at 2:36 AM, Olle E. Johansson wrote: >=20 >> Hadriel, >> While on the topic of the hardware, I would like to ask how these = systems handle DTLS and SRTP. >=20 > Assuming you mean terminating the SRTP, I only know of one = hardware-based SBC that claims support for terminating DTLS-SRTP, but I = don't know if it's real or slideware. I know of a couple software-based = ones that do. (you can probably google it to find out who) >=20 > But in general the most popular support by far is for SDES-based = keying. There are a couple of off-the-shelf chip solutions for = large-scale SRTP that handle it as a bump-in-the wire, but they need to = be told the keys per stream and don't handle DTLS inline themselves to = do so, so naturally SDES made it a lot easier to use them. Having said = that, I do believe that more SBC vendors in the US market will be = supporting DTLS-SRTP in the future because the US government has it = mandated in some agency or other I've been told. Whether other = governments will do the same I don't know. (then again the US government = mandates a lot that never gets used in practice) >=20 > Also, someone asked on this list if SBC vendors support SRTP to begin = with. Almost every SBC vendor I know of does support SRTP (at least = with SDES keying), but it usually costs more to do so, because it's done = in dedicated hardware. So most deployed SBC systems don't do SRTP, = because the people buying/deploying them have decided they don't need it = and don't want to pay for it. It's more popular in specific vertical = markets, but overall it's definitely a minority today. I heard from another hardware vendor about the issues with DTLS and = hardware chips. Thanks for confirming that.=20 /O From oej@edvina.net Fri Sep 30 12:07: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 2348721F8BB9 for ; Fri, 30 Sep 2011 12:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.014, 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 x30n20UAPIht for ; Fri, 30 Sep 2011 12:07:50 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 4368121F8B89 for ; Fri, 30 Sep 2011 12:07:50 -0700 (PDT) Received: from [192.168.40.76] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 33862754BCE4; Fri, 30 Sep 2011 19:10:41 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Fri, 30 Sep 2011 21:10:40 +0200 Content-Transfer-Encoding: 7bit Message-Id: <8BB8BC1C-BB35-48B2-B898-43015669761C@edvina.net> References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> <4E84F06B.7020705@skype.net> <2C381E05-59C5-4678-A431-CFDAC1098050@acmepacket.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1244.3) Cc: "" Subject: Re: [rtcweb] SBC hardware and SHA1 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 19:07:56 -0000 30 sep 2011 kl. 18:50 skrev Cameron Byrne: > As a service provider, i cannot imagine rolling out a solution that > lacks encryption. Cost of bad press and unmet user expectations is > higher than a few extra boxes. If you choose not to encrypt, well... > that becomes a differentiation for those that do. > > We have already bought and paid for SRTP in our existing IMS/SIP > applications that exist on the Internet and will mandate it for > anything we do with RTCWeb too, it's policy. Thank you for that comment. It confirms a lot of our previous discussion. - we need SRTP by default - service provides will get the equipment needed to provide the new services /O From ekr@rtfm.com Fri Sep 30 12:08: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 7E6D121F8BB9 for ; Fri, 30 Sep 2011 12:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.903 X-Spam-Level: X-Spam-Status: No, score=-102.903 tagged_above=-999 required=5 tests=[AWL=0.073, 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 zEHWkB-F4tOa for ; Fri, 30 Sep 2011 12:08:49 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5823721F8CC1 for ; Fri, 30 Sep 2011 12:08:49 -0700 (PDT) Received: by wwf22 with SMTP id 22so2220686wwf.13 for ; Fri, 30 Sep 2011 12:11:43 -0700 (PDT) Received: by 10.227.208.137 with SMTP id gc9mr14030484wbb.91.1317409901809; Fri, 30 Sep 2011 12:11:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.196.83 with HTTP; Fri, 30 Sep 2011 12:11:00 -0700 (PDT) In-Reply-To: References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> <4E84F06B.7020705@skype.net> <2C381E05-59C5-4678-A431-CFDAC1098050@acmepacket.com> From: Eric Rescorla Date: Fri, 30 Sep 2011 12:11:00 -0700 Message-ID: To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=0015174be9a638926904ae2d6573 Cc: "" Subject: Re: [rtcweb] SBC hardware and SHA1 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 19:08:50 -0000 --0015174be9a638926904ae2d6573 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 30, 2011 at 9:39 AM, Hadriel Kaplan wrote: > > On Sep 30, 2011, at 2:36 AM, Olle E. Johansson wrote: > > Hadriel, > While on the topic of the hardware, I would like to ask how these systems > handle DTLS and SRTP. > > > Assuming you mean terminating the SRTP, I only know of one hardware-based > SBC that claims support for terminating DTLS-SRTP, but I don't know if it's > real or slideware. I know of a couple software-based ones that do. (you can > probably google it to find out who) > I don't know a huge amount about how hardware-based SBCs are constructed, but it's important to remember that DTLS-SRTP is DTLS key management but SRTP data transport, so the naive way to build the system would be to do the DTLS in software and then push the keys onto SRTP, thus using all the normal SRTP packet processing. Obviously, there will be some performance cost associated with this (as there is for any asymmetric key exchange). The typical acceleration strategy for TLS is to have hardware acceleration for the asymmetric operations but have the actual TLS stack in software, for the obvious reasons of flexibility and upgradeability. Don't know how much that helps. -Ekr > But in general the most popular support by far is for SDES-based keying. > There are a couple of off-the-shelf chip solutions for large-scale SRTP > that handle it as a bump-in-the wire, but they need to be told the keys per > stream and don't handle DTLS inline themselves to do so, so naturally SDES > made it a lot easier to use them. Having said that, I do believe that more > SBC vendors in the US market will be supporting DTLS-SRTP in the future > because the US government has it mandated in some agency or other I've been > told. Whether other governments will do the same I don't know. (then again > the US government mandates a lot that never gets used in practice) > > Also, someone asked on this list if SBC vendors support SRTP to begin > with. Almost every SBC vendor I know of does support SRTP (at least with > SDES keying), but it usually costs more to do so, because it's done in > dedicated hardware. So most deployed SBC systems don't do SRTP, because the > people buying/deploying them have decided they don't need it and don't want > to pay for it. It's more popular in specific vertical markets, but overall > it's definitely a minority today. > > -hadriel > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --0015174be9a638926904ae2d6573 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 30, 2011 at 9:39 AM, Hadriel Kap= lan <HKaplan= @acmepacket.com> wrote:

On Sep 30, 2011, at 2:36 AM, Olle E. Johansson wrote:

Hadriel,
While on the topic of the hardware, I would like to ask how these syst= ems handle DTLS and SRTP.

Assuming you mean terminating the SRTP, I only know of one hardw= are-based SBC that claims support for terminating DTLS-SRTP, but I don'= t know if it's real or slideware. =A0I know of a couple software-based = ones that do. (you can probably google it to find out who)

I don't know a hu= ge amount about how hardware-based SBCs are constructed, but it's impor= tant
to remember that DTLS-SRTP is DTLS key management but SRTP d= ata transport, so the naive
way to build the system would be to do the DTLS in software and then p= ush the keys onto
SRTP, thus using all the normal SRTP packet pro= cessing.

Obviously, there will be some performance= cost associated with this (as there is for any
asymmetric key exchange). The typical acceleration strategy for TLS is= to have hardware
acceleration for the asymmetric operations but = have the actual TLS stack in software,
for the obvious reasons of= flexibility and upgradeability. Don't know how much that
helps.

-Ekr
=A0
=A0
=
But in general the most popular support by far is for SDES-based keyin= g. =A0There are a couple of off-the-shelf chip solutions for large-scale SR= TP that handle it as a bump-in-the wire, but they need to be told the keys = per stream and don't handle DTLS inline themselves to do so, so naturally SDES made it a lot easier to use them. = =A0Having said that, I do believe that more SBC vendors in the US market wi= ll be supporting DTLS-SRTP in the future because the US government has it m= andated in some agency or other I've been told. =A0Whether other governments will do the same I don't know.= (then again the US government mandates a lot that never gets used in pract= ice)

Also, someone asked on this list if SBC vendors support SRTP to begin = with. =A0Almost every SBC vendor I know of does support SRTP (at least with= SDES keying), but it usually costs more to do so, because it's done in= dedicated hardware. =A0So most deployed SBC systems don't do SRTP, because the people buying/deploying them ha= ve decided they don't need it and don't want to pay for it. =A0It&#= 39;s more popular in specific vertical markets, but overall it's defini= tely a minority today.

-hadriel



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


--0015174be9a638926904ae2d6573-- From ibc@aliax.net Fri Sep 30 12:15: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 C82BF21F8CB9 for ; Fri, 30 Sep 2011 12:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4OUBwNN-Feb for ; Fri, 30 Sep 2011 12:15:44 -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 23F9921F8CB1 for ; Fri, 30 Sep 2011 12:15:44 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so2303362vcb.31 for ; Fri, 30 Sep 2011 12:18:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.179.202 with SMTP id br10mr3420807vcb.41.1317410318494; Fri, 30 Sep 2011 12:18:38 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 30 Sep 2011 12:18:38 -0700 (PDT) In-Reply-To: <9C0BD967-A31E-4ABF-AB6F-CD635E53B82C@phonefromhere.com> References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> <9C0BD967-A31E-4ABF-AB6F-CD635E53B82C@phonefromhere.com> Date: Fri, 30 Sep 2011 21:18:38 +0200 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] Low Level Javascript API Proposal avail on the webrtc list X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 19:15:44 -0000 2011/9/28 Tim Panton : > Forking presents some interesting challenges. Not in case you implement pure SIP on top of JavaScript/WebSocket :) --=20 I=C3=B1aki Baz Castillo From dzonatas@gmail.com Fri Sep 30 12:29: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 F10B421F8696 for ; Fri, 30 Sep 2011 12:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.793 X-Spam-Level: X-Spam-Status: No, score=-3.793 tagged_above=-999 required=5 tests=[AWL=-0.194, 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 1ttsgriNNCGh for ; Fri, 30 Sep 2011 12:29:46 -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 D794A21F867F for ; Fri, 30 Sep 2011 12:29:45 -0700 (PDT) Received: by ywa6 with SMTP id 6so2215101ywa.31 for ; Fri, 30 Sep 2011 12:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=o75akZwMhDUJrdnkggR916ebF8L76hoplsI/9wSV6Ig=; b=wO3coohILarJUKRym3yXBW/w44xsdPkrm4+UoHJ83z9zPp7FxdzlVCmm1U4bzZo34M oPkWfrcrCj6lKkzkYmykfJNrEgpEBLidGkN1bhtfKD2NZMqcvhyORISqvGeJjoKjENOj DvhdklfWhXVOwiRTDCgDgd1Jb3m0gJ9eNGwfc= Received: by 10.68.71.163 with SMTP id w3mr29149308pbu.130.1317411158501; Fri, 30 Sep 2011 12:32:38 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id ml4sm21202663pbc.0.2011.09.30.12.32.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Sep 2011 12:32:37 -0700 (PDT) Message-ID: <4E8619E6.9000100@gmail.com> Date: Fri, 30 Sep 2011 12:35:02 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E80984A.903@skype.net> <4E809EE6.2050702@skype.net> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> <4E84F06B.7020705@skype.net> <2C381E05-59C5-4678-A431-CFDAC1098050@acmepacket.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [rtcweb] SBC hardware and SHA1 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 19:29:49 -0000 On 09/30/2011 09:50 AM, Cameron Byrne wrote: > On Fri, Sep 30, 2011 at 9:39 AM, Hadriel Kaplan wrote: > >> On Sep 30, 2011, at 2:36 AM, Olle E. Johansson wrote: >> >> Hadriel, >> While on the topic of the hardware, I would like to ask how these systems >> handle DTLS and SRTP. >> >> Assuming you mean terminating the SRTP, I only know of one hardware-based >> SBC that claims support for terminating DTLS-SRTP, but I don't know if it's >> real or slideware. �I know of a couple software-based ones that do. (you can >> probably google it to find out who) >> But in general the most popular support by far is for SDES-based keying. >> �There are a couple of off-the-shelf chip solutions for large-scale SRTP >> that handle it as a bump-in-the wire, but they need to be told the keys per >> stream and don't handle DTLS inline themselves to do so, so naturally SDES >> made it a lot easier to use them. �Having said that, I do believe that more >> SBC vendors in the US market will be supporting DTLS-SRTP in the future >> because the US government has it mandated in some agency or other I've been >> told. �Whether other governments will do the same I don't know. (then again >> the US government mandates a lot that never gets used in practice) >> Also, someone asked on this list if SBC vendors support SRTP to begin with. >> �Almost every SBC vendor I know of does support SRTP (at least with SDES >> keying), but it usually costs more to do so, because it's done in dedicated >> hardware. �So most deployed SBC systems don't do SRTP, because the people >> buying/deploying them have decided they don't need it and don't want to pay >> for it. �It's more popular in specific vertical markets, but overall it's >> definitely a minority today. >> -hadriel >> >> > As a service provider, i cannot imagine rolling out a solution that > lacks encryption. Perhaps node.js would be easier for browsers such that the browser's JS API can forward-to node.js where available. I'd imagine despite the choice of browser flavor that something like "use local node.js for encryption" in each may be ideal over direct to cloud/SBC. That may be easier for this WG for select innovation. Either that, or let browsers run API regression against JS-UNIX (i.e. jslinux) with RTP and with hardcoded SHA validators in /dev. This may be more ideal for B2B portability and manufacturer automation, yet it may seem anti-game despite being more federal-ready. I can imagine the JS API that includes encryption with real-time constraints. I have no interest in JS other than it helps convey that idea. > Cost of bad press and unmet user expectations is > higher than a few extra boxes. If you choose not to encrypt, well... > that becomes a differentiation for those that do. > > We have already bought and paid for SRTP in our existing IMS/SIP > applications that exist on the Internet and will mandate it for > anything we do with RTCWeb too, it's policy. > > Cameron > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- --- The wheel. From ibc@aliax.net Fri Sep 30 12:43: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 C1A3D21F8AD8 for ; Fri, 30 Sep 2011 12:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhqEPg1+lhC2 for ; Fri, 30 Sep 2011 12:43:33 -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 3002921F8B13 for ; Fri, 30 Sep 2011 12:43:33 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so2328982vcb.31 for ; Fri, 30 Sep 2011 12:46:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.34.171 with SMTP id a11mr10545545vdj.313.1317411987612; Fri, 30 Sep 2011 12:46:27 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 30 Sep 2011 12:46:27 -0700 (PDT) In-Reply-To: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> Date: Fri, 30 Sep 2011 21:46:27 +0200 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: Re: [rtcweb] Low Level Javascript API Proposal avail on the webrtc list X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 19:43:33 -0000 2011/9/28 Tim Panton : > I just want to ask folks to take a look at a proposal Neil Stratford wrot= e for the > Low Level Javascript API and sent to the webrtc list. > > It =C2=A0is based on his and my experience of web based audio plugins and= on a > proposal of Cullen's a while back. > > http://lists.w3.org/Archives/Public/public-webrtc/2011Sep/0106.html > > We'd appreciate any feedback either here or on the webrtc list as appropr= iate. Hi, the API in that document is just valid for a few specific scenarios (make a call, receive a call and maybe putting a session on hold). That is a very limited subset of what any VoIP protocol can offer, so I don't think it's a good idea for rtcweb to assume a custom protocol like that for inclusion in WebRTC JS API (as native JS code within the browser). Of course, a simple API like that would be useful for lot of people offering basic media services to the web site users (basic scenarios in which there is no call transfer, parallel forking and so). Regards. --=20 I=C3=B1aki Baz Castillo From tim@phonefromhere.com Fri Sep 30 13:07: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 0D05721F87FC for ; Fri, 30 Sep 2011 13:07:54 -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 s1kFiZVHIiMU for ; Fri, 30 Sep 2011 13:07:48 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 282AA21F87E2 for ; Fri, 30 Sep 2011 13:07:48 -0700 (PDT) Received: from [192.168.2.2] (unknown [212.183.140.36]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id 0405137A902; Fri, 30 Sep 2011 21:23:27 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Tim Panton In-Reply-To: Date: Fri, 30 Sep 2011 21:10:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <14235661-FD06-4209-8F18-8366AEC50004@phonefromhere.com> References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> <9C0BD967-A31E-4ABF-AB6F-CD635E53B82C@phonefromhere.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Low Level Javascript API Proposal avail on the webrtc list X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 20:07:54 -0000 On 30 Sep 2011, at 20:18, I=F1aki Baz Castillo wrote: > 2011/9/28 Tim Panton : >> Forking presents some interesting challenges. >=20 > Not in case you implement pure SIP on top of JavaScript/WebSocket :) So the question is - do you think that you _could_ implement SIP on top = of JavaScript/WebSocket and use the RTP/media api as described ? We tried to make them = orthogonal, but I think Neil feels that to support forking you may need additional features or flags to the = calls described in the proposal. Tim.= From ibc@aliax.net Fri Sep 30 13:54: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 4A1B521F8AAC for ; Fri, 30 Sep 2011 13:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ru-vR7+LAFHq for ; Fri, 30 Sep 2011 13:54:19 -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 B63CC21F8AAA for ; Fri, 30 Sep 2011 13:54:19 -0700 (PDT) Received: by vws5 with SMTP id 5so2389033vws.31 for ; Fri, 30 Sep 2011 13:57:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.177 with SMTP id bp17mr11701808vdb.447.1317416234157; Fri, 30 Sep 2011 13:57:14 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 30 Sep 2011 13:57:14 -0700 (PDT) In-Reply-To: <14235661-FD06-4209-8F18-8366AEC50004@phonefromhere.com> References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> <9C0BD967-A31E-4ABF-AB6F-CD635E53B82C@phonefromhere.com> <14235661-FD06-4209-8F18-8366AEC50004@phonefromhere.com> Date: Fri, 30 Sep 2011 22:57:14 +0200 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] Low Level Javascript API Proposal avail on the webrtc list X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 30 Sep 2011 20:54:20 -0000 2011/9/30 Tim Panton : >> Not in case you implement pure SIP on top of JavaScript/WebSocket :) > > So the question is - do you think that you _could_ implement SIP on top o= f JavaScript/WebSocket > and use the RTP/media api as described ? We tried to make them orthogonal= , but I think Neil feels that > to support forking you may need additional features or flags to the calls= described in the proposal. I don't know (yet) if a WebRTC client can establish different media sessions with different peers at the same time (it seems difficult as there is supposed to be a single microphone). If not, then at javascript level I can decide which session to enable and which one to pause (I hope). Also, if I make an outgoing call from the webbrowser and receive multiple 180/183 with different SDP, I could choose which one to render so I just establish the media session with one of them. --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Fri Sep 30 21: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 833EC21F8669 for ; Fri, 30 Sep 2011 21:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.204, 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 g4tg-oIsbaSd for ; Fri, 30 Sep 2011 21:04:37 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5370B21F8569 for ; Fri, 30 Sep 2011 21:04:37 -0700 (PDT) Received: by iaby26 with SMTP id y26so3151530iab.31 for ; Fri, 30 Sep 2011 21:07:31 -0700 (PDT) Received: by 10.42.139.129 with SMTP id g1mr3903631icu.113.1317442051646; Fri, 30 Sep 2011 21:07:31 -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 ek22sm11681552ibb.12.2011.09.30.21.07.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Sep 2011 21:07:30 -0700 (PDT) Received: by iaby26 with SMTP id y26so3151478iab.31 for ; Fri, 30 Sep 2011 21:07:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.22.105 with SMTP id c9mr62124024pbf.88.1317442049367; Fri, 30 Sep 2011 21:07:29 -0700 (PDT) Received: by 10.68.40.197 with HTTP; Fri, 30 Sep 2011 21:07:29 -0700 (PDT) In-Reply-To: References: <545388B3-3189-4291-BD1D-52898B888F3E@phonefromhere.com> <9C0BD967-A31E-4ABF-AB6F-CD635E53B82C@phonefromhere.com> <14235661-FD06-4209-8F18-8366AEC50004@phonefromhere.com> Date: Sat, 1 Oct 2011 00:07:29 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=bcaec52154c55d5f7b04ae34e1f0 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Low Level Javascript API Proposal avail on the webrtc list X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2011 04:04:56 -0000 --bcaec52154c55d5f7b04ae34e1f0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 30, 2011 at 4:57 PM, I=F1aki Baz Castillo wrote= : > > I don't know (yet) if a WebRTC client can establish different media > sessions with different peers at the same time (it seems difficult as > there is supposed to be a single microphone). > You should be able to setup multiple video calls. For audio you should be able to mix on the client side or provide a way for the client to switch. _____________ Roman Shpount --bcaec52154c55d5f7b04ae34e1f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Sep 30, 2011 at 4:57 PM, I=F1aki= Baz Castillo <ibc@al= iax.net> wrote:

I don't know (yet) if a WebRTC client can establish different media
sessions with different peers at the same time (it seems difficult as
there is supposed to be a single microphone).

You= should be able to setup multiple video calls. For audio you should be able= to mix on the client side or provide a way for the client to switch.
_____________
Roman Shpount

--bcaec52154c55d5f7b04ae34e1f0--


2011/9/19 Randell Jesup <randell-ietf@jesup.= org>
+1 (comments below in-line)

On 9/16/2011 4:43 PM, Ted Hardie wrote:

On Thu, Sep 15, 2011 at 8:23 PM, Jim McEachern <jim.mceachern@genband.com <ma= ilto:jim.mce= achern@genband.com>> wrote:

=A0 =A0Hadriel,
=A0 =A0Well said.

=A0 =A0Your closing paragraph sums it up nicely in my mind.

=A0 =A0<snip>
=A0 =A0The only thing we need to do for rtcweb is make sure the RTP
=A0 =A0library built into the browser supports media in such a way that =A0 =A0it can communicate with other RTP peers at a media plane,
=A0 =A0regardless of what signaling protocol those peers might be using, =A0 =A0preferably without going through media gateways. =A0And ... we need=
=A0 =A0to make sure it's possible to use SIP on the rtcweb server....<= br> =A0 =A0</snip>


I think there is more to it than this for it to be a success. =A0We have to= make sure that it is relatively easy to adopt =A0rtcweb in javascript appl= ications. =A0The way we've discussed that in the past was "2 party= video chat in 20 lines of javascript". =A0 If a novel signalling prot= ocol is created every time, that won't be a practical choice. =A0Even i= f the signalling is segmented into libraries, the app will have to download= the one in use by a particular website, potentially every time. =A0This is= better than a plugin in some ways and potentially actually worse in others= .

I agree whole-heartedly. =A0My (and I'll say Mozilla's) position is= that we believe that while enabling unique new signalling and negotiation = makes interesting new applications possible, we also must make sure that th= is ability is equally available to a (say) games developer who wants to add= voice or video chat to their game without having to learn or understand 20= years of discussions and experience with signalling and media protocols.
As far as I know, this is achieved by a user lev= el API regardless of the signalling controller nature; browser built-in or = JS stack, which serves as an abstraction of the library underlying ins and = outs.

=A0
The point was made repeatedly when I explained this primary area of content= ion that we want it to be easy to use by the "little guys", and t= hat even if signalling was a downloaded JS library, you'd end up with a= wild mixture of old versions in use, which may complicate interop/federati= on (plus the overhead to pull them down, and some possible security issues)= .=A0=A0

=A0I would say that Mixture of old versions and the pos= sible security issues are problems to face in any case.



We also have to make sure that the resulting application does not flood or = fry the network. That means it will have to have real congestion control me= chanisms. =A0 Trusting the javascript application for that has some real is= sues which we've already discussed. =A0 Splitting signaling and congest= ion control isn't a lot better. =A0If congestion control at the network= level is managed by the browser but signalling is in the javascript, then = information about that state has to pass into the JS application, so it can= manage the signalling. =A0That makes the APIs more complex and runs the ri= sk that a naive javascript application will not adjust to the congestion co= ntrol requirements at all.

I think we do want to optionally include the JS application in the decision= s about bit allocation, but handle it automatically for most cases. =A0A cl= ass of complex WebRTC apps will want to be able to allocate the bits themse= lves, and in some cases drop or add streams (or switch operation modes) in = response to bandwidth changes. =A0Details to be determined; I plan to make = a proposal on this. =A0However, unless you go out of your way none of this = will impinge on your straightforward WebRTC app.



The early web took off in part because of the ease of embedding things like= images (compared to gopher, for example) into rich content. =A0We have the= opportunity to create native web applications with much richer and more in= teractive experiences with rtcweb, but if it is not easy to do, it won'= t have the same impact. =A0If this is something that can be done only by fo= lks who can roll their own signalling protocol, it's dead, because the = number of content authors is too small. =A0If it even requires selecting am= ong an unbounded set of variously maintained libraries , it will be frustra= ting for the developer of simple applications. =A0 At that level, the exist= ing plugins will simply be more stable and better known.

+1



Providing baseline APIs into a well-known signaling capability seems to me = far more likely to result in a real flowering of rtcweb content. =A0That= 9;s why I want it.

Just my two cents, not taken from any hat,

Ted


Regards,
= =A0

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


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

--00151773e02800ef6804ad48a71c-- From oej@edvina.net Mon Sep 19 03:20: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 D81F021F8A7A for ; Mon, 19 Sep 2011 03:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.010, 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 LUVy9-Vj7cl9 for ; Mon, 19 Sep 2011 03:20:47 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 267A621F877F for ; Mon, 19 Sep 2011 03:20:47 -0700 (PDT) Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 1785E754BCE4; Mon, 19 Sep 2011 10:23:07 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <4E770A02.6070009@ericsson.com> Date: Mon, 19 Sep 2011 12:23:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0E8B5057-C00C-4596-A908-990DD9ADA7EE@edvina.net> References: <4E76E8E8.2050102@ericsson.com> <504F8A52-0D1E-4334-A77C-14BCB4349F79@edvina.net> <4E770A02.6070009@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1244.3) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 10:20:49 -0000 19 sep 2011 kl. 11:23 skrev Magnus Westerlund: > Olle, >=20 > On 2011-09-19 09:32, Olle E. Johansson wrote: >>> Thus the question to the WG is the following. >>>=20 >>> 1) Do you support or object the inclusion of use case A, B or Both = in >>> our Use case document? >> Yes. >=20 > Can you please clarify if Yes, means Both cases? THis particular yes was for case A, but I agree with both cases as use = cases that will affect the architecture. I don't necessarily mean that = these apps has to be part of the RTCweb core.=20 Monday morning. A bit more poor clarity than other days :-) >=20 >>>=20 >>> 2) Do you have additional comments for or against either of the use = cases? >> Nitpick: Case A also requires user consent. >=20 > Fully agree. Ok. /O From HKaplan@acmepacket.com Mon Sep 19 03:20: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 08A0B21F8B88 for ; Mon, 19 Sep 2011 03:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 nGz0F-JVxONH for ; Mon, 19 Sep 2011 03:20:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6342421F8B82 for ; Mon, 19 Sep 2011 03:20:53 -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; Mon, 19 Sep 2011 06:23:13 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 19 Sep 2011 06:23:13 -0400 From: Hadriel Kaplan To: Randell Jesup Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: AQHMdrYiXevUPhDJQkaD+HZMirl46g== Date: Mon, 19 Sep 2011 10:23:12 +0000 Message-ID: <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> In-Reply-To: <4E76E078.5020708@jesup.org> 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: <37D8E5A36B5E4C4CA4A12AD33F8FD76A@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 10:20:55 -0000 On Sep 19, 2011, at 2:26 AM, Randell Jesup wrote: >=20 > The point was made repeatedly when I explained this primary area of conte= ntion that we want it to be easy to use by the "little guys", and that even= if signalling was a downloaded JS library, you'd end up with a wild mixtur= e of old versions in use, which may complicate interop/federation (plus the= overhead to pull them down, and some possible security issues). And you think having it in the Browsers won't end up with a wild mixture of= old versions in use, and complicated interop/federation? =20 And on top of it you'll end up with a wild mixture of signaling vendors, be= cause there'll be a mixture of Browser vendors and it's unlikely they'll al= l use the same source code inside. What's worse, it won't be controllable = by the JS developer. At least with a JS library they're all using the same= source code, and the JS developer knows what it was/did if it was an older= version. With regard to the issue of overhead of pulling it down every time, I thoug= ht browsers cache JS scripts, no?=20 -hadriel From HKaplan@acmepacket.com Mon Sep 19 03:36: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 81C7121F8A80 for ; Mon, 19 Sep 2011 03:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 xttm-rkex5gI for ; Mon, 19 Sep 2011 03:36:58 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id DA2D821F8A4E for ; Mon, 19 Sep 2011 03:36:57 -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; Mon, 19 Sep 2011 06:39:19 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 19 Sep 2011 06:39:19 -0400 From: Hadriel Kaplan To: Magnus Westerlund Thread-Topic: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing Thread-Index: AQHMdrhjdof5AQZHskOT2rgEkdz1cw== Date: Mon, 19 Sep 2011 10:39:19 +0000 Message-ID: <017078EC-3E1A-4CC4-A29F-51B569474416@acmepacket.com> References: <4E76E8E8.2050102@ericsson.com> In-Reply-To: <4E76E8E8.2050102@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="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 10:36:58 -0000 On Sep 19, 2011, at 3:02 AM, Magnus Westerlund wrote: > A) Where the RTCWEB enabled browser can use a local application window, > the whole desktop or a Screen as a media source that can be encoded and > transported over the peerConnection for displaying/playback at the peer. >=20 > B) Where a remote peer can provide one or more input types such as mouse > and keyboard to control the local system, not only including the > browser, but also other operating system resources. This clearly can > only happen after additional consent, most likely on a per occasion > consent. >=20 > My interpretation is that A only allows for application sharing in > conferencing contexts, like in the WEBEX session the Interim meeting was > held with where we shared slides. Where the combination of A and B is > providing for VNC/Remote desktop. >=20 > Thus the question to the WG is the following. >=20 > 1) Do you support or object the inclusion of use case A, B or Both in > our Use case document? >=20 > 2) Do you have additional comments for or against either of the use cases= ? I think scenario A is less worrisome than B. Scenario A is a lot like webe= x, obviously, and from a logical perspective if we're going to be able to t= ake a local video file as input to a PeerConnection LocalMediaStream, and t= he video file could be of me doing stuff on my screen, then this is just a = shortcut to taking the video and sending the file at the same time. Scenario B, on the other hand, is the other half of VNC and my IT dept. wou= ld probably freak if a browser could do this, even with user consent. (in = fact, they'd probably freak at Scenario A too) There's a big difference be= tween installing an application for a specific purpose such as VNC, vs. ran= dom Javascript on websites turning the browser into VNC. Was there discuss= ion on the con call about what IT department types would think of these two= scenarios? -hadriel From HKaplan@acmepacket.com Mon Sep 19 04:17: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 AB46921F8BA4 for ; Mon, 19 Sep 2011 04:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 K4zqogrbBouQ for ; Mon, 19 Sep 2011 04:17:16 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1F89821F8BA0 for ; Mon, 19 Sep 2011 04:17:14 -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; Mon, 19 Sep 2011 07:19:35 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 19 Sep 2011 07:19:35 -0400 From: Hadriel Kaplan To: "Olle E. Johansson" Thread-Topic: [rtcweb] STUN for keep-alive - RTCP-less applications Thread-Index: AQHMdr4Ckawc/5gAdEGO6vps68cf4A== Date: Mon, 19 Sep 2011 11:19:34 +0000 Message-ID: <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> In-Reply-To: <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> 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: <591E7C8E7595F449B496015A2D039966@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 11:17:16 -0000 I agree for rtcweb <-> rtcweb, but for going to/from non-rtcweb devices thi= s is a problem. Unfortunately lots of SIP devices don't generate RTCP. Un= doubtedly going to non-rtcweb will often require gateways of some form or o= ther in the media plane, if for nothing else than ICE termination; but maki= ng such gateways generate fake RTCP is asking for the price to go up. :( -hadriel On Sep 19, 2011, at 2:35 AM, Olle E. Johansson wrote: >=20 > 18 sep 2011 kl. 23:10 skrev Harald Alvestrand: >=20 >> I don't think we want to support RTCP-less applicaitons; if saying "no" = to them helps them not occur (it doesn't always help...) >=20 > No, we don't want to support applications without RTCP. +1. >=20 > /O > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From oej@edvina.net Mon Sep 19 04:27: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 7B5B121F8BA7 for ; Mon, 19 Sep 2011 04:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.009, 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 YfB06D4cTmgS for ; Mon, 19 Sep 2011 04:27:33 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id E265421F8BA0 for ; Mon, 19 Sep 2011 04:27:32 -0700 (PDT) Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 06C50754BCE4; Mon, 19 Sep 2011 11:29:49 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acmepacket.com> Date: Mon, 19 Sep 2011 13:29:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1244.3) Cc: "" Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 11:27:33 -0000 19 sep 2011 kl. 13:19 skrev Hadriel Kaplan: >=20 > I agree for rtcweb <-> rtcweb, but for going to/from non-rtcweb = devices this is a problem. Unfortunately lots of SIP devices don't = generate RTCP. Undoubtedly going to non-rtcweb will often require = gateways of some form or other in the media plane, if for nothing else = than ICE termination; but making such gateways generate fake RTCP is = asking for the price to go up. :( >=20 That takes us back to the core question: How much should we let the old = luggage of SIP affect the architecture of the new shining stuff we're = creating here? I agree that the SIP world has failed in implementing RTCP. Maybe we = should discuss why and see what we can come up with. Some of my = observations from working with RTCP in SIP: - NAT effects on the RTCP stream is mostly not handled - RTCP Bye is not really used=20 - Some devices have a policy/setting that says "Send RTCP every Y = minute". Calls under Y minutes doesn't get RTCP, not even a BYE with = final status - A well-known vendor sends RTCP with time stamps from year 2031 I think the coupling between actual codec quality and RTCP is missing = with the ALAW/ULAW codecs. With more adaptive codecs and of course = video, RTCP is becoming a requirement. The current PSTN-centric mostly = ALAW/ULAW SIP devices only needs RTCP to measure quality after the call = is over which means that it's not a selling feature. So if we rephrase the issue: I think RTCP should be a MUST for rtcweb = implementations. However, calls should not fail when communicating with = RTP implementations that doesn't send RTCP.=20 /O > -hadriel >=20 >=20 > On Sep 19, 2011, at 2:35 AM, Olle E. Johansson wrote: >=20 >>=20 >> 18 sep 2011 kl. 23:10 skrev Harald Alvestrand: >>=20 >>> I don't think we want to support RTCP-less applicaitons; if saying = "no" to them helps them not occur (it doesn't always help...) >>=20 >> No, we don't want to support applications without RTCP. +1. >>=20 >> /O From Markus.Isomaki@nokia.com Mon Sep 19 04:50: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 A00A521F8B28 for ; Mon, 19 Sep 2011 04:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=0.429, 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 3tH0OwBqUHKF for ; Mon, 19 Sep 2011 04:50:43 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id ED26521F8B00 for ; Mon, 19 Sep 2011 04:50:42 -0700 (PDT) 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.3) with ESMTP id p8JBr27Y011378; Mon, 19 Sep 2011 14:53:03 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Sep 2011 14:40:35 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 19 Sep 2011 13:40:34 +0200 Received: from 008-AM1MPN1-043.mgdnok.nokia.com ([169.254.3.204]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0339.002; Mon, 19 Sep 2011 13:40:34 +0200 From: To: , Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: AQHMdLFRhtDWvVL9C0SO/zqb4ZpL+ZVUHxUAgABCRgCAADPg0A== Date: Mon, 19 Sep 2011 11:40:33 +0000 Message-ID: References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> In-Reply-To: <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> 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: 19 Sep 2011 11:40:35.0479 (UTC) FILETIME=[F21E9270:01CC76C0] X-Nokia-AV: Clean Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 11:50:43 -0000 Hi, Hadriel Kaplan wrote: >With regard to the issue of overhead of pulling it down every time, I thou= ght >browsers cache JS scripts, no? I suppose scripts are no different from other resources on the web, so they= can be cached even locally at the browser. So in principle, there shouldn'= t be a need to pull down the same script from the same site over and over. = But as far as I know, caching is based on URLs and not URNs. This means tha= t even if two sites were using the same library, caching wouldn't notice th= at, if the URLs were different. I don't know if there is a solution to this= (other than actually sharing the URL , which might not be practical). It w= ould be interesting to learn.=20 Markus >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of ext Hadriel Kaplan >Sent: 19 September, 2011 13:23 >To: Randell Jesup >Cc: >Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About >defining a signaling protocol for WebRTC (or not)] > > >On Sep 19, 2011, at 2:26 AM, Randell Jesup wrote: > >> >> The point was made repeatedly when I explained this primary area of >contention that we want it to be easy to use by the "little guys", and tha= t even >if signalling was a downloaded JS library, you'd end up with a wild mixtur= e of >old versions in use, which may complicate interop/federation (plus the >overhead to pull them down, and some possible security issues). > > >And you think having it in the Browsers won't end up with a wild mixture o= f >old versions in use, and complicated interop/federation? >And on top of it you'll end up with a wild mixture of signaling vendors, >because there'll be a mixture of Browser vendors and it's unlikely they'll= all >use the same source code inside. What's worse, it won't be controllable b= y >the JS developer. At least with a JS library they're all using the same s= ource >code, and the JS developer knows what it was/did if it was an older versio= n. > >With regard to the issue of overhead of pulling it down every time, I thou= ght >browsers cache JS scripts, no? > >-hadriel > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From HKaplan@acmepacket.com Mon Sep 19 04:50: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 75EF121F8B9C for ; Mon, 19 Sep 2011 04:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 mbcDTwl8dNuO for ; Mon, 19 Sep 2011 04:50:57 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id CE63321F8B00 for ; Mon, 19 Sep 2011 04:50:56 -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; Mon, 19 Sep 2011 07:53:18 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 19 Sep 2011 07:53:18 -0400 From: Hadriel Kaplan To: "Olle E. Johansson" Thread-Topic: [rtcweb] STUN for keep-alive - RTCP-less applications Thread-Index: AQHMdsK4ExBrOYyBMkez82rphd/3ng== Date: Mon, 19 Sep 2011 11:53:18 +0000 Message-ID: <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> In-Reply-To: <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 11:50:57 -0000 I agree with everything you said, including the rephrasing at the end. (and= is what I meant - be strict on send, liberal on receive) :) -hadriel On Sep 19, 2011, at 7:29 AM, Olle E. Johansson wrote: >=20 > 19 sep 2011 kl. 13:19 skrev Hadriel Kaplan: >=20 >>=20 >> I agree for rtcweb <-> rtcweb, but for going to/from non-rtcweb devices = this is a problem. Unfortunately lots of SIP devices don't generate RTCP. = Undoubtedly going to non-rtcweb will often require gateways of some form o= r other in the media plane, if for nothing else than ICE termination; but m= aking such gateways generate fake RTCP is asking for the price to go up. := ( >>=20 > That takes us back to the core question: How much should we let the old l= uggage of SIP affect the architecture of the new shining stuff we're creati= ng here? >=20 > I agree that the SIP world has failed in implementing RTCP. Maybe we shou= ld discuss why and see what we can come up with. Some of my observations fr= om working with RTCP in SIP: >=20 > - NAT effects on the RTCP stream is mostly not handled > - RTCP Bye is not really used=20 > - Some devices have a policy/setting that says "Send RTCP every Y minute"= . Calls under Y minutes doesn't get RTCP, not even a BYE with final status > - A well-known vendor sends RTCP with time stamps from year 2031 >=20 > I think the coupling between actual codec quality and RTCP is missing wit= h the ALAW/ULAW codecs. With more adaptive codecs and of course video, RTCP= is becoming a requirement. The current PSTN-centric mostly ALAW/ULAW SIP = devices only needs RTCP to measure quality after the call is over which mea= ns that it's not a selling feature. >=20 > So if we rephrase the issue: I think RTCP should be a MUST for rtcweb imp= lementations. However, calls should not fail when communicating with RTP im= plementations that doesn't send RTCP.=20 From vsingh.ietf@gmail.com Mon Sep 19 06:13: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 EAFF921F8BB8 for ; Mon, 19 Sep 2011 06:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 RYf+CR0Vn2go for ; Mon, 19 Sep 2011 06:13:08 -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 B559A21F8BA4 for ; Mon, 19 Sep 2011 06:13:07 -0700 (PDT) Received: by fxd18 with SMTP id 18so4291421fxd.31 for ; Mon, 19 Sep 2011 06:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=lB1PL5+sjppWW9r7dwWsyvHc43JeY7Uq7CACeEjfBw8=; b=E7CaCb4NxwrA3mTsEuj6e8pZhR8utsVeubsGyZNO3krhPDUsxqq+StWq08FS6H8VaW lRMMlvQPEM2BvaxmZOk5XbppRh5bdwdG6UJcSHWWdUQv3mAVJwHjMenuBM6XVGvKm29d 3SrlrcR/yOIRLuzvHbM6ABkNYZnXLe9qC4glw= Received: by 10.223.49.213 with SMTP id w21mr5187533faf.44.1316438130189; Mon, 19 Sep 2011 06:15:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.4.136 with HTTP; Mon, 19 Sep 2011 06:15:10 -0700 (PDT) In-Reply-To: References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <4E76F544.1040108@jesup.org> <382A4C80-101D-4FD0-8473-04679248ACFB@phonefromhere.com> From: Varun Singh Date: Mon, 19 Sep 2011 16:15:10 +0300 Message-ID: To: Henrik Lundin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 13:13:09 -0000 Hi, On Mon, Sep 19, 2011 at 11:29, Henrik Lundin wrote: > Tim, > The problem that we are trying to attack with the proposal is perhaps bet= ter > described as "available bandwidth estimation" rather than congestion > control. I _would_ like to try and separated it from codecs. The bandwidt= h > estimator should inform the sender of the current feasible rate between t= wo > endpoints, and it should then be up to the sending client (application, > codecs, channel coding, etc) to figure out a way to stay within that limi= t, > while maintaining an acceptable quality for the use-case at hand. > /Henrik > I would agree that the sending application+codec should decide what trade-off it wants to make, if any. However, it should still be open to discussion if the congestion control is a sender driven (e.g. TFRC) or receiver driven (e.g. TMMBR) or a combination of sender and receiver driven. > > On Mon, Sep 19, 2011 at 10:21 AM, Tim Panton wrot= e: >> >> On 19 Sep 2011, at 08:54, Randell Jesup wrote: >> >> > Open question to the list: should the congestion-control-geeks discuss >> > here on the >> > list the nitty-gritty details required to build the requirements and >> > especially to design >> > and debate a possible proposed "baseline" congestion-control algorithm= ? >> > >> > We can certainly do that detailed discussion by email and come back wi= th >> > a >> > draft; =A0I had been planning to do it by email, but recent discussion= on >> > rtcweb >> > made me think I should ask for opinions on this. =A0Given the structur= e, >> > if there's >> > any significant support for "on-the-list" I'll do that. =A0Realize tho= ugh >> > that they may >> > get pretty long and detailed without really touching on the larger >> > issues being >> > discussed here. >> > >> > Right now the bof members to discuss this and propose a draft would be >> > myself, >> > Harald, Justin, =A0Stefan Holmer and Magnus. >> > >> >> I'd like to lurk =A0on any BoF list, if I may, >> but I have a feeling that congestion control isn't quite such a >> self-contained problem >> as forming a BoF list might imply. >> >> Roughly, my argument is that any modern congestion control for RTC needs >> to involve the application >> and the codec. >> >> Here's an example: >> =A0 =A0 =A0 =A0I'm in a video conference with 4 other people and I'm exc= eeding the >> available downlink >> bandwidth. What I want is that the video degrades (framerate of quality) >> without _any_ degradation >> of the video. I might even want to drop all the video but keep the audio >> and screenshare alive. >> =A0 =A0 =A0 =A0Conversely if I'm watching an ice hockey game - I'd rathe= r lose >> audio quality than frame-rate. >> >> But in _both_ cases I'd like the app to try and tweak the encoder params >> to get within the available bandwidth >> before we start injecting delay or dropping frames. >> >> So my proposal is that the web app is given a chance to get within the >> available bandwidth >> before the system starts putting hard constraints on the RTP level. >> >> All of which makes it something we need to discuss in a holistic fashion >> with the rest of the API. >> >> Tim. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > -- > Henrik Lundin=A0|=A0WebRTC Software Eng=A0|=A0hlundin@google.com=A0|=A0+4= 6 70 646 13 41 > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --=20 http://www.netlab.tkk.fi/~varun/ From randell-ietf@jesup.org Mon Sep 19 06:17: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 497EE21F8B9A for ; Mon, 19 Sep 2011 06:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 imWRWaOd9rme for ; Mon, 19 Sep 2011 06:17:02 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id B051C21F8481 for ; Mon, 19 Sep 2011 06:17:02 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5dkr-0007qo-Lm for rtcweb@ietf.org; Mon, 19 Sep 2011 08:19:25 -0500 Message-ID: <4E774093.4020305@jesup.org> Date: Mon, 19 Sep 2011 09:16:03 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <4E76F544.1040108@jesup.org> <382A4C80-101D-4FD0-8473-04679248ACFB@phonefromhere.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] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 13:17:03 -0000 On 9/19/2011 4:29 AM, Henrik Lundin wrote: > Tim, > > The problem that we are trying to attack with the proposal is perhaps > better described as "available bandwidth estimation" rather than > congestion control. I _would_ like to try and separated it from > codecs. The bandwidth estimator should inform the sender of the > current feasible rate between two endpoints, and it should then be up > to the sending client (application, codecs, channel coding, etc) to > figure out a way to stay within that limit, while maintaining an > acceptable quality for the use-case at hand. Right - I think we're in agreement (and Tim is) that this is the best tack to take on the problem - involve the application in figuring out how to meet the bandwidth limits. This part of it will largely be an API specification problem; figuring out how to set up the API to tell the JS app what is available, and the interfaces for responding to that. > > On Mon, Sep 19, 2011 at 10:21 AM, Tim Panton > wrote: > > > I'd like to lurk on any BoF list, if I may, > but I have a feeling that congestion control isn't quite such a > self-contained problem > as forming a BoF list might imply. > > Roughly, my argument is that any modern congestion control for RTC > needs to involve the application > and the codec. > Absolutely agree. > > Here's an example: > I'm in a video conference with 4 other people and I'm > exceeding the available downlink > bandwidth. What I want is that the video degrades (framerate of > quality) without _any_ degradation > of the video. > I'm a little confused by that wording, but I suspect we agree. The app might want ask the senders to cut their framerate or cut their resolution, or cut quality but keep framerate & resolution, or ask the senders to switch to lower-bandwidth parameters unless the VAD decides the person is talking, etc. No one answer is the 'right' one for every app or situation. > I might even want to drop all the video but keep the audio and > screenshare alive. > Exactly. > Conversely if I'm watching an ice hockey game - I'd rather > lose audio quality than frame-rate. > > But in _both_ cases I'd like the app to try and tweak the encoder > params to get within the available bandwidth > before we start injecting delay or dropping frames. > > So my proposal is that the web app is given a chance to get within > the available bandwidth > before the system starts putting hard constraints on the RTP level. > > All of which makes it something we need to discuss in a holistic > fashion with the rest of the API. > -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Mon Sep 19 06:54: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 A5B7721F8C07 for ; Mon, 19 Sep 2011 06:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 Klp2unEdsMOO for ; Mon, 19 Sep 2011 06:54:32 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id D462421F8C00 for ; Mon, 19 Sep 2011 06:54:32 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5eL9-0005ju-KV for rtcweb@ietf.org; Mon, 19 Sep 2011 08:56:55 -0500 Message-ID: <4E77495E.4000409@jesup.org> Date: Mon, 19 Sep 2011 09:53:34 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> In-Reply-To: <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.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 default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 13:54:33 -0000 On 9/19/2011 6:23 AM, Hadriel Kaplan wrote: > On Sep 19, 2011, at 2:26 AM, Randell Jesup wrote: > >> The point was made repeatedly when I explained this primary area of contention that we want it to be easy to use by the "little guys", and that even if signalling was a downloaded JS library, you'd end up with a wild mixture of old versions in use, which may complicate interop/federation (plus the overhead to pull them down, and some possible security issues). > > And you think having it in the Browsers won't end up with a wild mixture of old versions in use, and complicated interop/federation? Not compared to the complexity if it's all "roll-your-own". No one suggested that people be locked into a signalling protocol, and JS libraries are an option. We do have a lot of experience with pseudo-standard APIs implemented in JS, such as jquery and many others, and these aren't unrealistic concerns. I lean towards a proposal I made a week or two ago; to allow full access (which allows user-written JS signalling libraries) but provide minimal SIP+O/A as an option within the browser. This could be a JS library, but the primary users of this would be the "little guys" who just want simple setup of media streams, and they're most likely to never update, while browsers are updated frequently. > And on top of it you'll end up with a wild mixture of signaling vendors, because there'll be a mixture of Browser vendors and it's unlikely they'll all use the same source code inside. What's worse, it won't be controllable by the JS developer. At least with a JS library they're all using the same source code, and the JS developer knows what it was/did if it was an older version. That's entirely available to the application; they can use their own if they wish. And while I suggest a simple SIP set be included, if we were certain a "standard" JS lib were freely available and solid enough, that would make the argument stronger for a JS lib. > With regard to the issue of overhead of pulling it down every time, I thought browsers cache JS scripts, no? Yes, and as of Firefox 3 if a script is served with Cache-Control: public, it will be cached to disk even if coming from https. Note that secure (https) content by default isn't cached unless cache-control options are set. I would strongly warn against fetching JS libs for a service like this over http, and as part of the security review here we may well go further than that. -- Randell Jesup randell-ietf@jesup.org From oej@edvina.net Mon Sep 19 06:58: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 B840D21F8C07 for ; Mon, 19 Sep 2011 06:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.008, 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 GdiZPgBbWfTb for ; Mon, 19 Sep 2011 06:58:59 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id C56DD21F8BFB for ; Mon, 19 Sep 2011 06:58:58 -0700 (PDT) Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id B8EF1754BCE4; Mon, 19 Sep 2011 14:01:18 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <4E77495E.4000409@jesup.org> Date: Mon, 19 Sep 2011 16:01:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <84B5D982-88B2-44B3-987D-1094E6856EB6@edvina.net> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 13:58:59 -0000 19 sep 2011 kl. 15:53 skrev Randell Jesup: > but provide minimal SIP+O/A as an option within > the browser My apologies, but I don't think you know how hard that would be to = define. SIP lite sounds simple, but is not a small task to define in the = IETF. =20 Looking back, I think the SIP RFC should had taken the same path as = XMPP, one RFC for "core protocol basics" and one for the first app "PSTN = telephony". That way we could have based a new dialect on the core and = moved forward without listening to requirements to backporting all the = stuff that is "SIP" today. Unfortunately, we're far away from that = position today. /O= From ibc@aliax.net Mon Sep 19 07:00: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 27AB221F8C08 for ; Mon, 19 Sep 2011 07:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, 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 bYOWCeypvHWV for ; Mon, 19 Sep 2011 07:00:54 -0700 (PDT) Received: from mail-qw0-f45.google.com (mail-qw0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7C97D21F8C04 for ; Mon, 19 Sep 2011 07:00:54 -0700 (PDT) Received: by qwg2 with SMTP id 2so6088569qwg.4 for ; Mon, 19 Sep 2011 07:03:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.72.50 with SMTP id a18mr1963199vdv.426.1316440997402; Mon, 19 Sep 2011 07:03:17 -0700 (PDT) Received: by 10.220.187.7 with HTTP; Mon, 19 Sep 2011 07:03:17 -0700 (PDT) In-Reply-To: <4E77495E.4000409@jesup.org> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> Date: Mon, 19 Sep 2011 16:03:17 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Randell Jesup Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 14:00:55 -0000 2011/9/19 Randell Jesup : > And while I suggest a simple SIP set be included, if we were certain a "s= tandard" JS lib were freely available and solid enough, that would make the= argument stronger for a JS lib. Hi. Are you proposing that browsers should/would speak SIP for media signaling? That would require a signaling central point (think about NAT), does it mean that web sites should provide a like-"SIP proxy" within their infraestructure? (think about web sites hosted in shared datacenter by an Apache or other web server not behind the control of the web developer). Regards. --=20 I=C3=B1aki Baz Castillo From randell-ietf@jesup.org Mon Sep 19 07:02: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 292DA21F8BB6 for ; Mon, 19 Sep 2011 07:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 alPk6w4U8ap0 for ; Mon, 19 Sep 2011 07:02:22 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A270121F8BB5 for ; Mon, 19 Sep 2011 07:02:22 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5eSj-0000FD-Or for rtcweb@ietf.org; Mon, 19 Sep 2011 09:04:45 -0500 Message-ID: <4E774B34.1090605@jesup.org> Date: Mon, 19 Sep 2011 10:01:24 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E76E8E8.2050102@ericsson.com> <017078EC-3E1A-4CC4-A29F-51B569474416@acmepacket.com> In-Reply-To: <017078EC-3E1A-4CC4-A29F-51B569474416@acmepacket.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] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 14:02:23 -0000 On 9/19/2011 6:39 AM, Hadriel Kaplan wrote: > On Sep 19, 2011, at 3:02 AM, Magnus Westerlund wrote: > >> A) Where the RTCWEB enabled browser can use a local application window, >> the whole desktop or a Screen as a media source that can be encoded and >> transported over the peerConnection for displaying/playback at the peer. >> >> B) Where a remote peer can provide one or more input types such as mouse >> and keyboard to control the local system, not only including the >> browser, but also other operating system resources. This clearly can >> only happen after additional consent, most likely on a per occasion >> consent. >> > I think scenario A is less worrisome than B. Scenario A is a lot like webex, obviously, and from a logical perspective if we're going to be able to take a local video file as input to a PeerConnection LocalMediaStream, and the video file could be of me doing stuff on my screen, then this is just a shortcut to taking the video and sending the file at the same time. > > Scenario B, on the other hand, is the other half of VNC and my IT dept. would probably freak if a browser could do this, even with user consent. (in fact, they'd probably freak at Scenario A too) There's a big difference between installing an application for a specific purpose such as VNC, vs. random Javascript on websites turning the browser into VNC. Was there discussion on the con call about what IT department types would think of these two scenarios? To be honest, no, it wasn't discussed, and it very much should be. This might get tied into the more general discussions of "ongoing" permission, and the related topic currently being worked on in various bodies is permissions for HTML5 "webapps". This capability might not even be offered for the user to accept unless installed as part of a webapp (mirroring the permissions model of installing applications, such as installing VNC). BTW, your IT department does know that Windows has Remote Desktop and Remote Assistance, right? ;-) -- Randell Jesup randell-ietf@jesup.org From prvs=236d0731c=tterriberry@mozilla.com Mon Sep 19 07:18: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 35A2621F8C1D for ; Mon, 19 Sep 2011 07:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.193 X-Spam-Level: X-Spam-Status: No, score=-1.193 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kdq9H+wPRHUq for ; Mon, 19 Sep 2011 07:18:57 -0700 (PDT) Received: from mxip3i.isis.unc.edu (mxip3i.isis.unc.edu [152.2.2.195]) by ietfa.amsl.com (Postfix) with ESMTP id A95E621F8C19 for ; Mon, 19 Sep 2011 07:18:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EALlPd06sGgRa/2dsb2JhbABCpkKBWoFTAQEEAR0bQAEQCyEWDwkDAgECAUUTAQcCBYduBLU8hngEh2+QZRKMMA X-IronPort-AV: E=Sophos;i="4.67,551,1309752000"; d="scan'208";a="184732466" Received: from mr2a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.90]) by mxip3o.isis.unc.edu with ESMTP; 19 Sep 2011 10:20:53 -0400 X-UNC-Auth-As: tterribe X-UNC-Auth-IP: 69.181.137.38 Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id p8JEKpLJ011582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Sep 2011 10:20:53 -0400 (EDT) Message-ID: <4E774FC3.3000806@mozilla.com> Date: Mon, 19 Sep 2011 07:20:51 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101120 Gentoo/2.0.10 SeaMonkey/2.0.10 MIME-Version: 1.0 CC: rtcweb@ietf.org References: <4E76E8E8.2050102@ericsson.com> <017078EC-3E1A-4CC4-A29F-51B569474416@acmepacket.com> <4E774B34.1090605@jesup.org> In-Reply-To: <4E774B34.1090605@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 14:18:58 -0000 >> browser into VNC. Was there discussion on the con call about what IT >> department types would think of these two scenarios? > > To be honest, no, it wasn't discussed, and it very much should be. This The issue of "what will the enterprise think" has certainly been raised before on this list (albeit in slightly different contexts). See, e.g., http://www.ietf.org/mail-archive/web/rtcweb/current/msg00768.html From randell-ietf@jesup.org Mon Sep 19 07:21: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 06B6E21F8C33 for ; Mon, 19 Sep 2011 07:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 QeOW12dNIW6N for ; Mon, 19 Sep 2011 07:21:02 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id EEF4E21F8C31 for ; Mon, 19 Sep 2011 07:21:01 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5ekm-0007hn-Ub for rtcweb@ietf.org; Mon, 19 Sep 2011 09:23:25 -0500 Message-ID: <4E774F92.4040405@jesup.org> Date: Mon, 19 Sep 2011 10:20:02 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 14:21:03 -0000 On 9/19/2011 10:03 AM, Iñaki Baz Castillo wrote: > 2011/9/19 Randell Jesup: >> And while I suggest a simple SIP set be included, if we were certain a "standard" JS lib were freely available and solid enough, that would make the argument stronger for a JS lib. > Hi. Are you proposing that browsers should/would speak SIP for media > signaling? More that they provide a predefined API module(s) that would handle the simple case using SIP/O+A. > That would require a signaling central point (think about > NAT), does it mean that web sites should provide a like-"SIP proxy" > within their infraestructure? (think about web sites hosted in shared > datacenter by an Apache or other web server not behind the control of > the web developer). It would require a SIP proxy only if the app developer decides to use the SIP module. -- Randell Jesup randell-ietf@jesup.org From ekr@rtfm.com Mon Sep 19 07:22: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 0380B21F8B8B for ; Mon, 19 Sep 2011 07:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=0.077, 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 XYAGqMx7SpsH for ; Mon, 19 Sep 2011 07:22:03 -0700 (PDT) Received: from mail-wy0-f170.google.com (mail-wy0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id BE1F921F8B9B for ; Mon, 19 Sep 2011 07:22:02 -0700 (PDT) Received: by wyg8 with SMTP id 8so6459862wyg.15 for ; Mon, 19 Sep 2011 07:24:25 -0700 (PDT) Received: by 10.227.154.66 with SMTP id n2mr2876611wbw.3.1316442265221; Mon, 19 Sep 2011 07:24:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.55.82 with HTTP; Mon, 19 Sep 2011 07:24:05 -0700 (PDT) In-Reply-To: <4E77495E.4000409@jesup.org> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> From: Eric Rescorla Date: Mon, 19 Sep 2011 07:24:05 -0700 Message-ID: To: Randell Jesup Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 14:22:04 -0000 On Mon, Sep 19, 2011 at 6:53 AM, Randell Jesup wro= te: > On 9/19/2011 6:23 AM, Hadriel Kaplan wrote: >> >> On Sep 19, 2011, at 2:26 AM, Randell Jesup wrote: >> >>> The point was made repeatedly when I explained this primary area of >>> contention that we want it to be easy to use by the "little guys", and = that >>> even if signalling was a downloaded JS library, you'd end up with a wil= d >>> mixture of old versions in use, which may complicate interop/federation >>> (plus the overhead to pull them down, and some possible security issues= ). >> >> And you think having it in the Browsers won't end up with a wild mixture >> of old versions in use, and complicated interop/federation? > > Not compared to the complexity if it's all "roll-your-own". =A0No one > suggested that > people be locked into a signalling protocol, and JS libraries are an opti= on. > =A0We do > have a lot of experience with pseudo-standard APIs implemented in JS, suc= h > as jquery > and many others, and these aren't unrealistic concerns. Randell, Does auto-updating change the landscape in terms of the browser version distribution? Mozilla have measurements on what fraction of the modern (i.e. post FF4) browser base is running the latest version of Firefox? Thanks, -Ekr From randell-ietf@jesup.org Mon Sep 19 07:23: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 9759D21F8C39 for ; Mon, 19 Sep 2011 07:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 aPmrPKsqtcLq for ; Mon, 19 Sep 2011 07:23:28 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2F72B21F8BCD for ; Mon, 19 Sep 2011 07:23:28 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5en9-0000Mz-BP for rtcweb@ietf.org; Mon, 19 Sep 2011 09:25:51 -0500 Message-ID: <4E775026.5000503@jesup.org> Date: Mon, 19 Sep 2011 10:22:30 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E76E8E8.2050102@ericsson.com> <017078EC-3E1A-4CC4-A29F-51B569474416@acmepacket.com> <4E774B34.1090605@jesup.org> <4E774FC3.3000806@mozilla.com> In-Reply-To: <4E774FC3.3000806@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] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 14:23:28 -0000 On 9/19/2011 10:20 AM, Timothy B. Terriberry wrote: >>> browser into VNC. Was there discussion on the con call about what IT >>> department types would think of these two scenarios? >> >> To be honest, no, it wasn't discussed, and it very much should be. This > > The issue of "what will the enterprise think" has certainly been > raised before on this list (albeit in slightly different contexts). > See, e.g., > http://www.ietf.org/mail-archive/web/rtcweb/current/msg00768.html Yes, though that's a different topic than the security aspect Hadriel was asking about (access to screen, mouse, keyboard, etc). And those have not been adequately explored around this use-case that I've proposed. -- Randell Jesup randell-ietf@jesup.org From henry.sinnreich@gmail.com Mon Sep 19 07:24: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 1AE6A21F8C3F for ; Mon, 19 Sep 2011 07:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.184 X-Spam-Level: X-Spam-Status: No, score=-3.184 tagged_above=-999 required=5 tests=[AWL=0.415, 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 6DGNh2LC3BhR for ; Mon, 19 Sep 2011 07:24:08 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7486221F8C39 for ; Mon, 19 Sep 2011 07:24:04 -0700 (PDT) Received: by gxk19 with SMTP id 19so5054268gxk.31 for ; Mon, 19 Sep 2011 07:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=yo/folA4ptHOaCjX3d93We+HSs8+eSeba2DZxSMC5Bo=; b=b983fS+fpMWso/QNqQEZ+y+aAPEzRcRKcnq6CKcjXcv4HjDtihr/Lf7H+72cHoUoIT vX8f90VWjfAkcPsp3CqjadeU6HkdSww03/ko4qxCS8JFtsUFzS6mzsjeXdMnhBrcgJWH vnT0KKgytYeKekFk4LJ4Y8JHTX6qBH77eqjAI= Received: by 10.151.114.19 with SMTP id r19mr2370097ybm.110.1316442384732; Mon, 19 Sep 2011 07:26:24 -0700 (PDT) Received: from [192.168.15.2] (cpe-76-184-249-163.tx.res.rr.com. [76.184.249.163]) by mx.google.com with ESMTPS id h20sm2093514ani.16.2011.09.19.07.26.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Sep 2011 07:26:23 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 19 Sep 2011 09:26:18 -0500 From: Henry Sinnreich To: Hadriel Kaplan , Harald Alvestrand Message-ID: Thread-Topic: [rtcweb] SDP offer/answer vs. JSON (was: About defining a signaling protocol for WebRTC (or not)) Thread-Index: AQHMdJ6ASfE9VHVwDUuGxXm7AxKbwZVUxvME In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "" Subject: Re: [rtcweb] SDP offer/answer vs. JSON (was: About defining a signaling protocol for WebRTC (or not)) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 14:24:09 -0000 +1 Very solidly argued. Henry On 9/16/11 1:29 PM, "Hadriel Kaplan" wrote: > > On Sep 15, 2011, at 9:09 AM, Harald Alvestrand wrote: > >> The disadvantage of parsing to another structure (I am fond of JSON myself) >> is that one has to maintain a data definition for the format being parsed to, >> a defined transform between that and the "canonical SDP structure" has to be >> implemented in user space when one does SDP interoperability, both of those >> have to be updated for every SDP extension that someone defines somewhere, >> and one is still not free to define extensions on the non-SDP side if one >> still requires the ability to map them into SDP. >> >> If one uses the "native" SDP format, which is the format in which every >> extension to the format gets documented, the browsers are the ones who *have* >> to parse it (although others are likely to). > > > Right so the above paragraphs get to the heart of the matter, methinks. > Ultimately we need W3C to define an API, and the API has to provide a means of > learning RTP/media info from the browser and commanding the browser to perform > certain things with RTP/media. One could expose this API as a true data > structure, or as a long string of tokens to be parsed/serialized back/forth. > If the latter, then the choices are basically JSON or SDP. And SDP seems > advantageous because it appears to be the least work for the simple use-cases, > because the javascript could just copy back/forth the SDP between the browser > and server. In other words you're optimizing for the very simple use-cases, > in exchange for making it more complicated for the advanced use-cases. Right? > > OK, that's a laudable goal. And I recognize that the decision has basically > already been made, and nothing's going to change it. > > But email's free... so for the sake of posterity (and email archiving) here're > some reasons not to use SDP anyway: > 1) Incorporating SDP and the offer/answer model into the Browser and W3C API > inexorably ties the W3C to the IETF MMUSIC working group for all time. So > far, I had been going on the assumption the IETF would be defining what the > RTP library had to do/expose, while W3C would define the API. But if the API > includes SDP offer/answer, that portion is the IETF's domain too, afaik. > Anything the W3C wants to do in the future for that has to go through the > IETF, not just IANA. (right?) > > 2) This isn't just about JSON vs. SDP - it's about SDP *offer/answer*. SDP > offer/answer wasn't meant to be an API between an application and its RTP > library - it's a *protocol* between applications. One side-effect of this is > it has historic state. For example, if an SDP offer contains two media lines, > and one media is removed, the number of SDP media lines don't reduce back to > one - EVER. So if PeerConnection.removeStream() is invoked, the Browser needs > to remember there was that stream and signal it in SDP as disabled for all > time, until PeerConnection is closed. If addStream() is invoked later, it > could/could-not re-use that same (disabled) media line, or add a new one. > > As another example, if a new SDP offer is sent out in SIP and gets rejected > with a 488, the session reverts to the previously agreed SDP state. The > Browser would therefore have to keep state of previous SDP and revert to it to > handle this case. For example, if my Javascript started with only an audio > MediaStream in PeerConnection and later added a video MediaStream to it, the > new SDP offer would contain two media lines - if the offer gets rejected with > 488, how is that communicated to the Browser and what will the browser do? > > 3) You might well want information conveyed across that "API" that is not > meant to be sent on the wire in SDP - things you don't want defined by IANA as > SDP tokens. For example, you may want to provide packet counts, jitter, > latency, and other meta-information about individual RTP codecs. Using JSON > allows you to have data member variables which will not get serialized into > SDP, but are purely for the javascript's use, while still within the > referential tree structure of the media stream info. Or they may be for > sending to peers, but simply not for SDP. (like you could send the > jitter/latency info through the signaling channel) > > 4) Obviously if the application as a whole needs to do SDP offer/answer, then > *someone* will have to implement it correctly, including the state-related > stuff. It could be the browser or the javascript that do this. Chrome may do > a perfect job of that in the browser, afaik. But there are other browser > vendors, including niche ones such as Dolphin and Skyfire. What are the odds > they all get it right the first time? > > So which would you rather have updating an SDP engine, if one is even > needed... or updating "every SDP extension that someone defines somewhere": > the javascript which is written by the developer that knows what they want > when they want it, and can update their code by updating their javascript (or > not if they don't need to); or the browsers which are written by companies not > under the javascript developer's control, at a time of the browser companies' > choosing? > > Obviously for some things the browser will have to be updated regardless, for > example to understand rather than just ignore new JSON entries, to provide new > codecs, etc. But not all new SDP attributes require changes in the media > plane, nor encoding into JSON. In fact, a lot doesn't - some of it's > higher-application info, not really for the RTP library, and more of it's > coming in the future. > > -hadriel > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From magnus.westerlund@ericsson.com Mon Sep 19 07:37: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 6730321F8BB1 for ; Mon, 19 Sep 2011 07:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.509 X-Spam-Level: X-Spam-Status: No, score=-106.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 wDpjk-eRMS+D for ; Mon, 19 Sep 2011 07:37:37 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 26CC121F8BAB for ; Mon, 19 Sep 2011 07:37:36 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-24-4e77543f9be6 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A3.CC.20773.F34577E4; Mon, 19 Sep 2011 16:39:59 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 19 Sep 2011 16:39:59 +0200 Message-ID: <4E77543E.1040704@ericsson.com> Date: Mon, 19 Sep 2011 16:39:58 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 14:37:38 -0000 Hi, As an individual I like to provide some analyze of the entropy in RTP/RTCP. Please consider, comment and provide opinion about the number of bits. On 2011-09-16 20:30, Eric Rescorla wrote: >> The RTCP receiver reports should be adequate for 'consent freshness', no? >> If I still like receiving the traffic, I'll report that I'm receiving it. >> If I have crashed or disconnected or am not listening on that port, I won't. > > I believe so, though I'd have to make sure there's enough entropy. And of course > some implementations may not do RTCP... > So one case of attack is the one when the webserver S uses the connected clients to attack target T by instructing client C to send to target T. So the Server or some server controlled entity A needs to send RTCP to C that makes C believe T is responding, i.e. spoofed source address that are T's plus the content of the RTCP RR. Please note that SRTP will not provide any protection if the webserver knows the key. Thus if security description is allowed, which appear reasonable if supporting legacy is the goal, which is the reason for this whole proposal. Then lets analyze the entropy provided by RTP/RTCP. RTP header: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ So this is what is sent from C to T in a sequence. Lets go through the fields in order: V: fixed field P: Indicator bit for padding. Not reported X: Extension header indicator. Not reported CC: CSRC Count: Normally 0. Not reported M: Defined by payload type. Not reported PT: Payload type, defined in signalling know by server Sequence number: Hopefully random initial offset. Monotonically incremented. Reported Timestamp: Random offset, Not reported SSRC: Random drawn. Likely signalled as it needs to be mapped to media streams in current API. Reported Lets then look at the fields present in an RR or SR RTCP Report block 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ report | SSRC_1 (SSRC of first source) | block +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | fraction lost | cumulative number of packets lost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SSRC_1: Assumed to be known by webserver Fraction lost: can be selected 0 or low value cumulative number of packets lost: Can be selected, just needs to increase at some interval if fraction lost isn't 0. Extended highest sequence number: Top 16 bit will be 0 when starting up. Now only the lowest 16 needs to be guessed. How difficult depends on the packet rate, higher packet rate makes it easier as the range that C will find the report valid for is larger. To make this robust any RTCP reporting that contains a extended sequence number matching what was sent the last few seconds (3-5) probably needs to be excepted. So actual bits of entropy may be as few as 8. Here a bad implementation case exist where the stack start at 0 and work its way up when it is close to 0 bits. Interarrival jitter: can't be checked and a reasonable low value can be selected. last SR: This one contains the middle 32-bits out of the SR's NTP that C sends. So this is likely based on the system clock. But if the system is synchronized with an NTP server, then the general range can be guessed. However, without intercepting the SR packet the time of transmitting the latest SR is unknown. For a time synchronized sender that transmits only regular SR reports using AVPF the trr-int will make the attacker aware of how often new SRs will be transmitted. And initially this field may be set to 0. So the first few intervals (3-5 * 3-5s = 9-25s) this field provide 0 protection. After that if one require the SR field to be correctly filled this field likely contains around 12 bits of entropy for a known clock base. DLSR can be set freely by attacker. The SDES packet provide no protection and it the only other mandated RTCP packet in a compound. Thus my estimate is that RTCP in the first 10 seconds, which appears to be the time interval we are interested can only provide the protection to the level of difficulty it is to guess the sequence number field within the range that has been sent the last 5 seconds, which I guess is in the range of 8-12 bits of entropy. If you mandate that the Last SR field is non-zero, which may delay the the verification, allowing for more forward packets (attack packet) to be sent, then we appear to get 20-24 bits. I would claim this is to little randomness. It might be okay if one has a paranoid implementation that clamps down on a stream that gets any non-consistent RTCP packet. However, I would consider such behavior a risk for being target of a denial of service attack against a media stream that has a valid counter part. I rather have more bits of entropy and continuing to allow a flow as long as there are reports that are consistent often enough. That makes the attacker spend resources without any major impact. Thus very little more amplification than what a straight overload attack causes. An attacker can also use multiple SSRCs to send its faked receiver reports with. Thus making it difficult to determine if the one matching the report is a valid feedback or a series of spoofed packets. Thus it can also generate a number of guesses against C without invalidating each sequence of guesses necessary to unlock high rate mode. What is missing in this analyze is what impact on off-path attackers the congestion control mechanism and its reports have. However, as they are likely based on sequence numbers the reporting does not get substantially more difficult, maybe only the range needed to be hit gets slightly more compact. Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From jim.mceachern@genband.com Mon Sep 19 07:50: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 AF63121F8C16 for ; Mon, 19 Sep 2011 07:50:05 -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 c9YLUCSR3Kgv for ; Mon, 19 Sep 2011 07:50:05 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 803C521F8C12 for ; Mon, 19 Sep 2011 07:50:03 -0700 (PDT) Received: from mail.genband.com ([63.149.188.88]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTndXI7XkZQeWta1RI4xaB9UP0adt8/zs@postini.com; Mon, 19 Sep 2011 07:52:28 PDT Received: from owa.genband.com ([172.16.21.97]) by mail.genband.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Sep 2011 09:52:18 -0500 Received: from GBPLMAIL03.genband.com ([fe80::81ee:2d58:ca01:fb9a]) by GBEX01.genband.com ([fe80::a0a8:7818:e701:2f58%13]) with mapi id 14.01.0289.001; Mon, 19 Sep 2011 09:52:17 -0500 From: Jim McEachern To: Randell Jesup , "rtcweb@ietf.org" Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: AQHMdLFOt60UzI2c1UGUj7NPRmalBJVUlG0AgABCRgCAADrHAP//u2DQ Date: Mon, 19 Sep 2011 14:52:16 +0000 Message-ID: <8584590C8D7DD141AA96D01920FC6C698C8989C5@gbplmail03.genband.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> In-Reply-To: <4E77495E.4000409@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [99.242.72.70] Content-Type: multipart/mixed; boundary="_002_8584590C8D7DD141AA96D01920FC6C698C8989C5gbplmail03genba_" MIME-Version: 1.0 X-OriginalArrivalTime: 19 Sep 2011 14:52:18.0118 (UTC) FILETIME=[BA39FE60:01CC76DB] X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.500.1024-18394.007 X-TM-AS-Result: No--30.729600-5.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 14:50:05 -0000 --_002_8584590C8D7DD141AA96D01920FC6C698C8989C5gbplmail03genba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comment inline Jim > -----Original Message----- > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf Of Randell Jesup > Sent: Monday, September 19, 2011 9:54 AM > To: rtcweb@ietf.org > Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About > defining a signaling protocol for WebRTC (or not)] >=20 > On 9/19/2011 6:23 AM, Hadriel Kaplan wrote: > > On Sep 19, 2011, at 2:26 AM, Randell Jesup wrote: > > > >> The point was made repeatedly when I explained this primary area of > contention that we want it to be easy to use by the "little guys", and th= at > even if signalling was a downloaded JS library, you'd end up with a wild > mixture of old versions in use, which may complicate interop/federation > (plus the overhead to pull them down, and some possible security issues). > > > > And you think having it in the Browsers won't end up with a wild mixtur= e of > old versions in use, and complicated interop/federation? >=20 > Not compared to the complexity if it's all "roll-your-own". No one sugge= sted > that people be locked into a signalling protocol, and JS libraries are an= option. > We do have a lot of experience with pseudo-standard APIs implemented in > JS, such as jquery and many others, and these aren't unrealistic concerns= . >=20 > I lean towards a proposal I made a week or two ago; to allow full access > (which allows user-written JS signalling libraries) but provide minimal > SIP+O/A as an option within the browser. This could be a JS library, but= the > primary users of this would be the "little guys" who just want simple set= up of > media streams, and they're most likely to never update, while browsers ar= e > updated frequently. Are you suggesting that the "minimal SIP+O/A as an option within the browse= r" be baked into the browser, or simply provided as a standard JS library t= hat would be made available to those who wanted to use it. It sounds like = you are suggesting the later, but I want to be certain, since it could make= a big difference. >=20 > > And on top of it you'll end up with a wild mixture of signaling vendors= , > because there'll be a mixture of Browser vendors and it's unlikely they'l= l all > use the same source code inside. What's worse, it won't be controllable = by > the JS developer. At least with a JS library they're all using the same = source > code, and the JS developer knows what it was/did if it was an older versi= on. >=20 > That's entirely available to the application; they can use their own if t= hey > wish. > And while I suggest a simple SIP set be included, if we were certain a > "standard" JS lib were freely available and solid enough, that would make= the > argument stronger for a JS lib. >=20 > > With regard to the issue of overhead of pulling it down every time, I > thought browsers cache JS scripts, no? >=20 > Yes, and as of Firefox 3 if a script is served with Cache-Control: public= , it will > be cached to disk even if coming from https. Note that secure (https) > content by default isn't cached unless cache-control options are set. >=20 > I would strongly warn against fetching JS libs for a service like this ov= er http, > and as part of the security review here we may well go further than that. >=20 >=20 > -- > Randell Jesup > randell-ietf@jesup.org >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --_002_8584590C8D7DD141AA96D01920FC6C698C8989C5gbplmail03genba_ Content-Type: text/x-vcard; name="Jim McEachern.vcf" Content-Description: Jim McEachern.vcf Content-Disposition: attachment; filename="Jim McEachern.vcf"; size=6149; creation-date="Mon, 19 Sep 2011 14:52:16 GMT"; modification-date="Mon, 19 Sep 2011 14:52:16 GMT" Content-Transfer-Encoding: base64 QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpYLU1TLVNJR05BVFVSRTpZRVMNCk47TEFOR1VBR0U9 ZW4tdXM6TWNFYWNoZXJuO0ppbQ0KRk46SmltIE1jRWFjaGVybg0KT1JHOkdFTkJBTkQNClRJVExF Ok5BIFN0YW5kYXJkcyBEaXJlY3Rvcg0KVEVMO1dPUks7Vk9JQ0U6KzEgMzQzLjg4My4yNTI1IDw9 PSBORVcNClRFTDtDRUxMO1ZPSUNFOisxIDYxMy44NTMuMDE3Ng0KQURSO1dPUks7UFJFRjo7OzM1 MDAgQ2FybGluZyBBdmVudWU7T3R0YXdhLDtPTjtLMkggOEU5O0NhbmFkYQ0KTEFCRUw7V09SSztQ UkVGO0VOQ09ESU5HPVFVT1RFRC1QUklOVEFCTEU6MzUwMCBDYXJsaW5nIEF2ZW51ZT0wRD0wQT0N Ck90dGF3YSwgT04sIEsySCA4RTkgQ2FuYWRhDQpYLU1TLU9MLURFRkFVTFQtUE9TVEFMLUFERFJF U1M6Mg0KRU1BSUw7UFJFRjtJTlRFUk5FVDpqaW0ubWNlYWNoZXJuQGdlbmJhbmQuY29tDQpYLU1T LVRFWFQ7Q1VTVE9NMTpPZmZpY2Ugb2YgdGhlIENUTw0KUEhPVE87VFlQRT1KUEVHO0VOQ09ESU5H PUJBU0U2NDoNCiAvOWovNEFBUVNrWkpSZ0FCQVFFQVlBQmdBQUQvMndCREFBWUVCUVlGQkFZR0JR WUhCd1lJQ2hBS0Nna0pDaFFPRHd3UUZ4UVkNCiBHQmNVRmhZYUhTVWZHaHNqSEJZV0lDd2dJeVlu S1NvcEdSOHRNQzBvTUNVb0tTai8yd0JEQVFjSEJ3b0lDaE1LQ2hNb0doWWENCiBLQ2dvS0Nnb0tD Z29LQ2dvS0Nnb0tDZ29LQ2dvS0Nnb0tDZ29LQ2dvS0Nnb0tDZ29LQ2dvS0Nnb0tDZ29LQ2dvS0Nq L3dBQVINCiBDQUJZQUVnREFTSUFBaEVCQXhFQi84UUFId0FBQVFVQkFRRUJBUUVBQUFBQUFBQUFB QUVDQXdRRkJnY0lDUW9MLzhRQXRSQUENCiBBZ0VEQXdJRUF3VUZCQVFBQUFGOUFRSURBQVFSQlJJ aE1VRUdFMUZoQnlKeEZES0JrYUVJSTBLeHdSVlMwZkFrTTJKeWdna0sNCiBGaGNZR1JvbEppY29L U28wTlRZM09EazZRMFJGUmtkSVNVcFRWRlZXVjFoWldtTmtaV1puYUdscWMzUjFkbmQ0ZVhxRGhJ V0cNCiBoNGlKaXBLVGxKV1dsNWlabXFLanBLV21wNmlwcXJLenRMVzJ0N2k1dXNMRHhNWEd4OGpK eXRMVDFOWFcxOWpaMnVIaTQrVGwNCiA1dWZvNmVyeDh2UDA5ZmIzK1BuNi84UUFId0VBQXdFQkFR RUJBUUVCQVFBQUFBQUFBQUVDQXdRRkJnY0lDUW9MLzhRQXRSRUENCiBBZ0VDQkFRREJBY0ZCQVFB QVFKM0FBRUNBeEVFQlNFeEJoSkJVUWRoY1JNaU1vRUlGRUtSb2JIQkNTTXpVdkFWWW5MUkNoWWsN CiBOT0VsOFJjWUdSb21KeWdwS2pVMk56ZzVPa05FUlVaSFNFbEtVMVJWVmxkWVdWcGpaR1ZtWjJo cGFuTjBkWFozZUhsNmdvT0UNCiBoWWFIaUltS2twT1VsWmFYbUptYW9xT2twYWFucUttcXNyTzB0 YmEzdUxtNndzUEV4Y2JIeU1uSzB0UFUxZGJYMk5uYTR1UGsNCiA1ZWJuNk9ucTh2UDA5ZmIzK1Bu Ni85b0FEQU1CQUFJUkF4RUFQd0Q2cHF2cU45YTZiWnlYVjlQSEJieGpMTzV3QlJxTjdiNmINCiBZ ejNsNUlJcmVGUzd1ZXdyNXI4YWVLdFM4YmEwa051a3YyWGZzdGJST1NmUWtEcXgvU3ViRTRsVVYz YlBZeWpLSjVqTnR2bGcNCiB0MytpOC95T3k4V2ZHS1ZuZUR3MWJxcURqN1RPdVNmZFY3ZmorVmVj WC9pTFg5WmxJdXRSdmJndC9Bcm5IL2ZJNHIxTHdaOEkNCiBvVWpqdXZFN21TVThpMGpiQ3Ivdk1P djBINjE2bHB1bGFmcGNRajA2eXQ3WkIyaWpDL25qclhJc1BYcjYxSldYWTkyV2E1WmwNCiBuN3ZD VXVkcnIvd1hkL2RvZktYOWo2dGp6ZjdPdjhkZC9rUC9BRHhWblQvRWV2YU5LUHN1bzN0dVYvZ1p6 ai92azhWOVkxUzENCiBQU2RQMVNJeDZqWlc5eWgvNTZ4aHNmUTlxUDdPY2RZVDFKWEZrS251MTZD Y2ZXLzROSGtYaFQ0eFNxNlFlSmJkV2pQSDJtQmMNCiBFZTdMMy9EOHE5aDA2K3RkU3M0N3F3bmpu dDVCbFhRNUJyeWZ4cDhJb21qa3V2RERsSkFNbTBrYkliL2RZOVBvZnpyZy9CWGkNCiByVWZCV3N0 Rk1rdjJYZnN1clI4Z2pIQklCNk1LY01SVnc4dVN2cXU0cStWNExOS1RyNWE3VFc4ZitCMCtXaDlP MFZXMDIrdDkNCiBTc0lMeXlrRXR2TW9kR0hjVVY2YWQ5VWZIU2k0dHhlNlBIdmoxNGpacmkzMEMy Y2hGQW11TWR5ZnVxZnAxL0VWMG53aThGUjYNCiBKcHNlcVg4UU9wM0tCbEREL1VvZWdIdWUvd0NW ZWVhQmEvOEFDWWZGdWFTNEcrMiswdk8rZVJzVDdvK25DaXZaZkhQaXUwOEoNCiA2U2JtY0NTNWt5 dHZBRGd1MzlBTzVyemFQTE9jc1JVMld4OWZtSHRNUGg2T1ZZWmU5SlhsYnEzMC93QS9KTG9iR3E2 blphVGENCiBOYzZsZFJXMEEvaWtiR2ZZZXA5aFhuR3NmR1hTcmQyVFM3SzR2Q1A0M0lqVS9UcWYw RmVVM1Z4ci9qdlhjN1pyMjZiN3NhY0oNCiBFdnQyVWU1cjBEUXZndTd4ckpybXBlV3g2eFd5NXgv d0kvNFVuaWExZC91VnAzS2prK1haZEZQTWFsNVBvdjhBZ2EvUFJFUC8NCiBBQXV5OTM1L3NhMzIr bm5Objg4VnQ2UDhadExuZFUxU3d1TFRQOGNaRWlqNjlEK2hxNy93cDN3M3MyK2RxT2Y3M25Mbi93 QkINCiBybjljK0M1V05uMFRVaXpEcEZjcmpQOEF3SWY0VVd4a05iMys0RkxoK3Y3bG5EejEvd0Ez K0o2MXBHcTJPc1dndWRNdW9ybUUNCiAvd0FTSE9ENkVkUWZyWEIvRi93VkhyR215YXZwOFFHcFd5 RnBBby8xeURxUHFPMzVlbGVQd3lhLzRFMXdFck5aWGE5VmJsSlYNCiAva3dyNkM4QitMYlR4YnBQ blJnUjNjV0Z1SU01Mm4xSHFwN1ZwQ3RIRlJkS29yTTVjVGw5Ykpxa2NiaFpjMVB2NWRuNVB1ZWQN CiAvQVh4R3kzRnhvRnkrWTNCbXQ4OW1IM2xIMTYvZ2FLNTNYTFgvaER2aXpHOEEyVzYzS1R4NDZl Vy9VZlRsaCtGRkxDMWxDTHANCiAxSHFtVm5lWHl4TmFPS3dzYnhxSlA1LzErSnQvQUNOUnJHdFhN MkEwVUNxU2UyV0pQL29OYzFyMTFmZkVMeDRZclBMSkpKNVYNCiB1RDkyT0lIN3gvRGsxMUZuWlNl R2RKK0lzNHlqSTYyMGYrNjdjSDhuRmFQN1AraklsamY2eEl1WkpIK3p4RTlsSExmbVNQeXINCiBt akJ6VUtEODIvdlBXclltRkNlSXpOYXUwWXg5WEZQOWZ6UFEvQ1hocXc4TWFXbHBZUmpmak1zeEh6 U3Q2ay8wN1Z0MXcveEMNCiArSUZwNFZYN05icXQxcWpESWl6OHNZN0Z6L1RyWGowbDc0eThjenY1 UnZicVBPTmtQeVFyN2RoK2RkdFRFd28vdTRLNzdJK2YNCiB3dVRZbk1FOFZpSnFFWHJ6UzYvMTh2 SStrL3RWdnYyZWZGdi9BTHU4WnFhdm0wL0M3eGI1ZS83RW03Kzc5b1RQODZnaDFIeGoNCiA0SHVF RXh2TFdQT0JIT044VGV3Nmo4aldmMTJVZGFrR2tkWCtybEdycGhjVEdVdTMvRE4va2ZRSGlydzdZ ZUpkTGV6MUNNSGoNCiBNY29IelJ0NmcvNXpYei9wVTkvOE8vSGdTNnp0aWZaTUIwbGhKKzhQdzVI dUs5aitIM2orejhWUi9aNWxXMTFSQmxvYy9LNDcNCiBsRC9UclhPZkg3UmttMHF5MWVOUUpZSDht UWp1amRNL1FqL3g2bGlZeHFRVmVudWlzb3FWY0ppSGxtTVh1ejBzKzc2cjFNSDQNCiArb2o2M285 MUFRZk90dUdYdUEyUWYvSHFLbWtzRzhTK0h2aDdNUVdrODlyU1EvN0t0My80REdUUlhQUER5cnpj NDdPMzVIclUNCiBNMm81Wmg0WWVycTF6TDdwTkhkZkZqVDAvd0NFRjE2YUJNU3lpRjVNZDlraTgv bC9Lc1B3YnJjWGhyNE5SNmpoVEl2bWlOVC8NCiBBQlNGMkFIK2V3cjBmV0xGTlQwcThzWmZ1WEVU Um4yeU1acnhQNGoyVTJqZUJmQ2VodUJISTdTUEtPZzNqSFg4WE5kZUlUcFMNCiBkVmRyZk8vL0FB VHdzcWNNWlJoZ3FqM3FKL0pSZC95SWZodDRNbDhZYWhQcm12dEk5a1pDVGs4M0Q1NTUvdWovQU90 WHZOcmINCiBRV2x1a0ZyRkhEQ2d3cVJxRlVEMkFxcDRmMCtIU3RFc3JHMUE4cUdKVkJIZmprL2lj bjhhMEsydzlCVW8rZlU4N05jeW5qcXoNCiBlMEZwRmRFdjh3cUc5dExlK3RudDd5R09lQnhobzVG M0EvaFUxRmRGcm5tSnVMdWo1OCtJbmhDZndUcXR2ck9oUEl0a1pBVWINCiBPVEEvOTBudUQyL0t1 MzhYYTFENGsrRGsrb2dBTklrZTlSL0RJSFVFZm5YYitLdE1oMWp3N3FGamNiZGtzTFlMZEZZY2cv Z1ENCiBEWGpQdyt0cHRaK0hIaWpSNDFNa2lTUnlSS1A3eC84QXJwWG16cCt5bktFTnBKNmVaOWZo OFY5ZXc5UEVWMzc5R2NidnZGdnINCiAvWDVub1B3Z3NVLzRRTFI1Wmt6SWp6U3g1L2h5N0RQNVov T2l1czBIVDAwblJiS3dqKzdid3JIbjFJSEovT2l1NmxEa2dvK1INCiA4emphL3dCWXhFNnEyYmJY emR5OVhsdngzdFZObm9lb1RSbVMydHJvcEtvN3EyMGtmanN4WHFWWlhpblJvZkVHZzNtbXo4Q1oN CiBNSzJNN0dIS3QrQnhTcjAvYVUzRkdtVzRsWVhGUXJTMlQxOUhvL3daeTJoV2wvWmFmRGUrQzcr TFVkR2xHNWJHOGM1ajlRa24NCiBVWTlHclhUeGZGYi9BQzYxcG1wNmE0Nmw0RExIK0R4NUdLNUx3 UnA5N2J4elJhVk9tbjY3WkVSMzJuekFtQzV4OTJRQWNydUcNCiBQbUhldXpqOFNTVzQyNjFwVjla U0RxOGNadUl2d2RBY2ZpQldOS1Q1VTcyL0wvZ2VoNkdNcEoxWEZybjgwN1M4dktWOTdwTy8NCiBY c04vNFRqdzVqL2tLUjU5Tmo1L0xHYWlmeGZIY2ZMb3VsNm5xVWgrNlZnTU1mNHZKZ1lxNS93bGVo NHovYUVXZlRhMjc4c1oNCiBxS1R4STA0MjZOcFYvZlNIb3p4bUNMOFhjRDlBYTBjMy9Ndmt2K0N6 a1ZDSzE5akwvdDUyWHowaithTUhXN0RVZFFzWnJ6eHANCiBxRVduYU5FTjdXTm81K2NkaEpKMVAw V3N6NEMyWWowblY3MUVLdzNOeUZqSCt5b1Avd0FWVUhqNnd2NzhXOWxxZHdsNXJkODINCiB5MDAr M3lJTFpmNHBXN3NRTS9NY2ZUaXZSdkRPanc2RG9WbnB0dnlzQ0FGc1kzTjFadnhPVFdNSWMxYm10 dDkrcDZHSnJxamwNCiA3cGN5dk5yUkt5U1hWZFhycGQ3MjYydWFkRkZGZHA4NEZGRkZBR0xydWdS NmpjUlgxcE0xbHFzQXhGZFJqSngvZGNkR1gyUDQNCiBWRkRxOS9aZ1I2M3BzdTRmOHZOa3BtaWIz d1BuWDZZUDFvb3JLYTVieVIyNGVick9OR3BxdW5kZWovUjNRLzhBNFNyUmZOMmYNCiBhLzMyTStY NUw3LysrZHVham4xZlVyNEdMUTlObFVuL0FKZXI1VEZHdnVGKyszMHdCNzBVVmpUcXlxUGxlaDM0 dkEwc0pCVkkNCiArOTY3ZmhZbDhQOEFoK0xTNXByeTRtZTkxVzQvMTEzS01NUi9kVWRGVWVncmJv b3JxakZSVmtlUFZxenF5NXB1N0NpaWltWm4NCiAvOWs9DQoNClgtTVMtT0wtREVTSUdOO0NIQVJT RVQ9dXRmLTg6PGNhcmQgeG1sbnM9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNl L291dGxvb2svMTIvZWxlY3Ryb25pY2J1c2luZXNzY2FyZHMiIHZlcj0iMS4wIiBsYXlvdXQ9Imxl ZnQiIGJnY29sb3I9ImZmZmZmZiI+PGltZyB4bWxucz0iIiBhbGlnbj0idGxlZnQiIGFyZWE9IjE1 IiB1c2U9InBob3RvIi8+PGZsZCB4bWxucz0iIiBwcm9wPSJuYW1lIiBhbGlnbj0ibGVmdCIgZGly PSJsdHIiIGNvbG9yPSIwMDAwMDAiIHNpemU9IjEwIi8+PGZsZCB4bWxucz0iIiBwcm9wPSJ0aXRs ZSIgYWxpZ249ImxlZnQiIGRpcj0ibHRyIiBjb2xvcj0iMDAwMDAwIiBzaXplPSI4Ii8+PGZsZCB4 bWxucz0iIiBwcm9wPSJ0ZXh0MSIgYWxpZ249ImxlZnQiIGRpcj0ibHRyIiBjb2xvcj0iMDAwMDAw IiBzaXplPSI4Ii8+PGZsZCB4bWxucz0iIiBwcm9wPSJibGFuayIgc2l6ZT0iOCIvPjxmbGQgeG1s bnM9IiIgcHJvcD0ib3JnIiBhbGlnbj0ibGVmdCIgZGlyPSJsdHIiIHN0eWxlPSJiIiBjb2xvcj0i MDAwMDAwIiBzaXplPSI4Ii8+PGZsZCB4bWxucz0iIiBwcm9wPSJhZGRyd29yayIgYWxpZ249Imxl ZnQiIGRpcj0ibHRyIiBjb2xvcj0iMDAwMDAwIiBzaXplPSI4Ii8+PGZsZCB4bWxucz0iIiBwcm9w PSJ0ZWx3b3JrIiBhbGlnbj0ibGVmdCIgZGlyPSJsdHIiIGNvbG9yPSIwMDAwMDAiIHNpemU9Ijgi PjxsYWJlbCBhbGlnbj0ibGVmdCIgY29sb3I9IjAwMDAwMCI+T2ZmaWNlPC9sYWJlbD48L2ZsZD48 ZmxkIHhtbG5zPSIiIHByb3A9InRlbGNlbGwiIGFsaWduPSJsZWZ0IiBkaXI9Imx0ciIgY29sb3I9 IjAwMDAwMCIgc2l6ZT0iOCI+PGxhYmVsIGFsaWduPSJsZWZ0IiBjb2xvcj0iMDAwMDAwIj5Nb2Jp bGU8L2xhYmVsPjwvZmxkPjxmbGQgeG1sbnM9IiIgcHJvcD0iZW1haWwiIGFsaWduPSJsZWZ0IiBk aXI9Imx0ciIgY29sb3I9IjAwMDAwMCIgc2l6ZT0iOCIvPjxmbGQgeG1sbnM9IiIgcHJvcD0iYmxh bmsiIHNpemU9IjgiLz48ZmxkIHhtbG5zPSIiIHByb3A9ImJsYW5rIiBzaXplPSI4Ii8+PGZsZCB4 bWxucz0iIiBwcm9wPSJibGFuayIgc2l6ZT0iOCIvPjxmbGQgeG1sbnM9IiIgcHJvcD0iYmxhbmsi IHNpemU9IjgiLz48ZmxkIHhtbG5zPSIiIHByb3A9ImJsYW5rIiBzaXplPSI4Ii8+PGZsZCB4bWxu cz0iIiBwcm9wPSJibGFuayIgc2l6ZT0iOCIvPjxmbGQgeG1sbnM9IiIgcHJvcD0iYmxhbmsiIHNp emU9IjgiLz48L2NhcmQ+DQpSRVY6MjAxMTA0MTRUMTQwNzIzWg0KRU5EOlZDQVJEDQo= --_002_8584590C8D7DD141AA96D01920FC6C698C8989C5gbplmail03genba_-- From randell-ietf@jesup.org Mon Sep 19 08: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 C844721F8C39 for ; Mon, 19 Sep 2011 08:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fkFbEoIjT33 for ; Mon, 19 Sep 2011 08:00:09 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id D273521F8C2B for ; Mon, 19 Sep 2011 08:00:09 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5fMe-0006F2-SN for rtcweb@ietf.org; Mon, 19 Sep 2011 10:02:32 -0500 Message-ID: <4E7758BF.7030709@jesup.org> Date: Mon, 19 Sep 2011 10:59:11 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@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] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 15:00:10 -0000 On 9/19/2011 10:24 AM, Eric Rescorla wrote: > On Mon, Sep 19, 2011 at 6:53 AM, Randell Jesup wrote: >> On 9/19/2011 6:23 AM, Hadriel Kaplan wrote: >>> On Sep 19, 2011, at 2:26 AM, Randell Jesup wrote: >>> >>>> The point was made repeatedly when I explained this primary area of >>>> contention that we want it to be easy to use by the "little guys", and that >>>> even if signalling was a downloaded JS library, you'd end up with a wild >>>> mixture of old versions in use, which may complicate interop/federation >>>> (plus the overhead to pull them down, and some possible security issues). >>> And you think having it in the Browsers won't end up with a wild mixture >>> of old versions in use, and complicated interop/federation? >> Not compared to the complexity if it's all "roll-your-own". No one >> suggested that >> people be locked into a signalling protocol, and JS libraries are an option. >> We do >> have a lot of experience with pseudo-standard APIs implemented in JS, such >> as jquery >> and many others, and these aren't unrealistic concerns. > Randell, > > Does auto-updating change the landscape in terms of the browser > version distribution? Absolutely. > > Mozilla have measurements on what fraction of the modern (i.e. post FF4) > browser base is running the latest version of Firefox? I know there are better figures out there (but I'm not sure if they're public, and I'm just working off these). http://www.w3schools.com/browsers/browsers_firefox.asp Note that FF6 was released during the middle of August, so 9.5% FF6, 15.9% FF5 (2.9% FF4) is actually pretty good. May->July went from 23.4% FF4, 0.3% FF5 (betas probably) to 4.6% FF4, 23.2% FF5 (0.6% FF6 betas). Those are out of all browsers, not just firefox, so the totals for firefox are around 40-42%. FF3.6 users are around 10% (roughly 1/4 of FF users) and slowly declining. There are issues there with large managed deployments; I won't re-open that can of worms here beyond saying we're working with such users to find ways to get them the ability to move forward. Chrome by all accounts has a higher uptake of new versions; largely from the silent background update behavior and partly from not having (or having less) locked-down enterprise deployments the way IE and Firefox do. We're looking into ways to make updating easier, more automatic and less painful for users without violating the principle of user control. (Again, a topic for another forum.) -- Randell Jesup randell-ietf@jesup.org From saul@ag-projects.com Mon Sep 19 08:04: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 B17D321F8C2F for ; Mon, 19 Sep 2011 08:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJsZaj3GuhYw for ; Mon, 19 Sep 2011 08:04:03 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB4121F8C2B for ; Mon, 19 Sep 2011 08:04:03 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 8BCA9B01B5; Mon, 19 Sep 2011 17:06:25 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id E6821B019A; Mon, 19 Sep 2011 17:06:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <4E774F92.4040405@jesup.org> Date: Mon, 19 Sep 2011 17:06:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 15:04:03 -0000 Hi, >=20 >> That would require a signaling central point (think about >> NAT), does it mean that web sites should provide a like-"SIP proxy" >> within their infraestructure? (think about web sites hosted in shared >> datacenter by an Apache or other web server not behind the control of >> the web developer). >=20 > It would require a SIP proxy only if the app developer decides to use = the SIP > module. >=20 I might be missing something, but how would Alice communicate with Bob = if both are behind NAT and there is no server involved? Asking some IP = and port out of band? I'm not aware of any Bonjour-style protocol for = the Internet, is there something similar which could be leveraged? I see no clean way for 2 browsers to communicate without a server = involved, and since it's not feasible to mandate that every browser = manufacturer deploys one, I'd rather not have any simplified or default = protocol. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From dwing@cisco.com Mon Sep 19 08:07: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 29BEE21F8BE8 for ; Mon, 19 Sep 2011 08:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.152 X-Spam-Level: X-Spam-Status: No, score=-103.152 tagged_above=-999 required=5 tests=[AWL=-0.553, 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 TpdT2hYdTl9I for ; Mon, 19 Sep 2011 08:07:17 -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 A0A3521F8BF7 for ; Mon, 19 Sep 2011 08:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3002; q=dns/txt; s=iport; t=1316444981; x=1317654581; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=377aEAnClwJ10xUIwBwDskF4D0LltT9N4QXL+QOMFVI=; b=LLXxCrJWA4BStyewAvbZPVJzjIAr3ZT35WTL4zs+msEOXPiJA+uVEW0k SCkH5IxucBXn4n4kfqtMYy5SaJkb0+XCGbxCQz0Q6kjCmYV0HSTDQ03Xo U7eWhOG+4oQLBEFb3mbS/ddVWvgRtMl24TBPkfrJIfowdoaR1oVEuywrV E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcAADxad06rRDoI/2dsb2JhbABCmEKBbIx7d4FTAQEBAQMICgEXED8MAQMCGAIEAQEBJwcZIwoJCAEBBAESCxefBwGdZ4Z4BIdvnSc X-IronPort-AV: E=Sophos;i="4.68,405,1312156800"; d="scan'208";a="2969599" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 19 Sep 2011 15:09:41 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8JF9eX2010327; Mon, 19 Sep 2011 15:09:40 GMT From: "Dan Wing" To: "'Harald Alvestrand'" , "'Eric Rescorla'" References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> In-Reply-To: <4E765E4A.3050801@alvestrand.no> Date: Mon, 19 Sep 2011 08:09:41 -0700 Message-ID: <0ced01cc76de$28731630$79594290$@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: Acx2R2qXVdoY0v75RAi4W657Pzj1QQAldyUA Content-Language: en-us Cc: rtcweb@ietf.org Subject: [rtcweb] consent freshness [was RE: STUN for keep-alive] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 15:07:20 -0000 > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Sunday, September 18, 2011 2:11 PM > To: Eric Rescorla > Cc: Dan Wing; rtcweb@ietf.org > Subject: Re: [rtcweb] STUN for keep-alive > > On 09/16/2011 08:30 PM, Eric Rescorla wrote: > > On Fri, Sep 16, 2011 at 11:07 AM, Dan Wing wrote: > >>> -----Original Message----- > >>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > >>> Behalf Of Eric Rescorla > >>> Sent: Wednesday, September 14, 2011 10:32 AM > >>> To: Christer Holmberg > >>> Cc: rtcweb@ietf.org > >>> Subject: Re: [rtcweb] STUN for keep-alive > >>> > >>> On Wed, Sep 14, 2011 at 10:20 AM, Christer Holmberg > >>> wrote: > >>>> Hi, > >>>> > >>>>> One new concern in this context is maintaining the consent > freshness. > >>>>> The browser needs to be sure that the recipient of traffic is > stil > >>> responding in a way that can't be forged. It's likely RTCP provides > >>> this (though we'd need to analyze to be sure) but perhaps better > would > >>> be to mandate STUN checks > >>>>> at enough frequency that you get some sort of level of > freshness.... > >>> maybe every 2 minutes or something. > >>>> Please note that the STUN keep-alives are implemented using STUN > >>> indication messages, so there are no replies (nor does the receiver > >>> perform an authentication check). > >>> > >>> > >>> Oh... I had forgotten that.... that's not good. > >> The RTCP receiver reports should be adequate for 'consent > freshness', no? > >> If I still like receiving the traffic, I'll report that I'm > receiving it. > >> If I have crashed or disconnected or am not listening on that port, > I won't. > > I believe so, though I'd have to make sure there's enough entropy. > And of course > > some implementations may not do RTCP... > Depending on RTCP seems less uncomfortable with SRTP than with > plaintext > RTCP. > I don't think we want to support RTCP-less applicaitons; if saying "no" > to them helps them not occur (it doesn't always help...) (Case in point: RTCP has long been a requirement for RTP, but implementation was still skipped by Cisco, and probably others.) I don't know how much entropy Eric was looking for. RTCP receiver reports only echo back the SSRC, which is 32 bits and is going to be static for the duration of each RTP session (yes, SSRC collision could make it change. But that is atypical.) STUN request/response echoes back the 96-bit transaction id, which changes as often as the requestor likes (typically each new STUN transaction). Which would someone skip -- skip sending/implementing RTCP for consent freshness, or skip sending/implementing STUN request/response for consent freshness? The STUN request/response is also additional data, whereas RTCP is something that is "already being sent" (thus the consent freshness isn't adding more bits on the wire). -d From magnus.westerlund@ericsson.com Mon Sep 19 08:33: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 2645C21F8BF4 for ; Mon, 19 Sep 2011 08:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.51 X-Spam-Level: X-Spam-Status: No, score=-106.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 vk9liwe9coax for ; Mon, 19 Sep 2011 08:33:03 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C0DD921F8B8C for ; Mon, 19 Sep 2011 08:33:02 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-a0-4e77613c45ed Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DF.24.02839.C31677E4; Mon, 19 Sep 2011 17:35:24 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Mon, 19 Sep 2011 17:35:24 +0200 Message-ID: <4E77613B.4020805@ericsson.com> Date: Mon, 19 Sep 2011 17:35:23 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Dan Wing References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <0ced01cc76de$28731630$79594290$@com> In-Reply-To: <0ced01cc76de$28731630$79594290$@com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 15:33:04 -0000 On 2011-09-19 17:09, Dan Wing wrote: >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: Sunday, September 18, 2011 2:11 PM >> To: Eric Rescorla >> Cc: Dan Wing; rtcweb@ietf.org >> Subject: Re: [rtcweb] STUN for keep-alive >> >> On 09/16/2011 08:30 PM, Eric Rescorla wrote: >>> On Fri, Sep 16, 2011 at 11:07 AM, Dan Wing wrote: >>>>> -----Original Message----- >>>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On >>>>> Behalf Of Eric Rescorla >>>>> Sent: Wednesday, September 14, 2011 10:32 AM >>>>> To: Christer Holmberg >>>>> Cc: rtcweb@ietf.org >>>>> Subject: Re: [rtcweb] STUN for keep-alive >>>>> >>>>> On Wed, Sep 14, 2011 at 10:20 AM, Christer Holmberg >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>>> One new concern in this context is maintaining the consent >> freshness. >>>>>>> The browser needs to be sure that the recipient of traffic is >> stil >>>>> responding in a way that can't be forged. It's likely RTCP provides >>>>> this (though we'd need to analyze to be sure) but perhaps better >> would >>>>> be to mandate STUN checks >>>>>>> at enough frequency that you get some sort of level of >> freshness.... >>>>> maybe every 2 minutes or something. >>>>>> Please note that the STUN keep-alives are implemented using STUN >>>>> indication messages, so there are no replies (nor does the receiver >>>>> perform an authentication check). >>>>> >>>>> >>>>> Oh... I had forgotten that.... that's not good. >>>> The RTCP receiver reports should be adequate for 'consent >> freshness', no? >>>> If I still like receiving the traffic, I'll report that I'm >> receiving it. >>>> If I have crashed or disconnected or am not listening on that port, >> I won't. >>> I believe so, though I'd have to make sure there's enough entropy. >> And of course >>> some implementations may not do RTCP... >> Depending on RTCP seems less uncomfortable with SRTP than with >> plaintext >> RTCP. >> I don't think we want to support RTCP-less applicaitons; if saying "no" >> to them helps them not occur (it doesn't always help...) > > (Case in point: RTCP has long been a requirement for RTP, but > implementation was still skipped by Cisco, and probably others.) > > I don't know how much entropy Eric was looking for. RTCP receiver > reports only echo back the SSRC, which is 32 bits and is going to > be static for the duration of each RTP session (yes, SSRC collision > could make it change. But that is atypical.) STUN request/response > echoes back the 96-bit transaction id, which changes as often as the > requestor likes (typically each new STUN transaction). As I wrote in http://www.ietf.org/mail-archive/web/rtcweb/current/msg01327.html The amount of entropy in an RTCP message may be as low as 8 bits. If certain restrictions is accepted then we can probably reach 20-24 bits without requiring more than basic RTCP provides. > > Which would someone skip -- skip sending/implementing RTCP for > consent freshness, or skip sending/implementing STUN request/response > for consent freshness? The STUN request/response is also additional > data, whereas RTCP is something that is "already being sent" (thus > the consent freshness isn't adding more bits on the wire). I think RTCP may work for consent freshness. A longer series of consistent RTCP messages to maintain the consent seems reasonable, despite the low number of entropy bits per actual message. But, I do think RTCP might have to few bits for the initial check where one wants a rapid indication that it is fine to send media at higher bit-rates. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Sep 19 08:44: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 356CF21F8C71 for ; Mon, 19 Sep 2011 08:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 euK0EiZndcaF for ; Mon, 19 Sep 2011 08:44:33 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 099D621F8C6A for ; Mon, 19 Sep 2011 08:44:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-20-4e7763ef493a Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DD.95.02839.FE3677E4; Mon, 19 Sep 2011 17:46:55 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Mon, 19 Sep 2011 17:46:55 +0200 Message-ID: <4E7763EE.3050307@ericsson.com> Date: Mon, 19 Sep 2011 17:46:54 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E71927C.1090606@skype.net> <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com> <20110915140248.4cc17977@lminiero-acer> <4E71F90D.8030302@alvestrand.no> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [rtcweb] SDP offer/answer vs. JSON X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 15:44:34 -0000 Hardiel, As we all low to discuss and nitpick each other arguments I do have a comment on some of your points. On 2011-09-16 20:29, Hadriel Kaplan wrote: > > But email's free... so for the sake of posterity (and email > archiving) here're some reasons not to use SDP anyway: > 1) Incorporating SDP and the offer/answer model into the Browser and > W3C API inexorably ties the W3C to the IETF MMUSIC working group for > all time. So far, I had been going on the assumption the IETF would > be defining what the RTP library had to do/expose, while W3C would > define the API. But if the API includes SDP offer/answer, that > portion is the IETF's domain too, afaik. Anything the W3C wants to do > in the future for that has to go through the IETF, not just IANA. > (right?) Depends on what parts of SDP you want to extend. And in fact most things can be done with not having to write an RFC. SDP attributes (a=) has the registration policy of Specification Required which means W3C can do what they want themselves an then ask IANA for registration. The Proto needs an RFC, but it can be RFC-editor or Informational. However, as new proto is a new transport, I do expect some IETF involvement anyway to make sure it works with the existing ones. I guess these are the two most important. And I am not going to discuss all of them, especially as some extensions may more properly belong in other parts of IETF than MMUSIC. For the ones interested in IANA rules for SDP, go look at section 8 in RFC4566. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From dwing@cisco.com Mon Sep 19 08:57: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 0661C21F8C6D for ; Mon, 19 Sep 2011 08:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.143 X-Spam-Level: X-Spam-Status: No, score=-103.143 tagged_above=-999 required=5 tests=[AWL=-0.544, 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 l+Iq-cgsGVSM for ; Mon, 19 Sep 2011 08:57:15 -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 1A3D921F8C6A for ; Mon, 19 Sep 2011 08:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5777; q=dns/txt; s=iport; t=1316447978; x=1317657578; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=+yNHXKWrmTNHj/2dvhaLzdp4Uo2MHNN+FHKYWfpTvz0=; b=NGVmOhCfiMgJnNXQc5BuuQ1qd4dX9jsxuyZalCPnqcjrw8kaduhSLKav /9oxAsYOE15d7zukOS9MkYunjRJRUZ5XLSJDPMb/Dv9RlTBIAcLh/vazF aPf2qnkqEeVvuDHp7KGlSlvl5OZTqcpCGEDwQGAB9a/iTUNMHkHwZnNgq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcAAANmd06rRDoJ/2dsb2JhbABCmFGBbIx7d4FTAQEBAQIBCAQGARdPBQcBAQICCQ8CBAEBAScHGQIhCgkIAQEEEwkCF4dVBJccAZ1rAoZ2BIc/MJ0n X-IronPort-AV: E=Sophos;i="4.68,406,1312156800"; d="scan'208";a="2979267" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 19 Sep 2011 15:59:38 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8JFxcCN029303; Mon, 19 Sep 2011 15:59:38 GMT From: "Dan Wing" To: "'Magnus Westerlund'" References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <0ced01cc76de$28731630$79594290$@com> <4E77613B.4020805@ericsson.com> In-Reply-To: <4E77613B.4020805@ericsson.com> Date: Mon, 19 Sep 2011 08:59:39 -0700 Message-ID: <0d4101cc76e5$2333d6d0$699b8470$@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: Acx24cFSMXH/w5cJTmCfz+4yvHkOgwAAnl0Q Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 15:57:16 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, September 19, 2011 8:35 AM > To: Dan Wing > Cc: 'Harald Alvestrand'; 'Eric Rescorla'; rtcweb@ietf.org > Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive] >=20 > On 2011-09-19 17:09, Dan Wing wrote: > >> -----Original Message----- > >> From: Harald Alvestrand [mailto:harald@alvestrand.no] > >> Sent: Sunday, September 18, 2011 2:11 PM > >> To: Eric Rescorla > >> Cc: Dan Wing; rtcweb@ietf.org > >> Subject: Re: [rtcweb] STUN for keep-alive > >> > >> On 09/16/2011 08:30 PM, Eric Rescorla wrote: > >>> On Fri, Sep 16, 2011 at 11:07 AM, Dan Wing = wrote: > >>>>> -----Original Message----- > >>>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] = On > >>>>> Behalf Of Eric Rescorla > >>>>> Sent: Wednesday, September 14, 2011 10:32 AM > >>>>> To: Christer Holmberg > >>>>> Cc: rtcweb@ietf.org > >>>>> Subject: Re: [rtcweb] STUN for keep-alive > >>>>> > >>>>> On Wed, Sep 14, 2011 at 10:20 AM, Christer Holmberg > >>>>> wrote: > >>>>>> Hi, > >>>>>> > >>>>>>> One new concern in this context is maintaining the consent > >> freshness. > >>>>>>> The browser needs to be sure that the recipient of traffic is > >> stil > >>>>> responding in a way that can't be forged. It's likely RTCP > provides > >>>>> this (though we'd need to analyze to be sure) but perhaps better > >> would > >>>>> be to mandate STUN checks > >>>>>>> at enough frequency that you get some sort of level of > >> freshness.... > >>>>> maybe every 2 minutes or something. > >>>>>> Please note that the STUN keep-alives are implemented using = STUN > >>>>> indication messages, so there are no replies (nor does the > receiver > >>>>> perform an authentication check). > >>>>> > >>>>> > >>>>> Oh... I had forgotten that.... that's not good. > >>>> The RTCP receiver reports should be adequate for 'consent > >> freshness', no? > >>>> If I still like receiving the traffic, I'll report that I'm > >> receiving it. > >>>> If I have crashed or disconnected or am not listening on that > port, > >> I won't. > >>> I believe so, though I'd have to make sure there's enough entropy. > >> And of course > >>> some implementations may not do RTCP... > >> Depending on RTCP seems less uncomfortable with SRTP than with > >> plaintext > >> RTCP. > >> I don't think we want to support RTCP-less applicaitons; if saying > "no" > >> to them helps them not occur (it doesn't always help...) > > > > (Case in point: RTCP has long been a requirement for RTP, but > > implementation was still skipped by Cisco, and probably others.) > > > > I don't know how much entropy Eric was looking for. RTCP receiver > > reports only echo back the SSRC, which is 32 bits and is going to > > be static for the duration of each RTP session (yes, SSRC collision > > could make it change. But that is atypical.) STUN request/response > > echoes back the 96-bit transaction id, which changes as often as the > > requestor likes (typically each new STUN transaction). >=20 > As I wrote in > http://www.ietf.org/mail-archive/web/rtcweb/current/msg01327.html Thanks for that pointer. In that post, you wrote: "So one case of attack is the one when the webserver S uses=20 the connected clients to attack target T by instructing client=20 C to send to target T.=20 ..." That attack is what Jonathan called the 'voice hammer' attack. =20 ICE solves that attack very well,=20 http://tools.ietf.org/html/rfc5245#section-18.5.1 -- is more needed for that attack? When Eric mentioned 'consent freshness', it was the first time I=20 had seen him use that term. (No, I didn't search the archives.) My interpretation 'consent freshness' is that, after a call had been up and running the RTP receiver might die or disconnect from the network, and a new host or restarted application might take over that IP address and possibly also start listening on that same UDP port. By 'consent freshness', he wants a valid listener to occasionally say "yes, I still like receiving this flow"=20 and he wants other listeners to not send that message -- causing the sender to eventually give up. > The amount of entropy in an RTCP message may be as low as 8 bits. If > certain restrictions is accepted then we can probably reach 20-24 bits > without requiring more than basic RTCP provides. >=20 > > > > Which would someone skip -- skip sending/implementing RTCP for > > consent freshness, or skip sending/implementing STUN = request/response > > for consent freshness? The STUN request/response is also additional > > data, whereas RTCP is something that is "already being sent" (thus > > the consent freshness isn't adding more bits on the wire). >=20 > I think RTCP may work for consent freshness. A longer series of > consistent RTCP messages to maintain the consent seems reasonable, > despite the low number of entropy bits per actual message. But, I do > think RTCP might have to few bits for the initial check where one = wants > a rapid indication that it is fine to send media at higher bit-rates. -d > 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 > ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Sep 19 08:58: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 EE70821F8C85 for ; Mon, 19 Sep 2011 08:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.512 X-Spam-Level: X-Spam-Status: No, score=-106.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 7Cg-Fozd7Cbv for ; Mon, 19 Sep 2011 08:58:35 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFC821F8C81 for ; Mon, 19 Sep 2011 08:58:35 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-28-4e776739cdac Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D0.57.02839.937677E4; Mon, 19 Sep 2011 18:00:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 19 Sep 2011 18:00:58 +0200 Message-ID: <4E776739.4010609@ericsson.com> Date: Mon, 19 Sep 2011 18:00:57 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> In-Reply-To: <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 15:58:36 -0000 On 2011-09-17 19:27, Hadriel Kaplan wrote: > > On Sep 17, 2011, at 4:27 AM, Olle E. Johansson wrote: > >> They will be able to use the rtcweb data channel, which is a >> concern. > > Yes, that's actually the most interesting piece of this whole thing, > in my opinion. Browsers don't typically offer raw sockets to > javascript as far as I know. And not only does it raise a lovely set > of security concerns, but also network collapse issues since UDP has > no congestion backoff and I believe the data channel we're talking > about is UDP(?). Well, it is something over UDP. We clearly need UDP for NAT traversal considerations. However, we also clearly need congestion control implemented in the browser, not in the JS to prevent two targets to unfairly saturate the path between the peers. > > And since the data channel is actually peer-to-peer rather than > client-to-server, the issues with not standardizing its protocol > become harder. I.e., leaving it a raw socket will only work if it > goes between the same javascripts, inside the same domain - if that's > ok, then the only issue is this would be put into SDP, and SDP isn't > constrained by a javascript domain. Hmm... gosh, if only rtcweb > didn't use SDP as its browser API... :) We need to standardize a number of Transport protocol functionalities for the RTCWEB data transport solution. To the degree that I do like to resurface some of my earlier suggestions around this. Why not use DCCP with TFRC or TCP like congestion control tunneled over UDP. The whole specification is ready. Which avoids any hiccup with the transport people and IESG. We can run either IP/UDP/DCCP/DTLS or specify the reverse if we want to protect also DCCP headers by defining IP/UDP/DTLS/DCCP. The main argument has been against implementation readiness of this solution. I would note that any homegrown solution will also not be implemented and available. And there do exist some stack implementations. And when it comes to complexity, one will realize that most functions are in fact needed anyway. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ekr@rtfm.com Mon Sep 19 09:15: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 B533E21F8CBE for ; Mon, 19 Sep 2011 09:15:15 -0700 (PDT) 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.076, 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 2HhoPqpUno9d for ; Mon, 19 Sep 2011 09:15:15 -0700 (PDT) Received: from mail-wy0-f170.google.com (mail-wy0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id EF4C621F8CBD for ; Mon, 19 Sep 2011 09:15:14 -0700 (PDT) Received: by wyg8 with SMTP id 8so6591982wyg.15 for ; Mon, 19 Sep 2011 09:17:37 -0700 (PDT) Received: by 10.227.28.17 with SMTP id k17mr3065397wbc.3.1316448998062; Mon, 19 Sep 2011 09:16:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.55.82 with HTTP; Mon, 19 Sep 2011 09:16:18 -0700 (PDT) In-Reply-To: <0d4101cc76e5$2333d6d0$699b8470$@com> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <0ced01cc76de$28731630$79594290$@com> <4E77613B.4020805@ericsson.com> <0d4101cc76e5$2333d6d0$699b8470$@com> From: Eric Rescorla Date: Mon, 19 Sep 2011 09:16:18 -0700 Message-ID: To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 16:15:15 -0000 On Mon, Sep 19, 2011 at 8:59 AM, Dan Wing wrote: >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > When Eric mentioned 'consent freshness', it was the first time I > had seen him use that term. =A0(No, I didn't search the archives.) Yeah, I just made it up. Maybe not the best term.... > My interpretation 'consent freshness' is that, after a call had been > up and running the RTP receiver might die or disconnect from the > network, and a new host or restarted application might take over > that IP address and possibly also start listening on that same > UDP port. =A0By 'consent freshness', he wants a valid listener to > occasionally say "yes, I still like receiving this flow" > and he wants other listeners to not send that message -- causing > the sender to eventually give up. Yep. I'm certainly open to arguments that this isn't important... :) -Ekr From igor.faynberg@alcatel-lucent.com Mon Sep 19 09:36: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 186B021F8BE4 for ; Mon, 19 Sep 2011 09:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 2H6LZngQ3+Hq for ; Mon, 19 Sep 2011 09:36:13 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 10C1921F8BDC for ; Mon, 19 Sep 2011 09:36:12 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p8JGcXYH022756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 19 Sep 2011 11:38:33 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8JGcWH1023968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Sep 2011 11:38:33 -0500 Received: from [135.222.134.166] (USMUYN0L055118.mh.lucent.com [135.222.134.166]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p8JGcWQ0028944; Mon, 19 Sep 2011 11:38:32 -0500 (CDT) Message-ID: <4E777008.6090100@alcatel-lucent.com> Date: Mon, 19 Sep 2011 12:38:32 -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: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> In-Reply-To: <4E77495E.4000409@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 16:36:14 -0000 I am 100% with Randell. (Incidentally, my idea of "minimal SIP" has been that the browser keeps the SIP state machine while receiving and sending SIP messages, with parsing left to application: the outbound parameters are supplied--and the inbound ones interpreted--by the JS application. In this way, pretty much all versions of SIP can be accomodated, while none of them has to be supported by the browser.) On a different topic, I am confused by the very name of this thread, as well as the "was" thread that it replaced. I thought that RTCWeb was about "packaging" the existing protocols, not inventing new ones... Igor On 9/19/2011 9:53 AM, Randell Jesup wrote: > ... > I lean towards a proposal I made a week or two ago; to allow full > access (which allows > user-written JS signalling libraries) but provide minimal SIP+O/A as > an option within > the browser. This could be a JS library, but the primary users of > this would be the > "little guys" who just want simple setup of media streams, and they're > most likely to > never update, while browsers are updated frequently. > > ... > That's entirely available to the application; they can use their own > if they wish. > And while I suggest a simple SIP set be included, if we were certain a > "standard" JS > lib were freely available and solid enough, that would make the > argument stronger for > a JS lib. > > .... From oej@edvina.net Mon Sep 19 09:38: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 A1D8A21F8C10 for ; Mon, 19 Sep 2011 09:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.008, 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 em8G3qdpYu+4 for ; Mon, 19 Sep 2011 09:38:33 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 08A8421F8BDC for ; Mon, 19 Sep 2011 09:38:33 -0700 (PDT) Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id A27E7754BCE5; Mon, 19 Sep 2011 16:40:53 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <4E776739.4010609@ericsson.com> Date: Mon, 19 Sep 2011 18:40:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1244.3) Cc: "" Subject: Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 16:38:33 -0000 19 sep 2011 kl. 18:00 skrev Magnus Westerlund: > On 2011-09-17 19:27, Hadriel Kaplan wrote: >>=20 >> On Sep 17, 2011, at 4:27 AM, Olle E. Johansson wrote: >>=20 >>> They will be able to use the rtcweb data channel, which is a >>> concern. >>=20 >> Yes, that's actually the most interesting piece of this whole thing, >> in my opinion. Browsers don't typically offer raw sockets to >> javascript as far as I know. And not only does it raise a lovely set >> of security concerns, but also network collapse issues since UDP has >> no congestion backoff and I believe the data channel we're talking >> about is UDP(?). >=20 > Well, it is something over UDP. We clearly need UDP for NAT traversal > considerations. However, we also clearly need congestion control > implemented in the browser, not in the JS to prevent two targets to > unfairly saturate the path between the peers. >=20 >>=20 >> And since the data channel is actually peer-to-peer rather than >> client-to-server, the issues with not standardizing its protocol >> become harder. I.e., leaving it a raw socket will only work if it >> goes between the same javascripts, inside the same domain - if that's >> ok, then the only issue is this would be put into SDP, and SDP isn't >> constrained by a javascript domain. Hmm... gosh, if only rtcweb >> didn't use SDP as its browser API... :) >=20 > We need to standardize a number of Transport protocol functionalities > for the RTCWEB data transport solution. To the degree that I do like = to > resurface some of my earlier suggestions around this. Why not use DCCP > with TFRC or TCP like congestion control tunneled over UDP. >=20 > The whole specification is ready. Which avoids any hiccup with the > transport people and IESG. >=20 > We can run either IP/UDP/DCCP/DTLS or specify the reverse if we want = to > protect also DCCP headers by defining IP/UDP/DTLS/DCCP. >=20 > The main argument has been against implementation readiness of this > solution. I would note that any homegrown solution will also not be > implemented and available. And there do exist some stack = implementations. >=20 > And when it comes to complexity, one will realize that most functions > are in fact needed anyway. Just to throw in another abbreviation: MSRP Isn't MSRP developed for this kind of sessions between users? Is there = something in the protocol design that stops it from being p2p? With MSRP, there's development experience as well as NAT traversal = solutions. /O= From mperumal@cisco.com Mon Sep 19 09:39: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 5572F21F8C12 for ; Mon, 19 Sep 2011 09:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.493 X-Spam-Level: X-Spam-Status: No, score=-10.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVxCp9ztaAkS for ; Mon, 19 Sep 2011 09:39:28 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BAB5921F8BDC for ; Mon, 19 Sep 2011 09:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=6733; q=dns/txt; s=iport; t=1316450511; x=1317660111; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6yfw/evJXg3dlF6Vyb6KUKsdIZ8Vm09NCu1S+5qJomc=; b=nHjsr95LjtCh8JZmZ+6j8SrEjUMQRL8hZbzThJMyojKNMOPsoZnj2VZE hPDZgEgUvOgGND0YBjkiRMNtVJGDPb7btlDT4phT4Iu4m+DlGYSnQijfC tJFWe7P0Ofaj7K18P7ovEkhdD3lqLZg3RvyYR9AD60XPtUgMjwbx/Q/Z9 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcAAF9wd05Io8UQ/2dsb2JhbABCmFGOZ3eBUwEBAQEDAQEBCQYBHT4LDAICAgEIEQQBAQsGFwEGARoMHwkIAQEEAQoICAEZh1mXEQGdcwKGFmAEhz8ukQKMDw X-IronPort-AV: E=Sophos;i="4.68,406,1312156800"; d="scan'208";a="55181392" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 19 Sep 2011 16:41:49 +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 p8JGfIVl028946; Mon, 19 Sep 2011 16:41:48 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); Mon, 19 Sep 2011 22:11:47 +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: Mon, 19 Sep 2011 22:11:45 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202066497EF@XMB-BGL-414.cisco.com> In-Reply-To: <4E77613B.4020805@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] consent freshness [was RE: STUN for keep-alive] Thread-Index: Acx24cVBAkoYrwjBRWKmAVnEVQm9mQAA1mrA References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se><4E70D2E6.1000809@alvestrand.no><7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se><092401cc749b$8fd64940$af82dbc0$@com><4E765E4A.3050801@alvestrand.no><0ced01cc76de$28731630$79594290$@com> <4E77613B.4020805@ericsson.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Magnus Westerlund" , "Dan Wing (dwing)" X-OriginalArrivalTime: 19 Sep 2011 16:41:47.0557 (UTC) FILETIME=[05EAD550:01CC76EB] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 16:39:29 -0000 Another aspect to consider: As per RFC 3550, the bare minimal valid RTCP packet is a compound RTCP = packet containing: - An RR packet with the reception report count set to 0 (RC=3D0) and - An SDES packet with CNAME Such a packet would look like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ header |V=3D2|P| RC=3D0 | PT=3DRR=3D201 | length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | = +=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+ header |V=3D2|P| SC=3D1 | PT=3DSDES=3D202 | length = | = +=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+ chunk | SSRC of packet sender | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CNAME=3D1 | length |user & domain padded to 32-bit = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I've seen endpoints sending/accepting such a packet as an indication for = session liveliness. However, there is no entropy at all in this packet. = Suppose an attacker manages to bring the receiver down and captures such = a RTCP packet. The attacker can keep replaying it (from the spoofed = source transport address) to make the sender believe that the receiver = is still alive and muted. Perhaps, RTCWeb apps should try to negotiate an RTCP extension carrying = a monotonically increasing number that must be part of every RTCP report = together with SRTCP, for replay attack protection.=20 Muthu |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On = Behalf Of Magnus Westerlund |Sent: Monday, September 19, 2011 9:05 PM |To: Dan Wing (dwing) |Cc: rtcweb@ietf.org |Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive] | |On 2011-09-19 17:09, Dan Wing wrote: |>> -----Original Message----- |>> From: Harald Alvestrand [mailto:harald@alvestrand.no] |>> Sent: Sunday, September 18, 2011 2:11 PM |>> To: Eric Rescorla |>> Cc: Dan Wing; rtcweb@ietf.org |>> Subject: Re: [rtcweb] STUN for keep-alive |>> |>> On 09/16/2011 08:30 PM, Eric Rescorla wrote: |>>> On Fri, Sep 16, 2011 at 11:07 AM, Dan Wing wrote: |>>>>> -----Original Message----- |>>>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On |>>>>> Behalf Of Eric Rescorla |>>>>> Sent: Wednesday, September 14, 2011 10:32 AM |>>>>> To: Christer Holmberg |>>>>> Cc: rtcweb@ietf.org |>>>>> Subject: Re: [rtcweb] STUN for keep-alive |>>>>> |>>>>> On Wed, Sep 14, 2011 at 10:20 AM, Christer Holmberg |>>>>> wrote: |>>>>>> Hi, |>>>>>> |>>>>>>> One new concern in this context is maintaining the consent |>> freshness. |>>>>>>> The browser needs to be sure that the recipient of traffic is |>> stil |>>>>> responding in a way that can't be forged. It's likely RTCP = provides |>>>>> this (though we'd need to analyze to be sure) but perhaps better |>> would |>>>>> be to mandate STUN checks |>>>>>>> at enough frequency that you get some sort of level of |>> freshness.... |>>>>> maybe every 2 minutes or something. |>>>>>> Please note that the STUN keep-alives are implemented using STUN |>>>>> indication messages, so there are no replies (nor does the = receiver |>>>>> perform an authentication check). |>>>>> |>>>>> |>>>>> Oh... I had forgotten that.... that's not good. |>>>> The RTCP receiver reports should be adequate for 'consent |>> freshness', no? |>>>> If I still like receiving the traffic, I'll report that I'm |>> receiving it. |>>>> If I have crashed or disconnected or am not listening on that = port, |>> I won't. |>>> I believe so, though I'd have to make sure there's enough entropy. |>> And of course |>>> some implementations may not do RTCP... |>> Depending on RTCP seems less uncomfortable with SRTP than with |>> plaintext |>> RTCP. |>> I don't think we want to support RTCP-less applicaitons; if saying = "no" |>> to them helps them not occur (it doesn't always help...) |> |> (Case in point: RTCP has long been a requirement for RTP, but |> implementation was still skipped by Cisco, and probably others.) |> |> I don't know how much entropy Eric was looking for. RTCP receiver |> reports only echo back the SSRC, which is 32 bits and is going to |> be static for the duration of each RTP session (yes, SSRC collision |> could make it change. But that is atypical.) STUN request/response |> echoes back the 96-bit transaction id, which changes as often as the |> requestor likes (typically each new STUN transaction). | |As I wrote in |http://www.ietf.org/mail-archive/web/rtcweb/current/msg01327.html | |The amount of entropy in an RTCP message may be as low as 8 bits. If |certain restrictions is accepted then we can probably reach 20-24 bits |without requiring more than basic RTCP provides. | |> |> Which would someone skip -- skip sending/implementing RTCP for |> consent freshness, or skip sending/implementing STUN request/response |> for consent freshness? The STUN request/response is also additional |> data, whereas RTCP is something that is "already being sent" (thus |> the consent freshness isn't adding more bits on the wire). | |I think RTCP may work for consent freshness. A longer series of |consistent RTCP messages to maintain the consent seems reasonable, |despite the low number of entropy bits per actual message. But, I do |think RTCP might have to few bits for the initial check where one wants |a rapid indication that it is fine to send media at higher bit-rates. | |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 prvs=236d0731c=tterriberry@mozilla.com Mon Sep 19 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 7452521F8C6A for ; Mon, 19 Sep 2011 09:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDbbTC6qQr1a for ; Mon, 19 Sep 2011 09:53:44 -0700 (PDT) Received: from mxip0i.isis.unc.edu (mxip0i.isis.unc.edu [152.2.0.72]) by ietfa.amsl.com (Postfix) with ESMTP id D3F2F21F8C66 for ; Mon, 19 Sep 2011 09:53:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EALtzd06sGgRa/2dsb2JhbABCplWBWoFTAQEFOEABEAsYCRYECwkDAgECAUUTAQcCvGmGeASHb5BlEoww X-IronPort-AV: E=Sophos;i="4.67,553,1309752000"; d="scan'208";a="256250476" Received: from mr2a.isis.unc.edu (HELO smtp.unc.edu) ([172.26.4.90]) by mxip0o.isis.unc.edu with ESMTP; 19 Sep 2011 12:56:04 -0400 X-UNC-Auth-As: tterribe X-UNC-Auth-IP: 63.245.220.240 Received: from [10.250.5.61] (corp-240.mv.mozilla.com [63.245.220.240]) (authenticated bits=0) by smtp.unc.edu (8.14.4/8.14.3) with ESMTP id p8JGtng1009125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Sep 2011 12:56:04 -0400 (EDT) Message-ID: <4E777414.1040801@mozilla.com> Date: Mon, 19 Sep 2011 09:55:48 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.19) Gecko/20110604 Gentoo/2.0.14 SeaMonkey/2.0.14 MIME-Version: 1.0 CC: "rtcweb@ietf.org" References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 16:53:44 -0000 Olle E. Johansson wrote: > Isn't MSRP developed for this kind of sessions between users? Is there something in the protocol design that stops it from being p2p? Perhaps I'm confused, but doesn't MSRP rely on reliable, in-order delivery? From harald@alvestrand.no Mon Sep 19 09:57: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 72F6C21F8C51 for ; Mon, 19 Sep 2011 09:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.593 X-Spam-Level: X-Spam-Status: No, score=-107.593 tagged_above=-999 required=5 tests=[AWL=3.007, 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 NEk6DfjJCWI3 for ; Mon, 19 Sep 2011 09:57:23 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CEEFD21F8C50 for ; Mon, 19 Sep 2011 09:57:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A933D39E0CD for ; Mon, 19 Sep 2011 18:59:45 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jmvax5NoWmDm for ; Mon, 19 Sep 2011 18:59:44 +0200 (CEST) Received: from [192.168.0.2] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 5DED539E051 for ; Mon, 19 Sep 2011 18:59:44 +0200 (CEST) Message-ID: <4E777500.5030201@alvestrand.no> Date: Mon, 19 Sep 2011 18:59:44 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 16:57:23 -0000 I am looking at the WEBRTC API spec, which specifies a rudimentary negotiation framework: SDP objects prefixed by the string "SDP". It seems clear to me that this needs at least information about whether something is an offer or an answer, and some way to complete the transaction when an offer is sent and something prevents it from completing. Until we know we need more, what about the following, to be specified in the WEBRTC API? SDP objects are sent through the API, prefixed with either of SDP OFFER SDP ANSWER Alternatively, one can pass SDP ERROR to reply to an SDP OFFER when something goes wrong. If one gets an OFFER and sends out an ANSWER, state changes. If OFFER gets an ANSWER back, state changes. In all other cases, state is as before. We need to handle glare - when one sends an OFFER and gets back an OFFER, reply with SDP ERROR, enter a "glare" state, wait a bit, and send out an offer again. Do we really have to have anything else? From dzonatas@gmail.com Mon Sep 19 10:01: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 E480C21F8C80 for ; Mon, 19 Sep 2011 10:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.827 X-Spam-Level: X-Spam-Status: No, score=-3.827 tagged_above=-999 required=5 tests=[AWL=-0.228, 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 SxezP2GeyicJ for ; Mon, 19 Sep 2011 10:01:59 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6E87821F8C7B for ; Mon, 19 Sep 2011 10:01:59 -0700 (PDT) Received: by iaby26 with SMTP id y26so6986976iab.31 for ; Mon, 19 Sep 2011 10:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=LuqeMNFoaaabt+0Aou+XFYAkWbf0AXcCJB0/3lL05Kk=; b=uAJKUlV3rRs1Aq1cb+rThhnozhPoXwwlIL55wMj2F0YlUmCHcrWgNvtOR4QrLLssAP yo+/JJft6Wo9h0ZmuUpWCHBsornzj7rOeto8THQa8bCFHG82wfcAuH9gjUXepBimf3XD jKO0JYP3qdAFduADOx6m0bqgTsNtH2w2p0Ryc= Received: by 10.231.21.26 with SMTP id h26mr4511860ibb.40.1316451861648; Mon, 19 Sep 2011 10:04:21 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id v16sm26500750ibe.0.2011.09.19.10.04.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Sep 2011 10:04:20 -0700 (PDT) Message-ID: <4E777685.7040002@gmail.com> Date: Mon, 19 Sep 2011 10:06:13 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> In-Reply-To: <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 17:02:00 -0000 On 09/19/2011 03:23 AM, Hadriel Kaplan wrote: > On Sep 19, 2011, at 2:26 AM, Randell Jesup wrote: > > >> The point was made repeatedly when I explained this primary area of contention that we want it to be easy to use by the "little guys", and that even if signalling was a downloaded JS library, you'd end up with a wild mixture of old versions in use, which may complicate interop/federation (plus the overhead to pull them down, and some possible security issues). >> > > And you think having it in the Browsers won't end up with a wild mixture of old versions in use, and complicated interop/federation? > And on top of it you'll end up with a wild mixture of signaling vendors, because there'll be a mixture of Browser vendors and it's unlikely they'll all use the same source code inside. What's worse, it won't be controllable by the JS developer. At least with a JS library they're all using the same source code, and the JS developer knows what it was/did if it was an older version. > > With regard to the issue of overhead of pulling it down every time, I thought browsers cache JS scripts, no? > > -hadriel > They should cache the JIT resultant bytecode. -- --- The wheel. From pkyzivat@alum.mit.edu Mon Sep 19 10:20: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 1F7DB21F8CCE for ; Mon, 19 Sep 2011 10:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 70AVnJLmS2cU for ; Mon, 19 Sep 2011 10:20:40 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id B6D8121F8C88 for ; Mon, 19 Sep 2011 10:20:38 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta07.westchester.pa.mail.comcast.net with comcast id aaFe1h0030QuhwU57hP2QY; Mon, 19 Sep 2011 17:23:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta02.westchester.pa.mail.comcast.net with comcast id ahP01h00v0tdiYw3NhP1zE; Mon, 19 Sep 2011 17:23:02 +0000 Message-ID: <4E777A79.6040607@alum.mit.edu> Date: Mon, 19 Sep 2011 13:23:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E777500.5030201@alvestrand.no> In-Reply-To: <4E777500.5030201@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 17:20:41 -0000 Harald, I really appreciate your addressing the need to explicitly distinguish offers from answers - it is important. SIP did a really bad job of that. In SIP one just sends the SDP and the determination of whether it is an offer or answer is contextual. That was a bad decision. On 9/19/11 12:59 PM, Harald Alvestrand wrote: > I am looking at the WEBRTC API spec, which specifies a rudimentary > negotiation framework: SDP objects prefixed by the string "SDP". > > It seems clear to me that this needs at least information about whether > something is an offer or an answer, and some way to complete the > transaction when an offer is sent and something prevents it from > completing. > Until we know we need more, what about the following, to be specified in > the WEBRTC API? > > SDP objects are sent through the API, prefixed with either of > > SDP OFFER > SDP ANSWER > > Alternatively, one can pass > > SDP ERROR > > to reply to an SDP OFFER when something goes wrong. > > If one gets an OFFER and sends out an ANSWER, state changes. > If OFFER gets an ANSWER back, state changes. > In all other cases, state is as before. > > We need to handle glare - when one sends an OFFER and gets back an > OFFER, reply with SDP ERROR, enter a "glare" state, wait a bit, and send > out an offer again. > > Do we really have to have anything else? Since, afaik, this is async messaging, I think you should have something used to identify an offer and then to refer back to it when sending the answer, to ensure that a received answer was indeed an answer to the offer you thought it was. And that is part of the rtcweb-o/a protocol you are defining. It will also need some rules to prevent sending two offers without getting an answer first, or at least define what you do if that happens. (If one side sends an offer and fails to get an answer back, what should it do?) Thanks, Paul > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From randell-ietf@jesup.org Mon Sep 19 10:37: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 4848821F8C65 for ; Mon, 19 Sep 2011 10:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 9J0k02FIOiEj for ; Mon, 19 Sep 2011 10:37:37 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id CB30D21F8C64 for ; Mon, 19 Sep 2011 10:37:31 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5hox-0003Ax-2m for rtcweb@ietf.org; Mon, 19 Sep 2011 12:39:55 -0500 Message-ID: <4E777DA0.80201@jesup.org> Date: Mon, 19 Sep 2011 13:36:32 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E77543E.1040704@ericsson.com> In-Reply-To: <4E77543E.1040704@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] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 17:37:38 -0000 On 9/19/2011 10:39 AM, Magnus Westerlund wrote: > Hi, > > As an individual I like to provide some analyze of the entropy in > RTP/RTCP. Please consider, comment and provide opinion about the number > of bits. Thanks for the excellent analysis, Magnus. > On 2011-09-16 20:30, Eric Rescorla wrote: >>> The RTCP receiver reports should be adequate for 'consent freshness', no? >>> If I still like receiving the traffic, I'll report that I'm receiving it. >>> If I have crashed or disconnected or am not listening on that port, I won't. >> I believe so, though I'd have to make sure there's enough entropy. And of course >> some implementations may not do RTCP... >> > So one case of attack is the one when the webserver S uses the connected > clients to attack target T by instructing client C to send to target T. > So the Server or some server controlled entity A needs to send RTCP to C > that makes C believe T is responding, i.e. spoofed source address that > are T's plus the content of the RTCP RR. Please note that SRTP will not > provide any protection if the webserver knows the key. Thus if security > description is allowed, which appear reasonable if supporting legacy is > the goal, which is the reason for this whole proposal. I would disagree with one aspect of that: I don't know that we need to support SDES, and if we do, we only need to support it for "legacy" connections, not true webrtc browser-to-browser connections, which I assert should always be DTLS. Of course, non-encrypted RTP to a legacy device would have no protection against spoofing of return RTCP at all. Note that we need to complete a valid ICE exchange with the target per the current spec, so T can only be attacked to begin with if the ICE exchange can be spoofed. The original scenario from Eric was about "how do I determine if the recipient wants to *continue* to receive data after a valid exchange (for example after ending the call or rebooting/crashing). I haven't checked the properties of ICE and the ability to spoof it, but before analyzing the entropy required to attack the return RTCP 'freshness' state, we need to show that the attack could be begun, or state that ICE is not mandatory for some connections. As you mention, if we need extra entropy it might be possible to add it, but not if we are assuming that the other side is a legacy SDES device. -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Mon Sep 19 11: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 298A621F8C6C for ; Mon, 19 Sep 2011 11:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 9rBSRwhUmLYt for ; Mon, 19 Sep 2011 11:45:22 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A45E321F8C68 for ; Mon, 19 Sep 2011 11:45:22 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5isc-0001hA-96 for rtcweb@ietf.org; Mon, 19 Sep 2011 13:47:46 -0500 Message-ID: <4E778D87.3000402@jesup.org> Date: Mon, 19 Sep 2011 14:44:23 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <8584590C8D7DD141AA96D01920FC6C698C8989C5@gbplmail03.genband.com> In-Reply-To: <8584590C8D7DD141AA96D01920FC6C698C8989C5@gbplmail03.genband.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 default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 18:45:23 -0000 On 9/19/2011 10:52 AM, Jim McEachern wrote: > I lean towards a proposal I made a week or two ago; to allow full > access (which allows user-written JS signalling libraries) but provide > minimal SIP+O/A as an option within the browser. This could be a JS > library, but the primary users of this would be the "little guys" who > just want simple setup of media streams, and they're most likely to > never update, while browsers are updated frequently. > Are you suggesting that the "minimal SIP+O/A as an option within the browser" be baked into the browser, or simply provided as a standard JS library that would be made available to those who wanted to use it. It sounds like you are suggesting the later, but I want to be certain, since it could make a big difference. I am suggesting that it be baked into the browser, but optional to use. I am willing to consider alternatives that provide similar ability to the web author, such as external "standard" libraries, or intermediate forms like someone suggested such as the SIP state machine in the browser, but parsing in the JS (which would also require a "standard" external library, just smaller). -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Mon Sep 19 11:52: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 DB5CC21F8CD2 for ; Mon, 19 Sep 2011 11:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=1.054, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBwmUW7+XIrj for ; Mon, 19 Sep 2011 11:52:09 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 6170421F8CDE for ; Mon, 19 Sep 2011 11:52:09 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5izB-00049D-20 for rtcweb@ietf.org; Mon, 19 Sep 2011 13:54:33 -0500 Message-ID: <4E778F1F.9090105@jesup.org> Date: Mon, 19 Sep 2011 14:51:11 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> In-Reply-To: <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.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] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 18:52:10 -0000 On 9/19/2011 11:06 AM, Sal Ibarra Corretg wrote: >>> That would require a signaling central point (think about >>> NAT), does it mean that web sites should provide a like-"SIP proxy" >>> within their infraestructure? (think about web sites hosted in shared >>> datacenter by an Apache or other web server not behind the control of >>> the web developer). >> It would require a SIP proxy only if the app developer decides to use the SIP >> module. >> > I might be missing something, but how would Alice communicate with Bob if both are behind NAT and there is no server involved? Asking some IP and port out of band? I'm not aware of any Bonjour-style protocol for the Internet, is there something similar which could be leveraged? > > I see no clean way for 2 browsers to communicate without a server involved, and since it's not feasible to mandate that every browser manufacturer deploys one, I'd rather not have any simplified or default protocol. You misunderstood me; I meant "if you use an optional SIP module, you'll need to have a SIP proxy on your server". WebRTC in general presumes some sort of server architecture to solve the discovery/invitation problem. There *are* some possible uses of WebRTC that might not use a central server(s). The simplest would be the "phone-tag" server, where you and the person you want to talk to exchange IP addresses and external port numbers over the phone, and type them into the web app, which then opens a default-configured PeerConnection and re-negotiates to the actual configuration. -- Randell Jesup randell-ietf@jesup.org From harald@alvestrand.no Mon Sep 19 12:12: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 6C28A21F8D5E for ; Mon, 19 Sep 2011 12:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.968 X-Spam-Level: X-Spam-Status: No, score=-107.968 tagged_above=-999 required=5 tests=[AWL=2.631, 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 1RiYIThp5us4 for ; Mon, 19 Sep 2011 12:12:13 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A51E621F8D5D for ; Mon, 19 Sep 2011 12:12:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 133FC39E0BB; Mon, 19 Sep 2011 21:14:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIM7bw+bN1jH; Mon, 19 Sep 2011 21:14:35 +0200 (CEST) Received: from [192.168.0.2] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 7F5C139E051; Mon, 19 Sep 2011 21:14:35 +0200 (CEST) Message-ID: <4E77949B.4010603@alvestrand.no> Date: Mon, 19 Sep 2011 21:14:35 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Magnus Westerlund References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> In-Reply-To: <4E776739.4010609@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 19:12:14 -0000 On 09/19/2011 06:00 PM, Magnus Westerlund wrote: > We need to standardize a number of Transport protocol functionalities > for the RTCWEB data transport solution. To the degree that I do like to > resurface some of my earlier suggestions around this. Why not use DCCP > with TFRC or TCP like congestion control tunneled over UDP. > > The whole specification is ready. Which avoids any hiccup with the > transport people and IESG. The last few times this has surfaced, the conversation has turned suddenly silent when I've asked where to find a DCCP-over-TFRC stack I can experiment with.... are there any out there that are "production ready"? The pseudoTCP stacks in libjingle have seen service for a long time.... Harald From dwing@cisco.com Mon Sep 19 13:31: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 A93C821F8CFE for ; Mon, 19 Sep 2011 13:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.458 X-Spam-Level: X-Spam-Status: No, score=-103.458 tagged_above=-999 required=5 tests=[AWL=-0.859, 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 FhCyFUtzC80i for ; Mon, 19 Sep 2011 13:31:05 -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 E464A21F8CBD for ; Mon, 19 Sep 2011 13:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1675; q=dns/txt; s=iport; t=1316464410; x=1317674010; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=LGH7EFyqM/PaMmASF7d3g6iM7T0iYD+ucNt39Go1fJo=; b=b1EzxFRNqYA++Z/8aJcaHs10TrVAccHOtwNv1oe17FDHPPuxj8Cuez/b eueseNxvNwmMqT8uQOp1I081nLD62z2/OBOrhFpp7d0LnKCQBHX90DwKr lQs35V8D5BGdFQvGi5R9LuMQ90yxjuP44aY9PCFU6gwze0oGFApePa6fY M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAB+md06rRDoH/2dsb2JhbABCmkOMfHeBUwEBAQECAQgKARcQPwUIAwIJDgE3GSMbAgQBHReHVZcDAZ4rhngEh2+dJw X-IronPort-AV: E=Sophos;i="4.68,407,1312156800"; d="scan'208";a="3044481" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 19 Sep 2011 20:33:29 +0000 Received: from dwingWS ([128.107.105.231]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8JKXTCY007870; Mon, 19 Sep 2011 20:33:29 GMT From: "Dan Wing" To: "'Hadriel Kaplan'" , "'Olle E. Johansson'" References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <4E73BA23.6040305@skype.net> <0E6DD5C7-A59F-4C35-9412-780CB19F2DE1@acmepacket.com> In-Reply-To: <0E6DD5C7-A59F-4C35-9412-780CB19F2DE1@acmepacket.com> Date: Mon, 19 Sep 2011 13:33:29 -0700 Message-ID: <0e7701cc770b$6459bcd0$2d0d3670$@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: AQHMdV8HZnV0C/itdk+1WJWhe7py/pVVKrlg Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] ICE and security X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 20:31:06 -0000 ... > So basically we're stuck with requiring ICE be used for every > media/data session, and thus not being able to interop directly with > devices which don't do ICE (which is most of the SIP world right now). To work, they "just" need to do ICE-Lite. ICE-Lite is the ability to respond to ICE's media path STUN messages. ICE-Lite does not require a STUN server, does not require a TURN server, and does not require gathering IP addresses that everyone finds (oddly) difficult. Those that don't do ICE-Lite can be front-ended with an SBC that does ICE-Lite for them. > One open question is if javascript will even be allowed to open a media > channel to a peer without human/user consent. I'll bet a beer it'll happen without human consent, yes. > I thought we were > requiring per-site consent. I guess a malicious site could still offer > legitimate media usage, and thus get user's consent, and then sometime > in the future the same website could turn evil; or it could offer > seemingly legitimate service that works, while in javascript creating a > forked stream that is the one attacking someone else. > > I wonder though if even requiring ICE is sufficient. If I'm a > malicious javascript, I could add enough ICE candidates against a > target that it would be the same as an RTP stream in aggregate (I > believe ICE's throttling limit was in fact approximately the rate of > RTP by design, if I recall correctly). Yep, if you 0wn enough hosts, just their "can I send you a flood of media packets" requests could, itself, be a flood of traffic. Let's talk about DNSSEC responses being a source of attack. -d From saul@ag-projects.com Mon Sep 19 13:31: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 0E43121F84FD for ; Mon, 19 Sep 2011 13:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=1.037, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZsohNCQdmHh for ; Mon, 19 Sep 2011 13:31:37 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 68CFC21F84BD for ; Mon, 19 Sep 2011 13:31:37 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 84E92B019E; Mon, 19 Sep 2011 22:34:00 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id CEC9AB019C; Mon, 19 Sep 2011 22:33:47 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <4E778F1F.9090105@jesup.org> Date: Mon, 19 Sep 2011 22:33:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 20:31:38 -0000 Hi, > You misunderstood me; I meant "if you use an optional SIP module, = you'll > need to have a SIP proxy on your server". WebRTC in general presumes = some sort > of server architecture to solve the discovery/invitation problem. = There *are* > some possible uses of WebRTC that might not use a central server(s). = The simplest > would be the "phone-tag" server, where you and the person you want to = talk to > exchange IP addresses and external port numbers over the phone, and = type them into > the web app, which then opens a default-configured PeerConnection and = re-negotiates > to the actual configuration. >=20 Still, you need this "phone-tag" server, so who will provide it? I don't = see a way for 2 parties to communicate without help from outside the = browser, thus, I wouldn't define any sort of protocol, even if we could = simplify one. My 2 cents, -- Sa=FAl Ibarra Corretg=E9 AG Projects From randell-ietf@jesup.org Mon Sep 19 15:37: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 3E15F21F8CF0 for ; Mon, 19 Sep 2011 15:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=1.018, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb3lfbuVqz3h for ; Mon, 19 Sep 2011 15:37:27 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A77A921F8CD0 for ; Mon, 19 Sep 2011 15:37:27 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5mVD-0008Ju-DC for rtcweb@ietf.org; Mon, 19 Sep 2011 17:39:51 -0500 Message-ID: <4E77C3EC.9060801@jesup.org> Date: Mon, 19 Sep 2011 18:36:28 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@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] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 22:37:28 -0000 On 9/19/2011 4:33 PM, Sal Ibarra Corretg wrote: >> You misunderstood me; I meant "if you use an optional SIP module, you'll >> need to have a SIP proxy on your server". WebRTC in general presumes some sort >> of server architecture to solve the discovery/invitation problem. There *are* >> some possible uses of WebRTC that might not use a central server(s). The simplest >> would be the "phone-tag" server, where you and the person you want to talk to >> exchange IP addresses and external port numbers over the phone, and type them into >> the web app, which then opens a default-configured PeerConnection and re-negotiates >> to the actual configuration. >> > Still, you need this "phone-tag" server, so who will provide it? I don't see a way for 2 parties to communicate without help from outside the browser, thus, I wouldn't define any sort of protocol, even if we could simplify one. The purpose of including a protocol (which is optional to use) isn't to allow direct browser-to-browser discovery or initiation without a server. In fact, it doesn't help *or* hurt that use-case. A primary reason for including a protocol is to make it easy to build things. We don't *just* want organizations with the resources of Google or Skype or Cisco (or Mozilla) to be the ones who can make use of this new capability; we want all web developers to feel it's within their grasp. This could be satisfied in a few ways, as discussed: "baked in" simple SIP/O+A; a JS lib plus support pieces for SIP/O+A like the state machine baked in; or a pure JS implementation. But we are wary of putting it out with merely the hope that a good-enough JS lib will show up someday (and there are other pros and cons; no need to repeat them here). As far as needing external servers: there are some ideas we're floating around that would allow for server-less or virtually server-less operation of WebRTC clients including discovery and initiation, from behind NATs. We haven't speced it out or even proven it's workable yet, but we're going to look very closely at some type of proof-by-existence for this idea. -- Randell Jesup randell-ietf@jesup.org From matthew.kaufman@skype.net Mon Sep 19 15:44: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 46A1221F8A57 for ; Mon, 19 Sep 2011 15:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.883 X-Spam-Level: X-Spam-Status: No, score=-2.883 tagged_above=-999 required=5 tests=[AWL=-1.284, BAYES_00=-2.599, GB_SUMOF=5, 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 wqevhAT4ukOX for ; Mon, 19 Sep 2011 15:44:48 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFDF21F8A56 for ; Mon, 19 Sep 2011 15:44:48 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id B195816F6; Tue, 20 Sep 2011 00:47:11 +0200 (CEST) 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=v60E09BMgynL0p b2EQGlLhBbtkU=; b=njrEDGY41iqNQkJmqT4FoaO1JH0KfyngkcqAevxVmOUhIi rIbyL+hkD4rDVvGTJ2Gf3G7QKSsiIHHW4vQWq5i4NqM/3c/Fj8+HS+PRFY3BaoHd GaKsb4UkQWZYKRGb0AbqPjgsup8nwhPMrE7wknmkidfKVgFBYbMZZ4Wmy915o= 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=eaFsPpQk+XWgJwiPXNE7R3 0y3vU8xPdk2tY3neTX40q216T2hBf2tx76H7p+/130Y7LzBXr80aOdmNw5HwGyAz M6KeUI8Sf9td7vAv1Rs+48Q5O5hcWZruY0Wy2n7FtlqVSUKHzYBd7lV7ckHs9GUE QfL4D794HFrSlKjuO/UyM= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id B02DF7F6; Tue, 20 Sep 2011 00:47:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 8DAF63507ED9; Tue, 20 Sep 2011 00:47:11 +0200 (CEST) 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 9bDcLOp8R-1M; Tue, 20 Sep 2011 00:47:10 +0200 (CEST) Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 751113507EE0; Tue, 20 Sep 2011 00:47:10 +0200 (CEST) Message-ID: <4E77C636.7080501@skype.net> Date: Mon, 19 Sep 2011 15:46:14 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Randell Jesup References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> In-Reply-To: <4E77C3EC.9060801@jesup.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 22:44:49 -0000 On 9/19/2011 3:36 PM, Randell Jesup wrote: > > The purpose of including a protocol (which is optional to use) isn't > to allow > direct browser-to-browser discovery or initiation without a server. > In fact, > it doesn't help *or* hurt that use-case. A primary reason for > including a protocol > is to make it easy to build things. > By that logic we should have a built-in shopping cart to make creating web storefronts easier, a built-in email client to make it easier to build the next Gmail, etc. Except that all the interesting things that have ever happened on the web are because clever people used the minimal built-in stuff to make something much more than the sum of its parts, not because the masses used the pre-built parts to replicate what already exists. I don't want my web browser to have a phone inside of it. I want my web browser to be the thing that someone turns into the next great real-time communications experience... whatever that is. Matthew Kaufman From roman@telurix.com Mon Sep 19 15:56: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 6F01A21F8997 for ; Mon, 19 Sep 2011 15:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9G+WPAn-hRL for ; Mon, 19 Sep 2011 15:56:53 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7695021F88B6 for ; Mon, 19 Sep 2011 15:56:53 -0700 (PDT) Received: by pzk33 with SMTP id 33so20076889pzk.4 for ; Mon, 19 Sep 2011 15:59:17 -0700 (PDT) Received: by 10.68.49.133 with SMTP id u5mr4764657pbn.96.1316473157518; Mon, 19 Sep 2011 15:59:17 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx.google.com with ESMTPS id u10sm71549394pbr.12.2011.09.19.15.59.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Sep 2011 15:59:16 -0700 (PDT) Received: by pzk33 with SMTP id 33so20076789pzk.4 for ; Mon, 19 Sep 2011 15:59:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.30.2 with SMTP id o2mr5098926pbh.509.1316473155651; Mon, 19 Sep 2011 15:59:15 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Mon, 19 Sep 2011 15:59:15 -0700 (PDT) In-Reply-To: <4E77C3EC.9060801@jesup.org> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> Date: Mon, 19 Sep 2011 18:59:15 -0400 Message-ID: From: Roman Shpount To: Randell Jesup Content-Type: multipart/alternative; boundary=bcaec520f401cc86b004ad534ad2 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 19 Sep 2011 22:56:54 -0000 --bcaec520f401cc86b004ad534ad2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Randell, What I fail to understand is in what way would adding signaling to the web browser would make things easy to build? How is what you are proposing better then 2 or 3 well written samples? On the other hand, if you decide to build such simple signaling interface, depending on what use case you are trying to address you will end up with very different libraries. You have to decide how complex you want to make this library on the server vs the client side. You will need to decide if the purpose of this library is to simplify browser-to-browser or browser-to-PSTN calls. There is going to be a large number of very complex decisions none of which have obvious answers and will greatly affect the overall library design. Most importantly, I think this is a misconception that you can build something that can be developed in 20 lines or less and be useful. Real-tim= e communication is order of magnitude more complex then most of the web related applications. You need to deal with multiple event sources, deal with event collisions, negotiation failures, call state machines. And this is what required for the basic call setups. Once you start dealing with transfers, conferences, call status monitoring, things become even more complex. It is almost impossible to develop something that is simple to use that serves more then one or two specific use cases. If we try to invent something like this we might never finish. _____________ Roman Shpount On Mon, Sep 19, 2011 at 6:36 PM, Randell Jesup wrot= e: > On 9/19/2011 4:33 PM, Sa=FAl Ibarra Corretg=E9 wrote: > >> You misunderstood me; I meant "if you use an optional SIP module, you'll >>> need to have a SIP proxy on your server". WebRTC in general presumes >>> some sort >>> of server architecture to solve the discovery/invitation problem. Ther= e >>> *are* >>> some possible uses of WebRTC that might not use a central server(s). >>> The simplest >>> would be the "phone-tag" server, where you and the person you want to >>> talk to >>> exchange IP addresses and external port numbers over the phone, and typ= e >>> them into >>> the web app, which then opens a default-configured PeerConnection and >>> re-negotiates >>> to the actual configuration. >>> >>> Still, you need this "phone-tag" server, so who will provide it? I don= 't >> see a way for 2 parties to communicate without help from outside the >> browser, thus, I wouldn't define any sort of protocol, even if we could >> simplify one. >> > > The purpose of including a protocol (which is optional to use) isn't to > allow > direct browser-to-browser discovery or initiation without a server. In > fact, > it doesn't help *or* hurt that use-case. A primary reason for including = a > protocol > is to make it easy to build things. We don't *just* want organizations > with the > resources of Google or Skype or Cisco (or Mozilla) to be the ones who can > make > use of this new capability; we want all web developers to feel it's withi= n > their > grasp. This could be satisfied in a few ways, as discussed: "baked in" > simple > SIP/O+A; a JS lib plus support pieces for SIP/O+A like the state machine > baked > in; or a pure JS implementation. But we are wary of putting it out with > merely > the hope that a good-enough JS lib will show up someday (and there are > other pros > and cons; no need to repeat them here). > > As far as needing external servers: there are some ideas we're floating > around > that would allow for server-less or virtually server-less operation of > WebRTC > clients including discovery and initiation, from behind NATs. We haven't > speced it out or even proven it's workable yet, but we're going to look > very > closely at some type of proof-by-existence for this idea. > > > > -- > Randell Jesup > randell-ietf@jesup.org > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --bcaec520f401cc86b004ad534ad2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Randell,

What I fail to understand is in what way would adding signa= ling to the web browser would=A0 make things easy to build? How is what you= are proposing better then 2 or 3 well written samples?

On the other= hand, if you decide to build such simple signaling interface, depending on= what use case you are trying to address you will end up with very differen= t libraries. You have to decide how complex you want to make this library o= n the server vs the client side. You will need to decide if the purpose of = this library is to simplify browser-to-browser or browser-to-PSTN calls. Th= ere is going to be a large number of very complex decisions none of which h= ave obvious answers and will greatly affect the overall library design.

Most importantly, I think this is a misconception that you can build so= mething that can be developed in 20 lines or less and be useful. Real-time = communication is order of magnitude more complex then most of the web relat= ed applications. You need to deal with multiple event sources, deal with ev= ent collisions, negotiation failures, call state machines. And this is what= required for the basic call setups. Once you start dealing with transfers,= conferences, call status monitoring, things become even more complex. It i= s almost impossible to develop something that is simple to use that serves = more then one or two specific use cases. If we try to invent something like= this we might never finish.
_____________
Roman Shpount


On Mon, Sep 19, 2011 at 6:36 PM, Randell= Jesup <rand= ell-ietf@jesup.org> wrote:
On 9/19/2011 4:33 PM, Sa=FAl Ibarra Corretg=E9 wrote:
You misunderstood me; I meant "if you use an optional SIP module, you&= #39;ll
need to have a SIP proxy on your server". =A0WebRTC in general presume= s some sort
of server architecture to solve the discovery/invitation problem. =A0There = *are*
some possible uses of WebRTC that might not use a central server(s). =A0 Th= e simplest
would be the "phone-tag" server, where you and the person you wan= t to talk to
exchange IP addresses and external port numbers over the phone, and type th= em into
the web app, which then opens a default-configured PeerConnection and re-ne= gotiates
to the actual configuration.

Still, you need this "phone-tag" server, so who will provide it? = I don't see a way for 2 parties to communicate without help from outsid= e the browser, thus, I wouldn't define any sort of protocol, even if we= could simplify one.

The purpose of including a protocol (which is optional to use) isn't to= allow
direct browser-to-browser discovery or initiation without a server. =A0In f= act,
it doesn't help *or* hurt that use-case. =A0A primary reason for includ= ing a protocol
is to make it easy to build things. =A0We don't *just* want organizatio= ns with the
resources of Google or Skype or Cisco (or Mozilla) to be the ones who can m= ake
use of this new capability; we want all web developers to feel it's wit= hin their
grasp. =A0This could be satisfied in a few ways, as discussed: "baked = in" simple
SIP/O+A; a JS lib plus support pieces for SIP/O+A like the state machine ba= ked
in; or a pure JS implementation. =A0But we are wary of putting it out with = merely
the hope that a good-enough JS lib will show up someday (and there are othe= r pros
and cons; no need to repeat them here).

As far as needing external servers: there are some ideas we're floating= around
that would allow for server-less or virtually server-less operation of WebR= TC
clients including discovery and initiation, from behind NATs. =A0We haven&#= 39;t
speced it out or even proven it's workable yet, but we're going to = look very
closely at some type of proof-by-existence for this idea.



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

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

--bcaec520f401cc86b004ad534ad2-- From HKaplan@acmepacket.com Mon Sep 19 18:21: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 23BD021F8B03 for ; Mon, 19 Sep 2011 18:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 L15AZX7F0-Mx for ; Mon, 19 Sep 2011 18:21:01 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 53A9221F8AFF for ; Mon, 19 Sep 2011 18:21:01 -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; Mon, 19 Sep 2011 21:23:19 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 19 Sep 2011 21:23:19 -0400 From: Hadriel Kaplan To: Randell Jesup Thread-Topic: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing Thread-Index: AQHMdzPds7ADiC0xR0Si0yam86wrPw== Date: Tue, 20 Sep 2011 01:23:12 +0000 Message-ID: <0113846C-765C-43D1-80EA-A9F9D8943989@acmepacket.com> References: <4E76E8E8.2050102@ericsson.com> <017078EC-3E1A-4CC4-A29F-51B569474416@acmepacket.com> <4E774B34.1090605@jesup.org> In-Reply-To: <4E774B34.1090605@jesup.org> 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: <84B9A1CE3B9F7B44B287456839A5C1B4@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 01:21:02 -0000 On Sep 19, 2011, at 10:01 AM, Randell Jesup wrote: > BTW, your IT department does know that Windows has Remote Desktop and Rem= ote Assistance, > right? ;-) Yup, and I don't know what they think of that. My guess is they're ok with= RDP because it's a separate well-known TCP listen port number they can blo= ck in the firewalls, and afaik doesn't work behind NATs (when the server is= behind a NAT) unless you create static port maps. And RA requires a separ= ate permissions password for the session, I think. -hadriel From HKaplan@acmepacket.com Mon Sep 19 18:37: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 5395621F8A4E for ; Mon, 19 Sep 2011 18:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 bo8nZjQGsDFP for ; Mon, 19 Sep 2011 18:37:20 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 886DC21F8A4B for ; Mon, 19 Sep 2011 18:37:20 -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; Mon, 19 Sep 2011 21:39:43 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 19 Sep 2011 21:39:44 -0400 From: Hadriel Kaplan To: Harald Alvestrand Thread-Topic: [rtcweb] Minimal SDP negotiation mechanism Thread-Index: AQHMdzYrM8NQBuqbMkGVQzMD9HmeUQ== Date: Tue, 20 Sep 2011 01:39:43 +0000 Message-ID: <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> References: <4E777500.5030201@alvestrand.no> In-Reply-To: <4E777500.5030201@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 01:37:21 -0000 In SIP it's possible to get two or more different answers back for one offe= r, due to forking. I'm not sure you want/need to handle that case, but it = can and does in-practice happen in SIP. Also, in SIP it's technically possible to generate SDP which is neither an = offer nor an answer, but is rather "capabilities". This is described in RF= C 3264 section 9, and used in responses to SIP OPTIONS requests by some dev= ices. As Cullen noted in some earlier email in the mailing list, this coul= d probably be hacked around with a fake SDP answer or error, but ya may wan= t to keep things clean and just handle this case explicitly instead. -hadriel On Sep 19, 2011, at 12:59 PM, Harald Alvestrand wrote: > I am looking at the WEBRTC API spec, which specifies a rudimentary negoti= ation framework: SDP objects prefixed by the string "SDP". >=20 > It seems clear to me that this needs at least information about whether s= omething is an offer or an answer, and some way to complete the transaction= when an offer is sent and something prevents it from completing. > Until we know we need more, what about the following, to be specified in = the WEBRTC API? >=20 > SDP objects are sent through the API, prefixed with either of >=20 > SDP OFFER > SDP ANSWER >=20 > Alternatively, one can pass >=20 > SDP ERROR >=20 > to reply to an SDP OFFER when something goes wrong. >=20 > If one gets an OFFER and sends out an ANSWER, state changes. > If OFFER gets an ANSWER back, state changes. > In all other cases, state is as before. >=20 > We need to handle glare - when one sends an OFFER and gets back an OFFER,= reply with SDP ERROR, enter a "glare" state, wait a bit, and send out an o= ffer again. >=20 > Do we really have to have anything else? >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From jim.mceachern@genband.com Mon Sep 19 18:58: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 333C721F8AED for ; Mon, 19 Sep 2011 18:58:33 -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 ZYnauOzwaYp9 for ; Mon, 19 Sep 2011 18:58:32 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id AED8D21F84D4 for ; Mon, 19 Sep 2011 18:58:27 -0700 (PDT) Received: from mail.genband.com ([63.149.188.88]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTnfz0t9CAVj1qaiJ+jDuDB5SIywnILOt@postini.com; Mon, 19 Sep 2011 19:00:57 PDT Received: from owa.genband.com ([172.16.21.98]) by mail.genband.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Sep 2011 20:59:42 -0500 Received: from GBPLMAIL03.genband.com ([fe80::81ee:2d58:ca01:fb9a]) by gbex02.genband.com ([fe80::f0b6:4f10:74b0:f8b%15]) with mapi id 14.01.0289.001; Mon, 19 Sep 2011 20:59:41 -0500 From: Jim McEachern To: Harald Alvestrand Thread-Topic: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing Thread-Index: AQHMdpoKQqo6ybJBbkGwLU8CXowJrZVUojQAgADigsQ= Date: Tue, 20 Sep 2011 01:59:41 +0000 Message-ID: <7F213C9E-3AD9-4527-80B3-BACD280D09FA@genband.com> References: <4E76E8E8.2050102@ericsson.com>,<4E76EF3A.4010500@alvestrand.no> In-Reply-To: <4E76EF3A.4010500@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Sep 2011 01:59:42.0635 (UTC) FILETIME=[F69E5FB0:01CC7738] X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.500.1024-18396.003 X-TM-AS-Result: No--31.592600-5.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 01:58:33 -0000 I also support including A) in our use cases now, but deferring B) till lat= er. Jim=20 On Sep 19, 2011, at 3:29 AM, "Harald Alvestrand" wro= te: > On 09/19/2011 09:02 AM, Magnus Westerlund wrote: >> WG, >>=20 >> There where some discussion in the Interim meeting last week about a >> Screen/Application/Desktop sharing support use case. My take away from >> the discussion is that this use cases is likely well enough understood >> to actually start a consensus call now. However, to us WG chairs it was >> clear that the use case in question actually needs to be split into two >> parts. >>=20 >> A) Where the RTCWEB enabled browser can use a local application window, >> the whole desktop or a Screen as a media source that can be encoded and >> transported over the peerConnection for displaying/playback at the peer. > I think this is a fairly well defined applicaiton (basically, take input = from a synthetic source, where the synthetic source may be anything availab= le to the browser), the baseline (but not the optimum) could simply be enco= ding the stuff using a default codec, and the access procedures shouldn't b= e much different than for microphone and camera. I support its inclusion in= the document. >=20 > Note: The implementation of such a feature is far from trivial. I would n= ot want to require that all browsers implementing RTCWeb support the featur= e. >> B) Where a remote peer can provide one or more input types such as mouse >> and keyboard to control the local system, not only including the >> browser, but also other operating system resources. This clearly can >> only happen after additional consent, most likely on a per occasion >> consent. > I see this as a more tricky thing to get right (in most apps, the mixing= of events from multiple sources depends strongly on both proper timing/seq= uencing and reliable delivery). I would like to not address this for now (R= TCWeb version 1). >> My interpretation is that A only allows for application sharing in >> conferencing contexts, like in the WEBEX session the Interim meeting was >> held with where we shared slides. Where the combination of A and B is >> providing for VNC/Remote desktop. >>=20 >> Thus the question to the WG is the following. >>=20 >> 1) Do you support or object the inclusion of use case A, B or Both in >> our Use case document? >>=20 >> 2) Do you have additional comments for or against either of the use case= s? >>=20 >>=20 >> As WG chair >>=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 >>=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From pravindran@sonusnet.com Mon Sep 19 22: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 F18C521F8A7D for ; Mon, 19 Sep 2011 22:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=1.106, BAYES_00=-2.599, GB_I_INVITATION=-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 8gRW3Jyz3xCZ for ; Mon, 19 Sep 2011 22:25:16 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 13DF821F858D for ; Mon, 19 Sep 2011 22:25:09 -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 p8K5S4pX001774; Tue, 20 Sep 2011 01:28:04 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Sep 2011 01:27:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC7755.FD96E0ED" Date: Tue, 20 Sep 2011 10:57:28 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: Acx3H9LXmjupTQnLQgm90FJ2QBUwvgANWiZw References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com><05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org> From: "Ravindran Parthasarathi" To: "Roman Shpount" , "Randell Jesup" X-OriginalArrivalTime: 20 Sep 2011 05:27:33.0215 (UTC) FILETIME=[FFA9DEF0:01CC7755] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 05:25:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC7755.FD96E0ED Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Roman, =20 I agree with you in case you wish to have all class 5 services in this = architecture. In the web game server wherein the basic call has to be = established between two parties, this complexity is not required. One of = the main aim of the RTCWeb default signaling protocol is to make two = party real-time communication easy with less development effort for any = web developer. =20 Thanks Partha =20 From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf = Of Roman Shpount Sent: Tuesday, September 20, 2011 4:29 AM To: Randell Jesup Cc: rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About = defining a signaling protocol for WebRTC (or not)] =20 Randell, What I fail to understand is in what way would adding signaling to the = web browser would make things easy to build? How is what you are = proposing better then 2 or 3 well written samples? On the other hand, if you decide to build such simple signaling = interface, depending on what use case you are trying to address you will = end up with very different libraries. You have to decide how complex you = want to make this library on the server vs the client side. You will = need to decide if the purpose of this library is to simplify = browser-to-browser or browser-to-PSTN calls. There is going to be a = large number of very complex decisions none of which have obvious = answers and will greatly affect the overall library design. Most importantly, I think this is a misconception that you can build = something that can be developed in 20 lines or less and be useful. = Real-time communication is order of magnitude more complex then most of = the web related applications. You need to deal with multiple event = sources, deal with event collisions, negotiation failures, call state = machines. And this is what required for the basic call setups. Once you = start dealing with transfers, conferences, call status monitoring, = things become even more complex. It is almost impossible to develop = something that is simple to use that serves more then one or two = specific use cases. If we try to invent something like this we might = never finish. _____________ Roman Shpount On Mon, Sep 19, 2011 at 6:36 PM, Randell Jesup = wrote: On 9/19/2011 4:33 PM, Sa=FAl Ibarra Corretg=E9 wrote: You misunderstood me; I meant "if you use an optional SIP module, = you'll need to have a SIP proxy on your server". WebRTC in general presumes = some sort of server architecture to solve the discovery/invitation problem. = There *are* some possible uses of WebRTC that might not use a central server(s). = The simplest would be the "phone-tag" server, where you and the person you want to = talk to exchange IP addresses and external port numbers over the phone, and = type them into the web app, which then opens a default-configured PeerConnection and = re-negotiates to the actual configuration. Still, you need this "phone-tag" server, so who will provide it? I don't = see a way for 2 parties to communicate without help from outside the = browser, thus, I wouldn't define any sort of protocol, even if we could = simplify one. The purpose of including a protocol (which is optional to use) isn't to = allow direct browser-to-browser discovery or initiation without a server. In = fact, it doesn't help *or* hurt that use-case. A primary reason for including = a protocol is to make it easy to build things. We don't *just* want organizations = with the resources of Google or Skype or Cisco (or Mozilla) to be the ones who = can make use of this new capability; we want all web developers to feel it's = within their grasp. This could be satisfied in a few ways, as discussed: "baked in" = simple SIP/O+A; a JS lib plus support pieces for SIP/O+A like the state machine = baked in; or a pure JS implementation. But we are wary of putting it out with = merely the hope that a good-enough JS lib will show up someday (and there are = other pros and cons; no need to repeat them here). As far as needing external servers: there are some ideas we're floating = around that would allow for server-less or virtually server-less operation of = WebRTC clients including discovery and initiation, from behind NATs. We = haven't speced it out or even proven it's workable yet, but we're going to look = very closely at some type of proof-by-existence for this idea. --=20 Randell Jesup randell-ietf@jesup.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 ------_=_NextPart_001_01CC7755.FD96E0ED Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Roman,

 

I agree with you in case you wish to have all class 5 = services in this architecture. In the web game server wherein the basic call has to = be established between two parties, this complexity is not required. One of = the main aim of the RTCWeb default signaling protocol is to make two party = real-time communication easy with less development effort for any web = developer.

 

Thanks

Partha

 

From:= rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of = Roman Shpount
Sent: Tuesday, September 20, 2011 4:29 AM
To: Randell Jesup
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: = About defining a signaling protocol for WebRTC (or not)]

 

Randell,

What I fail to understand is in what way would adding signaling to the = web browser would  make things easy to build? How is what you are = proposing better then 2 or 3 well written samples?

On the other hand, if you decide to build such simple signaling = interface, depending on what use case you are trying to address you will end up = with very different libraries. You have to decide how complex you want to make = this library on the server vs the client side. You will need to decide if the purpose of this library is to simplify browser-to-browser or = browser-to-PSTN calls. There is going to be a large number of very complex decisions = none of which have obvious answers and will greatly affect the overall library = design.

Most importantly, I think this is a misconception that you can build = something that can be developed in 20 lines or less and be useful. Real-time = communication is order of magnitude more complex then most of the web related = applications. You need to deal with multiple event sources, deal with event = collisions, negotiation failures, call state machines. And this is what required for = the basic call setups. Once you start dealing with transfers, conferences, = call status monitoring, things become even more complex. It is almost = impossible to develop something that is simple to use that serves more then one or two specific use cases. If we try to invent something like this we might = never finish.
_____________
Roman Shpount

On Mon, Sep 19, 2011 at 6:36 PM, Randell Jesup = <randell-ietf@jesup.org> = wrote:

On 9/19/2011 4:33 PM, Sa=FAl Ibarra Corretg=E9 = wrote:

You misunderstood = me; I meant "if you use an optional SIP module, you'll
need to have a SIP proxy on your server".  WebRTC in general = presumes some sort
of server architecture to solve the discovery/invitation problem. =  There *are*
some possible uses of WebRTC that might not use a central server(s). =   The simplest
would be the "phone-tag" server, where you and the person you = want to talk to
exchange IP addresses and external port numbers over the phone, and type = them into
the web app, which then opens a default-configured PeerConnection and re-negotiates
to the actual configuration.

Still, you need this "phone-tag" server, = so who will provide it? I don't see a way for 2 parties to communicate without = help from outside the browser, thus, I wouldn't define any sort of protocol, = even if we could simplify one.


The purpose of including a protocol (which is optional to use) isn't to = allow
direct browser-to-browser discovery or initiation without a server. =  In fact,
it doesn't help *or* hurt that use-case.  A primary reason for = including a protocol
is to make it easy to build things.  We don't *just* want = organizations with the
resources of Google or Skype or Cisco (or Mozilla) to be the ones who = can make
use of this new capability; we want all web developers to feel it's = within their
grasp.  This could be satisfied in a few ways, as discussed: = "baked in" simple
SIP/O+A; a JS lib plus support pieces for SIP/O+A like the state machine = baked
in; or a pure JS implementation.  But we are wary of putting it out = with merely
the hope that a good-enough JS lib will show up someday (and there are = other pros
and cons; no need to repeat them here).

As far as needing external servers: there are some ideas we're floating = around
that would allow for server-less or virtually server-less operation of = WebRTC
clients including discovery and initiation, from behind NATs.  We = haven't
speced it out or even proven it's workable yet, but we're going to look = very
closely at some type of proof-by-existence for this idea.



--
Randell Jesup
randell-ietf@jesup.org

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

 

------_=_NextPart_001_01CC7755.FD96E0ED-- From s.choi@daemon.or.kr Mon Sep 19 22:46: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 655C021F8B0F for ; Mon, 19 Sep 2011 22:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 n6mVvNUzOwrk for ; Mon, 19 Sep 2011 22:46:36 -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 45A5F21F8B0D for ; Mon, 19 Sep 2011 22:46:36 -0700 (PDT) Received: by fxd18 with SMTP id 18so198589fxd.31 for ; Mon, 19 Sep 2011 22:48:59 -0700 (PDT) Received: by 10.223.45.85 with SMTP id d21mr699356faf.63.1316497738952; Mon, 19 Sep 2011 22:48:58 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by mx.google.com with ESMTPS id b21sm446928fab.8.2011.09.19.22.48.57 (version=SSLv3 cipher=OTHER); Mon, 19 Sep 2011 22:48:57 -0700 (PDT) Received: by bkaq10 with SMTP id q10so167260bka.31 for ; Mon, 19 Sep 2011 22:48:55 -0700 (PDT) Received: by 10.204.133.138 with SMTP id f10mr212626bkt.379.1316497735840; Mon, 19 Sep 2011 22:48:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.205.81.10 with HTTP; Mon, 19 Sep 2011 22:37:43 -0700 (PDT) In-Reply-To: References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> From: Soo-Hyun Choi Date: Tue, 20 Sep 2011 14:37:43 +0900 Message-ID: To: Henrik Lundin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 05:46:37 -0000 A question and a suggestion. >>>> >>>> 4. Section 4. >>>> >>>> "This algorithm is run every time a receive report arrives at the >>>> =A0 =A0sender, which will happen [[how often do we expect? and why?]].= =A0If >>>> =A0 =A0no receive report is recieved within [[what timeout?]], the alg= orithm >>>> =A0 =A0will take action as if all packets in the interval have been lo= st. >>>> =A0 =A0[[does that make sense?]]" >>>> >>>> The transmission of receiver reports is highly dependent on RTP profil= e, >>>> the RTCP bandwidth, trr-int parameter and any feedback events. >>>> >>>> If I start with assuming AVPF which seems reasonable in most browser t= o >>>> browser case with our current proposals for RTP support. Then if there >>>> are no feedback events the transmission of receiver reports will occur >>>> as often as the bandwidth allows, but no more often than the value of >>>> trr-int parameter. >>>> >>>> Here is might be worth mentioning that I do expect trr-int to be set t= o >>>> avoid RTCP reporting to often due to the relatively high RTCP bandwidt= h >>>> values that will be set due to the multiplexing of audio and video in = a >>>> single RTP session. Thus avoiding that RTCP rates are as high or large= r >>>> than the audio streams they report in steady state. >>> >>> Agreed. =A0This is where my plans to suggest a baseline algorithm that >>> melds >>> the reception data of all the streams in the PeerConnection may be a >>> significant advantage over doing bandwidth estimation on each stream >>> independently. =A0We'll see if I can make the idea work, but there are = some >>> significant advantages if it does. =A0If not, we can estimate in each >>> channel >>> independently as per the Google algorithm. >>> >>> You can also use rtcp-fb PLI/etc events to hang these reports off of, >>> increasing >>> the frequency they get through with minimal extra bandwidth use. >>> >>> >>>> When feedback events occur the stack will have the choice of sending a >>>> RTCP RR, that is a choice provided due to the reduced size RTCP >>>> specification included. But if the loss cumulative count diff is >>>> non-zero it might be worth mandating that the RR/SR is included in any >>>> such feedback RTCP packet. >>> >>> Exactly - or a TMMBR with the results of the receiver-side bandwidth >>> calculations. >>> >>>> For that reason causing a feedback event when there is losses and >>>> schedule them using the early algorithm may be a good choice to ensure >>>> timely reporting of any loss. >>>> >>>> If one uses AVP then the RTCP timing rules will give you when you >>>> transmit RTCP feeedback and thus the parameterization becomes central >>>> here. A clear issue is if people uses the minimal interval of 5 second= s >>>> or the 360/Session_BW(in kbps). I would note that 5 seconds is very lo= ng >>>> in adaptation situations. >>> >>> Yes. > > In the proposed algorithm, the RTCP interval adds to the system response > time. The response time governs the bandwidth increase rate so that the s= tep > into over-use will have a limited delay build-up before it can be detecte= d > and mitigated. Thus, a long RTCP interval results in a slow adaptation, b= ut > it should still be stable. > I wonder how would you guarantee that such a long RTCP interval doesn't result in instability when estimating bandwidth? Typically, a delay-based CC algorithm can be vulnerable when timer become inacurate. I suspect the delayed RTCP feedback can calculate available bandwidth correctly. Why not use per-packet based feedback (using AVPF, for example) in order not to cause any harm with this kind of situation? I would think that a CC mechanism, at least, should be able to calculate and suggest right/correct rate to the upper layer's codec so that it could determine whether it actually increase/decrease encoding rate or not, depending upon CC's suggested rate. Kind regards, Soo-Hyun From hlundin@google.com Mon Sep 19 22:56: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 8FDCC21F888A for ; Mon, 19 Sep 2011 22:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.092 X-Spam-Level: X-Spam-Status: No, score=-105.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCND87gSeeIT for ; Mon, 19 Sep 2011 22:56:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id ECFF621F85D1 for ; Mon, 19 Sep 2011 22:56:28 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p8K5wqnM025955 for ; Mon, 19 Sep 2011 22:58:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1316498333; bh=u1INRmnk5CMLoweCkz01drMcz7E=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=CD6O4XhJ8e3mIizOmsheJvPeA7oAI968TSiMWjqL+QsoiqlbsXaNUaq5W5NHsIuQl wcfIE/mgpHbkYuvlMdj8w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=Fe1wMQw8rLHuIS24Gp8PV53uH2UKGeSCoofia3DGuWr7rZ7ZnixYT1PbplKcUhxhZ 3Qjd49lxo3BpLAIweZr5w== Received: from gxk22 (gxk22.prod.google.com [10.202.11.22]) by hpaq1.eem.corp.google.com with ESMTP id p8K5wol9018399 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 19 Sep 2011 22:58:51 -0700 Received: by gxk22 with SMTP id 22so145254gxk.30 for ; Mon, 19 Sep 2011 22:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2TvMISDOn7Ek7slSW1mpcnz8hZ8t5UBkiBZfdVaVza0=; b=pCuy7S5314Cof/ylsH28hSdW8FoO/VhVwHDak2dnu9o5gc2QODitGMt1tUlTUfT4gt wE3NZO2rTrft7Izvglkg== Received: by 10.100.56.25 with SMTP id e25mr288115ana.70.1316498330043; Mon, 19 Sep 2011 22:58:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.56.25 with SMTP id e25mr288109ana.70.1316498329898; Mon, 19 Sep 2011 22:58:49 -0700 (PDT) Received: by 10.100.166.9 with HTTP; Mon, 19 Sep 2011 22:58:49 -0700 (PDT) In-Reply-To: References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> Date: Tue, 20 Sep 2011 07:58:49 +0200 Message-ID: From: Henrik Lundin To: Soo-Hyun Choi Content-Type: multipart/alternative; boundary=0016e647661c4d0dd404ad592794 X-System-Of-Record: true Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 05:56:30 -0000 --0016e647661c4d0dd404ad592794 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 20, 2011 at 7:37 AM, Soo-Hyun Choi wrote: > A question and a suggestion. > > > > >>>> > >>>> 4. Section 4. > >>>> > >>>> "This algorithm is run every time a receive report arrives at the > >>>> sender, which will happen [[how often do we expect? and why?]]. If > >>>> no receive report is recieved within [[what timeout?]], the > algorithm > >>>> will take action as if all packets in the interval have been lost. > >>>> [[does that make sense?]]" > >>>> > >>>> The transmission of receiver reports is highly dependent on RTP > profile, > >>>> the RTCP bandwidth, trr-int parameter and any feedback events. > >>>> > >>>> If I start with assuming AVPF which seems reasonable in most browser > to > >>>> browser case with our current proposals for RTP support. Then if there > >>>> are no feedback events the transmission of receiver reports will occur > >>>> as often as the bandwidth allows, but no more often than the value of > >>>> trr-int parameter. > >>>> > >>>> Here is might be worth mentioning that I do expect trr-int to be set > to > >>>> avoid RTCP reporting to often due to the relatively high RTCP > bandwidth > >>>> values that will be set due to the multiplexing of audio and video in > a > >>>> single RTP session. Thus avoiding that RTCP rates are as high or > larger > >>>> than the audio streams they report in steady state. > >>> > >>> Agreed. This is where my plans to suggest a baseline algorithm that > >>> melds > >>> the reception data of all the streams in the PeerConnection may be a > >>> significant advantage over doing bandwidth estimation on each stream > >>> independently. We'll see if I can make the idea work, but there are > some > >>> significant advantages if it does. If not, we can estimate in each > >>> channel > >>> independently as per the Google algorithm. > >>> > >>> You can also use rtcp-fb PLI/etc events to hang these reports off of, > >>> increasing > >>> the frequency they get through with minimal extra bandwidth use. > >>> > >>> > >>>> When feedback events occur the stack will have the choice of sending a > >>>> RTCP RR, that is a choice provided due to the reduced size RTCP > >>>> specification included. But if the loss cumulative count diff is > >>>> non-zero it might be worth mandating that the RR/SR is included in any > >>>> such feedback RTCP packet. > >>> > >>> Exactly - or a TMMBR with the results of the receiver-side bandwidth > >>> calculations. > >>> > >>>> For that reason causing a feedback event when there is losses and > >>>> schedule them using the early algorithm may be a good choice to ensure > >>>> timely reporting of any loss. > >>>> > >>>> If one uses AVP then the RTCP timing rules will give you when you > >>>> transmit RTCP feeedback and thus the parameterization becomes central > >>>> here. A clear issue is if people uses the minimal interval of 5 > seconds > >>>> or the 360/Session_BW(in kbps). I would note that 5 seconds is very > long > >>>> in adaptation situations. > >>> > >>> Yes. > > > > In the proposed algorithm, the RTCP interval adds to the system response > > time. The response time governs the bandwidth increase rate so that the > step > > into over-use will have a limited delay build-up before it can be > detected > > and mitigated. Thus, a long RTCP interval results in a slow adaptation, > but > > it should still be stable. > > > > I wonder how would you guarantee that such a long RTCP interval > doesn't result in instability when estimating bandwidth? Typically, a > delay-based CC algorithm can be vulnerable when timer become > inacurate. I suspect the delayed RTCP feedback can calculate available > bandwidth correctly. Why not use per-packet based feedback (using > AVPF, for example) in order not to cause any harm with this kind of > situation? > I agree that more frequent feedback does improve the bandwidth estimation. No doubt about that. > I would think that a CC mechanism, at least, should be able to > calculate and suggest right/correct rate to the upper layer's codec so > that it could determine whether it actually increase/decrease encoding > rate or not, depending upon CC's suggested rate. > > > Kind regards, > Soo-Hyun > -- Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41 --0016e647661c4d0dd404ad592794 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Sep 20, 2011 at 7:37 AM, Soo-Hyu= n Choi <s= oohyun.choi@cl.cam.ac.uk> wrote:
A question and a suggestion.



>>>>
>>>> 4. Section 4.
>>>>
>>>> "This algorithm is run every time a receive report ar= rives at the
>>>> =A0 =A0sender, which will happen [[how often do we expect?= and why?]]. =A0If
>>>> =A0 =A0no receive report is recieved within [[what timeout= ?]], the algorithm
>>>> =A0 =A0will take action as if all packets in the interval = have been lost.
>>>> =A0 =A0[[does that make sense?]]"
>>>>
>>>> The transmission of receiver reports is highly dependent o= n RTP profile,
>>>> the RTCP bandwidth, trr-int parameter and any feedback eve= nts.
>>>>
>>>> If I start with assuming AVPF which seems reasonable in mo= st browser to
>>>> browser case with our current proposals for RTP support. T= hen if there
>>>> are no feedback events the transmission of receiver report= s will occur
>>>> as often as the bandwidth allows, but no more often than t= he value of
>>>> trr-int parameter.
>>>>
>>>> Here is might be worth mentioning that I do expect trr-int= to be set to
>>>> avoid RTCP reporting to often due to the relatively high R= TCP bandwidth
>>>> values that will be set due to the multiplexing of audio a= nd video in a
>>>> single RTP session. Thus avoiding that RTCP rates are as h= igh or larger
>>>> than the audio streams they report in steady state.
>>>
>>> Agreed. =A0This is where my plans to suggest a baseline algori= thm that
>>> melds
>>> the reception data of all the streams in the PeerConnection ma= y be a
>>> significant advantage over doing bandwidth estimation on each = stream
>>> independently. =A0We'll see if I can make the idea work, b= ut there are some
>>> significant advantages if it does. =A0If not, we can estimate = in each
>>> channel
>>> independently as per the Google algorithm.
>>>
>>> You can also use rtcp-fb PLI/etc events to hang these reports = off of,
>>> increasing
>>> the frequency they get through with minimal extra bandwidth us= e.
>>>
>>>
>>>> When feedback events occur the stack will have the choice = of sending a
>>>> RTCP RR, that is a choice provided due to the reduced size= RTCP
>>>> specification included. But if the loss cumulative count d= iff is
>>>> non-zero it might be worth mandating that the RR/SR is inc= luded in any
>>>> such feedback RTCP packet.
>>>
>>> Exactly - or a TMMBR with the results of the receiver-side ban= dwidth
>>> calculations.
>>>
>>>> For that reason causing a feedback event when there is los= ses and
>>>> schedule them using the early algorithm may be a good choi= ce to ensure
>>>> timely reporting of any loss.
>>>>
>>>> If one uses AVP then the RTCP timing rules will give you w= hen you
>>>> transmit RTCP feeedback and thus the parameterization beco= mes central
>>>> here. A clear issue is if people uses the minimal interval= of 5 seconds
>>>> or the 360/Session_BW(in kbps). I would note that 5 second= s is very long
>>>> in adaptation situations.
>>>
>>> Yes.
>
> In the proposed algorithm, the RTCP interval adds to the system respon= se
> time. The response time governs the bandwidth increase rate so that th= e step
> into over-use will have a limited delay build-up before it can be dete= cted
> and mitigated. Thus, a long RTCP interval results in a slow adaptation= , but
> it should still be stable.
>

I wonder how would you guarantee that such a long RTCP interval=
doesn't result in instability when estimating bandwidth? Typically, a delay-based CC algorithm can be vulnerable when timer become
inacurate. I suspect the delayed RTCP feedback can calculate available
bandwidth correctly. Why not use per-packet based feedback (using
AVPF, for example) in order not to cause any harm with this kind of
situation?
I agree that more frequent feedback does im= prove the bandwidth estimation. No doubt about that.


I would think that a CC mechanism, at least, should be able to
calculate and suggest right/correct rate to the upper layer's codec so<= br> that it could determine whether it actually increase/decrease encoding
rate or not, depending upon CC's suggested rate.


Kind regards,
Soo-Hyun



--
Henrik Lundin=A0|=A0WebRTC Software Eng=A0|=A0hlundin@google.com=A0|=A0+46 70 646 13 = 41


--0016e647661c4d0dd404ad592794-- From HKaplan@acmepacket.com Mon Sep 19 22:56: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 7018921F84D1 for ; Mon, 19 Sep 2011 22:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 JcttG53iATLH for ; Mon, 19 Sep 2011 22:56:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id CE19F21F845D for ; Mon, 19 Sep 2011 22:56: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; Tue, 20 Sep 2011 01:59:11 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 20 Sep 2011 01:59:11 -0400 From: Hadriel Kaplan To: Ravindran Parthasarathi Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: AQHMd1pqLHvBWHS2NkWGn3FMeQaTYw== Date: Tue, 20 Sep 2011 05:59:10 +0000 Message-ID: References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com><05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.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: <751649407B8B3049B32AF273FA73206A@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Randell Jesup , "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 05:56:47 -0000 On Sep 20, 2011, at 1:27 AM, Ravindran Parthasarathi wrote: > I agree with you in case you wish to have all class 5 services in this ar= chitecture. In the web game server wherein the basic call has to be establi= shed between two parties, this complexity is not required. OK, let's take the game example... only 2-player games would be able to use= a simple rtcweb-SIP agent. Anything more than 2-player would want to use = the multi-party "conferencing" model of rtcweb, which can't even be signale= d with SIP today as far as I can tell. (not that I've thought about it too = much, but I can't see how it would without some changes to SIP) > One of the main aim of the RTCWeb default signaling protocol is to make t= wo party real-time communication easy with less development effort for any = web developer. Why doesn't using JS libraries provide that ease of development, assuming t= here's a good "signaling agent" JS library for whatever communication model= the deployer wants/needs? If there isn't a good JS library, then one woul= d wonder why we think all browsers will have a good built-in signaling agen= t instead.=20 -hadriel =20 From randell-ietf@jesup.org Mon Sep 19 23:40: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 2EF4811E8073 for ; Mon, 19 Sep 2011 23:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 QXTRZ3odCrYI for ; Mon, 19 Sep 2011 23:40:24 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C05DD11E8083 for ; Mon, 19 Sep 2011 23:40:24 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5u2b-0007ve-5r for rtcweb@ietf.org; Tue, 20 Sep 2011 01:42:49 -0500 Message-ID: <4E78351C.20103@jesup.org> Date: Tue, 20 Sep 2011 02:39:24 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.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] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 06:40:26 -0000 On 9/20/2011 1:59 AM, Hadriel Kaplan wrote: > On Sep 20, 2011, at 1:27 AM, Ravindran Parthasarathi wrote: > >> I agree with you in case you wish to have all class 5 services in this architecture. In the web game server wherein the basic call has to be established between two parties, this complexity is not required. > OK, let's take the game example... only 2-player games would be able to use a simple rtcweb-SIP agent. Anything more than 2-player would want to use the multi-party "conferencing" model of rtcweb, which can't even be signaled with SIP today as far as I can tell. (not that I've thought about it too much, but I can't see how it would without some changes to SIP) It should be easy - either as N-1 2-person calls to the person hosting the game, or N calls via a central server (equivalent to a mixer), or as a full mesh of direct calls (3 2-person calls for a 3-person game, 6 for a 4-person game, etc), or even sparse meshes (makes sense in a game where not all players are 'near' each other). >> One of the main aim of the RTCWeb default signaling protocol is to make two party real-time communication easy with less development effort for any web developer. > Why doesn't using JS libraries provide that ease of development, assuming there's a good "signaling agent" JS library for whatever communication model the deployer wants/needs? If there isn't a good JS library, then one would wonder why we think all browsers will have a good built-in signaling agent instead. Well, there are a lot more available C/C++ SIP libraries than JS SIP libraries (I've heard of one non-open-I-assume one under development), to start with. The same applies to XMPP (one known implementation - may not be free), etc. Let alone well-tested and used JS SIP/etc libraries. Yes, we could develop them. I don't see that as being easier than developing the equivalent in C++, assuming you decided to start both efforts from scratch - and one may well not have to start from scratch. -- Randell Jesup randell-ietf@jesup.org From s.choi@daemon.or.kr Tue Sep 20 00:05: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 6E78A21F8906 for ; Tue, 20 Sep 2011 00:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 4va41pRj9QAD for ; Tue, 20 Sep 2011 00:05:40 -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 49CD421F88B7 for ; Tue, 20 Sep 2011 00:05:39 -0700 (PDT) Received: by fxd18 with SMTP id 18so256139fxd.31 for ; Tue, 20 Sep 2011 00:08:04 -0700 (PDT) Received: by 10.223.18.149 with SMTP id w21mr769949faa.118.1316502483973; Tue, 20 Sep 2011 00:08:03 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by mx.google.com with ESMTPS id y8sm634128faj.10.2011.09.20.00.07.55 (version=SSLv3 cipher=OTHER); Tue, 20 Sep 2011 00:07:58 -0700 (PDT) Received: by bkaq10 with SMTP id q10so224373bka.31 for ; Tue, 20 Sep 2011 00:07:55 -0700 (PDT) Received: by 10.204.142.145 with SMTP id q17mr257938bku.275.1316502475276; Tue, 20 Sep 2011 00:07:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.205.81.10 with HTTP; Tue, 20 Sep 2011 00:07:35 -0700 (PDT) In-Reply-To: References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> From: Soo-Hyun Choi Date: Tue, 20 Sep 2011 16:07:35 +0900 Message-ID: To: Henrik Lundin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 07:05:41 -0000 On Tue, Sep 20, 2011 at 14:58, Henrik Lundin wrote: > > > On Tue, Sep 20, 2011 at 7:37 AM, Soo-Hyun Choi > wrote: >> >> A question and a suggestion. >> >> >> >> >>>> >> >>>> 4. Section 4. >> >>>> >> >>>> "This algorithm is run every time a receive report arrives at the >> >>>> =A0 =A0sender, which will happen [[how often do we expect? and why?= ]]. >> >>>> =A0If >> >>>> =A0 =A0no receive report is recieved within [[what timeout?]], the >> >>>> algorithm >> >>>> =A0 =A0will take action as if all packets in the interval have been= lost. >> >>>> =A0 =A0[[does that make sense?]]" >> >>>> >> >>>> The transmission of receiver reports is highly dependent on RTP >> >>>> profile, >> >>>> the RTCP bandwidth, trr-int parameter and any feedback events. >> >>>> >> >>>> If I start with assuming AVPF which seems reasonable in most browse= r >> >>>> to >> >>>> browser case with our current proposals for RTP support. Then if >> >>>> there >> >>>> are no feedback events the transmission of receiver reports will >> >>>> occur >> >>>> as often as the bandwidth allows, but no more often than the value = of >> >>>> trr-int parameter. >> >>>> >> >>>> Here is might be worth mentioning that I do expect trr-int to be se= t >> >>>> to >> >>>> avoid RTCP reporting to often due to the relatively high RTCP >> >>>> bandwidth >> >>>> values that will be set due to the multiplexing of audio and video = in >> >>>> a >> >>>> single RTP session. Thus avoiding that RTCP rates are as high or >> >>>> larger >> >>>> than the audio streams they report in steady state. >> >>> >> >>> Agreed. =A0This is where my plans to suggest a baseline algorithm th= at >> >>> melds >> >>> the reception data of all the streams in the PeerConnection may be a >> >>> significant advantage over doing bandwidth estimation on each stream >> >>> independently. =A0We'll see if I can make the idea work, but there a= re >> >>> some >> >>> significant advantages if it does. =A0If not, we can estimate in eac= h >> >>> channel >> >>> independently as per the Google algorithm. >> >>> >> >>> You can also use rtcp-fb PLI/etc events to hang these reports off of= , >> >>> increasing >> >>> the frequency they get through with minimal extra bandwidth use. >> >>> >> >>> >> >>>> When feedback events occur the stack will have the choice of sendin= g >> >>>> a >> >>>> RTCP RR, that is a choice provided due to the reduced size RTCP >> >>>> specification included. But if the loss cumulative count diff is >> >>>> non-zero it might be worth mandating that the RR/SR is included in >> >>>> any >> >>>> such feedback RTCP packet. >> >>> >> >>> Exactly - or a TMMBR with the results of the receiver-side bandwidth >> >>> calculations. >> >>> >> >>>> For that reason causing a feedback event when there is losses and >> >>>> schedule them using the early algorithm may be a good choice to >> >>>> ensure >> >>>> timely reporting of any loss. >> >>>> >> >>>> If one uses AVP then the RTCP timing rules will give you when you >> >>>> transmit RTCP feeedback and thus the parameterization becomes centr= al >> >>>> here. A clear issue is if people uses the minimal interval of 5 >> >>>> seconds >> >>>> or the 360/Session_BW(in kbps). I would note that 5 seconds is very >> >>>> long >> >>>> in adaptation situations. >> >>> >> >>> Yes. >> > >> > In the proposed algorithm, the RTCP interval adds to the system respon= se >> > time. The response time governs the bandwidth increase rate so that th= e >> > step >> > into over-use will have a limited delay build-up before it can be >> > detected >> > and mitigated. Thus, a long RTCP interval results in a slow adaptation= , >> > but >> > it should still be stable. >> > >> >> I wonder how would you guarantee that such a long RTCP interval >> doesn't result in instability when estimating bandwidth? Typically, a >> delay-based CC algorithm can be vulnerable when timer become >> inacurate. I suspect the delayed RTCP feedback can calculate available >> bandwidth correctly. Why not use per-packet based feedback (using >> AVPF, for example) in order not to cause any harm with this kind of >> situation? > > I agree that more frequent feedback does improve the bandwidth estimation= . > No doubt about that. >> Well, the problem of the inaccurate feedback timer is that it could make the whole things go wrong. I.e., Inaccurate BW estimation could lead into providing inaccurate information about the available BW to the upper layer, which eventually result in instability at the codec's encoding rate. Wouldn't we need to be a little more careful on choosing/designing CC algos, which I believe we are capable of? Kind regards, Soo-Hyun >> I would think that a CC mechanism, at least, should be able to >> calculate and suggest right/correct rate to the upper layer's codec so >> that it could determine whether it actually increase/decrease encoding >> rate or not, depending upon CC's suggested rate. >> >> >> Kind regards, >> Soo-Hyun > > > > -- > Henrik Lundin=A0|=A0WebRTC Software Eng=A0|=A0hlundin@google.com=A0|=A0+4= 6 70 646 13 41 > > From HKaplan@acmepacket.com Tue Sep 20 00:17: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 358AF11E8080 for ; Tue, 20 Sep 2011 00:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 0a9BpQFmY2e7 for ; Tue, 20 Sep 2011 00:17:49 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id BB45C11E8073 for ; Tue, 20 Sep 2011 00:17:48 -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; Tue, 20 Sep 2011 03:20:12 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 20 Sep 2011 03:20:11 -0400 From: Hadriel Kaplan To: Randell Jesup Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: AQHMd2Ww2V9ZOtZta0qF5HzNdmfwDA== Date: Tue, 20 Sep 2011 07:19:51 +0000 Message-ID: References: <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> <4E78351C.20103@jesup.org> In-Reply-To: <4E78351C.20103@jesup.org> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 07:17:50 -0000 On Sep 20, 2011, at 2:39 AM, Randell Jesup wrote: > On 9/20/2011 1:59 AM, Hadriel Kaplan wrote: >> OK, let's take the game example... only 2-player games would be able to = use a simple rtcweb-SIP agent. Anything more than 2-player would want to u= se the multi-party "conferencing" model of rtcweb, which can't even be sign= aled with SIP today as far as I can tell. (not that I've thought about it t= oo much, but I can't see how it would without some changes to SIP) >=20 > It should be easy - either as N-1 2-person calls to the person hosting th= e game, or > N calls via a central server (equivalent to a mixer), or as a full mesh o= f direct > calls (3 2-person calls for a 3-person game, 6 for a 4-person game, etc),= or even > sparse meshes (makes sense in a game where not all players are 'near' eac= h other). Can't do N-1 2-person calls to the person hosting the game, because rtcweb = doesn't support "full" mixing in the browser, only local media mixing. (ie,= everyone will hear the person hosting the game, and the person hosting the= game will hear everyone else, but the rest won't hear each other) Calls via a central media server require a central media server, which kind= a defeats the "easy" concept and using our shiny new toy of rtcweb. A full mesh is what *should* happen, but SIP/SDP can't do it, afaict. It w= ould treat them either as independent calls even at a media layer, or as a = full-mixer conference focus model. The closest thing we have would probabl= y be the Join header, but I believe it's semantics is to join as a full mix= er conf call. Isn't this full-mesh media-forking thing actually a new sema= ntic for SIP/SDP? (it's hard to believe with 100+ drafts/RFCs this scenari= o hasn't already been addressed in SIP - I must be just having a memory lea= k) -hadriel From saul@ag-projects.com Tue Sep 20 00:26: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 3CCAD21F847C for ; Tue, 20 Sep 2011 00:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.712 X-Spam-Level: X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xATjwrGZpIiP for ; Tue, 20 Sep 2011 00:26:32 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 70A5C21F847A for ; Tue, 20 Sep 2011 00:26:32 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id DFD9AB01B8; Tue, 20 Sep 2011 09:28:55 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 1029FB019A; Tue, 20 Sep 2011 09:28:41 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Tue, 20 Sep 2011 09:28:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> To: Roman Shpount X-Mailer: Apple Mail (2.1084) Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 07:26:33 -0000 On Sep 20, 2011, at 12:59 AM, Roman Shpount wrote: > Randell, >=20 > What I fail to understand is in what way would adding signaling to the = web browser would make things easy to build? How is what you are = proposing better then 2 or 3 well written samples? >=20 > On the other hand, if you decide to build such simple signaling = interface, depending on what use case you are trying to address you will = end up with very different libraries. You have to decide how complex you = want to make this library on the server vs the client side. You will = need to decide if the purpose of this library is to simplify = browser-to-browser or browser-to-PSTN calls. There is going to be a = large number of very complex decisions none of which have obvious = answers and will greatly affect the overall library design. >=20 > Most importantly, I think this is a misconception that you can build = something that can be developed in 20 lines or less and be useful. = Real-time communication is order of magnitude more complex then most of = the web related applications. You need to deal with multiple event = sources, deal with event collisions, negotiation failures, call state = machines. And this is what required for the basic call setups. Once you = start dealing with transfers, conferences, call status monitoring, = things become even more complex. It is almost impossible to develop = something that is simple to use that serves more then one or two = specific use cases. If we try to invent something like this we might = never finish. +1. If we add some signaling protocol to the browser to ease web developers = then someone might say "why don't we also add X, Y and Z". The browser = only needs the media plane, the signaling can be elsewhere, and it's far = better to have it elsewhere. As Roman pointed out, RTC applications are not something that can nor = should be done in 20 lines of JS. It's just complex. If people want to = make simple apps they can build a simple JS library using an invented = simple protocol. But RTCWeb shouldn't encourage this IMHO. -- Sa=FAl Ibarra Corretg=E9 AG Projects From randell-ietf@jesup.org Tue Sep 20 00:46: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 D968521F85AA for ; Tue, 20 Sep 2011 00:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 AeqdfsWHqMB5 for ; Tue, 20 Sep 2011 00:46:59 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 486F621F84DB for ; Tue, 20 Sep 2011 00:46:59 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R5v52-0007JZ-5g for rtcweb@ietf.org; Tue, 20 Sep 2011 02:49:24 -0500 Message-ID: <4E7844B7.8000005@jesup.org> Date: Tue, 20 Sep 2011 03:45:59 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> <4E78351C.20103@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] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 07:47:00 -0000 On 9/20/2011 3:19 AM, Hadriel Kaplan wrote: > On Sep 20, 2011, at 2:39 AM, Randell Jesup wrote: > >> On 9/20/2011 1:59 AM, Hadriel Kaplan wrote: >>> OK, let's take the game example... only 2-player games would be able to use a simple rtcweb-SIP agent. Anything more than 2-player would want to use the multi-party "conferencing" model of rtcweb, which can't even be signaled with SIP today as far as I can tell. (not that I've thought about it too much, but I can't see how it would without some changes to SIP) >> It should be easy - either as N-1 2-person calls to the person hosting the game, or >> N calls via a central server (equivalent to a mixer), or as a full mesh of direct >> calls (3 2-person calls for a 3-person game, 6 for a 4-person game, etc), or even >> sparse meshes (makes sense in a game where not all players are 'near' each other). > Can't do N-1 2-person calls to the person hosting the game, because rtcweb doesn't support "full" mixing in the browser, only local media mixing. (ie, everyone will hear the person hosting the game, and the person hosting the game will hear everyone else, but the rest won't hear each other) Ok; I hadn't looked at what controls we're giving the JS app (mostly focusing on IETF level stuff). W3C issue. It would be nice if an app could set up a bridge; I'm a little surprised it can't. > Calls via a central media server require a central media server, which kinda defeats the "easy" concept and using our shiny new toy of rtcweb. I never said all uses are easy. Simple uses are easy (like 2-person games), complex uses are possible (and as easy as we can do). I'd like to avoid a separate mixer, though, I agree. > A full mesh is what *should* happen, but SIP/SDP can't do it, afaict. It would treat them either as independent calls even at a media layer, or as a full-mixer conference focus model. The closest thing we have would probably be the Join header, but I believe it's semantics is to join as a full mixer conf call. Isn't this full-mesh media-forking thing actually a new semantic for SIP/SDP? (it's hard to believe with 100+ drafts/RFCs this scenario hasn't already been addressed in SIP - I must be just having a memory leak) SIP has been very focused on device<->server interaction, not device<->device. However: note that we have an app that knows why it has these calls in place; we're not defining an abstract, portable protocol use here. It would be worthwhile to work out the details of these 'mesh' and ad-hoc (bridged) conference models and if they fit into the security model, since they enable (and reduce the cost of) a number of important uses. -- Randell Jesup randell-ietf@jesup.org From ibc@aliax.net Tue Sep 20 01:07: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 C7FF621F84C3 for ; Tue, 20 Sep 2011 01:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, 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 hrsHrVGmVY4d for ; Tue, 20 Sep 2011 01:07:00 -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 38C8D21F84ED for ; Tue, 20 Sep 2011 01:07:00 -0700 (PDT) Received: by qyk33 with SMTP id 33so274385qyk.10 for ; Tue, 20 Sep 2011 01:09:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.94.112 with SMTP id db16mr354062vdb.497.1316506165175; Tue, 20 Sep 2011 01:09:25 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Tue, 20 Sep 2011 01:09:24 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> Date: Tue, 20 Sep 2011 10:09:24 +0200 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: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 08:07:00 -0000 2011/9/20 Ravindran Parthasarathi : > One of the main aim of the RTCWeb default signaling protocol is to make t= wo > party real-time communication easy with less development effort for any w= eb > developer. Hi, let me some comments please: 1) "RTCWeb default signaling protocol" is not defined neither it exists. I would ask you for not talking about it as if it was already approved since that could become confusing for readers. Also, given other threads it's clear that most of the people here is contrary to a "RTCWeb default signaling protocol" or "SIP built-in the browser". They have also given good rationale across multiple threads. 2) If browsers speak pure SIP then the server side MUST also speak SIP. How to accomplish with that in shared web hostings? Must the web admins learn about SIP and installing/configuring a OpenSER/Kamailio/OpenSIPS/SER SIP proxy/registrar? This question has been made several times in some threads. No reply yet (same occurs with other given arguments). 3) Making the signaling path a separate flow means that the web server (so the web application in server side) would not be aware about sessions status. So if for example two users visit the same page and speak through their web browsers and later one of them logouts from the web, the server has no easy way to force the call termination. Neither a "forum-administrator" could reject an spammer from an audio conference room (or it would be hard to accomplish). In contrast, if the signaling is carried via HTTP/WebSocket, the logic is centralized and the server application would be aware of existing sessions. Best regards. --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Tue Sep 20 01: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 F2F9D21F8B56 for ; Tue, 20 Sep 2011 01:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 WzposXtd9qva for ; Tue, 20 Sep 2011 01:14:52 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 45D9721F8B51 for ; Tue, 20 Sep 2011 01:14:52 -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; Tue, 20 Sep 2011 04:17:16 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 20 Sep 2011 04:17:15 -0400 From: Hadriel Kaplan To: Randell Jesup Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: AQHMd220PqVpjlbCTEKowCUVUodjXA== Date: Tue, 20 Sep 2011 08:17:15 +0000 Message-ID: References: <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> <4E78351C.20103@jesup.org> <4E7844B7.8000005@jesup.org> In-Reply-To: <4E7844B7.8000005@jesup.org> 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: <117546E686F54B4DA447B869386B0453@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 08:14:53 -0000 On Sep 20, 2011, at 3:45 AM, Randell Jesup wrote: > Ok; I hadn't looked at what controls we're giving the JS app (mostly focu= sing on IETF > level stuff). W3C issue. It would be nice if an app could set up a brid= ge; I'm > a little surprised it can't. If it could, we'd probably have the siprec/remote-recording requirement acc= ommodated. :) >> A full mesh is what *should* happen, but SIP/SDP can't do it, afaict. I= t would treat them either as independent calls even at a media layer, or as= a full-mixer conference focus model. The closest thing we have would prob= ably be the Join header, but I believe it's semantics is to join as a full = mixer conf call. Isn't this full-mesh media-forking thing actually a new s= emantic for SIP/SDP? (it's hard to believe with 100+ drafts/RFCs this scen= ario hasn't already been addressed in SIP - I must be just having a memory = leak) >=20 > SIP has been very focused on device<->server interaction, not device<->de= vice. However: > note that we have an app that knows why it has these calls in place; we'r= e not defining an > abstract, portable protocol use here. Aha! So it's not "SIP" that you meant... you meant "something that looks l= ike SIP but isn't SIP per the RFCs". ;) -hadriel From magnus.westerlund@ericsson.com Tue Sep 20 01:15: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 A86F521F8B56 for ; Tue, 20 Sep 2011 01:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.514 X-Spam-Level: X-Spam-Status: No, score=-106.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 Ckr5GEjyz727 for ; Tue, 20 Sep 2011 01:15:38 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id CE22221F8B51 for ; Tue, 20 Sep 2011 01:15:37 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-a9-4e784c3af233 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8B.35.02839.A3C487E4; Tue, 20 Sep 2011 10:18:02 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Sep 2011 10:18:01 +0200 Message-ID: <4E784C38.2010909@ericsson.com> Date: Tue, 20 Sep 2011 10:18:00 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Muthu Arul Mozhi Perumal (mperumal)" References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se><4E70D2E6.1000809@alvestrand.no><7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se><092401cc749b$8fd64940$af82dbc0$@com><4E765E4A.3050801@alvestrand.no><0ced01cc76de$28731630$79594290$@com> <4E77613B.4020805@ericsson.com> <1D062974A4845E4D8A343C6538049202066497EF@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C6538049202066497EF@XMB-BGL-414.cisco.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 08:15:38 -0000 On 2011-09-19 18:41, Muthu Arul Mozhi Perumal (mperumal) wrote: > Another aspect to consider: As per RFC 3550, the bare minimal valid > RTCP packet is a compound RTCP packet containing: - An RR packet with > the reception report count set to 0 (RC=0) and - An SDES packet with > CNAME > > Such a packet would look like this: > > 0 1 2 3 0 1 2 3 > 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > header |V=2|P| RC=0 | PT=RR=201 | length > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > SSRC of packet sender | > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > header |V=2|P| SC=1 | PT=SDES=202 | length > | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > chunk | SSRC of packet sender > | 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > CNAME=1 | length |user & domain padded to 32-bit | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > I've seen endpoints sending/accepting such a packet as an indication > for session liveliness. However, there is no entropy at all in this > packet. Suppose an attacker manages to bring the receiver down and > captures such a RTCP packet. The attacker can keep replaying it (from > the spoofed source transport address) to make the sender believe that > the receiver is still alive and muted. well, the reasonable assumption if you are using this for consent freshness is to verify that your flow is reported on in a reasonable way. That do provide some entropy in sequence number and Last SR field in the report block as I wrote in my other email. > > Perhaps, RTCWeb apps should try to negotiate an RTCP extension > carrying a monotonically increasing number that must be part of every > RTCP report together with SRTCP, for replay attack protection. That is a possibility, but I think one can start by ensuring that one actually check for ones own traffic being reported back. That gives you some entropy. Which is a slightly longer context gives you good verification that you are not contining sending into a location where there receiver you intended to have sent to moves away. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Tue Sep 20 01:26: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 0920321F8A97 for ; Tue, 20 Sep 2011 01:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.514 X-Spam-Level: X-Spam-Status: No, score=-106.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 yISFPlVzCtDf for ; Tue, 20 Sep 2011 01:26:42 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id DBC2C21F8A7B for ; Tue, 20 Sep 2011 01:26:41 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e9-4e784ed27a2f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 37.C8.20773.2DE487E4; Tue, 20 Sep 2011 10:29:06 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Sep 2011 10:29:06 +0200 Message-ID: <4E784ED1.5000502@ericsson.com> Date: Tue, 20 Sep 2011 10:29:05 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Randell Jesup References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E77543E.1040704@ericsson.com> <4E777DA0.80201@jesup.org> In-Reply-To: <4E777DA0.80201@jesup.org> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 08:26:43 -0000 On 2011-09-19 19:36, Randell Jesup wrote: > On 9/19/2011 10:39 AM, Magnus Westerlund wrote: >> Hi, >> >> As an individual I like to provide some analyze of the entropy in >> RTP/RTCP. Please consider, comment and provide opinion about the number >> of bits. > Thanks for the excellent analysis, Magnus. > >> On 2011-09-16 20:30, Eric Rescorla wrote: >>>> The RTCP receiver reports should be adequate for 'consent freshness', no? >>>> If I still like receiving the traffic, I'll report that I'm receiving it. >>>> If I have crashed or disconnected or am not listening on that port, I won't. >>> I believe so, though I'd have to make sure there's enough entropy. And of course >>> some implementations may not do RTCP... >>> >> So one case of attack is the one when the webserver S uses the connected >> clients to attack target T by instructing client C to send to target T. >> So the Server or some server controlled entity A needs to send RTCP to C >> that makes C believe T is responding, i.e. spoofed source address that >> are T's plus the content of the RTCP RR. Please note that SRTP will not >> provide any protection if the webserver knows the key. Thus if security >> description is allowed, which appear reasonable if supporting legacy is >> the goal, which is the reason for this whole proposal. > > I would disagree with one aspect of that: I don't know that we need to > support SDES, and if we do, we only need to support it for "legacy" > connections, not true webrtc browser-to-browser connections, which I > assert should always be DTLS. Of course, non-encrypted RTP to a legacy > device would have no protection against spoofing of return RTCP at all. I think this analyze is valid for several different proposals that has been raised. 1) Consent Freshness, i.e. the verification that a previous verified destination continues to be present 2) Use RTCP instead of ICE for delivery consent, especially against legacy which likely doesn't support ICE nor SRTP. And I would also observe that we have no WG consensus on the security mechanism. We have no WG document containing an assumption, nor have we made a consensus call about what mechanism to support. I agree that DTLS seems to have strong support as default keying mechanism, but also their has been a fair amount of voices that thinks Security Descriptions should be supported also to make keying towards legacy SRTP systems much simpler. Yes, it is likely time to do the consensus calls on the media security mechanisms so that will be settled. > > Note that we need to complete a valid ICE exchange with the target > per the current spec, so T can only be attacked to begin with if the ICE > exchange can be spoofed. The original scenario from Eric was about "how > do I determine if the recipient wants to *continue* to receive data > after a valid exchange (for example after ending the call or > rebooting/crashing). I haven't checked the properties of ICE and the > ability to spoof it, but before analyzing the entropy required to attack > the return RTCP 'freshness' state, we need to show that the attack could > be begun, or state that ICE is not mandatory for some connections. But, if we want to look at not using ICE with legacy and still establish consent to receive then RTCP has been discussed and I did want to provide some indication of how strong this is. Which I agree is fairly week, that considering that one appear to need several RRs in sequence that are consistent combined with the reporter having received SRs to be reasonably sure, which implies 10-30 seconds before consent is being established as a less than working idea. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From oej@edvina.net Tue Sep 20 01:46: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 B618421F8B08 for ; Tue, 20 Sep 2011 01:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.008, 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 v4xZFN8ZHqk3 for ; Tue, 20 Sep 2011 01:46:16 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 309C021F8AB9 for ; Tue, 20 Sep 2011 01:46:16 -0700 (PDT) Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 44FFC754BCE4; Tue, 20 Sep 2011 08:48:37 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: Date: Tue, 20 Sep 2011 10:48:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> <4E78351C.20103@jesup.org> <4E7844B7.80000 05@jesup.org> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1244.3) Cc: Randell Jesup , "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 08:46:16 -0000 20 sep 2011 kl. 10:17 skrev Hadriel Kaplan: >=20 > On Sep 20, 2011, at 3:45 AM, Randell Jesup wrote: >=20 >> Ok; I hadn't looked at what controls we're giving the JS app (mostly = focusing on IETF >> level stuff). W3C issue. It would be nice if an app could set up a = bridge; I'm >> a little surprised it can't. >=20 > If it could, we'd probably have the siprec/remote-recording = requirement accommodated. :) Well, take a look at the source code for FreeSwitch or Asterisk and = you'll see that "setting up a bridge" is not a piece of cake... You are making the assumption that you have no formatting issues and = don't need to change framerate for video, orientation or anything else = or audio transcoding. >=20 >=20 >>> A full mesh is what *should* happen, but SIP/SDP can't do it, = afaict. It would treat them either as independent calls even at a media = layer, or as a full-mixer conference focus model. The closest thing we = have would probably be the Join header, but I believe it's semantics is = to join as a full mixer conf call. Isn't this full-mesh media-forking = thing actually a new semantic for SIP/SDP? (it's hard to believe with = 100+ drafts/RFCs this scenario hasn't already been addressed in SIP - I = must be just having a memory leak) >>=20 >> SIP has been very focused on device<->server interaction, not = device<->device. However: >> note that we have an app that knows why it has these calls in place; = we're not defining an >> abstract, portable protocol use here. >=20 > Aha! So it's not "SIP" that you meant... you meant "something that = looks like SIP but isn't SIP per the RFCs". ;) >=20 According to RFC 3261 SIP is a peer 2 peer protocol and not a = device->server protocol. Just making a point. /O From pravindran@sonusnet.com Tue Sep 20 01:51: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 73F6521F8511 for ; Tue, 20 Sep 2011 01:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=-0.061, 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 HEDDIaiZS4-i for ; Tue, 20 Sep 2011 01:51:59 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id CA5E821F8510 for ; Tue, 20 Sep 2011 01:51:58 -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 p8K8srJq006197; Tue, 20 Sep 2011 04:54:53 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Sep 2011 04:54:22 -0400 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: Tue, 20 Sep 2011 14:24:21 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0E12@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: Acx3bJ/O1CWDXs32QnSt1wgAlRrTYwABSYuQ References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com><05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org><2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 20 Sep 2011 08:54:22.0488 (UTC) FILETIME=[E42AA980:01CC7772] Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 08:51:59 -0000 SGkgSW5ha2ksDQoNCkkgaGF2ZSBhbnN3ZXJlZCB0byB5b3UgaW4gdGhlIGFub3RoZXIgdGhyZWFk IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNn MDExNzIuaHRtbCkuICBJIHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBhcmUgbG90IG9mIHRocmVhZCwg U28geW91IG1pZ2h0IGhhdmUgY29uZnVzZWQuICBBcyBJIGluZGljYXRlZCBpbiB0aGUgZWFybGll ciBtYWlsLCBJJ2xsIGNvbWUgdXAgd2l0aCB0aGUgd3JpdGUgdXAgdG8gZGlzY3VzcyB0aGUgbmVl ZCBmb3IgIlJUQ1dlYiBkZWZhdWx0IHNpZ25hbGluZyBwcm90b2NvbCIuIFBsZWFzZSBub3RlIGlu IHRoZSBtYWlsIHRocmVhZCB0aGF0IHRoZXJlIGlzIG5vIG1lbnRpb24gb2YgU0lQIGFzIGEgUlRD V2ViIGRlZmF1bHQgc2lnbmFsaW5nIHByb3RvY29sLiBUaGUgYXJndW1lbnQgaXMgYmV0d2VlbiAi bm90aGluZyIgdnMgImRlZmF1bHQiIHNpZ25hbGluZyBwcm90b2NvbC4NCg0KU0lQIG9yIFhNUFAg YmFzZWQgcHJvdG9jb2wgd2lsbCBiZSBzZWxlY3RlZCBhcyBhIGRlZmF1bHQgcHJvdG9jb2wgYmFz ZWQgb24gdGVjaG5pY2FsIG1lcml0IG9mIGEgZ2l2ZW4gUlRDV2ViIHNpZ25hbGluZyBwcm9ibGVt IGJ1dCBpdCBpcyBhIHNlY29uZCBzdGFnZS4NCg0KVGhhbmtzDQpQYXJ0aGENCg0KPi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogScOxYWtpIEJheiBDYXN0aWxsbyBbbWFpbHRvOmli Y0BhbGlheC5uZXRdDQo+U2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDIwLCAyMDExIDE6MzkgUE0N Cj5UbzogUmF2aW5kcmFuIFBhcnRoYXNhcmF0aGkNCj5DYzogUm9tYW4gU2hwb3VudDsgUmFuZGVs bCBKZXN1cDsgcnRjd2ViQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtydGN3ZWJdIFJUQ1dlYiBk ZWZhdWx0IHNpZ25hbGluZyBwcm90b2NvbCBbd2FzIFJFOiBBYm91dA0KPmRlZmluaW5nIGEgc2ln bmFsaW5nIHByb3RvY29sIGZvciBXZWJSVEMgKG9yIG5vdCldDQo+DQo+MjAxMS85LzIwIFJhdmlu ZHJhbiBQYXJ0aGFzYXJhdGhpIDxwcmF2aW5kcmFuQHNvbnVzbmV0LmNvbT46DQo+PiBPbmUgb2Yg dGhlIG1haW4gYWltIG9mIHRoZSBSVENXZWIgZGVmYXVsdCBzaWduYWxpbmcgcHJvdG9jb2wgaXMg dG8NCj5tYWtlIHR3bw0KPj4gcGFydHkgcmVhbC10aW1lIGNvbW11bmljYXRpb24gZWFzeSB3aXRo IGxlc3MgZGV2ZWxvcG1lbnQgZWZmb3J0IGZvcg0KPmFueSB3ZWINCj4+IGRldmVsb3Blci4NCj4N Cj5IaSwgbGV0IG1lIHNvbWUgY29tbWVudHMgcGxlYXNlOg0KPg0KPjEpICJSVENXZWIgZGVmYXVs dCBzaWduYWxpbmcgcHJvdG9jb2wiIGlzIG5vdCBkZWZpbmVkIG5laXRoZXIgaXQNCj5leGlzdHMu IEkgd291bGQgYXNrIHlvdSBmb3Igbm90IHRhbGtpbmcgYWJvdXQgaXQgYXMgaWYgaXQgd2FzIGFs cmVhZHkNCj5hcHByb3ZlZCBzaW5jZSB0aGF0IGNvdWxkIGJlY29tZSBjb25mdXNpbmcgZm9yIHJl YWRlcnMuIEFsc28sIGdpdmVuDQo+b3RoZXIgdGhyZWFkcyBpdCdzIGNsZWFyIHRoYXQgbW9zdCBv ZiB0aGUgcGVvcGxlIGhlcmUgaXMgY29udHJhcnkgdG8gYQ0KPiJSVENXZWIgZGVmYXVsdCBzaWdu YWxpbmcgcHJvdG9jb2wiIG9yICJTSVAgYnVpbHQtaW4gdGhlIGJyb3dzZXIiLg0KPlRoZXkgaGF2 ZSBhbHNvIGdpdmVuIGdvb2QgcmF0aW9uYWxlIGFjcm9zcyBtdWx0aXBsZSB0aHJlYWRzLg0KPg0K PjIpIElmIGJyb3dzZXJzIHNwZWFrIHB1cmUgU0lQIHRoZW4gdGhlIHNlcnZlciBzaWRlIE1VU1Qg YWxzbyBzcGVhaw0KPlNJUC4gSG93IHRvIGFjY29tcGxpc2ggd2l0aCB0aGF0IGluIHNoYXJlZCB3 ZWIgaG9zdGluZ3M/IE11c3QgdGhlIHdlYg0KPmFkbWlucyBsZWFybiBhYm91dCBTSVAgYW5kIGlu c3RhbGxpbmcvY29uZmlndXJpbmcgYQ0KPk9wZW5TRVIvS2FtYWlsaW8vT3BlblNJUFMvU0VSIFNJ UCBwcm94eS9yZWdpc3RyYXI/IFRoaXMgcXVlc3Rpb24gaGFzDQo+YmVlbiBtYWRlIHNldmVyYWwg dGltZXMgaW4gc29tZSB0aHJlYWRzLiBObyByZXBseSB5ZXQgKHNhbWUgb2NjdXJzDQo+d2l0aCBv dGhlciBnaXZlbiBhcmd1bWVudHMpLg0KPg0KPjMpIE1ha2luZyB0aGUgc2lnbmFsaW5nIHBhdGgg YSBzZXBhcmF0ZSBmbG93IG1lYW5zIHRoYXQgdGhlIHdlYiBzZXJ2ZXINCj4oc28gdGhlIHdlYiBh cHBsaWNhdGlvbiBpbiBzZXJ2ZXIgc2lkZSkgd291bGQgbm90IGJlIGF3YXJlIGFib3V0DQo+c2Vz c2lvbnMgc3RhdHVzLiBTbyBpZiBmb3IgZXhhbXBsZSB0d28gdXNlcnMgdmlzaXQgdGhlIHNhbWUg cGFnZSBhbmQNCj5zcGVhayB0aHJvdWdoIHRoZWlyIHdlYiBicm93c2VycyBhbmQgbGF0ZXIgb25l IG9mIHRoZW0gbG9nb3V0cyBmcm9tDQo+dGhlIHdlYiwgdGhlIHNlcnZlciBoYXMgbm8gZWFzeSB3 YXkgdG8gZm9yY2UgdGhlIGNhbGwgdGVybWluYXRpb24uDQo+TmVpdGhlciBhICJmb3J1bS1hZG1p bmlzdHJhdG9yIiBjb3VsZCByZWplY3QgYW4gc3BhbW1lciBmcm9tIGFuIGF1ZGlvDQo+Y29uZmVy ZW5jZSByb29tIChvciBpdCB3b3VsZCBiZSBoYXJkIHRvIGFjY29tcGxpc2gpLiBJbiBjb250cmFz dCwgaWYNCj50aGUgc2lnbmFsaW5nIGlzIGNhcnJpZWQgdmlhIEhUVFAvV2ViU29ja2V0LCB0aGUg bG9naWMgaXMgY2VudHJhbGl6ZWQNCj5hbmQgdGhlIHNlcnZlciBhcHBsaWNhdGlvbiB3b3VsZCBi ZSBhd2FyZSBvZiBleGlzdGluZyBzZXNzaW9ucy4NCj4NCj4NCj5CZXN0IHJlZ2FyZHMuDQo+DQo+ DQo+LS0NCj5Jw7Fha2kgQmF6IENhc3RpbGxvDQo+PGliY0BhbGlheC5uZXQ+DQo= From HKaplan@acmepacket.com Tue Sep 20 01:53: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 28C0421F86B3 for ; Tue, 20 Sep 2011 01:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 7JF5jEeSab0u for ; Tue, 20 Sep 2011 01:53:48 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7D49D21F8512 for ; Tue, 20 Sep 2011 01:53:48 -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; Tue, 20 Sep 2011 04:56:12 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 20 Sep 2011 04:56:12 -0400 From: Hadriel Kaplan To: "Olle E. Johansson" Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: AQHMd3MlcSAuiyw20EW6ZlHZryVV1w== Date: Tue, 20 Sep 2011 08:56:11 +0000 Message-ID: References: <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> <4E78351C.20103@jesup.org> <4E7844B7.80000 05@jesup.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <7229B2162AA46D409B1D46DFDF4FD39A@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Randell Jesup , "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 08:53:49 -0000 On Sep 20, 2011, at 4:48 AM, Olle E. Johansson wrote: >> If it could, we'd probably have the siprec/remote-recording requirement = accommodated. :) > Well, take a look at the source code for FreeSwitch or Asterisk and you'l= l see that "setting up a bridge" is not a piece of cake... > You are making the assumption that you have no formatting issues and don'= t need to change framerate for video, orientation or anything else or audio= transcoding. Nope, I'm not making any such assumption. I was just pointing out that if = the browser did full mixing, then we'd have the remote recording use-case t= hing done too.=20 >>> SIP has been very focused on device<->server interaction, not device<->= device. However: >>> note that we have an app that knows why it has these calls in place; we= 're not defining an >>> abstract, portable protocol use here. >>=20 >> Aha! So it's not "SIP" that you meant... you meant "something that look= s like SIP but isn't SIP per the RFCs". ;) >>=20 > According to RFC 3261 SIP is a peer 2 peer protocol and not a device->ser= ver protocol. Just making a point. I'm not sure if you meant that in response to my remark or Randell's? What= I meant by saying "it's not really SIP" wasn't because I think SIP is not = device<->device (on the contrary, it is)... but rather that if rtcweb uses = SIP but then doesn't actually follow the rules of SIP, then it's *not* SIP. -hadriel From oej@edvina.net Tue Sep 20 02:01: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 2574B21F8AB0 for ; Tue, 20 Sep 2011 02:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.007, 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 FnJwmJDffW7j for ; Tue, 20 Sep 2011 02:01:46 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEA521F8876 for ; Tue, 20 Sep 2011 02:01:46 -0700 (PDT) Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 83B5B754BCE4; Tue, 20 Sep 2011 09:04:10 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: Date: Tue, 20 Sep 2011 11:04:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <142BBF6F-F3D5-4D04-8F65-2B1C4CF1A2A2@edvina.net> References: <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> <4E78351C.20103@jesup.org> <4E7844B7.80000 05@jesup.org> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1244.3) Cc: Randell Jesup , "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 09:01:47 -0000 20 sep 2011 kl. 10:56 skrev Hadriel Kaplan: >=20 > On Sep 20, 2011, at 4:48 AM, Olle E. Johansson wrote: >=20 >>> If it could, we'd probably have the siprec/remote-recording = requirement accommodated. :) >> Well, take a look at the source code for FreeSwitch or Asterisk and = you'll see that "setting up a bridge" is not a piece of cake... >> You are making the assumption that you have no formatting issues and = don't need to change framerate for video, orientation or anything else = or audio transcoding. >=20 > Nope, I'm not making any such assumption. I was just pointing out = that if the browser did full mixing, then we'd have the remote recording = use-case thing done too.=20 >=20 >=20 >>>> SIP has been very focused on device<->server interaction, not = device<->device. However: >>>> note that we have an app that knows why it has these calls in = place; we're not defining an >>>> abstract, portable protocol use here. >>>=20 >>> Aha! So it's not "SIP" that you meant... you meant "something that = looks like SIP but isn't SIP per the RFCs". ;) >>>=20 >> According to RFC 3261 SIP is a peer 2 peer protocol and not a = device->server protocol. Just making a point. >=20 > I'm not sure if you meant that in response to my remark or Randell's? = What I meant by saying "it's not really SIP" wasn't because I think SIP = is not device<->device (on the contrary, it is)... but rather that if = rtcweb uses SIP but then doesn't actually follow the rules of SIP, then = it's *not* SIP. >=20 Sorry, both comments was meant for Randell. But thank you for your = response :-) My opinion is that a limited version of SIP for rtcweb would not only be = impossible to develop and keep in a limited scope, it would hurt the = RTCweb process. And it's interesting to observe how many SIP oldtimers = in this list that maintain that opinion... It might be something worthwile to define in the process of trying to = move SIP towards the Internet Standard goal, but that's a separate = issue. /O From ibc@aliax.net Tue Sep 20 02:12: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 023EC21F8B83 for ; Tue, 20 Sep 2011 02:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, 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 3QWNLhod-CrO for ; Tue, 20 Sep 2011 02:12:23 -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 5A85B21F8B81 for ; Tue, 20 Sep 2011 02:12:23 -0700 (PDT) Received: by vws5 with SMTP id 5so539107vws.31 for ; Tue, 20 Sep 2011 02:14:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.213.132 with SMTP id gw4mr139187vcb.52.1316510088009; Tue, 20 Sep 2011 02:14:48 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Tue, 20 Sep 2011 02:14:47 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0E12@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F0E12@sonusinmail02.sonusnet.com> Date: Tue, 20 Sep 2011 11:14:47 +0200 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: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 09:12:24 -0000 2011/9/20 Ravindran Parthasarathi : > I have answered to you in the another thread (http://www.ietf.org/mail-ar= chive/web/rtcweb/current/msg01172.html). =C2=A0I understand that there are = lot of thread, So you might have confused. Hi Ravindran. It seems that you avoid replying to the questions in my previous mail (3 points you have never answered). Same arguments was given in the thread you point above, again without responses. Why? > SIP or XMPP based protocol will be selected as a default protocol based o= n technical merit of a given RTCWeb signaling problem but it is a second st= age. What does it mean "SIP or XMPP based protocol will be selected as a default protocol [...]"? Anyone reading your mails would assume that such a decision is already taken. Is it? who took it? Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Sep 20 02:21: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 2F7CC21F8BDC for ; Tue, 20 Sep 2011 02:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, 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 RN5QYo3nGq1d for ; Tue, 20 Sep 2011 02:21:24 -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 96A8A21F8BC3 for ; Tue, 20 Sep 2011 02:21:24 -0700 (PDT) Received: by vws5 with SMTP id 5so548600vws.31 for ; Tue, 20 Sep 2011 02:23:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.213.132 with SMTP id gw4mr141501vcb.52.1316510629562; Tue, 20 Sep 2011 02:23:49 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Tue, 20 Sep 2011 02:23:49 -0700 (PDT) In-Reply-To: <142BBF6F-F3D5-4D04-8F65-2B1C4CF1A2A2@edvina.net> References: <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> <4E78351C.20103@jesup.org> <142BBF6F-F3D5-4D04-8F65-2B1C4CF1A2A2@edvina.net> Date: Tue, 20 Sep 2011 11:23:49 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Randell Jesup , "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 09:21:25 -0000 2011/9/20 Olle E. Johansson : > My opinion is that a limited version of SIP for rtcweb would not only be = impossible to develop and keep in a limited scope, it would hurt the RTCweb= process. And it's interesting to observe how many SIP oldtimers in this li= st that maintain that opinion... I'm strongly contrary to built SIP on browsers (by the same arguments given in various threads). --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Sep 20 02:38: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 B6E6221F8BF0 for ; Tue, 20 Sep 2011 02:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, 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 G-yVqp7dq6eE for ; Tue, 20 Sep 2011 02:38:17 -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 300A321F8BE4 for ; Tue, 20 Sep 2011 02:38:17 -0700 (PDT) Received: by vws5 with SMTP id 5so567037vws.31 for ; Tue, 20 Sep 2011 02:40:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.175.229 with SMTP id cd5mr454519vdc.363.1316511641667; Tue, 20 Sep 2011 02:40:41 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Tue, 20 Sep 2011 02:40:41 -0700 (PDT) In-Reply-To: <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acmepacket.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> Date: Tue, 20 Sep 2011 11:40:41 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 09:38:17 -0000 2011/9/19 Olle E. Johansson : > So if we rephrase the issue: I think RTCP should be a MUST for rtcweb imp= lementations. However, calls should not fail when communicating with RTP im= plementations that doesn't send RTCP. +1 Be flexible on receiving and strict in sending. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Tue Sep 20 04: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 B9B3A21F8B75 for ; Tue, 20 Sep 2011 04:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jFcSGcv2dcZ for ; Tue, 20 Sep 2011 04:45:12 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1A45C21F8B70 for ; Tue, 20 Sep 2011 04:45:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3366D39E0BC for ; Tue, 20 Sep 2011 13:47:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQigqUXjrpTv for ; Tue, 20 Sep 2011 13:47:34 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id CE9A939E08A for ; Tue, 20 Sep 2011 13:47:34 +0200 (CEST) Message-ID: <4E787D56.8060106@alvestrand.no> Date: Tue, 20 Sep 2011 13:47:34 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 11:45:12 -0000 On 09/20/11 09:07, Soo-Hyun Choi wrote: > Well, the problem of the inaccurate feedback timer is that it could > make the whole things go wrong. > > I.e., Inaccurate BW estimation could lead into providing inaccurate > information about the available BW to the upper layer, which > eventually result in instability at the codec's encoding rate. > > Wouldn't we need to be a little more careful on choosing/designing CC > algos, which I believe we are capable of? > One prayer.... let's avoid unquantifiable terms in our discussions. "A little more careful" is an unquantifiable term. If we want to say "I think the algorithm must guarantee that the bandwidth estimate is updated within 1.5 seconds when the available bandwidth changes from 2 Mbit/sec to 1 Mbit/sec", let's say something like that - focus on what the requirements are. We can always be a little more careful. But it doesn't tell us when we're close enough. Harald From pravindran@sonusnet.com Tue Sep 20 04:50: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 DB11221F8C0C for ; Tue, 20 Sep 2011 04:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=-0.060, 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 TFPypdrm7d0m for ; Tue, 20 Sep 2011 04:50:51 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD8C21F8BF7 for ; Tue, 20 Sep 2011 04:50:51 -0700 (PDT) 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 p8KBrkks025313; Tue, 20 Sep 2011 07:53:46 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Sep 2011 07:52:53 -0400 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: Tue, 20 Sep 2011 17:22:50 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0E38@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: Acx3dc/q6XkjXS2uTcqq7kBUq/+VAQAE/+oA References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com><05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org><2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com><2E239D6FCD033C4BAF15F386A979BF510F0E12@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= X-OriginalArrivalTime: 20 Sep 2011 11:52:53.0815 (UTC) FILETIME=[D49D7470:01CC778B] Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 11:50:52 -0000 SGkgSW5ha2ksDQoNClBsZWFzZSByZWFkIGlubGluZS4NCg0KVGhhbmtzDQpQYXJ0aGENCg0KPi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogScOxYWtpIEJheiBDYXN0aWxsbyBbbWFp bHRvOmliY0BhbGlheC5uZXRdDQo+U2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDIwLCAyMDExIDI6 NDUgUE0NCj5UbzogUmF2aW5kcmFuIFBhcnRoYXNhcmF0aGkNCj5DYzogUm9tYW4gU2hwb3VudDsg UmFuZGVsbCBKZXN1cDsgcnRjd2ViQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtydGN3ZWJdIFJU Q1dlYiBkZWZhdWx0IHNpZ25hbGluZyBwcm90b2NvbCBbd2FzIFJFOiBBYm91dA0KPmRlZmluaW5n IGEgc2lnbmFsaW5nIHByb3RvY29sIGZvciBXZWJSVEMgKG9yIG5vdCldDQo+DQo+MjAxMS85LzIw IFJhdmluZHJhbiBQYXJ0aGFzYXJhdGhpIDxwcmF2aW5kcmFuQHNvbnVzbmV0LmNvbT46DQo+PiBJ IGhhdmUgYW5zd2VyZWQgdG8geW91IGluIHRoZSBhbm90aGVyIHRocmVhZA0KPihodHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNnMDExNzIuaHRtbCku IMKgSQ0KPnVuZGVyc3RhbmQgdGhhdCB0aGVyZSBhcmUgbG90IG9mIHRocmVhZCwgU28geW91IG1p Z2h0IGhhdmUgY29uZnVzZWQuDQo+DQo+SGkgUmF2aW5kcmFuLiBJdCBzZWVtcyB0aGF0IHlvdSBh dm9pZCByZXBseWluZyB0byB0aGUgcXVlc3Rpb25zIGluIG15DQo+cHJldmlvdXMgbWFpbCAoMyBw b2ludHMgeW91IGhhdmUgbmV2ZXIgYW5zd2VyZWQpLiBTYW1lIGFyZ3VtZW50cyB3YXMNCj5naXZl biBpbiB0aGUgdGhyZWFkIHlvdSBwb2ludCBhYm92ZSwgYWdhaW4gd2l0aG91dCByZXNwb25zZXMu IFdoeT8NCj4NCj4NCjxwYXJ0aGE+IFRoZSBpbnRlbnRpb24gaXMgbm90IHRvIGF2b2lkIHlvdXIg cXVlc3Rpb25zLiBJIGhhdmUgYW5zd2VyZWQgdGhlIHF1ZXN0aW9ucyB3aGljaCBhcmUgcmVsZXZh bnQgdG8gImRlZmF1bHQiIHZzICJub3RoaW5nIi4gRm9yIGV4YW1wbGUsIA0KDQoiMikgSWYgYnJv d3NlcnMgc3BlYWsgcHVyZSBTSVAgdGhlbiB0aGUgc2VydmVyIHNpZGUgTVVTVCBhbHNvIHNwZWFr IFNJUC4gSG93IHRvIGFjY29tcGxpc2ggd2l0aCB0aGF0IGluIHNoYXJlZCB3ZWIgaG9zdGluZ3M/ IE11c3QgdGhlIHdlYiBhZG1pbnMgbGVhcm4gYWJvdXQgU0lQIGFuZCBpbnN0YWxsaW5nL2NvbmZp Z3VyaW5nIGEgT3BlblNFUi9LYW1haWxpby9PcGVuU0lQUy9TRVIgU0lQIHByb3h5L3JlZ2lzdHJh cj8gVGhpcyBxdWVzdGlvbiBoYXMgYmVlbiBtYWRlIHNldmVyYWwgdGltZXMgaW4gc29tZSB0aHJl YWRzLiBObyByZXBseSB5ZXQgKHNhbWUgb2NjdXJzIHdpdGggb3RoZXIgZ2l2ZW4gYXJndW1lbnRz KS4iIA0KDQpJdCBpcyB0aGUgcXVlc3Rpb24gb24gU0lQIGRlcGxveW1lbnQgaXNzdWUgZm9yIHdl YiBhZG1pbiBhbmQgaXQgaGFzIG5vIHJlbGV2YW5jZSB0byAiZGVmYXVsdCIgdnMgIm5vdGhpbmci IHNpZ25hbGluZyBwcm90b2NvbCBpbiBSVENXZWIgY2xpZW50LiANCg0KQXBhcnQgZnJvbSB0aGlz LCBjb3VwbGUgb2YgcXVlc3Rpb25zIGFyZSBjaXJjbGVkIGluIGRpZmZlcmVudCB0aHJlYWRzIGFu ZCByZXBseSBoYXMgdG8gYmUgcHJvcGFnYXRlZCBhZ2FpbiBiZWNhdXNlIG9mIHRoZSBkaXNjb250 aW51aXR5IGluIHRoZSB0aHJlYWQgYnV0IHRoZXJlIGlzIG5vIGNvbmNsdXNpb24uIEknbSBhZnJh aWQgdGhhdCBpdCBtYXkgZGlsdXRlIHRoZSBkaXNjdXNzaW9uLiBJdCBpcyB0aGUgbWFpbiBtb3Rp dmF0aW9uIGZvciBtZSB0byB3cml0ZSB0aGUgdGV4dCByYXRoZXIgdGhhbiBoYW5kbGluZyBpbiBl LW1haWwgdGhyZWFkIGFsaWFzLiA8L3BhcnRoYT4NCg0KPj4gU0lQIG9yIFhNUFAgYmFzZWQgcHJv dG9jb2wgd2lsbCBiZSBzZWxlY3RlZCBhcyBhIGRlZmF1bHQgcHJvdG9jb2wNCj5iYXNlZCBvbiB0 ZWNobmljYWwgbWVyaXQgb2YgYSBnaXZlbiBSVENXZWIgc2lnbmFsaW5nIHByb2JsZW0gYnV0IGl0 IGlzIGENCj5zZWNvbmQgc3RhZ2UuDQo+DQo+V2hhdCBkb2VzIGl0IG1lYW4gIlNJUCBvciBYTVBQ IGJhc2VkIHByb3RvY29sIHdpbGwgYmUgc2VsZWN0ZWQgYXMgYQ0KPmRlZmF1bHQgcHJvdG9jb2wg Wy4uLl0iPyBBbnlvbmUgcmVhZGluZyB5b3VyIG1haWxzIHdvdWxkIGFzc3VtZSB0aGF0DQo+c3Vj aCBhIGRlY2lzaW9uIGlzIGFscmVhZHkgdGFrZW4uDQoNCjxwYXJ0aGE+ICBJIGNvdWxkIG5vdCBp bWFnaW5lIGhvdyB0byB5b3UgYXNzdW1lIHRoYXQgZGVmYXVsdCBwcm90b2NvbCBkZWNpc2lvbiBp cyBhbHJlYWR5IHRha2VuIGJhc2VkIG9uIHRoZSBhYm92ZSBzdGF0ZW1lbnQgPC9wYXJ0aGE+DQoN CiBJcyBpdD8gd2hvIHRvb2sgaXQ/DQo+DQo+DQo+UmVnYXJkcy4NCj4NCj4tLQ0KPknDsWFraSBC YXogQ2FzdGlsbG8NCj48aWJjQGFsaWF4Lm5ldD4NCg== From christer.holmberg@ericsson.com Tue Sep 20 05:06: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 EF84921F8C1E for ; Tue, 20 Sep 2011 05:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 OwSEguKGhZT8 for ; Tue, 20 Sep 2011 05:06:23 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCE221F8BF8 for ; Tue, 20 Sep 2011 05:06:22 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-29-4e7882505d80 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EC.88.02839.052887E4; Tue, 20 Sep 2011 14:08:48 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 20 Sep 2011 14:08:48 +0200 From: Christer Holmberg To: Hadriel Kaplan , Harald Alvestrand Date: Tue, 20 Sep 2011 14:08:46 +0200 Thread-Topic: [rtcweb] Minimal SDP negotiation mechanism Thread-Index: AQHMdzYrM8NQBuqbMkGVQzMD9HmeUZVWLKng Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> In-Reply-To: <69262135-CF5D-4E79-85CD-82DFDC4250C0@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 12:06:24 -0000 Hi,=20 >In SIP it's possible to get two or more different answers=20 >back for one offer, due to forking. I'm not sure you=20 >want/need to handle that case, but it can and does=20 >in-practice happen in SIP. Whether we want the browser to support forking is one thing, and I guess it= much depends on whether we want to be able to do things on the media plane= during the early phase of a session establishment. But, at least the API needs to allow a JS SIP app to "replace" a previously= received SDP with a new one (if the SIP app, in the forking case, for exam= ple chooses to always use the latest received SDP answer). Regards, Christer >=20 > Also, in SIP it's technically possible to generate SDP which=20 > is neither an offer nor an answer, but is rather=20 > "capabilities". This is described in RFC 3264 section 9, and=20 > used in responses to SIP OPTIONS requests by some devices. =20 > As Cullen noted in some earlier email in the mailing list,=20 > this could probably be hacked around with a fake SDP answer=20 > or error, but ya may want to keep things clean and just=20 > handle this case explicitly instead. >=20 > -hadriel >=20 >=20 > On Sep 19, 2011, at 12:59 PM, Harald Alvestrand wrote: >=20 > > I am looking at the WEBRTC API spec, which specifies a=20 > rudimentary negotiation framework: SDP objects prefixed by=20 > the string "SDP". > >=20 > > It seems clear to me that this needs at least information=20 > about whether something is an offer or an answer, and some=20 > way to complete the transaction when an offer is sent and=20 > something prevents it from completing. > > Until we know we need more, what about the following, to be=20 > specified in the WEBRTC API? > >=20 > > SDP objects are sent through the API, prefixed with either of > >=20 > > SDP OFFER > > SDP ANSWER > >=20 > > Alternatively, one can pass > >=20 > > SDP ERROR > >=20 > > to reply to an SDP OFFER when something goes wrong. > >=20 > > If one gets an OFFER and sends out an ANSWER, state changes. > > If OFFER gets an ANSWER back, state changes. > > In all other cases, state is as before. > >=20 > > We need to handle glare - when one sends an OFFER and gets=20 > back an OFFER, reply with SDP ERROR, enter a "glare" state,=20 > wait a bit, and send out an offer again. > >=20 > > Do we really have to have anything else? > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From emil@sip-communicator.org Tue Sep 20 05:09: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 629AE21F8C4C for ; Tue, 20 Sep 2011 05:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 JL3SEiCaqUTB for ; Tue, 20 Sep 2011 05:09:12 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3A421F8C1E for ; Tue, 20 Sep 2011 05:09:11 -0700 (PDT) Received: by wyg24 with SMTP id 24so524179wyg.31 for ; Tue, 20 Sep 2011 05:11:37 -0700 (PDT) Received: by 10.216.230.223 with SMTP id j73mr912740weq.39.1316520697190; Tue, 20 Sep 2011 05:11:37 -0700 (PDT) Received: from pastropnet.u-strasbg.fr (pastropnet.u-strasbg.fr. [130.79.90.87]) by mx.google.com with ESMTPS id gd6sm2037667wbb.1.2011.09.20.05.11.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 05:11:36 -0700 (PDT) Message-ID: <4E7882F6.3080604@jitsi.org> Date: Tue, 20 Sep 2011 14:11:34 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; bg; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: Magnus Westerlund References: <4E76E8E8.2050102@ericsson.com> In-Reply-To: <4E76E8E8.2050102@ericsson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 12:09:13 -0000 Hey there, I support both A and B. I'd also be OK if they were optional (as far as that's verifiable by remote peers of course). Cheers, Emil =D0=9D=D0=B0 19.09.11 09:02, Magnus Westerlund =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: > WG, >=20 > There where some discussion in the Interim meeting last week about a > Screen/Application/Desktop sharing support use case. My take away from > the discussion is that this use cases is likely well enough understood > to actually start a consensus call now. However, to us WG chairs it was= > clear that the use case in question actually needs to be split into two= > parts. >=20 > A) Where the RTCWEB enabled browser can use a local application window,= > the whole desktop or a Screen as a media source that can be encoded and= > transported over the peerConnection for displaying/playback at the peer= =2E > > B) Where a remote peer can provide one or more input types such as mous= e > and keyboard to control the local system, not only including the > browser, but also other operating system resources. This clearly can > only happen after additional consent, most likely on a per occasion > consent. > > My interpretation is that A only allows for application sharing in > conferencing contexts, like in the WEBEX session the Interim meeting wa= s > held with where we shared slides. Where the combination of A and B is > providing for VNC/Remote desktop. >=20 > Thus the question to the WG is the following. >=20 > 1) Do you support or object the inclusion of use case A, B or Both in > our Use case document? > > 2) Do you have additional comments for or against either of the use cas= es? >=20 >=20 > As WG chair >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 http://jitsi.org FAX: +33.1.77.62.47.31 From emil@sip-communicator.org Tue Sep 20 05:09: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 B5EE021F8C5B for ; Tue, 20 Sep 2011 05:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 y2GIkT3e-Y3d for ; Tue, 20 Sep 2011 05:09:20 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 936AE21F8C5A for ; Tue, 20 Sep 2011 05:09:19 -0700 (PDT) Received: by wwf22 with SMTP id 22so438820wwf.13 for ; Tue, 20 Sep 2011 05:11:44 -0700 (PDT) Received: by 10.216.19.75 with SMTP id m53mr728624wem.73.1316520704169; Tue, 20 Sep 2011 05:11:44 -0700 (PDT) Received: from pastropnet.u-strasbg.fr (pastropnet.u-strasbg.fr. [130.79.90.87]) by mx.google.com with ESMTPS id j18sm2026478wbo.6.2011.09.20.05.11.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 05:11:43 -0700 (PDT) Message-ID: <4E7882FE.7030408@jitsi.org> Date: Tue, 20 Sep 2011 14:11:42 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; bg; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: Harald Alvestrand References: <4E76E8E8.2050102@ericsson.com> <4E76EF3A.4010500@alvestrand.no> In-Reply-To: <4E76EF3A.4010500@alvestrand.no> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 12:09:24 -0000 Hey Harald, =D0=9D=D0=B0 19.09.11 09:28, Harald Alvestrand =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: >> B) Where a remote peer can provide one or more input types such as mou= se >> and keyboard to control the local system, not only including the >> browser, but also other operating system resources. This clearly can >> only happen after additional consent, most likely on a per occasion >> consent. > I see this as a more tricky thing to get right (in most apps, the=20 > mixing of events from multiple sources depends strongly on both proper = > timing/sequencing and reliable delivery). I would like to not address=20 > this for now (RTCWeb version 1). I wouldn't be that worried about this. From the feedback we are getting from our implementation, users don't seem to mind asynchronous even delivery that much. They simply expect remote control to lag a little bit when interacting with a remote desktop. Cheers, Emil -- http://jitsi.org From emil@sip-communicator.org Tue Sep 20 05:10: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 3714D21F8C39 for ; Tue, 20 Sep 2011 05:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Vmmg9IM1uMWD for ; Tue, 20 Sep 2011 05:10:19 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4854921F8C2F for ; Tue, 20 Sep 2011 05:10:19 -0700 (PDT) Received: by wyg24 with SMTP id 24so524967wyg.31 for ; Tue, 20 Sep 2011 05:12:23 -0700 (PDT) Received: by 10.216.187.201 with SMTP id y51mr746286wem.95.1316520743504; Tue, 20 Sep 2011 05:12:23 -0700 (PDT) Received: from pastropnet.u-strasbg.fr (pastropnet.u-strasbg.fr. [130.79.90.87]) by mx.google.com with ESMTPS id ev5sm2015729wbb.11.2011.09.20.05.12.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 05:12:22 -0700 (PDT) Message-ID: <4E788325.4030004@jitsi.org> Date: Tue, 20 Sep 2011 14:12:21 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; bg; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: "Olle E. Johansson" References: <4E76E8E8.2050102@ericsson.com> <4E76EF3A.4010500@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 12:10:20 -0000 =D0=9D=D0=B0 19.09.11 09:50, Olle E. Johansson =D0=BD=D0=B0=D0=BF=D0=B8=D1= =81=D0=B0: >>> B) Where a remote peer can provide one or more input types such >>> as mouse and keyboard to control the local system, not only >>> including the browser, but also other operating system resources. >>> This clearly can only happen after additional consent, most >>> likely on a per occasion consent. >> I see this as a more tricky thing to get right (in most apps, the >> mixing of events from multiple sources depends strongly on both >> proper timing/sequencing and reliable delivery). I would like to >> not address this for now (RTCWeb version 1). > I think it's a good use case for the data channel. How many such use > cases do we have? While use case A is quite often handled as a normal > video stream, use case B is likely something like VNC. This is an > application that is part of Microsoft Lync as well as the free SIP > client Blink today. I don't see both as having separate implementations. We could very well have browsers stream the desktop as a regular video flow in one direction and then add to that (or not) user feedback in the opposite direction. The feedback could go over signalling (which is what we are doing in Jitsi), over RTP (something like RFC 4733's DTMF) or over Pseudo TCP. Either way I think it's something quite important and I don't think there's a good reason to leave it for later. I would be happy to work on that. Cheers, Emil --=20 http://jitsi.org From ibc@aliax.net Tue Sep 20 05:13: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 51D3321F8C4B for ; Tue, 20 Sep 2011 05:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 KRBRe97Zd36w for ; Tue, 20 Sep 2011 05:13:45 -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 35FBB21F8B0F for ; Tue, 20 Sep 2011 05:13:44 -0700 (PDT) Received: by vws5 with SMTP id 5so730526vws.31 for ; Tue, 20 Sep 2011 05:16:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.9.129 with SMTP id l1mr179843vcl.87.1316520968951; Tue, 20 Sep 2011 05:16:08 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Tue, 20 Sep 2011 05:16:08 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 20 Sep 2011 14:16:08 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 12:13:46 -0000 2011/9/20 Christer Holmberg : > Whether we want the browser to support forking is one thing, and I guess = it much depends on whether we want to be able to do things on the media pla= ne during the early phase of a session establishment. I hope. If not, let's forget about integrating WebRTC in any telephony environment. The point here is that *media sessions* are "independant" of signaling. If we make WebRTC just to deal with media plane, the signaling (coded in JavaScript by a custom or native library) could handle early media sessions with no problem. But if we impose a signaling protocol (built-in within the browser WebRTC stack) then we'll be limited to adopted design constrains, which is not good. > But, at least the API needs to allow a JS SIP app to "replace" a previous= ly received SDP with a new one (if the SIP app, in the forking case, for ex= ample chooses to always use the latest received SDP answer). There is no a magic solution for that case: which media to render when parallel forking occurs and more than one branch replies a 180/183 with SDP? Note that "199" response tries to "help" a bit: "SIP Response Code for Indication of Terminated Dialog" http://tools.ietf.org/html/rfc6228 If we let it at the JS application level, the developer could handle those cases and decide which media session to render. BTW: would be possible to render various at the same time by mixing the incoming audio?. Regards. --=20 I=C3=B1aki Baz Castillo From harald@alvestrand.no Tue Sep 20 05: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 44EF521F8C45 for ; Tue, 20 Sep 2011 05:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.632 X-Spam-Level: X-Spam-Status: No, score=-108.632 tagged_above=-999 required=5 tests=[AWL=1.967, 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 riUAcuhxYEbA for ; Tue, 20 Sep 2011 05:15:03 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 99A0821F8C3D for ; Tue, 20 Sep 2011 05:15:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EE43839E0BC; Tue, 20 Sep 2011 14:17:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDJGvDkrdWkX; Tue, 20 Sep 2011 14:17:28 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 53A3A39E08A; Tue, 20 Sep 2011 14:17:28 +0200 (CEST) Message-ID: <4E788458.1090108@alvestrand.no> Date: Tue, 20 Sep 2011 14:17:28 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Christer Holmberg References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 12:15:04 -0000 On 09/20/11 14:08, Christer Holmberg wrote: > Hi, > >> In SIP it's possible to get two or more different answers >> back for one offer, due to forking. I'm not sure you >> want/need to handle that case, but it can and does >> in-practice happen in SIP. > Whether we want the browser to support forking is one thing, and I guess it much depends on whether we want to be able to do things on the media plane during the early phase of a session establishment. I think we need to do all the transforms we need to do. It would be great if there was a consistent set of things we are required to be able to do. If a JS app wants to support forking, I think it's reasonable to leave it to the JS which answer it wants to pass on to the PeerConnection object. When we get multiple ANSWERs like this, is there any information from the first ANSWER that needs to be preserved after the second ANSWER has arrived? (I really hope that the answer is a really clear NO...) > But, at least the API needs to allow a JS SIP app to "replace" a previously received SDP with a new one (if the SIP app, in the forking case, for example chooses to always use the latest received SDP answer). We might get SIP compatibility if we decide that SDP ANSWER can be received at any time, changes the state of the connection, and never generates a response. SDP ANSWER is now an one-way offer/answer. From jmillan@aliax.net Tue Sep 20 05:33: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 156A721F8C4D for ; Tue, 20 Sep 2011 05:33:29 -0700 (PDT) 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.120, 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 C4BYQculUhXC for ; Tue, 20 Sep 2011 05:33:28 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 16BC621F8C45 for ; Tue, 20 Sep 2011 05:33:28 -0700 (PDT) Received: by iaby26 with SMTP id y26so720405iab.31 for ; Tue, 20 Sep 2011 05:35:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.0.221 with SMTP id 29mr1223440ibc.56.1316522079854; Tue, 20 Sep 2011 05:34:39 -0700 (PDT) Received: by 10.231.36.201 with HTTP; Tue, 20 Sep 2011 05:34:39 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0E12@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F0E12@sonusinmail02.sonusnet.com> Date: Tue, 20 Sep 2011 14:34:39 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: Ravindran Parthasarathi Content-Type: multipart/alternative; boundary=00151773d3d2e8a1a004ad5eae22 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 12:33:29 -0000 --00151773d3d2e8a1a004ad5eae22 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, 2011/9/20 Ravindran Parthasarathi > Hi Inaki, > > I have answered to you in the another thread ( > http://www.ietf.org/mail-archive/web/rtcweb/current/msg01172.html). I > understand that there are lot of thread, So you might have confused. To be honest, I'm also confused. You opened two new threads to respond to Sa=FAl and Tim respectively from the original one. > As I indicated in the earlier mail, I'll come up with the write up to > discuss the need for "RTCWeb default signaling protocol". That`s OK. Let's read it and discuss about it then. > Please note in the mail thread that there is no mention of SIP as a RTCWe= b > default signaling protocol. The argument is between "nothing" vs "default= " > signaling protocol. > Up to now, that 'default' you mean is not even a formal proposal. Thanks > SIP or XMPP based protocol will be selected as a default protocol based o= n > technical merit of a given RTCWeb signaling problem but it is a second > stage. > > Thanks > Partha > > >-----Original Message----- > >From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] > >Sent: Tuesday, September 20, 2011 1:39 PM > >To: Ravindran Parthasarathi > >Cc: Roman Shpount; Randell Jesup; rtcweb@ietf.org > >Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About > >defining a signaling protocol for WebRTC (or not)] > > > >2011/9/20 Ravindran Parthasarathi : > >> One of the main aim of the RTCWeb default signaling protocol is to > >make two > >> party real-time communication easy with less development effort for > >any web > >> developer. > > > >Hi, let me some comments please: > > > >1) "RTCWeb default signaling protocol" is not defined neither it > >exists. I would ask you for not talking about it as if it was already > >approved since that could become confusing for readers. Also, given > >other threads it's clear that most of the people here is contrary to a > >"RTCWeb default signaling protocol" or "SIP built-in the browser". > >They have also given good rationale across multiple threads. > > > >2) If browsers speak pure SIP then the server side MUST also speak > >SIP. How to accomplish with that in shared web hostings? Must the web > >admins learn about SIP and installing/configuring a > >OpenSER/Kamailio/OpenSIPS/SER SIP proxy/registrar? This question has > >been made several times in some threads. No reply yet (same occurs > >with other given arguments). > > > >3) Making the signaling path a separate flow means that the web server > >(so the web application in server side) would not be aware about > >sessions status. So if for example two users visit the same page and > >speak through their web browsers and later one of them logouts from > >the web, the server has no easy way to force the call termination. > >Neither a "forum-administrator" could reject an spammer from an audio > >conference room (or it would be hard to accomplish). In contrast, if > >the signaling is carried via HTTP/WebSocket, the logic is centralized > >and the server application would be aware of existing sessions. > > > > > >Best regards. > > > > > >-- > >I=F1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00151773d3d2e8a1a004ad5eae22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

2011/9/20 Ravindran Parthasarathi = <pravindran@sonusnet.com>
Hi Inaki,

I have answered to you in the another thread (http://w= ww.ietf.org/mail-archive/web/rtcweb/current/msg01172.html). =A0I unders= tand that there are lot of thread, So you might have confused.

To be honest, I'm also confused. You opened two new= threads to respond to Sa=FAl and Tim respectively from the original one.
=A0
=A0As I indicated in the earlier mail, I'll come up with the write up = to discuss the need for "RTCWeb default signaling protocol".

That`s OK. Let's read it and discuss about = it then. =A0

=A0
Please note in= the mail thread that there is no mention of SIP as a RTCWeb default signal= ing protocol. The argument is between "nothing" vs "default&= quot; signaling protocol.

Up to now, that 'default' you mean= is not even a formal proposal.


Tha= nks


SIP or XMPP based protocol will be selected as a default protocol based on = technical merit of a given RTCWeb signaling problem but it is a second stag= e.

Thanks
Partha

>-----Original Message-----
>From: I=F1aki Baz Castillo [mailto:ibc@aliax.net]
>Sent: Tuesday, September 20, 2011 1:39 PM
>To: Ravindran Parthasarathi
>Cc: Roman Shpount; Randell Jesup; rtcweb@ietf.org
>Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About<= br> >defining a signaling protocol for WebRTC (or not)]
>
>2011/9/20 Ravindran Parthasarathi <pravindran@sonusnet.= com>:
>> One of the main aim of the RTCWeb default signaling protocol is to=
>make two
>> party real-time communication easy with less development effort fo= r
>any web
>> developer.
>
>Hi, let me some comments please:
>
>1) "RTCWeb default signaling protocol" is not defined neither= it
>exists. I would ask you for not talking about it as if it was already >approved since that could become confusing for readers. Also, given
>other threads it's clear that most of the people here is contrary t= o a
>"RTCWeb default signaling protocol" or "SIP built-in the= browser".
>They have also given good rationale across multiple threads.
>
>2) If browsers speak pure SIP then the server side MUST also speak
>SIP. How to accomplish with that in shared web hostings? Must the web >admins learn about SIP and installing/configuring a
>OpenSER/Kamailio/OpenSIPS/SER SIP proxy/registrar? This question has >been made several times in some threads. No reply yet (same occurs
>with other given arguments).
>
>3) Making the signaling path a separate flow means that the web server<= br> >(so the web application in server side) would not be aware about
>sessions status. So if for example two users visit the same page and >speak through their web browsers and later one of them logouts from
>the web, the server has no easy way to force the call termination.
>Neither a "forum-administrator" could reject an spammer from = an audio
>conference room (or it would be hard to accomplish). In contrast, if >the signaling is carried via HTTP/WebSocket, the logic is centralized >and the server application would be aware of existing sessions.
>
>
>Best regards.
>
>
>--
>I=F1aki Baz Castillo
><ibc@aliax.net>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--00151773d3d2e8a1a004ad5eae22-- From christer.holmberg@ericsson.com Tue Sep 20 05:34: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 D91A521F8C6C for ; Tue, 20 Sep 2011 05:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.385 X-Spam-Level: X-Spam-Status: No, score=-6.385 tagged_above=-999 required=5 tests=[AWL=-0.086, 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 uYl+AkHdiHKZ for ; Tue, 20 Sep 2011 05:34:01 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1796221F8C19 for ; Tue, 20 Sep 2011 05:34:00 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-f4-4e7888cab7d5 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 75.FD.02839.AC8887E4; Tue, 20 Sep 2011 14:36:26 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 20 Sep 2011 14:36:25 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Tue, 20 Sep 2011 14:36:24 +0200 Thread-Topic: [rtcweb] Minimal SDP negotiation mechanism Thread-Index: Acx3jxSR/5BtZgBRS++4cnJ+QX60kAAAW/Kg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233F6F291@ESESSCMS0356.eemea.ericsson.se> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@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] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 12:34:02 -0000 Hi,=20 >> Whether we want the browser to support forking is one=20 >> thing, and I guess it much depends on whether we want to be=20 >> able to do things on the media plane during the early phase=20 >> of a session establishment. >=20 > I hope. If not, let's forget about integrating WebRTC in any=20 > telephony environment. >=20 > The point here is that *media sessions* are "independant" of=20 > signaling. If we make WebRTC just to deal with media plane,=20 > the signaling (coded in JavaScript by a custom or native=20 > library) could handle early media sessions with no problem. >=20 > But if we impose a signaling protocol (built-in within the=20 > browser WebRTC stack) then we'll be limited to adopted design=20 > constrains, which is not good. That's not what I am suggesting. But, forking also have impacts on the medi= a plane. >>But, at least the API needs to allow a JS SIP app to=20 >>"replace" a previously received SDP with a new one (if the=20 >>SIP app, in the forking case, for example chooses to always=20 >>use the latest received SDP answer). >=20 >There is no a magic solution for that case: which media to=20 >render when parallel forking occurs and more than one branch=20 >replies a 180/183 with SDP? The JS SIP app can decide that, but my point was that the JS SIP app needs = to be able to "replace" the SDP answer with anohter one (received on anothe= r early dialog) - *IF* it chooses to do so. > Note that "199" response tries to "help" a bit: >=20 > "SIP Response Code for Indication of Terminated Dialog" > http://tools.ietf.org/html/rfc6228 That's such a great piece of RFC :) And, it does help the JS SIP app to make a decission, but the API still nee= ds to allow to "replace" the SDP answer. >If we let it at the JS application level, the developer could=20 >handle those cases and decide which media session to render. Yes, the JS app can make the decision - but, again, the API still needs to = allow the JS app to enforce that decision. =20 >BTW: would be possible to render various at the same time by=20 >mixing the incoming audio?. Well, that is what my first question was more or less about. Regards, Christer From s.choi@daemon.or.kr Tue Sep 20 05:34: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 C96FC21F8C71 for ; Tue, 20 Sep 2011 05:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 PRDL2FPTSlx0 for ; Tue, 20 Sep 2011 05:34:22 -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 6A74A21F8C6C for ; Tue, 20 Sep 2011 05:34:22 -0700 (PDT) Received: by fxd18 with SMTP id 18so550598fxd.31 for ; Tue, 20 Sep 2011 05:36:46 -0700 (PDT) Received: by 10.223.38.196 with SMTP id c4mr1275962fae.32.1316522206351; Tue, 20 Sep 2011 05:36:46 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by mx.google.com with ESMTPS id f10sm1332381fac.14.2011.09.20.05.36.44 (version=SSLv3 cipher=OTHER); Tue, 20 Sep 2011 05:36:45 -0700 (PDT) Received: by bkaq10 with SMTP id q10so529445bka.31 for ; Tue, 20 Sep 2011 05:36:44 -0700 (PDT) Received: by 10.204.130.130 with SMTP id t2mr532489bks.223.1316522204221; Tue, 20 Sep 2011 05:36:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.205.81.10 with HTTP; Tue, 20 Sep 2011 05:36:24 -0700 (PDT) In-Reply-To: <4E787D56.8060106@alvestrand.no> References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <4E787D56.8060106@alvestrand.no> From: Soo-Hyun Choi Date: Tue, 20 Sep 2011 21:36:24 +0900 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 12:34:23 -0000 Harald, On Tue, Sep 20, 2011 at 20:47, Harald Alvestrand wrote: > > let's avoid unquantifiable terms in our discussions. "A little more careful" > is an unquantifiable term. > > If we want to say "I think the algorithm must guarantee that the bandwidth > estimate is updated within 1.5 seconds when the available bandwidth changes > from 2 Mbit/sec to 1 Mbit/sec", let's say something like that - focus on > what the requirements are. > > We can always be a little more careful. But it doesn't tell us when we're > close enough. > Sorry if my previous email looked that way to you (of course, I didn't mean to just pray for the mere hope). I was talking about some general CC principles in the high level for real-time interactive multimedia applications, like some of us did too in this thread. One of the critical metrics of a delay-based CC algo is an accurate measurement of inter-packet interval (IPI) and timely report of IPI to the sender so it can update the send rate correctly, which we all agreed in this email thread. Although everyone in this list seemed to aware of this, I have highlighted again that the relatively course-grained RTCP carrying the IPI measurement data can cause instability at the encoder's output bitrate due to the following reason. > I.e., Inaccurate BW estimation could lead into providing inaccurate > information about the available BW to the upper layer, which > eventually result in instability at the codec's encoding rate. So, my original question/suggestion was why not use AVPF (which is smaller packet than the standard RTCP) to generate/report more frequently to the sender in your algorithm. Or alternatively, I have already designed a window-version's of TFRC that re-introduces a TCP-like Ack-clocking, so-called TFWC (TCP-Friendly Window-based CC), which performs reasonably well (as good as TFRC) for the similar situations (RTC environment). I would like to ask to this list (or Harald) if suggesting alternative CC algo idea could fit into the RTCWEB Charter's scope - if so, I could elaborate more by writing an I-D or so. In the mean time, you could check my document at http://tfwc.hackerslab.eu/ if you are interested. Kind regards, Soo-Hyun From christer.holmberg@ericsson.com Tue Sep 20 05:40: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 2C17C21F8BAE for ; Tue, 20 Sep 2011 05:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 hkSTviS+KRpA for ; Tue, 20 Sep 2011 05:40:33 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 62E9A21F8B9F for ; Tue, 20 Sep 2011 05:40:33 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-f4-4e788a5270a9 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 28.1F.02839.25A887E4; Tue, 20 Sep 2011 14:42:58 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 20 Sep 2011 14:42:57 +0200 From: Christer Holmberg To: Harald Alvestrand Date: Tue, 20 Sep 2011 14:42:55 +0200 Thread-Topic: [rtcweb] Minimal SDP negotiation mechanism Thread-Index: Acx3j0RVhrNg2QYcS/OzKt07zeJ9CAAArFeA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> In-Reply-To: <4E788458.1090108@alvestrand.no> 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] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 12:40:34 -0000 Hi,=20 >> In SIP it's possible to get two or more different answers back for=20 >> one offer, due to forking. I'm not sure you want/need to=20 >> handle that=20 >> case, but it can and does in-practice happen in SIP. >> Whether we want the browser to support forking is one=20 >> thing, and I guess it much depends on whether we want to be=20 >> able to do things on the media plane during the early phase=20 >> of a session establishment. > I think we need to do all the transforms we need to do. It=20 > would be great if there was a consistent set of things we are=20 > required to be able to do. > If a JS app wants to support forking, I think it's reasonable=20 > to leave it to the JS which answer it wants to pass on to the=20 > PeerConnection object. When we get multiple ANSWERs like=20 > this, is there any information from the first ANSWER that=20 > needs to be preserved after the second ANSWER has arrived? (I=20 > really hope that the answer is a really clear NO...) The answers as such are independent from each other, so from that perspecti= ve the answer is NO :) The question is whether we want to allow actions to to take place on the me= dia plane before we know which early dialog will be part of the established= call. For example, you won't be able to perform resource reservation procedures f= or multiple early dialog if the browser only deals with one early dialog at= any given time. >> But, at least the API needs to allow a JS SIP app to=20 >> "replace" a previously received SDP with a new one (if the=20 >> SIP app, in the forking case, for example chooses to always=20 >> use the latest received SDP answer). > We might get SIP compatibility if we decide that SDP ANSWER=20 > can be received at any time, changes the state of the=20 > connection, and never generates a response. SDP ANSWER is now=20 > an one-way offer/answer. Doesn't the browser still need to know with which offer the answer is assoc= iated? Regards, Christer From harald@alvestrand.no Tue Sep 20 05:41: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 BF5EE21F84B3 for ; Tue, 20 Sep 2011 05:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.663 X-Spam-Level: X-Spam-Status: No, score=-108.663 tagged_above=-999 required=5 tests=[AWL=1.936, 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 2ynKV69QV-fP for ; Tue, 20 Sep 2011 05:41:48 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C979B21F84A9 for ; Tue, 20 Sep 2011 05:41:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3C9BD39E0BC; Tue, 20 Sep 2011 14:44:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TA4dZT76j8y; Tue, 20 Sep 2011 14:44:12 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 9313A39E08A; Tue, 20 Sep 2011 14:44:12 +0200 (CEST) Message-ID: <4E788A9C.40105@alvestrand.no> Date: Tue, 20 Sep 2011 14:44:12 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Soo-Hyun Choi References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <4E787D56.8060106@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] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 12:41:48 -0000 On 09/20/11 14:36, Soo-Hyun Choi wrote: > Harald, > > On Tue, Sep 20, 2011 at 20:47, Harald Alvestrand wrote: >> let's avoid unquantifiable terms in our discussions. "A little more careful" >> is an unquantifiable term. >> >> If we want to say "I think the algorithm must guarantee that the bandwidth >> estimate is updated within 1.5 seconds when the available bandwidth changes >> from 2 Mbit/sec to 1 Mbit/sec", let's say something like that - focus on >> what the requirements are. >> >> We can always be a little more careful. But it doesn't tell us when we're >> close enough. >> > Sorry if my previous email looked that way to you (of course, I didn't > mean to just pray for the mere hope). I was talking about some general > CC principles in the high level for real-time interactive multimedia > applications, like some of us did too in this thread. Sorry, not intended to point at anyone in particular - I have been worried about several conversations that seemed to be straying very far from the "brass tacks" here. > One of the critical metrics of a delay-based CC algo is an accurate > measurement of inter-packet interval (IPI) and timely report of IPI to > the sender so it can update the send rate correctly, which we all > agreed in this email thread. Although everyone in this list seemed to > aware of this, I have highlighted again that the relatively > course-grained RTCP carrying the IPI measurement data can cause > instability at the encoder's output bitrate due to the following > reason. The draft's suggestion is to avoid the need for communicating all the IPI information from the receiver to the sender by doing part of the processing and estimation at the receiver. I think we need to send the resulting information quickly when it changes, but don't need to send it so often when it remains stable. What "quickly" means in this context is a good question - 0.1 second? 1 second? Certainly less than 5 seconds? > >> I.e., Inaccurate BW estimation could lead into providing inaccurate >> information about the available BW to the upper layer, which >> eventually result in instability at the codec's encoding rate. > > So, my original question/suggestion was why not use AVPF (which is > smaller packet than the standard RTCP) to generate/report more > frequently to the sender in your algorithm. Or alternatively, I have > already designed a window-version's of TFRC that re-introduces a > TCP-like Ack-clocking, so-called TFWC (TCP-Friendly Window-based CC), > which performs reasonably well (as good as TFRC) for the similar > situations (RTC environment). > > I would like to ask to this list (or Harald) if suggesting alternative > CC algo idea could fit into the RTCWEB Charter's scope - if so, I > could elaborate more by writing an I-D or so. In the mean time, you > could check my document at http://tfwc.hackerslab.eu/ if you are > interested. I am certainly looking for input on where we can best have this discussion, too! Algorithm design is outside of RTCWEB's charter, but I think requirements/criteria for what "good enough" means for RTCWEB is inside it. From stefan.lk.hakansson@ericsson.com Tue Sep 20 05:56: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 D1F5B21F8C9B for ; Tue, 20 Sep 2011 05:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=-0.037, 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 YTOmkAKyVT4w for ; Tue, 20 Sep 2011 05:56:18 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id F34A421F8C97 for ; Tue, 20 Sep 2011 05:56:17 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-8b-4e788e01efae Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C1.F0.20773.10E887E4; Tue, 20 Sep 2011 14:58:41 +0200 (CEST) Received: from [150.132.141.36] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Sep 2011 14:58:40 +0200 Message-ID: <4E788E00.9020909@ericsson.com> Date: Tue, 20 Sep 2011 14:58:40 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E76E8E8.2050102@ericsson.com> In-Reply-To: <4E76E8E8.2050102@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 12:56:18 -0000 I think we should skip both these use cases for the time being. I think we have more than enough to design and agree on to get real-time audio and video (with recording) and p2p data. There are design choices to make and agree on all over the place (from user consent to RTP). Besides I think that the most obvious (WebEx-like if you want) use case for A is document sharing and slide presentations - and we all know that there are several such services available already. So the pieces to build them are already available. So my 2 cents say: let's push this into phase 2, and focus on getting phase 1 out in a timely manner :) Sorry for not being enthusiastic. On 2011-09-19 09:02, Magnus Westerlund wrote: > WG, > > There where some discussion in the Interim meeting last week about a > Screen/Application/Desktop sharing support use case. My take away from > the discussion is that this use cases is likely well enough understood > to actually start a consensus call now. However, to us WG chairs it was > clear that the use case in question actually needs to be split into two > parts. > > A) Where the RTCWEB enabled browser can use a local application window, > the whole desktop or a Screen as a media source that can be encoded and > transported over the peerConnection for displaying/playback at the peer. > > B) Where a remote peer can provide one or more input types such as mouse > and keyboard to control the local system, not only including the > browser, but also other operating system resources. This clearly can > only happen after additional consent, most likely on a per occasion > consent. > > My interpretation is that A only allows for application sharing in > conferencing contexts, like in the WEBEX session the Interim meeting was > held with where we shared slides. Where the combination of A and B is > providing for VNC/Remote desktop. > > Thus the question to the WG is the following. > > 1) Do you support or object the inclusion of use case A, B or Both in > our Use case document? > > 2) Do you have additional comments for or against either of the use cases? > > > As WG chair > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Frgatan 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 harald@alvestrand.no Tue Sep 20 05:57: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 5982321F8C15 for ; Tue, 20 Sep 2011 05:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.693 X-Spam-Level: X-Spam-Status: No, score=-108.693 tagged_above=-999 required=5 tests=[AWL=1.906, 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 vfPNDF5-VTK5 for ; Tue, 20 Sep 2011 05:57:48 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 724E521F8BF4 for ; Tue, 20 Sep 2011 05:57:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D54E939E0BC; Tue, 20 Sep 2011 15:00:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpJXIIqGuiUa; Tue, 20 Sep 2011 15:00:13 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 3D0A339E08A; Tue, 20 Sep 2011 15:00:13 +0200 (CEST) Message-ID: <4E788E5C.9090306@alvestrand.no> Date: Tue, 20 Sep 2011 15:00:12 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Christer Holmberg References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 12:57:49 -0000 On 09/20/11 14:42, Christer Holmberg wrote: > Hi, > >>> In SIP it's possible to get two or more different answers back for >>> one offer, due to forking. I'm not sure you want/need to >>> handle that >>> case, but it can and does in-practice happen in SIP. >>> Whether we want the browser to support forking is one >>> thing, and I guess it much depends on whether we want to be >>> able to do things on the media plane during the early phase >>> of a session establishment. >> I think we need to do all the transforms we need to do. It >> would be great if there was a consistent set of things we are >> required to be able to do. >> If a JS app wants to support forking, I think it's reasonable >> to leave it to the JS which answer it wants to pass on to the >> PeerConnection object. When we get multiple ANSWERs like >> this, is there any information from the first ANSWER that >> needs to be preserved after the second ANSWER has arrived? (I >> really hope that the answer is a really clear NO...) > The answers as such are independent from each other, so from that perspective the answer is NO :) > > The question is whether we want to allow actions to to take place on the media plane before we know which early dialog will be part of the established call. > > For example, you won't be able to perform resource reservation procedures for multiple early dialog if the browser only deals with one early dialog at any given time. I get a steady increase in my uneasiness here. A PeerConnection should (in my opinion) be about the connection between the browser and a single other endpoint, and the media transmitted between those two. Once we start requiring that the PeerConnection know the difference between "early" media and "late" media, it seems to me we're slipping down a slippery slope. From the standpoint of PeerConnections, it may make sense to treat a forked call as two PeerConnections rather than one - but in that case, we may have the need to be able to create a PeerConnection from another PeerConnection (duplicating state, and maybe sharing resources, which is ugly). Forking is hard, it seems. >>> But, at least the API needs to allow a JS SIP app to >>> "replace" a previously received SDP with a new one (if the >>> SIP app, in the forking case, for example chooses to always >>> use the latest received SDP answer). >> We might get SIP compatibility if we decide that SDP ANSWER >> can be received at any time, changes the state of the >> connection, and never generates a response. SDP ANSWER is now >> an one-way offer/answer. > Doesn't the browser still need to know with which offer the answer is associated? The browser (PeerConnection implementation) or the Javascript? That's a question I don't have an answer to. Is there any information in there where the browser would act differently if it knew which offer the answer was associatied to? I went over the offer/answer with Per Kjellander today; if we follow RFC 3264's recommendation of only having one outstanding offer at a time, we did not find any need to identify offers ("there can be only one") - if we can get into the situation where we get an answer after we've sent out a subsequent offer and gotten that answered, we may get a need for it. > Regards, > > Christer > > From oej@edvina.net Tue Sep 20 06: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 6418521F8C6B for ; Tue, 20 Sep 2011 06:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.007, 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 Z+--YDrXmJAG for ; Tue, 20 Sep 2011 06:05:26 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id CA87C21F8C5B for ; Tue, 20 Sep 2011 06:05:25 -0700 (PDT) Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id A7E2A754BCE4; Tue, 20 Sep 2011 13:07:48 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <4E788E5C.9090306@alvestrand.no> Date: Tue, 20 Sep 2011 15:07:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1244.3) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 13:05:26 -0000 20 sep 2011 kl. 15:00 skrev Harald Alvestrand: > Once we start requiring that the PeerConnection know the difference = between "early" media and "late" media, it seems to me we're slipping = down a slippery slope. The difference between early and late media is purely a billing decision = in PSTN. I don't think we should separate these on the rtcweb side. It's = a PSTN gateway issue, not something to be bothered with in rtcweb. "The campaign to simplify call states" /O= From christer.holmberg@ericsson.com Tue Sep 20 06:13: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 D08E521F8C33 for ; Tue, 20 Sep 2011 06:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 V9ayxcmlb5kz for ; Tue, 20 Sep 2011 06:13: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 0D02E21F8BD7 for ; Tue, 20 Sep 2011 06:13:33 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-02-4e78920e80cd Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E6.D5.02839.E02987E4; Tue, 20 Sep 2011 15:15:58 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 20 Sep 2011 15:15:58 +0200 From: Christer Holmberg To: "Olle E. Johansson" , Harald Alvestrand Date: Tue, 20 Sep 2011 15:15:56 +0200 Thread-Topic: [rtcweb] Minimal SDP negotiation mechanism Thread-Index: Acx3lk2e7TgaS9nSQpaTg0AHLLwYwwAAMO7w Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233F6F2EB@ESESSCMS0356.eemea.ericsson.se> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> In-Reply-To: <11209B22-4D96-4367-BC31-A4D586B55A83@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 13:13:34 -0000 Hi,=20 >> Once we start requiring that the PeerConnection know the=20 >> difference between "early" media and "late" media, it seems=20 >> to me we're slipping down a slippery slope. >=20 >The difference between early and late media is purely a=20 >billing decision in PSTN. I don't think we should separate=20 >these on the rtcweb side. It's a PSTN gateway issue, not=20 >something to be bothered with in rtcweb. It's not about knowing the difference between "early" and "late" media - it= 's about whether the API and browser need to support multiple SIMULTANOUS S= DP answers - or whether we assume that the JS SIP app will always, at any g= iven time, only provide ONE SDP answer to the API and browser. Regards, Christer From ibc@aliax.net Tue Sep 20 06:21: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 73FCA21F8CA7 for ; Tue, 20 Sep 2011 06:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 BJ4BgK93N9DE for ; Tue, 20 Sep 2011 06:21:19 -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 E381121F8CA1 for ; Tue, 20 Sep 2011 06:21:18 -0700 (PDT) Received: by vws5 with SMTP id 5so798444vws.31 for ; Tue, 20 Sep 2011 06:23:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.69.18 with SMTP id a18mr611841vdu.430.1316525023456; Tue, 20 Sep 2011 06:23:43 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Tue, 20 Sep 2011 06:23:43 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F6F291@ESESSCMS0356.eemea.ericsson.se> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233F6F291@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 20 Sep 2011 15:23:43 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 13:21:19 -0000 2011/9/20 Christer Holmberg : > The JS SIP app can decide that, but my point was that the JS SIP app need= s to be able to "replace" the SDP answer with anohter one (received on anot= her early dialog) - *IF* it chooses to do so. Sure. That must be designed by the signaling layer. What I hope is that such signaling layer is up to the JS code (optionally in form of custom code or a given WebRTC JS API). --=20 I=C3=B1aki Baz Castillo From magnus.westerlund@ericsson.com Tue Sep 20 06: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 B4DF821F8520 for ; Tue, 20 Sep 2011 06:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 Dt53n7pkQc+K for ; Tue, 20 Sep 2011 06:22:13 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id EB85821F8514 for ; Tue, 20 Sep 2011 06:22:12 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-30-4e7894150ae3 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 28.87.02839.514987E4; Tue, 20 Sep 2011 15:24:37 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Sep 2011 15:24:36 +0200 Message-ID: <4E78940C.4040405@ericsson.com> Date: Tue, 20 Sep 2011 15:24:28 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <4E777500.5030201@alvestrand.no> In-Reply-To: <4E777500.5030201@alvestrand.no> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 13:22:13 -0000 On 2011-09-19 18:59, Harald Alvestrand wrote: > We need to handle glare - when one sends an OFFER and gets back an > OFFER, reply with SDP ERROR, enter a "glare" state, wait a bit, and send > out an offer again. > I think that is a bad design for glare handling. I agree it needs to be handled. I think the ICE version of glare handling could work pretty well here. Any offer needs to include a random 32 bit number. If the end-point receive an offer in relation to a peer-connection while it has an outstanding offer then it compares these codes. Who ever has the greatest numerical value wins and that offer is handled the other is responded with an error stating GLARE. Thus there is no extra delay and more clear resolution of the glare case. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From lorenzo@meetecho.com Tue Sep 20 06:27: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 6164A21F8BE4 for ; Tue, 20 Sep 2011 06:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 K299l8hJ8IOQ for ; Tue, 20 Sep 2011 06:27:11 -0700 (PDT) Received: from smtplq01.aruba.it (smtplq-out17.aruba.it [62.149.158.37]) by ietfa.amsl.com (Postfix) with SMTP id 1519F21F8B74 for ; Tue, 20 Sep 2011 06:27:10 -0700 (PDT) Received: (qmail 14916 invoked by uid 89); 20 Sep 2011 13:29:34 -0000 Received: from unknown (HELO smtp2.aruba.it) (62.149.158.222) by smtplq01.aruba.it with SMTP; 20 Sep 2011 13:29:34 -0000 Received: (qmail 16031 invoked by uid 89); 20 Sep 2011 13:29:34 -0000 Received: from unknown (HELO lminiero-acer) (lorenzo@meetecho.com@143.225.229.166) by smtp2.ad.aruba.it with SMTP; 20 Sep 2011 13:29:34 -0000 Date: Tue, 20 Sep 2011 15:25:02 +0200 From: Lorenzo Miniero To: Stefan =?ISO-8859-1?B?SOVrYW5zc29u?= LK Message-ID: <20110920152502.62f06c61@lminiero-acer> In-Reply-To: <4E788E00.9020909@ericsson.com> References: <4E76E8E8.2050102@ericsson.com> <4E788E00.9020909@ericsson.com> Organization: Meetecho X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.0; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Rating: smtp2.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 13:27:12 -0000 +1, let's not put too many things together. Lorenzo Il giorno Tue, 20 Sep 2011 14:58:40 +0200 Stefan H=E5kansson LK ha scritto: > I think we should skip both these use cases for the time being. >=20 > I think we have more than enough to design and agree on to get > real-time audio and video (with recording) and p2p data. There are > design choices to make and agree on all over the place (from user > consent to RTP). >=20 > Besides I think that the most obvious (WebEx-like if you want) use > case for A is document sharing and slide presentations - and we all > know that there are several such services available already. So the > pieces to build them are already available. >=20 > So my 2 cents say: let's push this into phase 2, and focus on getting=20 > phase 1 out in a timely manner :) Sorry for not being enthusiastic. >=20 > On 2011-09-19 09:02, Magnus Westerlund wrote: > > WG, > > > > There where some discussion in the Interim meeting last week about a > > Screen/Application/Desktop sharing support use case. My take away > > from the discussion is that this use cases is likely well enough > > understood to actually start a consensus call now. However, to us > > WG chairs it was clear that the use case in question actually needs > > to be split into two parts. > > > > A) Where the RTCWEB enabled browser can use a local application > > window, the whole desktop or a Screen as a media source that can be > > encoded and transported over the peerConnection for > > displaying/playback at the peer. > > > > B) Where a remote peer can provide one or more input types such as > > mouse and keyboard to control the local system, not only including > > the browser, but also other operating system resources. This > > clearly can only happen after additional consent, most likely on a > > per occasion consent. > > > > My interpretation is that A only allows for application sharing in > > conferencing contexts, like in the WEBEX session the Interim > > meeting was held with where we shared slides. Where the combination > > of A and B is providing for VNC/Remote desktop. > > > > Thus the question to the WG is the following. > > > > 1) Do you support or object the inclusion of use case A, B or Both > > in our Use case document? > > > > 2) Do you have additional comments for or against either of the use > > cases? > > > > > > As WG chair > > > > Magnus Westerlund > > > > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From oej@edvina.net Tue Sep 20 06:38: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 6062621F8C71 for ; Tue, 20 Sep 2011 06:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.007, 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 4RykThuD+zZR for ; Tue, 20 Sep 2011 06:38:28 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id B588421F8C5D for ; Tue, 20 Sep 2011 06:38:28 -0700 (PDT) Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 76849754BCE4; Tue, 20 Sep 2011 13:40:10 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F6F2EB@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 20 Sep 2011 15:40:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A61D589-1C23-4364-AA4A-60338D8C5859@edvina.net> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2EB@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1244.3) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 13:38:29 -0000 20 sep 2011 kl. 15:15 skrev Christer Holmberg: >=20 > Hi,=20 >=20 >>> Once we start requiring that the PeerConnection know the=20 >>> difference between "early" media and "late" media, it seems=20 >>> to me we're slipping down a slippery slope. >>=20 >> The difference between early and late media is purely a=20 >> billing decision in PSTN. I don't think we should separate=20 >> these on the rtcweb side. It's a PSTN gateway issue, not=20 >> something to be bothered with in rtcweb. >=20 > It's not about knowing the difference between "early" and "late" media = - it's about whether the API and browser need to support multiple = SIMULTANOUS SDP answers - or whether we assume that the JS SIP app will = always, at any given time, only provide ONE SDP answer to the API and = browser. I just wanted to get rid of the early/late media discussion. As you = state, the forking issue with getting multiple responses is a separate = issue. Do we have any use cases using forking? Is forking a desired feature or = something that SIP brought in? To give an example to those of you with no SIP history: In SIP you can send one OFFER and get multiple ANSWERs in 200 OK from = different devices. This means that you actually have multiple calls and = need to hang up all of those that you do not want, or just mix them = somehow and live with it.=20 With early media, it gets even more confusing, because you will get an = SDP answer before the call is in up state (in 180/183 response) then = another SDP answer from another device at 200 OK. In this case you have = an early dialog with early media with the device sending the first = answer, a dialog that terminates at 200 OK.=20 Supporting this behaviour adds complexity. And not all SIP devices = support these situations properly, as we've proven at SIPit testing.=20 Which leads to an unshameful plug: SIPit in Monaco is now open for = registration - for all SIP developers to attend :-) /O From magnus.westerlund@ericsson.com Tue Sep 20 07:26: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 9470921F8C7E for ; Tue, 20 Sep 2011 07:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.517 X-Spam-Level: X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 Q0rq4uA1Irmo for ; Tue, 20 Sep 2011 07:26:05 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A948821F8C77 for ; Tue, 20 Sep 2011 07:26:04 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-66-4e78a30df073 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.115.81]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 44.B2.02839.D03A87E4; Tue, 20 Sep 2011 16:28:30 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Sep 2011 16:28:20 +0200 Message-ID: <4E78A302.7030700@ericsson.com> Date: Tue, 20 Sep 2011 16:28:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E76E8E8.2050102@ericsson.com> In-Reply-To: <4E76E8E8.2050102@ericsson.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 14:26:05 -0000 I will conclude this call next week on Monday after a week. Based on the response rate already, I don't see much need for a longer time interval for the call. Cheers Magnus On 2011-09-19 09:02, Magnus Westerlund wrote: > WG, > > There where some discussion in the Interim meeting last week about a > Screen/Application/Desktop sharing support use case. My take away from > the discussion is that this use cases is likely well enough understood > to actually start a consensus call now. However, to us WG chairs it was > clear that the use case in question actually needs to be split into two > parts. > > A) Where the RTCWEB enabled browser can use a local application window, > the whole desktop or a Screen as a media source that can be encoded and > transported over the peerConnection for displaying/playback at the peer. > > B) Where a remote peer can provide one or more input types such as mouse > and keyboard to control the local system, not only including the > browser, but also other operating system resources. This clearly can > only happen after additional consent, most likely on a per occasion > consent. > > My interpretation is that A only allows for application sharing in > conferencing contexts, like in the WEBEX session the Interim meeting was > held with where we shared slides. Where the combination of A and B is > providing for VNC/Remote desktop. > > Thus the question to the WG is the following. > > 1) Do you support or object the inclusion of use case A, B or Both in > our Use case document? > > 2) Do you have additional comments for or against either of the use cases? > > > As WG chair > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Frgatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From emil@sip-communicator.org Tue Sep 20 07:31: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 4985F21F8531 for ; Tue, 20 Sep 2011 07:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uz1GNKrmC6xl for ; Tue, 20 Sep 2011 07:31:53 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA7021F8532 for ; Tue, 20 Sep 2011 07:31:53 -0700 (PDT) Received: by bkaq10 with SMTP id q10so645683bka.31 for ; Tue, 20 Sep 2011 07:34:18 -0700 (PDT) Received: by 10.204.136.220 with SMTP id s28mr616225bkt.152.1316529258506; Tue, 20 Sep 2011 07:34:18 -0700 (PDT) Received: from pastropnet.u-strasbg.fr ([2001:660:4701:1001:d9e:622a:e238:3c32]) by mx.google.com with ESMTPS id d1sm1782302bku.1.2011.09.20.07.34.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 07:34:17 -0700 (PDT) Message-ID: <4E78A467.7040409@jitsi.org> Date: Tue, 20 Sep 2011 16:34:15 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; bg; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= References: <4E76E8E8.2050102@ericsson.com> <4E788E00.9020909@ericsson.com> In-Reply-To: <4E788E00.9020909@ericsson.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 14:31:54 -0000 =D0=9D=D0=B0 20.09.11 14:58, Stefan H=C3=A5kansson LK =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0: > I think we should skip both these use cases for the time being. >=20 > I think we have more than enough to design and agree on to get real-tim= e=20 > audio and video (with recording) and p2p data. There are design choices= =20 > to make and agree on all over the place (from user consent to RTP). I am not sure I understand the we-already-have-too-much-on-our-plate argument. If Desktop Sharing is declared optional then the specification could move at its own pace without blocking other specs or implementation= s. > Besides I think that the most obvious (WebEx-like if you want) use case= =20 > for A is document sharing and slide presentations - and we all know tha= t=20 > there are several such services available already. So the pieces to=20 > build them are already available. We already have more than several ways of doing VoIP and video calls, many of which already work in browsers. Obviously, the argument hasn't prevented us from starting RTCWEB. Emil >=20 > So my 2 cents say: let's push this into phase 2, and focus on getting=20 > phase 1 out in a timely manner :) Sorry for not being enthusiastic. >=20 > On 2011-09-19 09:02, Magnus Westerlund wrote: >> WG, >> >> There where some discussion in the Interim meeting last week about a >> Screen/Application/Desktop sharing support use case. My take away from= >> the discussion is that this use cases is likely well enough understood= >> to actually start a consensus call now. However, to us WG chairs it wa= s >> clear that the use case in question actually needs to be split into tw= o >> parts. >> >> A) Where the RTCWEB enabled browser can use a local application window= , >> the whole desktop or a Screen as a media source that can be encoded an= d >> transported over the peerConnection for displaying/playback at the pee= r. >> >> B) Where a remote peer can provide one or more input types such as mou= se >> and keyboard to control the local system, not only including the >> browser, but also other operating system resources. This clearly can >> only happen after additional consent, most likely on a per occasion >> consent. >> >> My interpretation is that A only allows for application sharing in >> conferencing contexts, like in the WEBEX session the Interim meeting w= as >> held with where we shared slides. Where the combination of A and B is >> providing for VNC/Remote desktop. >> >> Thus the question to the WG is the following. >> >> 1) Do you support or object the inclusion of use case A, B or Both in >> our Use case document? >> >> 2) Do you have additional comments for or against either of the use ca= ses? >> >> >> As WG chair >> >> 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 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 http://jitsi.org FAX: +33.1.77.62.47.31 From magnus.westerlund@ericsson.com Tue Sep 20 07:34: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 4CB3D21F8C6A for ; Tue, 20 Sep 2011 07:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.517 X-Spam-Level: X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 1mnznjJJ6WQV for ; Tue, 20 Sep 2011 07:34:19 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8292021F8548 for ; Tue, 20 Sep 2011 07:34:19 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-65-4e78a4fc08b2 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6D.C2.20773.CF4A87E4; Tue, 20 Sep 2011 16:36:44 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Tue, 20 Sep 2011 16:36:44 +0200 Message-ID: <4E78A4FB.1050504@ericsson.com> Date: Tue, 20 Sep 2011 16:36:43 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> <4E77949B.4010603@alvestrand.no> In-Reply-To: <4E77949B.4010603@alvestrand.no> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 14:34:20 -0000 On 2011-09-19 21:14, Harald Alvestrand wrote: > On 09/19/2011 06:00 PM, Magnus Westerlund wrote: >> We need to standardize a number of Transport protocol functionalities >> for the RTCWEB data transport solution. To the degree that I do like to >> resurface some of my earlier suggestions around this. Why not use DCCP >> with TFRC or TCP like congestion control tunneled over UDP. >> >> The whole specification is ready. Which avoids any hiccup with the >> transport people and IESG. > The last few times this has surfaced, the conversation has turned > suddenly silent when I've asked where to find a DCCP-over-TFRC stack I > can experiment with.... are there any out there that are "production ready"? To my knowledge there is a DCCP stack in Linux. Exactly it status is unknown to me and which of the CC it supports. There has been also additional projects for implementations. I would note that no implementation exist of DTLS with a CC algorithm and additional mechanism. Thus that would be a from scratch implementation effort without any input what has been done so far. And if we can in fact decide early on something fully specified you have a lot of time to implement this before the rest are standards ready. > > The pseudoTCP stacks in libjingle have seen service for a long time.... > Well, that is addressing another set of requirements namely the reliable data transport. Lets not confuse the two sets. We appear to have interest in both unreliable and reliable data transport. Regarding pseudoTCP we still need a specification for it. I think for example the psuedo header used in the checksum needs specification in TCP over UDP. It might not be a big spec, but someone needs to write it and find a home for it. I would note that we are somewhat limited in this WG to actually do protocol work. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From roman@telurix.com Tue Sep 20 07:50: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 4F85C21F8CF2 for ; Tue, 20 Sep 2011 07:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.767 X-Spam-Level: X-Spam-Status: No, score=-2.767 tagged_above=-999 required=5 tests=[AWL=0.209, 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 uZPJ-rYS9mhu for ; Tue, 20 Sep 2011 07:50:48 -0700 (PDT) Received: from mail-qw0-f50.google.com (mail-qw0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9E47221F8CD7 for ; Tue, 20 Sep 2011 07:50:47 -0700 (PDT) Received: by qwj9 with SMTP id 9so1218843qwj.9 for ; Tue, 20 Sep 2011 07:53:13 -0700 (PDT) Received: by 10.229.71.161 with SMTP id h33mr695634qcj.276.1316530393076; Tue, 20 Sep 2011 07:53:13 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id hc3sm1724082qab.22.2011.09.20.07.53.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 07:53:12 -0700 (PDT) Received: by yxt33 with SMTP id 33so483241yxt.31 for ; Tue, 20 Sep 2011 07:53:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.39.229 with SMTP id s5mr3427649pbk.107.1316530390582; Tue, 20 Sep 2011 07:53:10 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 20 Sep 2011 07:53:10 -0700 (PDT) In-Reply-To: <1A61D589-1C23-4364-AA4A-60338D8C5859@edvina.net> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2EB@ESESSCMS0356.eemea.ericsson.se> <1A61D589-1C23-4364-AA4A-60338D8C5859@edvina.net> Date: Tue, 20 Sep 2011 10:53:10 -0400 Message-ID: From: Roman Shpount To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=bcaec520f3fb4445ac04ad609e59 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 14:50:49 -0000 --bcaec520f3fb4445ac04ad609e59 Content-Type: text/plain; charset=ISO-8859-1 There are actually three related issues here: 1. As mentioned earlier, a single offer in SIP can create multiple dialogs with independent answers. Each dialog is independent from each other and it is up to end user device to choose how to render it (mix audio, play the audio from the latest, display multiple videos side by side). These dialogs can be early (created by a provisional response) or final (created by a success response), but this distinction typically does not affect the media plane. There are a number of common use cases for forking with multiple answers such as service announcements (play some announcement from a media server using an early dialog then start playing audio from the call using another dialog), color ring back (play custom music while dialing the user), find me/follow me (where call can be answered by the desk and cell phone creating two final dialogs). One of the biggest design issues with such multiple answer fork scenarios is that there is no way to map received media to the actual answer, since there is nothing in the answer SDP which identifies the response RTP stream. 2. The second scenario is non-standard, but very widely used -- in the same dialog, different responses are send in the provisional and final SIP responses. This is usually a result of forking being masked by a B2BUA or SBC. Even though this is non-standard this is usually trivial to implement, since all that needs to be done is to reinitialize the media stream based on the new answer. 3. Even when multiple answers are not used, multiple different media streams can be sent based on the offer. First of all, it is common to receive media before the signaling response is received. Second, standard requires that offerer should be ready to receive media once the offer is sent and there is nothing that prevents multiple media streams from being sent to it. Furthermore, multiple answers only define what media and where should be sent to the answerer, but in no way specifies how many remote parties, from which addresses, and what type of media will send the media to the offerer. New media streams with new SSRC from new addresses with new media types present in the offer can be added at any time without the offer/answer exchange. Typically this is supported in such a way that only the newest media stream, after probation interval, is played and older media streams are ignored, but other more robust solutions are possible. If we plan to interop with existing VoIP solutions, we will need to support 1 and 2, as well as define the expected behavior for 3. _____________ Roman Shpount On Tue, Sep 20, 2011 at 9:40 AM, Olle E. Johansson wrote: > > 20 sep 2011 kl. 15:15 skrev Christer Holmberg: > > > > > Hi, > > > >>> Once we start requiring that the PeerConnection know the > >>> difference between "early" media and "late" media, it seems > >>> to me we're slipping down a slippery slope. > >> > >> The difference between early and late media is purely a > >> billing decision in PSTN. I don't think we should separate > >> these on the rtcweb side. It's a PSTN gateway issue, not > >> something to be bothered with in rtcweb. > > > > It's not about knowing the difference between "early" and "late" media - > it's about whether the API and browser need to support multiple SIMULTANOUS > SDP answers - or whether we assume that the JS SIP app will always, at any > given time, only provide ONE SDP answer to the API and browser. > > I just wanted to get rid of the early/late media discussion. As you state, > the forking issue with getting multiple responses is a separate issue. > > Do we have any use cases using forking? Is forking a desired feature or > something that SIP brought in? > > To give an example to those of you with no SIP history: > > In SIP you can send one OFFER and get multiple ANSWERs in 200 OK from > different devices. This means that you actually have multiple calls and need > to hang up all of those that you do not want, or just mix them somehow and > live with it. > > With early media, it gets even more confusing, because you will get an SDP > answer before the call is in up state (in 180/183 response) then another SDP > answer from another device at 200 OK. In this case you have an early dialog > with early media with the device sending the first answer, a dialog that > terminates at 200 OK. > > Supporting this behaviour adds complexity. And not all SIP devices support > these situations properly, as we've proven at SIPit testing. > > Which leads to an unshameful plug: SIPit in Monaco is now open for > registration - for all SIP developers to attend :-) > > /O > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec520f3fb4445ac04ad609e59 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There are actually three related issues here:

1. As mentioned earlie= r, a single offer in SIP can create multiple dialogs with independent answe= rs. Each dialog is independent from each other and it is up to end user dev= ice to choose how to render it (mix audio, play the audio from the latest, = display multiple videos side by side). These dialogs can be early (created = by a provisional response) or final (created by a success response), but th= is distinction typically does not affect the media plane. There are a numbe= r of common use cases for forking with multiple answers such as service ann= ouncements (play some announcement from a media server using an early dialo= g then start playing audio from the call using another dialog), color ring = back (play custom music while dialing the user), find me/follow me (where c= all can be answered by the desk and cell phone creating two final dialogs).= One of the biggest design issues with such multiple answer fork scenarios = is that there is no way to map received media to the actual answer, since t= here is nothing in the answer SDP which identifies the response RTP stream.=

2. The second scenario is non-standard, but very widely used -- in the = same dialog, different responses are send in the provisional and final SIP = responses. This is usually a result of forking being masked by a B2BUA or S= BC. Even though this is non-standard this is usually trivial to implement, = since all that needs to be done is to reinitialize the media stream based o= n the new answer.

3. Even when multiple answers are not used, multiple different media st= reams can be sent based on the offer. First of all, it is common to receive= media before the signaling response is received. Second, standard requires= that offerer should be ready to receive media once the offer is sent and t= here is nothing that prevents multiple media streams from being sent to it.= Furthermore, multiple answers only define what media and where should be s= ent to the answerer, but in no way specifies how many remote parties, from = which addresses, and what type of media will send the media to the offerer.= New media streams with new SSRC from new addresses with new media types pr= esent in the offer can be added at any time without the offer/answer exchan= ge. Typically this is supported in such a way that only the newest media st= ream, after probation interval, is played and older media streams are ignor= ed, but other more robust solutions are possible.

If we plan to interop with existing VoIP solutions, we will need to sup= port 1 and 2, as well as define the expected behavior for 3.
_____________
Roman Shpount


On Tue, Sep 20, 2011 at 9:40 AM, Olle E.= Johansson <oej@edvi= na.net> wrote:

20 sep 2011 kl. 15:15 skrev Christer Holmberg:

>
> Hi,
>
>>> Once we start requiring that the PeerConnection know the
>>> difference between "early" media and "late"= ; media, it seems
>>> to me we're slipping down a slippery slope.
>>
>> The difference between early and late media is purely a
>> billing decision in PSTN. I don't think we should separate
>> these on the rtcweb side. It's a PSTN gateway issue, not
>> something to be bothered with in rtcweb.
>
> It's not about knowing the difference between "early" an= d "late" media - it's about whether the API and browser need = to support multiple SIMULTANOUS SDP answers - or whether we assume that the= JS SIP app will always, at any given time, only provide ONE SDP answer to = the API and browser.

I just wanted to get rid of the early/late media discussion. As you s= tate, the forking issue with getting multiple responses is a separate issue= .

Do we have any use cases using forking? Is forking a desired feature or som= ething that SIP brought in?

To give an example to those of you with no SIP history:

In SIP you can send one OFFER and get multiple ANSWERs in 200 OK from diffe= rent devices. This means that you actually have multiple calls and need to = hang up all of those that you do not want, or just mix them somehow and liv= e with it.

With early media, it gets even more confusing, because you will get an SDP = answer before the call is in up state (in 180/183 response) then another SD= P answer from another device at 200 OK. In this case you have an early dial= og with early media with the device sending the first answer, a dialog that= terminates at 200 OK.

Supporting this behaviour adds complexity. And not all SIP devices support = these situations properly, as we've proven at SIPit testing.

Which leads to an unshameful plug: SIPit in Monaco is now open for registra= tion - for all SIP developers to attend :-)

/O


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

--bcaec520f3fb4445ac04ad609e59-- From ted.ietf@gmail.com Tue Sep 20 07:58: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 A987721F8C2B for ; Tue, 20 Sep 2011 07:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=-2.494, BAYES_00=-2.599, GB_SUMOF=5, 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 L3FDHHRvndqo for ; Tue, 20 Sep 2011 07:58:26 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1528621F8C1E for ; Tue, 20 Sep 2011 07:58:26 -0700 (PDT) Received: by gxk19 with SMTP id 19so500869gxk.31 for ; Tue, 20 Sep 2011 08:00:52 -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=/zGRe5L78LiJy1/SQRCzyqr+GUo2Y31/oml62+jGIko=; b=h6ITq8/GOsUQNAeIZsx2gRWGonuFysCg7vfknj4HAJ2COHMnj0TXdBN9XDc9F+Hks0 pZ8DOxPST/DKMV/LPeQ1O5QQp+xZh5o7BLyMduv98Zw4iiptR7qlFEIp7rlQbo1un2Fj bXOon53EmdEE1xslwh/WVDx7V1YQkyIcevV2I= MIME-Version: 1.0 Received: by 10.236.201.129 with SMTP id b1mr5483010yho.19.1316530844749; Tue, 20 Sep 2011 08:00:44 -0700 (PDT) Received: by 10.236.105.201 with HTTP; Tue, 20 Sep 2011 08:00:44 -0700 (PDT) In-Reply-To: <4E77C636.7080501@skype.net> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <4E77C636.7080501@skype.net> Date: Tue, 20 Sep 2011 17:00:44 +0200 Message-ID: From: Ted Hardie To: Matthew Kaufman Content-Type: multipart/alternative; boundary=20cf303dd4e8564ee004ad60b96a Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 14:58:26 -0000 --20cf303dd4e8564ee004ad60b96a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 20, 2011 at 12:46 AM, Matthew Kaufman wrote: > > By that logic we should have a built-in shopping cart to make creating web > storefronts easier, a built-in email client to make it easier to build the > next Gmail, etc. > > Except that all the interesting things that have ever happened on the web > are because clever people used the minimal built-in stuff to make something > much more than the sum of its parts, not because the masses used the > pre-built parts to replicate what already exists. > > I don't want my web browser to have a phone inside of it. I want my web > browser to be the thing that someone turns into the next great real-time > communications experience... whatever that is. > > I may still be jet-lagged (okay, I am still jet-lagged), but the reductio ad absurdum of that seems to be "I don't want my web browser to have a baked in file transfer protocol, I want it to be a platform for building the next great file transfer protocol experience". Having a standard signaling method for setting up media session neither prevents the creation of other signaling methods nor does it limit what sessions are getting created. It does facilitate doing the things we know we want to do in the common case--which includes making embeddable interactive audio/video easy to code and deploy. Again, just my two Rappen. Ted --20cf303dd4e8564ee004ad60b96a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Sep 20, 2011 at 12:46 AM, Matthew Kaufman <matthew.kaufman@skype.net>= wrote:

By that logic we should have a built-in shopping cart to make creating web = storefronts easier, a built-in email client to make it easier to build the = next Gmail, etc.

Except that all the interesting things that have ever happened on the web a= re because clever people used the minimal built-in stuff to make something = much more than the sum of its parts, not because the masses used the pre-bu= ilt parts to replicate what already exists.

I don't want my web browser to have a phone inside of it. I want my web= browser to be the thing that someone turns into the next great real-time c= ommunications experience... whatever that is.


I may still be jet-lagged (okay, I = am still jet-lagged), but the reductio ad absurdum of that seems to be &quo= t;I don't want my web browser to have a baked in file transfer protocol= , I want it to be a platform for building the next great file transfer prot= ocol experience".=A0

Having a standard signaling method for setting up media= session neither prevents the creation of other signaling methods nor does = it limit what sessions are getting created. =A0It does facilitate doing the= things we know we want to do in the common case--which includes =A0making = embeddable interactive audio/video easy to code and deploy.

Again, just my two Rappen.

Ted=
--20cf303dd4e8564ee004ad60b96a-- From fluffy@cisco.com Tue Sep 20 08:06: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 1CBB621F8C6B for ; Tue, 20 Sep 2011 08:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.147 X-Spam-Level: X-Spam-Status: No, score=-103.147 tagged_above=-999 required=5 tests=[AWL=-0.548, 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 Vc1sqrMyPN-7 for ; Tue, 20 Sep 2011 08:06:30 -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 6F56121F8C77 for ; Tue, 20 Sep 2011 08:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2521; q=dns/txt; s=iport; t=1316531336; x=1317740936; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=YxBufm4XRv0QW+M2mECoBni4TJ2UB4zTwkMAdlou1tk=; b=DCeyMZmXPJ3EOlY43UD6nupOYthRKZj8VGdLUU72KSfvYzRdQqAoPZgh ytrKGby0yKU9WnIusGw62y/lOJrIUukVcPA9ALetXmmDlUs/4c3mCWob5 HSQi/ziYEJGyi6uDbssEwKIS5nyfAnYpdJyeA+YKOo5VC1KLRMQEPoDhQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHOreE6rRDoJ/2dsb2JhbABCp1x4gVMBAQEBAgEBAQEJBgEKUQsFCQILPwcbDB8RBhMih1UGlVUBnkEChhtgBIdwi1uFHoww X-IronPort-AV: E=Sophos;i="4.68,411,1312156800"; d="scan'208";a="3196493" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 20 Sep 2011 15:08:56 +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 p8KF8t96001351; Tue, 20 Sep 2011 15:08:56 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <4E76E8E8.2050102@ericsson.com> Date: Tue, 20 Sep 2011 09:08:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <859C2B20-7858-480C-9E5E-577C889C330D@cisco.com> References: <4E76E8E8.2050102@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 15:06:31 -0000 I think we should do both and we should do it by using SDP to = negotiation a session of VNC as defined in RFC 6143. Given we will have = a way of setting up a data channel between endpoints, running RFC 6143 = on top of it is trivial and does not add much work or complexity. I = would propose this as optional to implement.=20 On Sep 19, 2011, at 1:02 AM, Magnus Westerlund wrote: > WG, >=20 > There where some discussion in the Interim meeting last week about a > Screen/Application/Desktop sharing support use case. My take away from > the discussion is that this use cases is likely well enough understood > to actually start a consensus call now. However, to us WG chairs it = was > clear that the use case in question actually needs to be split into = two > parts. >=20 > A) Where the RTCWEB enabled browser can use a local application = window, > the whole desktop or a Screen as a media source that can be encoded = and > transported over the peerConnection for displaying/playback at the = peer. >=20 > B) Where a remote peer can provide one or more input types such as = mouse > and keyboard to control the local system, not only including the > browser, but also other operating system resources. This clearly can > only happen after additional consent, most likely on a per occasion > consent. >=20 > My interpretation is that A only allows for application sharing in > conferencing contexts, like in the WEBEX session the Interim meeting = was > held with where we shared slides. Where the combination of A and B is > providing for VNC/Remote desktop. >=20 > Thus the question to the WG is the following. >=20 > 1) Do you support or object the inclusion of use case A, B or Both in > our Use case document? >=20 > 2) Do you have additional comments for or against either of the use = cases? >=20 >=20 > As WG chair >=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 dzonatas@gmail.com Tue Sep 20 08:08: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 B3B0E21F8CD4 for ; Tue, 20 Sep 2011 08:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.824 X-Spam-Level: X-Spam-Status: No, score=-3.824 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 cKIY4S+MC6qq for ; Tue, 20 Sep 2011 08:08:58 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 18DCE21F8CD0 for ; Tue, 20 Sep 2011 08:08:58 -0700 (PDT) Received: by gxk19 with SMTP id 19so512588gxk.31 for ; Tue, 20 Sep 2011 08:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bOejBLGIF6aDtSTMDSDrnWPhAn33a5eltzbjWxFspP8=; b=grB5eCE6CuYaNKOx0+TXdzKo0OQuEmir2uAV+q5WWluPwEhBd/NV7HJIqxWnm9fwPZ IUfsbhphKsluEJqAZVroAlRlrHWJz06I+0ky2Uw2RAu1Fj9y+9AYkF7o6Bnw3euJsqUj W6M1omQKKw92LXXrlRliOApGlnVju3xrUAo0c= Received: by 10.42.137.1 with SMTP id w1mr1710433ict.29.1316531482027; Tue, 20 Sep 2011 08:11:22 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id j2sm2558765ibx.11.2011.09.20.08.11.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 08:11:21 -0700 (PDT) Message-ID: <4E78AD9D.8010408@gmail.com> Date: Tue, 20 Sep 2011 08:13:33 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> <4E78351C.20103@jesup.org> <4E7844B7.80000 05@jesup.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 15:08:58 -0000 On 09/20/2011 01:56 AM, Hadriel Kaplan wrote: > On Sep 20, 2011, at 4:48 AM, Olle E. Johansson wrote: > > >>> If it could, we'd probably have the siprec/remote-recording requirement accommodated. :) >>> >> Well, take a look at the source code for FreeSwitch or Asterisk and you'll see that "setting up a bridge" is not a piece of cake... >> You are making the assumption that you have no formatting issues and don't need to change framerate for video, orientation or anything else or audio transcoding. >> > Nope, I'm not making any such assumption. I was just pointing out that if the browser did full mixing, then we'd have the remote recording use-case thing done too. > The browser that does "full mixing" is then consider the simulator, so I would like to make sure that mix is done in real-time (capable of dispersement by solid surfaces rendered, like ray-cast for audio). I think the question is if there needs to be an API for the mixer (in constraint to rtcweb), as I can see that may be harder to interact with simulators. Or, do we think of browsers that may have hal mixers (1st person spatial only) that don't provide any simulation. > > >>>> SIP has been very focused on device<->server interaction, not device<->device. However: >>>> note that we have an app that knows why it has these calls in place; we're not defining an >>>> abstract, portable protocol use here. >>>> >>> Aha! So it's not "SIP" that you meant... you meant "something that looks like SIP but isn't SIP per the RFCs". ;) >>> >>> >> According to RFC 3261 SIP is a peer 2 peer protocol and not a device->server protocol. Just making a point. >> > I'm not sure if you meant that in response to my remark or Randell's? What I meant by saying "it's not really SIP" wasn't because I think SIP is not device<->device (on the contrary, it is)... but rather that if rtcweb uses SIP but then doesn't actually follow the rules of SIP, then it's *not* SIP. > > -hadriel > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- --- The wheel. From randell-ietf@jesup.org Tue Sep 20 08:24: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 2F16621F8C9F for ; Tue, 20 Sep 2011 08:24:45 -0700 (PDT) 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 vsi0cdbqp7k6 for ; Tue, 20 Sep 2011 08:24:44 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 4820F21F8C5D for ; Tue, 20 Sep 2011 08:24:44 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R62E2-0006ko-0q for rtcweb@ietf.org; Tue, 20 Sep 2011 10:27:10 -0500 Message-ID: <4E78B002.3090803@jesup.org> Date: Tue, 20 Sep 2011 11:23:46 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E76E8E8.2050102@ericsson.com> <4E76EF3A.4010500@alvestrand.no> <4E788325.4030004@jitsi.org> In-Reply-To: <4E788325.4030004@jitsi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 15:24:45 -0000 On 9/20/2011 8:12 AM, Emil Ivov wrote: > На 19.09.11 09:50, Olle E. Johansson написа: >>>> B) Where a remote peer can provide one or more input types such >>>> as mouse and keyboard to control the local system, not only >>>> including the browser, but also other operating system resources. >>>> This clearly can only happen after additional consent, most >>>> likely on a per occasion consent. >>> I see this as a more tricky thing to get right (in most apps, the >>> mixing of events from multiple sources depends strongly on both >>> proper timing/sequencing and reliable delivery). I would like to >>> not address this for now (RTCWeb version 1). >> I think it's a good use case for the data channel. How many such use >> cases do we have? While use case A is quite often handled as a normal >> video stream, use case B is likely something like VNC. This is an >> application that is part of Microsoft Lync as well as the free SIP >> client Blink today. > I don't see both as having separate implementations. We could very well > have browsers stream the desktop as a regular video flow in one > direction and then add to that (or not) user feedback in the opposite > direction. The feedback could go over signalling (which is what we are > doing in Jitsi), over RTP (something like RFC 4733's DTMF) or over > Pseudo TCP. > > Either way I think it's something quite important and I don't think > there's a good reason to leave it for later. > > I would be happy to work on that. Great! There is one fundamental question to answer about this use-case: How does it work in the existing JS security model? For B) to work, it not only has to accept mouse/keyboard/etc input from the other side, but it must take that and inject it into local browser or OS. The only way I can see to get that to work without a *massive* breach in the JS security model would be to have it be something JS can't touch directly, but like a codec is routed (with user permission) to the playback mechanism. And even there the permission from the user would have to be very carefully tied to the source. This would mean that the format for all the data on the wire would need to be specified and standardized; it can't easily be an application-specific protocol. (Ok, I can see one painful, indirect way to avoid our building a remote desktop wire protocol, which is to give a way for the JS app to provide the message format in a non-executable manner that we could use to transform the wire data into user-input data. But that's really no win for us.) Or one has to standardize it as a "codec", but that's complicated by not wanting to deliver it over an unreliable channel. The alternative would be to have the JS app be (VERY) trusted, which so far is not the threat model we're using. Perhaps once again this ties into whatever security model will be used for user-installed web-apps, since those in many cases will be taking the place of trusted binary installed apps. So, looking into this would be great, but I suspect it we can't put it into the first spec. It could be a follow-on, perhaps under the webapp security model. (My apologies; I know that there's lots of work going on in that space, but I haven't been following it closely.) While I'd love to see both A and B in WebRTC 1.0, I just don't see B as being feasible in this timeframe. Feel free to show I'm wrong, though! -- Randell Jesup randell-ietf@jesup.org From dzonatas@gmail.com Tue Sep 20 08:30: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 00DBF21F8BD3 for ; Tue, 20 Sep 2011 08:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.821 X-Spam-Level: X-Spam-Status: No, score=-3.821 tagged_above=-999 required=5 tests=[AWL=-0.222, 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 vvBtcCfqUTEz for ; Tue, 20 Sep 2011 08:30:39 -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 E2B6621F8C0D for ; Tue, 20 Sep 2011 08:30:38 -0700 (PDT) Received: by ywa6 with SMTP id 6so536184ywa.31 for ; Tue, 20 Sep 2011 08:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=vDE+AYWJ05lArcolmI5lJu/0qgxOzpOmdDRVHV0wADY=; b=OdulEXPg04nP3YLJ+cEhkODtSAneL5j1v2NC6FJCTCsoi6xgbC/cdbV7B2ZEszEL1b tGcz9uBvQU2Qqrrrht9Fg9nvRXvGHO5jlVt96BPU2jNKurGqp/ij+Hkz/gYP6VK4pu9z Zxq28KxLH60Sunq1DLIULL0im+PfNdzLGJ8RU= Received: by 10.42.156.133 with SMTP id z5mr759247icw.165.1316532784876; Tue, 20 Sep 2011 08:33:04 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id dv19sm2665024ibb.3.2011.09.20.08.33.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 08:33:03 -0700 (PDT) Message-ID: <4E78B2B5.7010904@gmail.com> Date: Tue, 20 Sep 2011 08:35:17 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <4E787D56.8060106@alvestrand.no> <4E788A9C.40105@alvestrand.no> In-Reply-To: <4E788A9C.40105@alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 15:30:40 -0000 On 09/20/2011 05:44 AM, Harald Alvestrand wrote: > On 09/20/11 14:36, Soo-Hyun Choi wrote: >> Harald, >> >> On Tue, Sep 20, 2011 at 20:47, Harald >> Alvestrand wrote: >>> let's avoid unquantifiable terms in our discussions. "A little more >>> careful" >>> is an unquantifiable term. >>> >>> If we want to say "I think the algorithm must guarantee that the >>> bandwidth >>> estimate is updated within 1.5 seconds when the available bandwidth >>> changes >>> from 2 Mbit/sec to 1 Mbit/sec", let's say something like that - >>> focus on >>> what the requirements are. >>> >>> We can always be a little more careful. But it doesn't tell us when >>> we're >>> close enough. >>> >> Sorry if my previous email looked that way to you (of course, I didn't >> mean to just pray for the mere hope). I was talking about some general >> CC principles in the high level for real-time interactive multimedia >> applications, like some of us did too in this thread. > Sorry, not intended to point at anyone in particular - I have been > worried about several conversations that seemed to be straying very > far from the "brass tacks" here. >> One of the critical metrics of a delay-based CC algo is an accurate >> measurement of inter-packet interval (IPI) and timely report of IPI to >> the sender so it can update the send rate correctly, which we all >> agreed in this email thread. Although everyone in this list seemed to >> aware of this, I have highlighted again that the relatively >> course-grained RTCP carrying the IPI measurement data can cause >> instability at the encoder's output bitrate due to the following >> reason. > The draft's suggestion is to avoid the need for communicating all the > IPI information from the receiver to the sender by doing part of the > processing and estimation at the receiver. I think we need to send the > resulting information quickly when it changes, but don't need to send > it so often when it remains stable. What "quickly" means in this > context is a good question - 0.1 second? 1 second? Certainly less than > 5 seconds? In the context of RTCWEB, I have constrained the meaning of quick to an ICE path. Or, any information known *before* the duration of any session is "quick", yet that does not include any actual connection delay. >> >>> I.e., Inaccurate BW estimation could lead into providing inaccurate >>> information about the available BW to the upper layer, which >>> eventually result in instability at the codec's encoding rate. >> >> So, my original question/suggestion was why not use AVPF (which is >> smaller packet than the standard RTCP) to generate/report more >> frequently to the sender in your algorithm. Or alternatively, I have >> already designed a window-version's of TFRC that re-introduces a >> TCP-like Ack-clocking, so-called TFWC (TCP-Friendly Window-based CC), >> which performs reasonably well (as good as TFRC) for the similar >> situations (RTC environment). >> >> I would like to ask to this list (or Harald) if suggesting alternative >> CC algo idea could fit into the RTCWEB Charter's scope - if so, I >> could elaborate more by writing an I-D or so. In the mean time, you >> could check my document at http://tfwc.hackerslab.eu/ if you are >> interested. > I am certainly looking for input on where we can best have this > discussion, too! > Algorithm design is outside of RTCWEB's charter, but I think > requirements/criteria for what "good enough" means for RTCWEB is > inside it. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > -- --- The wheel. From ted.ietf@gmail.com Tue Sep 20 08:44: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 22D2921F8C77 for ; Tue, 20 Sep 2011 08:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.070, 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 EQOTxz-Ql5sA for ; Tue, 20 Sep 2011 08:44:23 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 96AD821F8C76 for ; Tue, 20 Sep 2011 08:44:23 -0700 (PDT) Received: by yxt33 with SMTP id 33so540185yxt.31 for ; Tue, 20 Sep 2011 08:46:49 -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=FVC16F62k6UH/1uS5Q32If+FPNpjMgKB+5DMyngWelU=; b=B4vSZcvyua+R3CkiVEp/TFydk+FwvDz0ML2jrIrULwQG4kpZL/OyKVszCZgGT9in1g t8W9Nb6pqMRIIAzxTcUFM8EbDvNrZ19QO+j+jqopBZB49VNKYsevpj8BGqN01ldVdDhl BRVAfBmpa+JVhY959Uicjp0lnktFdw4RsQY/8= MIME-Version: 1.0 Received: by 10.236.76.38 with SMTP id a26mr5857099yhe.53.1316533609693; Tue, 20 Sep 2011 08:46:49 -0700 (PDT) Received: by 10.236.105.201 with HTTP; Tue, 20 Sep 2011 08:46:49 -0700 (PDT) Date: Tue, 20 Sep 2011 17:46:49 +0200 Message-ID: From: Ted Hardie To: rtcweb@ietf.org Content-Type: multipart/alternative; boundary=20cf303bf65c2401e404ad615eb5 Subject: [rtcweb] Security analysis doc X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 15:44:24 -0000 --20cf303bf65c2401e404ad615eb5 Content-Type: text/plain; charset=ISO-8859-1 The chairs have asked Eric Rescorla to submit his next update as working group draft, with the understanding that it will be focused on describing the threat model and assurances desired. The security mechanisms may be described in other documents, especially in the protocol documents. Ted, Cullen, Magnus --20cf303bf65c2401e404ad615eb5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The chairs have asked Eric Rescorla to submit his next update as working gr= oup draft, with the understanding that it will be focused on describing the= threat model and assurances desired. =A0The security mechanisms may be des= cribed in other documents, especially in the protocol documents.

Ted, Cullen, Magnus
--20cf303bf65c2401e404ad615eb5-- From randell-ietf@jesup.org Tue Sep 20 08:53: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 238D021F8C26 for ; Tue, 20 Sep 2011 08:53:16 -0700 (PDT) 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 qh24f5--zvfj for ; Tue, 20 Sep 2011 08:52:51 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id EF5E921F8C00 for ; Tue, 20 Sep 2011 08:52:50 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R62fE-0001nV-Lm for rtcweb@ietf.org; Tue, 20 Sep 2011 10:55:16 -0500 Message-ID: <4E78B698.6070400@jesup.org> Date: Tue, 20 Sep 2011 11:51:52 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <4E787D56.8060106@alvestrand.no> <4E788A9C.40105@alvestrand.no> In-Reply-To: <4E788A9C.40105@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] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-00.txt) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2011 15:53:16 -0000 On 9/20/2011 8:44 AM, Harald Alvestrand wrote: > On 09/20/11 14:36, Soo-Hyun Choi wrote: One of the critical metrics of > a delay-based CC algo is an accurate >> measurement of inter-packet interval (IPI) and timely report of IPI to >> the sender so it can update the send rate correctly, which we all >> agreed in this email thread. Although everyone in this list seemed to >> aware of this, I have highlighted again that the relatively >> course-grained RTCP carrying the IPI measurement data can cause >> instability at the encoder's output bitrate due to the following >> reason. > The draft's suggestion is to avoid the need for communicating all the > IPI information from the receiver to the sender by doing part of the > processing and estimation at the receiver. I think we need to send the > resulting information quickly when it changes, but don't need to send > it so often when it remains stable. What "quickly" means in this > context is a good question - 0.1 second? 1 second? Certainly less than > 5 seconds? I agree with Harald here; the entire algorithm doesn't need to run on the sender side alone. An RFC can contain algorithms for calculating values (see RTCP jitter for an example), but I think here we want to make sure that the mechanisms we provide allow things to work when the implementations at the send and receive side are different. For example, for the classic one-stream CC model like Google/GIPS's algorithm their use of TMMBR - it should work with anyone supporting TMMBR. In our case we may find we need to add a new FB message, since the existing ones may not cover what we need to convey (and we probably don't want to go the RTCP APP route). Or we may find it makes most sense to use a RTP header extension. We'll see. >> >> I would like to ask to this list (or Harald) if suggesting alternative >> CC algo idea could fit into the RTCWEB Charter's scope - if so, I >> could elaborate more by writing an I-D or so. In the mean time, you >> could check my document at http://tfwc.hackerslab.eu/ if you are >> interested. > I am certainly looking for input on where we can best have this > discussion, too! > Algorithm design is outside of RTCWEB's charter, but I think > requirements/criteria for what "good enough" means for RTCWEB is > inside it. Agree (mostly) with Harald there, but I agree we don't want to specify the CC algorithm in total. We may very well want to document a proposed baseline algorithm that meets the requirements we lay down in the spec, however. -- Randell Jesup randell-ietf@jesup.org From oej@edvina.net Tue Sep 20 09:07: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 B465021F8610 for ; Tue, 20 Sep 2011 09:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.006, 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 RrbKnUxIu7Tc for ; Tue, 20 Sep 2011 09:07:17 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 42C3321F85A1 for ; Tue, 20 Sep 2011 09:07:16 -0700 (PDT) Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 680D6754BCE4; Tue, 20 Sep 2011 16:09:39 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Tue, 20 Sep 2011 18:09:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <008491B0-0CEE-4166-BE01-1358687ECF1E@edvina.net> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2EB@ESESSCMS0356.eemea.ericsson.se> <1A61D589-1C23-4364-AA4A-60338D8C5859@edvina.net> To: Roman Shpount X-Mailer: Apple Mail (2.1244.3) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 16:07:17 -0000 20 sep 2011 kl. 16:53 skrev Roman Shpount: > There are actually three related issues here: >=20 > 1. As mentioned earlier, a single offer in SIP can create multiple = dialogs with independent answers. Each dialog is independent from each = other and it is up to end user device to choose how to render it (mix = audio, play the audio from the latest, display multiple videos side by = side). These dialogs can be early (created by a provisional response) or = final (created by a success response), but this distinction typically = does not affect the media plane. There are a number of common use cases = for forking with multiple answers such as service announcements (play = some announcement from a media server using an early dialog then start = playing audio from the call using another dialog), color ring back (play = custom music while dialing the user), find me/follow me (where call can = be answered by the desk and cell phone creating two final dialogs). One = of the biggest design issues with such multiple answer fork scenarios is = that there is no way to map received media to the actual answer, since = there is nothing in the answer SDP which identifies the response RTP = stream. >=20 > 2. The second scenario is non-standard, but very widely used -- in the = same dialog, different responses are send in the provisional and final = SIP responses. This is usually a result of forking being masked by a = B2BUA or SBC. Even though this is non-standard this is usually trivial = to implement, since all that needs to be done is to reinitialize the = media stream based on the new answer. >=20 > 3. Even when multiple answers are not used, multiple different media = streams can be sent based on the offer. First of all, it is common to = receive media before the signaling response is received. Second, = standard requires that offerer should be ready to receive media once the = offer is sent and there is nothing that prevents multiple media streams = from being sent to it. Furthermore, multiple answers only define what = media and where should be sent to the answerer, but in no way specifies = how many remote parties, from which addresses, and what type of media = will send the media to the offerer. New media streams with new SSRC from = new addresses with new media types present in the offer can be added at = any time without the offer/answer exchange. Typically this is supported = in such a way that only the newest media stream, after probation = interval, is played and older media streams are ignored, but other more = robust solutions are possible. >=20 > If we plan to interop with existing VoIP solutions, we will need to = support 1 and 2, as well as define the expected behavior for 3. Agree. I think that would be bad. What do you think? /O > _____________ > Roman Shpount >=20 >=20 > On Tue, Sep 20, 2011 at 9:40 AM, Olle E. Johansson = wrote: >=20 > 20 sep 2011 kl. 15:15 skrev Christer Holmberg: >=20 > > > > Hi, > > > >>> Once we start requiring that the PeerConnection know the > >>> difference between "early" media and "late" media, it seems > >>> to me we're slipping down a slippery slope. > >> > >> The difference between early and late media is purely a > >> billing decision in PSTN. I don't think we should separate > >> these on the rtcweb side. It's a PSTN gateway issue, not > >> something to be bothered with in rtcweb. > > > > It's not about knowing the difference between "early" and "late" = media - it's about whether the API and browser need to support multiple = SIMULTANOUS SDP answers - or whether we assume that the JS SIP app will = always, at any given time, only provide ONE SDP answer to the API and = browser. >=20 > I just wanted to get rid of the early/late media discussion. As you = state, the forking issue with getting multiple responses is a separate = issue. >=20 > Do we have any use cases using forking? Is forking a desired feature = or something that SIP brought in? >=20 > To give an example to those of you with no SIP history: >=20 > In SIP you can send one OFFER and get multiple ANSWERs in 200 OK from = different devices. This means that you actually have multiple calls and = need to hang up all of those that you do not want, or just mix them = somehow and live with it. >=20 > With early media, it gets even more confusing, because you will get an = SDP answer before the call is in up state (in 180/183 response) then = another SDP answer from another device at 200 OK. In this case you have = an early dialog with early media with the device sending the first = answer, a dialog that terminates at 200 OK. >=20 > Supporting this behaviour adds complexity. And not all SIP devices = support these situations properly, as we've proven at SIPit testing. >=20 > Which leads to an unshameful plug: SIPit in Monaco is now open for = registration - for all SIP developers to attend :-) >=20 > /O >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From john.elwell@siemens-enterprise.com Tue Sep 20 09:39: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 C0CDC11E8128 for ; Tue, 20 Sep 2011 09:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.009 X-Spam-Level: X-Spam-Status: No, score=-103.009 tagged_above=-999 required=5 tests=[AWL=-0.410, 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 ENoYFw5u9W1i for ; Tue, 20 Sep 2011 09:39:00 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 770D611E8126 for ; Tue, 20 Sep 2011 09:38:59 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 9DB011EB8456; Tue, 20 Sep 2011 18:41:22 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 20 Sep 2011 18:41:22 +0200 From: "Elwell, John" To: Hadriel Kaplan , Harald Alvestrand Date: Tue, 20 Sep 2011 18:41:20 +0200 Thread-Topic: [rtcweb] SDP offer/answer vs. JSON (was: About defining a signaling protocol for WebRTC (or not)) Thread-Index: AQHMdJ6ASfE9VHVwDUuGxXm7AxKbwZVWdODA Message-ID: References: <4E71927C.1090606@skype.net> <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com> <20110915140248.4cc17977@lminiero-acer> <4E71F90D.8030302@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [rtcweb] SDP offer/answer vs. JSON (was: About defining a signaling protocol for WebRTC (or not)) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 16:39:00 -0000 I agree with the points Hadriel makes. And I would add another point. SDP s= ometimes has several ways of doing the same thing, some official, some de f= acto. For example, cap-neg as the official way of negotiating a profile (sa= y AVP versus SAVP) and well-practiced but simpler techniques for doing the = same thing. By having JSON at the API, it is left to the application (JS or= server) to decide which techniques to use when federating, according to th= e environment it finds itself in. I believe this is the right way to go. Pl= ease don't lock this into the browser and force cap-neg (say) on everyone. John > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 16 September 2011 19:29 > To: Harald Alvestrand > Cc: > Subject: [rtcweb] SDP offer/answer vs. JSON (was: About=20 > defining a signaling protocol for WebRTC (or not)) >=20 >=20 > On Sep 15, 2011, at 9:09 AM, Harald Alvestrand wrote: >=20 > > The disadvantage of parsing to another structure (I am fond=20 > of JSON myself) is that one has to maintain a data definition=20 > for the format being parsed to, a defined transform between=20 > that and the "canonical SDP structure" has to be implemented=20 > in user space when one does SDP interoperability, both of=20 > those have to be updated for every SDP extension that someone=20 > defines somewhere, and one is still not free to define=20 > extensions on the non-SDP side if one still requires the=20 > ability to map them into SDP. > >=20 > > If one uses the "native" SDP format, which is the format in=20 > which every extension to the format gets documented, the=20 > browsers are the ones who *have* to parse it (although others=20 > are likely to). >=20 >=20 > Right so the above paragraphs get to the heart of the matter,=20 > methinks. Ultimately we need W3C to define an API, and the=20 > API has to provide a means of learning RTP/media info from=20 > the browser and commanding the browser to perform certain=20 > things with RTP/media. One could expose this API as a true=20 > data structure, or as a long string of tokens to be=20 > parsed/serialized back/forth. If the latter, then the=20 > choices are basically JSON or SDP. And SDP seems=20 > advantageous because it appears to be the least work for the=20 > simple use-cases, because the javascript could just copy=20 > back/forth the SDP between the browser and server. In other=20 > words you're optimizing for the very simple use-cases, in=20 > exchange for making it more complicated for the advanced=20 > use-cases. Right? >=20 > OK, that's a laudable goal. And I recognize that the=20 > decision has basically already been made, and nothing's going=20 > to change it.=20 >=20 > But email's free... so for the sake of posterity (and email=20 > archiving) here're some reasons not to use SDP anyway: > 1) Incorporating SDP and the offer/answer model into the=20 > Browser and W3C API inexorably ties the W3C to the IETF=20 > MMUSIC working group for all time. So far, I had been going=20 > on the assumption the IETF would be defining what the RTP=20 > library had to do/expose, while W3C would define the API. =20 > But if the API includes SDP offer/answer, that portion is the=20 > IETF's domain too, afaik. Anything the W3C wants to do in=20 > the future for that has to go through the IETF, not just=20 > IANA. (right?) >=20 > 2) This isn't just about JSON vs. SDP - it's about SDP=20 > *offer/answer*. SDP offer/answer wasn't meant to be an API=20 > between an application and its RTP library - it's a=20 > *protocol* between applications. One side-effect of this is=20 > it has historic state. For example, if an SDP offer contains=20 > two media lines, and one media is removed, the number of SDP=20 > media lines don't reduce back to one - EVER. So if=20 > PeerConnection.removeStream() is invoked, the Browser needs=20 > to remember there was that stream and signal it in SDP as=20 > disabled for all time, until PeerConnection is closed. If=20 > addStream() is invoked later, it could/could-not re-use that=20 > same (disabled) media line, or add a new one. >=20 > As another example, if a new SDP offer is sent out in SIP and=20 > gets rejected with a 488, the session reverts to the=20 > previously agreed SDP state. The Browser would therefore=20 > have to keep state of previous SDP and revert to it to handle=20 > this case. For example, if my Javascript started with only=20 > an audio MediaStream in PeerConnection and later added a=20 > video MediaStream to it, the new SDP offer would contain two=20 > media lines - if the offer gets rejected with 488, how is=20 > that communicated to the Browser and what will the browser do? >=20 > 3) You might well want information conveyed across that "API"=20 > that is not meant to be sent on the wire in SDP - things you=20 > don't want defined by IANA as SDP tokens. For example, you=20 > may want to provide packet counts, jitter, latency, and other=20 > meta-information about individual RTP codecs. Using JSON=20 > allows you to have data member variables which will not get=20 > serialized into SDP, but are purely for the javascript's use,=20 > while still within the referential tree structure of the=20 > media stream info. Or they may be for sending to peers, but=20 > simply not for SDP. (like you could send the jitter/latency=20 > info through the signaling channel) >=20 > 4) Obviously if the application as a whole needs to do SDP=20 > offer/answer, then *someone* will have to implement it=20 > correctly, including the state-related stuff. It could be=20 > the browser or the javascript that do this. Chrome may do a=20 > perfect job of that in the browser, afaik. But there are=20 > other browser vendors, including niche ones such as Dolphin=20 > and Skyfire. What are the odds they all get it right the first time? >=20 > So which would you rather have updating an SDP engine, if one=20 > is even needed... or updating "every SDP extension that=20 > someone defines somewhere": the javascript which is written=20 > by the developer that knows what they want when they want it,=20 > and can update their code by updating their javascript (or=20 > not if they don't need to); or the browsers which are written=20 > by companies not under the javascript developer's control, at=20 > a time of the browser companies' choosing?=20 >=20 > Obviously for some things the browser will have to be updated=20 > regardless, for example to understand rather than just ignore=20 > new JSON entries, to provide new codecs, etc. But not all=20 > new SDP attributes require changes in the media plane, nor=20 > encoding into JSON. In fact, a lot doesn't - some of it's=20 > higher-application info, not really for the RTP library, and=20 > more of it's coming in the future.=20 >=20 > -hadriel >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From dzonatas@gmail.com Tue Sep 20 10:19: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 B425111E8073 for ; Tue, 20 Sep 2011 10:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.818 X-Spam-Level: X-Spam-Status: No, score=-3.818 tagged_above=-999 required=5 tests=[AWL=-0.219, 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 d7pvYo4BevJD for ; Tue, 20 Sep 2011 10:19:54 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A134E21F8BCB for ; Tue, 20 Sep 2011 10:19:54 -0700 (PDT) Received: by iaby26 with SMTP id y26so1003381iab.31 for ; Tue, 20 Sep 2011 10:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=zTEtn8G3Za1K5YLk3DR4Zuo87RdXxLvvQ6npWIepDa4=; b=WDek0LQIhUN1k/ckFW4OqVYWCwxQOxkUj2ZdeR35QsvLZ4Ta7yjXFFVmOC2MJ4aQUK Feb/agQNt5Uk9BzEWGh7KsZyOU6A8pSG3X8QyTlWAfwnDXTLB8K1g8Jua8flE9yZTLJB Fd5QFBKvBlknTqlbV8M1gVsJmTep4K1FFSIwQ= Received: by 10.231.9.40 with SMTP id j40mr1766111ibj.2.1316539340892; Tue, 20 Sep 2011 10:22:20 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id r14sm2972108ibe.7.2011.09.20.10.22.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 10:22:19 -0700 (PDT) Message-ID: <4E78CC51.5080706@gmail.com> Date: Tue, 20 Sep 2011 10:24:33 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E71927C.1090606@skype.net> <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com> <20110915140248.4cc17977@lminiero-acer> <4E71F90D.8030302@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] SDP offer/answer vs. JSON X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 17:19:55 -0000 In the simulated room, the board posted the note-well such that all participants, even unknown, had this much quickness in resolution rather than be stuck in cap-neg in more blind situations. On the media plane, we may be able to make those "styx" notices, much like iNotify, yet these are one of those things that just works and still needs improvements, like this. From the top, the API needs the JSON-to-XPointer device driver for late binds; use-case: default emulation of scripted UI-only with saved-state. Is there some default for display size? Shop owners may want some signal sent that switches modes on all display units from after-hours to real-time. With some notices, where it makes sense, you don't always want to-allow augmentation of posted note-well displays. On 09/20/2011 09:41 AM, Elwell, John wrote: > I agree with the points Hadriel makes. And I would add another point. SDP sometimes has several ways of doing the same thing, some official, some de facto. For example, cap-neg as the official way of negotiating a profile (say AVP versus SAVP) and well-practiced but simpler techniques for doing the same thing. By having JSON at the API, it is left to the application (JS or server) to decide which techniques to use when federating, according to the environment it finds itself in. I believe this is the right way to go. Please don't lock this into the browser and force cap-neg (say) on everyone. > > John > > > > >> -----Original Message----- >> From: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hadriel Kaplan >> Sent: 16 September 2011 19:29 >> To: Harald Alvestrand >> Cc: >> Subject: [rtcweb] SDP offer/answer vs. JSON (was: About >> defining a signaling protocol for WebRTC (or not)) >> >> >> On Sep 15, 2011, at 9:09 AM, Harald Alvestrand wrote: >> >> >>> The disadvantage of parsing to another structure (I am fond >>> >> of JSON myself) is that one has to maintain a data definition >> for the format being parsed to, a defined transform between >> that and the "canonical SDP structure" has to be implemented >> in user space when one does SDP interoperability, both of >> those have to be updated for every SDP extension that someone >> defines somewhere, and one is still not free to define >> extensions on the non-SDP side if one still requires the >> ability to map them into SDP. >> >>> If one uses the "native" SDP format, which is the format in >>> >> which every extension to the format gets documented, the >> browsers are the ones who *have* to parse it (although others >> are likely to). >> >> >> Right so the above paragraphs get to the heart of the matter, >> methinks. Ultimately we need W3C to define an API, and the >> API has to provide a means of learning RTP/media info from >> the browser and commanding the browser to perform certain >> things with RTP/media. One could expose this API as a true >> data structure, or as a long string of tokens to be >> parsed/serialized back/forth. If the latter, then the >> choices are basically JSON or SDP. And SDP seems >> advantageous because it appears to be the least work for the >> simple use-cases, because the javascript could just copy >> back/forth the SDP between the browser and server. In other >> words you're optimizing for the very simple use-cases, in >> exchange for making it more complicated for the advanced >> use-cases. Right? >> >> OK, that's a laudable goal. And I recognize that the >> decision has basically already been made, and nothing's going >> to change it. >> >> But email's free... so for the sake of posterity (and email >> archiving) here're some reasons not to use SDP anyway: >> 1) Incorporating SDP and the offer/answer model into the >> Browser and W3C API inexorably ties the W3C to the IETF >> MMUSIC working group for all time. So far, I had been going >> on the assumption the IETF would be defining what the RTP >> library had to do/expose, while W3C would define the API. >> But if the API includes SDP offer/answer, that portion is the >> IETF's domain too, afaik. Anything the W3C wants to do in >> the future for that has to go through the IETF, not just >> IANA. (right?) >> >> 2) This isn't just about JSON vs. SDP - it's about SDP >> *offer/answer*. SDP offer/answer wasn't meant to be an API >> between an application and its RTP library - it's a >> *protocol* between applications. One side-effect of this is >> it has historic state. For example, if an SDP offer contains >> two media lines, and one media is removed, the number of SDP >> media lines don't reduce back to one - EVER. So if >> PeerConnection.removeStream() is invoked, the Browser needs >> to remember there was that stream and signal it in SDP as >> disabled for all time, until PeerConnection is closed. If >> addStream() is invoked later, it could/could-not re-use that >> same (disabled) media line, or add a new one. >> >> As another example, if a new SDP offer is sent out in SIP and >> gets rejected with a 488, the session reverts to the >> previously agreed SDP state. The Browser would therefore >> have to keep state of previous SDP and revert to it to handle >> this case. For example, if my Javascript started with only >> an audio MediaStream in PeerConnection and later added a >> video MediaStream to it, the new SDP offer would contain two >> media lines - if the offer gets rejected with 488, how is >> that communicated to the Browser and what will the browser do? >> >> 3) You might well want information conveyed across that "API" >> that is not meant to be sent on the wire in SDP - things you >> don't want defined by IANA as SDP tokens. For example, you >> may want to provide packet counts, jitter, latency, and other >> meta-information about individual RTP codecs. Using JSON >> allows you to have data member variables which will not get >> serialized into SDP, but are purely for the javascript's use, >> while still within the referential tree structure of the >> media stream info. Or they may be for sending to peers, but >> simply not for SDP. (like you could send the jitter/latency >> info through the signaling channel) >> >> 4) Obviously if the application as a whole needs to do SDP >> offer/answer, then *someone* will have to implement it >> correctly, including the state-related stuff. It could be >> the browser or the javascript that do this. Chrome may do a >> perfect job of that in the browser, afaik. But there are >> other browser vendors, including niche ones such as Dolphin >> and Skyfire. What are the odds they all get it right the first time? >> >> So which would you rather have updating an SDP engine, if one >> is even needed... or updating "every SDP extension that >> someone defines somewhere": the javascript which is written >> by the developer that knows what they want when they want it, >> and can update their code by updating their javascript (or >> not if they don't need to); or the browsers which are written >> by companies not under the javascript developer's control, at >> a time of the browser companies' choosing? >> >> Obviously for some things the browser will have to be updated >> regardless, for example to understand rather than just ignore >> new JSON entries, to provide new codecs, etc. But not all >> new SDP attributes require changes in the media plane, nor >> encoding into JSON. In fact, a lot doesn't - some of it's >> higher-application info, not really for the RTP library, and >> more of it's coming in the future. >> >> -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 > > -- --- The wheel. From dzonatas@gmail.com Tue Sep 20 10:54: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 36AE621F8B45 for ; Tue, 20 Sep 2011 10:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.815 X-Spam-Level: X-Spam-Status: No, score=-3.815 tagged_above=-999 required=5 tests=[AWL=-0.216, 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 xgdQ11LfNiXX for ; Tue, 20 Sep 2011 10:54:50 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E896A21F8B3F for ; Tue, 20 Sep 2011 10:54:49 -0700 (PDT) Received: by iaby26 with SMTP id y26so1034225iab.31 for ; Tue, 20 Sep 2011 10:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=x8hPoic+WWvhiCPfAUSO4GNG8nyDFBLub7ANcmxL59Y=; b=tovnYZMre6K8wmAAz2COGplBafqsVmwEuNeGSsBPIJme/efrglLvA/oVMnrzh1sqZF bBcvqdqhXFVRSVgOUUPf4lVHjY8Oo7uAOA5xOgFiRduu7Z6Zahvtchso/R6ZmI01kPrY tqUilh1TzCavIU7fb45wOGVF9Gx2wm8aQZZcI= Received: by 10.231.9.40 with SMTP id j40mr1820048ibj.2.1316541435274; Tue, 20 Sep 2011 10:57:15 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id ek22sm3048517ibb.12.2011.09.20.10.57.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 10:57:14 -0700 (PDT) Message-ID: <4E78D47C.70405@gmail.com> Date: Tue, 20 Sep 2011 10:59:24 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E71927C.1090606@skype.net> <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com> <20110915140248.4cc17977@lminiero-acer> <4E71F90D.8030302@alvestrand.no> <4E78CC51.5080706@gmail.com> In-Reply-To: <4E78CC51.5080706@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] SDP offer/answer vs. JSON X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 17:54:51 -0000 Login to the simulator may mean no login needed to other credentials; further, this is where some debate over ICE or... http://www.ietf.org/about/note-well.html ...browser in the simulator. Maybe we can SSRC the XPointer XML, and focus on that interop with OAuth MAC in single UDP over S/MIME or IPv6. Again, where this makes sense: OAuth MAC plus S/MIME TOGETHER. I bet the browsers devs can guess the default. On 09/20/2011 10:24 AM, Dzonatas Sol wrote: > In the simulated room, the board posted the note-well such that all > participants, even unknown, had this much quickness in resolution > rather than be stuck in cap-neg in more blind situations. > > On the media plane, we may be able to make those "styx" notices, much > like iNotify, yet these are one of those things that just works and > still needs improvements, like this. > > From the top, the API needs the JSON-to-XPointer device driver for > late binds; use-case: default emulation of scripted UI-only with > saved-state. > > Is there some default for display size? Shop owners may want some > signal sent that switches modes on all display units from after-hours > to real-time. With some notices, where it makes sense, you don't > always want to-allow augmentation of posted note-well displays. > > On 09/20/2011 09:41 AM, Elwell, John wrote: >> I agree with the points Hadriel makes. And I would add another point. >> SDP sometimes has several ways of doing the same thing, some >> official, some de facto. For example, cap-neg as the official way of >> negotiating a profile (say AVP versus SAVP) and well-practiced but >> simpler techniques for doing the same thing. By having JSON at the >> API, it is left to the application (JS or server) to decide which >> techniques to use when federating, according to the environment it >> finds itself in. I believe this is the right way to go. Please don't >> lock this into the browser and force cap-neg (say) on everyone. >> >> John >> >> >> >>> -----Original Message----- >>> From: rtcweb-bounces@ietf.org >>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hadriel Kaplan >>> Sent: 16 September 2011 19:29 >>> To: Harald Alvestrand >>> Cc: >>> Subject: [rtcweb] SDP offer/answer vs. JSON (was: About >>> defining a signaling protocol for WebRTC (or not)) >>> >>> >>> On Sep 15, 2011, at 9:09 AM, Harald Alvestrand wrote: >>> >>>> The disadvantage of parsing to another structure (I am fond >>> of JSON myself) is that one has to maintain a data definition >>> for the format being parsed to, a defined transform between >>> that and the "canonical SDP structure" has to be implemented >>> in user space when one does SDP interoperability, both of >>> those have to be updated for every SDP extension that someone >>> defines somewhere, and one is still not free to define >>> extensions on the non-SDP side if one still requires the >>> ability to map them into SDP. >>>> If one uses the "native" SDP format, which is the format in >>> which every extension to the format gets documented, the >>> browsers are the ones who *have* to parse it (although others >>> are likely to). >>> >>> >>> Right so the above paragraphs get to the heart of the matter, >>> methinks. Ultimately we need W3C to define an API, and the >>> API has to provide a means of learning RTP/media info from >>> the browser and commanding the browser to perform certain >>> things with RTP/media. One could expose this API as a true >>> data structure, or as a long string of tokens to be >>> parsed/serialized back/forth. If the latter, then the >>> choices are basically JSON or SDP. And SDP seems >>> advantageous because it appears to be the least work for the >>> simple use-cases, because the javascript could just copy >>> back/forth the SDP between the browser and server. In other >>> words you're optimizing for the very simple use-cases, in >>> exchange for making it more complicated for the advanced >>> use-cases. Right? >>> >>> OK, that's a laudable goal. And I recognize that the >>> decision has basically already been made, and nothing's going >>> to change it. >>> >>> But email's free... so for the sake of posterity (and email >>> archiving) here're some reasons not to use SDP anyway: >>> 1) Incorporating SDP and the offer/answer model into the >>> Browser and W3C API inexorably ties the W3C to the IETF >>> MMUSIC working group for all time. So far, I had been going >>> on the assumption the IETF would be defining what the RTP >>> library had to do/expose, while W3C would define the API. >>> But if the API includes SDP offer/answer, that portion is the >>> IETF's domain too, afaik. Anything the W3C wants to do in >>> the future for that has to go through the IETF, not just >>> IANA. (right?) >>> >>> 2) This isn't just about JSON vs. SDP - it's about SDP >>> *offer/answer*. SDP offer/answer wasn't meant to be an API >>> between an application and its RTP library - it's a >>> *protocol* between applications. One side-effect of this is >>> it has historic state. For example, if an SDP offer contains >>> two media lines, and one media is removed, the number of SDP >>> media lines don't reduce back to one - EVER. So if >>> PeerConnection.removeStream() is invoked, the Browser needs >>> to remember there was that stream and signal it in SDP as >>> disabled for all time, until PeerConnection is closed. If >>> addStream() is invoked later, it could/could-not re-use that >>> same (disabled) media line, or add a new one. >>> >>> As another example, if a new SDP offer is sent out in SIP and >>> gets rejected with a 488, the session reverts to the >>> previously agreed SDP state. The Browser would therefore >>> have to keep state of previous SDP and revert to it to handle >>> this case. For example, if my Javascript started with only >>> an audio MediaStream in PeerConnection and later added a >>> video MediaStream to it, the new SDP offer would contain two >>> media lines - if the offer gets rejected with 488, how is >>> that communicated to the Browser and what will the browser do? >>> >>> 3) You might well want information conveyed across that "API" >>> that is not meant to be sent on the wire in SDP - things you >>> don't want defined by IANA as SDP tokens. For example, you >>> may want to provide packet counts, jitter, latency, and other >>> meta-information about individual RTP codecs. Using JSON >>> allows you to have data member variables which will not get >>> serialized into SDP, but are purely for the javascript's use, >>> while still within the referential tree structure of the >>> media stream info. Or they may be for sending to peers, but >>> simply not for SDP. (like you could send the jitter/latency >>> info through the signaling channel) >>> >>> 4) Obviously if the application as a whole needs to do SDP >>> offer/answer, then *someone* will have to implement it >>> correctly, including the state-related stuff. It could be >>> the browser or the javascript that do this. Chrome may do a >>> perfect job of that in the browser, afaik. But there are >>> other browser vendors, including niche ones such as Dolphin >>> and Skyfire. What are the odds they all get it right the first time? >>> >>> So which would you rather have updating an SDP engine, if one >>> is even needed... or updating "every SDP extension that >>> someone defines somewhere": the javascript which is written >>> by the developer that knows what they want when they want it, >>> and can update their code by updating their javascript (or >>> not if they don't need to); or the browsers which are written >>> by companies not under the javascript developer's control, at >>> a time of the browser companies' choosing? >>> >>> Obviously for some things the browser will have to be updated >>> regardless, for example to understand rather than just ignore >>> new JSON entries, to provide new codecs, etc. But not all >>> new SDP attributes require changes in the media plane, nor >>> encoding into JSON. In fact, a lot doesn't - some of it's >>> higher-application info, not really for the RTP library, and >>> more of it's coming in the future. >>> >>> -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 >> > > -- --- The wheel. From oej@edvina.net Tue Sep 20 11:28: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 8D4811F0C60 for ; Tue, 20 Sep 2011 11:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 oBekvcXy9pON for ; Tue, 20 Sep 2011 11:28:55 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9D21F0C57 for ; Tue, 20 Sep 2011 11:28:54 -0700 (PDT) Received: from [IPv6:2001:470:1f15:d79:1921:6f02:2098:710d] (unknown [IPv6:2001:470:1f15:d79:1921:6f02:2098:710d]) by smtp7.webway.se (Postfix) with ESMTPA id 5924E754BCE4; Tue, 20 Sep 2011 18:31:17 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Tue, 20 Sep 2011 18:09:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <008491B0-0CEE-4166-BE01-1358687ECF1E@edvina.net> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2EB@ESESSCMS0356.eemea.ericsson.se> <1A61D589-1C23-4364-AA4A-60338D8C5859@edvina.net> To: Roman Shpount X-Mailer: Apple Mail (2.1244.3) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 18:28:55 -0000 20 sep 2011 kl. 16:53 skrev Roman Shpount: > There are actually three related issues here: >=20 > 1. As mentioned earlier, a single offer in SIP can create multiple = dialogs with independent answers. Each dialog is independent from each = other and it is up to end user device to choose how to render it (mix = audio, play the audio from the latest, display multiple videos side by = side). These dialogs can be early (created by a provisional response) or = final (created by a success response), but this distinction typically = does not affect the media plane. There are a number of common use cases = for forking with multiple answers such as service announcements (play = some announcement from a media server using an early dialog then start = playing audio from the call using another dialog), color ring back (play = custom music while dialing the user), find me/follow me (where call can = be answered by the desk and cell phone creating two final dialogs). One = of the biggest design issues with such multiple answer fork scenarios is = that there is no way to map received media to the actual answer, since = there is nothing in the answer SDP which identifies the response RTP = stream. >=20 > 2. The second scenario is non-standard, but very widely used -- in the = same dialog, different responses are send in the provisional and final = SIP responses. This is usually a result of forking being masked by a = B2BUA or SBC. Even though this is non-standard this is usually trivial = to implement, since all that needs to be done is to reinitialize the = media stream based on the new answer. >=20 > 3. Even when multiple answers are not used, multiple different media = streams can be sent based on the offer. First of all, it is common to = receive media before the signaling response is received. Second, = standard requires that offerer should be ready to receive media once the = offer is sent and there is nothing that prevents multiple media streams = from being sent to it. Furthermore, multiple answers only define what = media and where should be sent to the answerer, but in no way specifies = how many remote parties, from which addresses, and what type of media = will send the media to the offerer. New media streams with new SSRC from = new addresses with new media types present in the offer can be added at = any time without the offer/answer exchange. Typically this is supported = in such a way that only the newest media stream, after probation = interval, is played and older media streams are ignored, but other more = robust solutions are possible. >=20 > If we plan to interop with existing VoIP solutions, we will need to = support 1 and 2, as well as define the expected behavior for 3. Agree. I think that would be bad. What do you think? /O > _____________ > Roman Shpount >=20 >=20 > On Tue, Sep 20, 2011 at 9:40 AM, Olle E. Johansson = wrote: >=20 > 20 sep 2011 kl. 15:15 skrev Christer Holmberg: >=20 > > > > Hi, > > > >>> Once we start requiring that the PeerConnection know the > >>> difference between "early" media and "late" media, it seems > >>> to me we're slipping down a slippery slope. > >> > >> The difference between early and late media is purely a > >> billing decision in PSTN. I don't think we should separate > >> these on the rtcweb side. It's a PSTN gateway issue, not > >> something to be bothered with in rtcweb. > > > > It's not about knowing the difference between "early" and "late" = media - it's about whether the API and browser need to support multiple = SIMULTANOUS SDP answers - or whether we assume that the JS SIP app will = always, at any given time, only provide ONE SDP answer to the API and = browser. >=20 > I just wanted to get rid of the early/late media discussion. As you = state, the forking issue with getting multiple responses is a separate = issue. >=20 > Do we have any use cases using forking? Is forking a desired feature = or something that SIP brought in? >=20 > To give an example to those of you with no SIP history: >=20 > In SIP you can send one OFFER and get multiple ANSWERs in 200 OK from = different devices. This means that you actually have multiple calls and = need to hang up all of those that you do not want, or just mix them = somehow and live with it. >=20 > With early media, it gets even more confusing, because you will get an = SDP answer before the call is in up state (in 180/183 response) then = another SDP answer from another device at 200 OK. In this case you have = an early dialog with early media with the device sending the first = answer, a dialog that terminates at 200 OK. >=20 > Supporting this behaviour adds complexity. And not all SIP devices = support these situations properly, as we've proven at SIPit testing. >=20 > Which leads to an unshameful plug: SIPit in Monaco is now open for = registration - for all SIP developers to attend :-) >=20 > /O >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From henry.sinnreich@gmail.com Tue Sep 20 12:48: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 447E91F0C41 for ; Tue, 20 Sep 2011 12:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[AWL=0.392, 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 bmTW3jU+vZ69 for ; Tue, 20 Sep 2011 12:48:25 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 94BBE1F0C40 for ; Tue, 20 Sep 2011 12:48:25 -0700 (PDT) Received: by gyd12 with SMTP id 12so778393gyd.31 for ; Tue, 20 Sep 2011 12:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=h3KLOxlgP0UaygT/6Nco11FIVpgvmBGvaH/8qWooYw4=; b=CbZUp7N26kIrHKyDFZ/DjhI3bFZ5Dg98rj3KWoUpOO+wtU6VeCM33oQFfmXx1qWfwX JjjzqrqyrMrzpaBBHhNebBtRpIMrcKSSqBcr0l7lQy5WTlA6Emc/Girj781fkiqCH5MT SU4+amql5mkrqkjV3SwfiRWu40drM468EBPxI= Received: by 10.236.195.10 with SMTP id o10mr7460313yhn.115.1316548252053; Tue, 20 Sep 2011 12:50:52 -0700 (PDT) Received: from [192.168.15.2] (cpe-76-184-249-163.tx.res.rr.com. [76.184.249.163]) by mx.google.com with ESMTPS id t56sm3274550yhh.20.2011.09.20.12.50.45 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 12:50:45 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 20 Sep 2011 14:50:42 -0500 From: Henry Sinnreich To: Hadriel Kaplan , Randell Jesup Message-ID: Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: AQHMd2Ww2V9ZOtZta0qF5HzNdmfwDJVWrlwZ In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "" Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 19:48:26 -0000 +1 > A full mesh is what *should* happen, but SIP/SDP can't do it, afaict. It > would treat them either as independent calls even at a media layer, or as a > full-mixer conference focus model. The closest thing we have would probably > be the Join header, but I believe it's semantics is to join as a full mixer > conf call. Isn't this full-mesh media-forking thing actually a new semantic > for SIP/SDP? (it's hard to believe with 100+ drafts/RFCs this scenario hasn't > already been addressed in SIP - I must be just having a memory leak) Thanks, Henry On 9/20/11 2:19 AM, "Hadriel Kaplan" wrote: > > On Sep 20, 2011, at 2:39 AM, Randell Jesup wrote: > >> On 9/20/2011 1:59 AM, Hadriel Kaplan wrote: >>> OK, let's take the game example... only 2-player games would be able to use >>> a simple rtcweb-SIP agent. Anything more than 2-player would want to use >>> the multi-party "conferencing" model of rtcweb, which can't even be signaled >>> with SIP today as far as I can tell. (not that I've thought about it too >>> much, but I can't see how it would without some changes to SIP) >> >> It should be easy - either as N-1 2-person calls to the person hosting the >> game, or >> N calls via a central server (equivalent to a mixer), or as a full mesh of >> direct >> calls (3 2-person calls for a 3-person game, 6 for a 4-person game, etc), or >> even >> sparse meshes (makes sense in a game where not all players are 'near' each >> other). > > Can't do N-1 2-person calls to the person hosting the game, because rtcweb > doesn't support "full" mixing in the browser, only local media mixing. (ie, > everyone will hear the person hosting the game, and the person hosting the > game will hear everyone else, but the rest won't hear each other) > > Calls via a central media server require a central media server, which kinda > defeats the "easy" concept and using our shiny new toy of rtcweb. > > A full mesh is what *should* happen, but SIP/SDP can't do it, afaict. It > would treat them either as independent calls even at a media layer, or as a > full-mixer conference focus model. The closest thing we have would probably > be the Join header, but I believe it's semantics is to join as a full mixer > conf call. Isn't this full-mesh media-forking thing actually a new semantic > for SIP/SDP? (it's hard to believe with 100+ drafts/RFCs this scenario hasn't > already been addressed in SIP - I must be just having a memory leak) > > -hadriel > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From fluffy@cisco.com Tue Sep 20 12:56: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 D652D1F0C41 for ; Tue, 20 Sep 2011 12:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.142 X-Spam-Level: X-Spam-Status: No, score=-103.142 tagged_above=-999 required=5 tests=[AWL=-0.543, 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 mIFSKkf+MYYN for ; Tue, 20 Sep 2011 12:56:04 -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 518621F0C40 for ; Tue, 20 Sep 2011 12:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1095; q=dns/txt; s=iport; t=1316548711; x=1317758311; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8m5UAqyOgRQHwUsb10b3+dWhtsIKIAgDaaTUQ+LN8cg=; b=gyqcZEEXatG7Z1oaxcKcvo047Tg24hzn5+PjBp6dJMkXo60Cah2TZBAH iq6oFi1W0GV1LaCE3cU2Gmv4rVm0k5AcueChSLoE9oJvaObMRXZSnXZRM ejiN4z8Tq0R5r21WaYpxN/CRWEteOXzU43WFuqCZx9iZkZi/B1tVsp4Oy c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAIHveE6rRDoH/2dsb2JhbABCpXqBaHiBUwEBAQECARIBJzgHBQsLGC5XBjWHVZUFAZ4vhh1gBIdwi1uFHoww X-IronPort-AV: E=Sophos;i="4.68,413,1312156800"; d="scan'208";a="3262725" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 20 Sep 2011 19:58:30 +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 p8KJwTtx001817; Tue, 20 Sep 2011 19:58:29 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E78940C.4040405@ericsson.com> Date: Tue, 20 Sep 2011 13:58:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 19:56:04 -0000 On Sep 20, 2011, at 7:24 AM, Magnus Westerlund wrote: > On 2011-09-19 18:59, Harald Alvestrand wrote: >=20 >> We need to handle glare - when one sends an OFFER and gets back an=20 >> OFFER, reply with SDP ERROR, enter a "glare" state, wait a bit, and = send=20 >> out an offer again. >>=20 >=20 > I think that is a bad design for glare handling. I agree it needs to = be > handled. I think the ICE version of glare handling could work pretty > well here. Any offer needs to include a random 32 bit number. If the > end-point receive an offer in relation to a peer-connection while it = has > an outstanding offer then it compares these codes. Who ever has the > greatest numerical value wins and that offer is handled the other is > responded with an error stating GLARE. Thus there is no extra delay = and > more clear resolution of the glare case. >=20 > Cheers >=20 > Magnus Westerlund I think it has to be possible to gateway what happens here to what = happens in SIP with glare - I suspect that more or less puts us on using = the SIP glare mechanism.=20= From fluffy@cisco.com Tue Sep 20 13:04: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 293FA1F0C41 for ; Tue, 20 Sep 2011 13:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.138 X-Spam-Level: X-Spam-Status: No, score=-103.138 tagged_above=-999 required=5 tests=[AWL=-0.539, 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 r2nKRY7uf0-m for ; Tue, 20 Sep 2011 13:04:51 -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 AE4971F0C40 for ; Tue, 20 Sep 2011 13:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2109; q=dns/txt; s=iport; t=1316549238; x=1317758838; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ayc/wlm88z9fOToSB1Av2xq4hYPltolYbX4p5++ZBQ0=; b=QY/3Drcrg/ACsPQoQ9oKpIASNUW286IzDRWxS41EQFB6g/0cXugcPTpS US30kUKNFg09Rv1/JtSQ/anIyMwxNwQbfpOwBb15UdNCnrq9XTXsTzAMR IccAqEhue6qZ9zmW6L5EID0LyGXGqPkPQ8tDMlgz5vlRXPU9kf0H5j2kZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANzxeE6rRDoG/2dsb2JhbABCp2J4gVMBAQEBAgESASc/BQtRVwY1h1WVBgGeK4YdYASHcItbhR6MMA X-IronPort-AV: E=Sophos;i="4.68,413,1312156800"; d="scan'208";a="3267264" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 20 Sep 2011 20:07:17 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8KK7Fi6021431; Tue, 20 Sep 2011 20:07:15 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> Date: Tue, 20 Sep 2011 14:07:14 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 20:04:52 -0000 On Sep 20, 2011, at 7:07 AM, Olle E. Johansson wrote: > 20 sep 2011 kl. 15:00 skrev Harald Alvestrand: >=20 >> Once we start requiring that the PeerConnection know the difference = between "early" media and "late" media, it seems to me we're slipping = down a slippery slope. >=20 > The difference between early and late media is purely a billing = decision in PSTN. I don't think we should separate these on the rtcweb = side. It's a PSTN gateway issue, not something to be bothered with in = rtcweb. >=20 > "The campaign to simplify call states" Simplification is good - just make sure that it is possible to gateway = to a SIP call to 1-800-go-fedex. A simplification that broke that would, = in my personal opinion, would not be acceptable. (and I think that early = media is a bit more than just a billing artifact but that's a longer = story). You agree? That said, I think that doing both forking and early media is hard. Lets = assume we are using a signaling gateway that is not a media gateway to = translate between a SIP call on one side and whatever is happening over = on the browser side. The basic issue is the browser initiating the = communications needs to be able to start receiving multiple RTP streams = before it even has signaling information to tell it how many it might = receive. To simplify this problem, Cary and my draft proposes not = allowing forking on the SIP side of the signaling gateway but still = allowing early media. If you wanted to do do forking in this case, one = would need a SBC that processed media and turned the forked medial legs = into one media leg.=20 What I'm trying to say is I agree that early media + forking is hard, = and the way I would like to simplify that is not allow forking. Note = that none of this has much to do with if the PeerConnection object knows = if media is early or late - what it needs to deal with is receiving RTP = regardless os if the SIP signaling GW had sent it any signaling that = indicated what had been in the SIP answer of the SIP side of a signaling = GW.=20 Cullen From fluffy@cisco.com Tue Sep 20 13:06: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 BB6661F0C41 for ; Tue, 20 Sep 2011 13:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.133 X-Spam-Level: X-Spam-Status: No, score=-103.133 tagged_above=-999 required=5 tests=[AWL=-0.534, 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 gnV366UhLj6W for ; Tue, 20 Sep 2011 13:06:13 -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 368CE1F0C40 for ; Tue, 20 Sep 2011 13:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1979; q=dns/txt; s=iport; t=1316549316; x=1317758916; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tNgfr17I1/rAypq/+YgVOdwPtndWXxA3NMpYSwCa+SI=; b=AFTwgU68ikJHjrtS1NGAU/QkEZd04DX1NRYlMudaT9WQKEPnQwKWBHxq drvKViS1pp4oM5G/wE+WL1adYo4zYv5qMODhOa50GXcuusFI8B9+eaPPV F4HADWUREZxsjn50tX4FvipzCpN5uleVu2rYUGAzdWY6N+2FGS77FjiQ0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANzxeE6rRDoJ/2dsb2JhbABCp2J4gVMBAQEBAgEBAQEPASc0CwULC0YnMAYTIodVBpUAAZ4rhh1gBIdwi1uFHoww X-IronPort-AV: E=Sophos;i="4.68,413,1312156800"; d="scan'208";a="3270425" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 20 Sep 2011 20:08:36 +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 p8KK8ZIa024393; Tue, 20 Sep 2011 20:08:35 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E777500.5030201@alvestrand.no> Date: Tue, 20 Sep 2011 14:08:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E777500.5030201@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 20:06:13 -0000 I think this sounds about right to me - I have been thinking about a = draft along the lines of this and showing how it maps to SIP. Keep in = mind there are also cases where one sides sends an OFFER, gets an = ANSWER, but that ANSWER has an error. I think another key component is = that a signaling GW needs to pass along an opaque blob that gets passed = back to it so you can signaling GW that are only transaction state full = and don't have to retain state for the duration of the communications. = You also need some identifier information so that a JS application = participating in multiple sessions can know what session a given piece = of SDP goes with.=20 On Sep 19, 2011, at 10:59 AM, Harald Alvestrand wrote: > I am looking at the WEBRTC API spec, which specifies a rudimentary = negotiation framework: SDP objects prefixed by the string "SDP". >=20 > It seems clear to me that this needs at least information about = whether something is an offer or an answer, and some way to complete the = transaction when an offer is sent and something prevents it from = completing. > Until we know we need more, what about the following, to be specified = in the WEBRTC API? >=20 > SDP objects are sent through the API, prefixed with either of >=20 > SDP OFFER > SDP ANSWER >=20 > Alternatively, one can pass >=20 > SDP ERROR >=20 > to reply to an SDP OFFER when something goes wrong. >=20 > If one gets an OFFER and sends out an ANSWER, state changes. > If OFFER gets an ANSWER back, state changes. > In all other cases, state is as before. >=20 > We need to handle glare - when one sends an OFFER and gets back an = OFFER, reply with SDP ERROR, enter a "glare" state, wait a bit, and send = out an offer again. >=20 > Do we really have to have anything else? >=20 >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From oej@edvina.net Tue Sep 20 13:15: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 C60DD1F0C5D for ; Tue, 20 Sep 2011 13:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 IhoZfykjB92O for ; Tue, 20 Sep 2011 13:15:25 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 35B7B1F0C41 for ; Tue, 20 Sep 2011 13:15:25 -0700 (PDT) Received: from [IPv6:2001:470:1f15:d79:1921:6f02:2098:710d] (unknown [IPv6:2001:470:1f15:d79:1921:6f02:2098:710d]) by smtp7.webway.se (Postfix) with ESMTPA id CFEF7754BCE5; Tue, 20 Sep 2011 20:17:48 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> Date: Tue, 20 Sep 2011 22:17:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1244.3) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 20:15:25 -0000 20 sep 2011 kl. 22:07 skrev Cullen Jennings: >=20 > On Sep 20, 2011, at 7:07 AM, Olle E. Johansson wrote: >=20 >> 20 sep 2011 kl. 15:00 skrev Harald Alvestrand: >>=20 >>> Once we start requiring that the PeerConnection know the difference = between "early" media and "late" media, it seems to me we're slipping = down a slippery slope. >>=20 >> The difference between early and late media is purely a billing = decision in PSTN. I don't think we should separate these on the rtcweb = side. It's a PSTN gateway issue, not something to be bothered with in = rtcweb. >>=20 >> "The campaign to simplify call states" >=20 > Simplification is good - just make sure that it is possible to gateway = to a SIP call to 1-800-go-fedex. A simplification that broke that would, = in my personal opinion, would not be acceptable. (and I think that early = media is a bit more than just a billing artifact but that's a longer = story). You agree? Absolutely, but if the call is in UP state on the rtcweb side as soon as = the PSTN/SIP gateway receives early media we will have no issue with = sending DTMF in early media, which is what you are trying to trick me = with :-) Now, if we force early media which is supposed to be one-way, not many = implementations would support fedex. I don't see this as a problem if we = just forget the early-media and late-media difference and just talk = about media and if it's up or not up. That would handle ringback as = well.=20 In my head, rtcweb is only the handset of a phone. The phone knows about = early media, but the handset just has a mike and a speaker and it's = simply on or off. >=20 > That said, I think that doing both forking and early media is hard. = Lets assume we are using a signaling gateway that is not a media gateway = to translate between a SIP call on one side and whatever is happening = over on the browser side. The basic issue is the browser initiating the = communications needs to be able to start receiving multiple RTP streams = before it even has signaling information to tell it how many it might = receive. To simplify this problem, Cary and my draft proposes not = allowing forking on the SIP side of the signaling gateway but still = allowing early media. If you wanted to do do forking in this case, one = would need a SBC that processed media and turned the forked medial legs = into one media leg.=20 SBS or b2bua - in this case rtcweb to SIP ua. Yep, that's my way of = thinking.=20 >=20 > What I'm trying to say is I agree that early media + forking is hard, = and the way I would like to simplify that is not allow forking. Note = that none of this has much to do with if the PeerConnection object knows = if media is early or late - what it needs to deal with is receiving RTP = regardless os if the SIP signaling GW had sent it any signaling that = indicated what had been in the SIP answer of the SIP side of a signaling = GW.=20 Agree.=20 /O= From fluffy@cisco.com Tue Sep 20 13:37: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 5FB0621F8C46 for ; Tue, 20 Sep 2011 13:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.128 X-Spam-Level: X-Spam-Status: No, score=-103.128 tagged_above=-999 required=5 tests=[AWL=-0.529, 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 P7swfCSfiTK3 for ; Tue, 20 Sep 2011 13:37:28 -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 B522521F8C40 for ; Tue, 20 Sep 2011 13:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3987; q=dns/txt; s=iport; t=1316551195; x=1317760795; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=QjKdRFSAQ9EA6vEZMQXvl48d7bJMcvJn86WvTZy9jZs=; b=azSYVHZTH4u5AuhLJmKXiGPOkknQwXX9c+iW9WeLn8gYwX+GjiLR5XBn MOW/sGofew98vJKfWSHGIMh64fklsM/iEJPmcRNmX2v5YHdZYF9A6EIeX uuf7jsxugi0d9zxkLZmJ+CEwK+RSOqKUSi9EKrT1XJKM3f0aYkmckjvV9 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACD5eE6rRDoH/2dsb2JhbAAtFadieIFTAQEBAQIBEgEnPxALGC5XBjWHVZR/AYtrkj2GHWAEh3CLW4UejDA X-IronPort-AV: E=Sophos;i="4.68,413,1312156800"; d="scan'208";a="3267163" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 20 Sep 2011 20:39:54 +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 p8KKdrQO025345; Tue, 20 Sep 2011 20:39:53 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Tue, 20 Sep 2011 14:39:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <16825C99-401A-40AF-9721-CAF99C6FE7C2@cisco.com> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 20:37:29 -0000 On Sep 20, 2011, at 2:17 PM, Olle E. Johansson wrote: >=20 > 20 sep 2011 kl. 22:07 skrev Cullen Jennings: >=20 >>=20 >> On Sep 20, 2011, at 7:07 AM, Olle E. Johansson wrote: >>=20 >>> 20 sep 2011 kl. 15:00 skrev Harald Alvestrand: >>>=20 >>>> Once we start requiring that the PeerConnection know the difference = between "early" media and "late" media, it seems to me we're slipping = down a slippery slope. >>>=20 >>> The difference between early and late media is purely a billing = decision in PSTN. I don't think we should separate these on the rtcweb = side. It's a PSTN gateway issue, not something to be bothered with in = rtcweb. >>>=20 >>> "The campaign to simplify call states" >>=20 >> Simplification is good - just make sure that it is possible to = gateway to a SIP call to 1-800-go-fedex. A simplification that broke = that would, in my personal opinion, would not be acceptable. (and I = think that early media is a bit more than just a billing artifact but = that's a longer story). You agree? > Absolutely, but if the call is in UP state on the rtcweb side as soon = as the PSTN/SIP gateway receives early media we will have no issue with = sending DTMF in early media, which is what you are trying to trick me = with :-) really I was not going to mention DTMF :-)=20 I was thinking a a call where the browser initiates the call, sends = something to the web2sip signaling gateway that sends a SIP invite to = the PSTN GW. Now the PSTN gateway sends a 180 and starts ICE. Then the = PSTN GW starts sending RTP with the fedex prompts in them and then it = eventually sends a 200. The key thing is the browser needed to be able = to receive RTP before the signaling gateway received the 200. As long as = we are on the same page there, it's good with me. The PSTN GW sends the = RTP directly to the the browser but sends the SIP to the signaling = gateway.=20 >=20 > Now, if we force early media which is supposed to be one-way, not many = implementations would support fedex. I don't see this as a problem if we = just forget the early-media and late-media difference and just talk = about media and if it's up or not up. That would handle ringback as = well.=20 I could care less about if the media is 1 way or two way. I just care = about hearing the prompts when I call 1-800-fedex. (I care about early = media, not one way media :-)=20 >=20 > In my head, rtcweb is only the handset of a phone. The phone knows = about early media, but the handset just has a mike and a speaker and = it's simply on or off. sure - not problem with that >=20 >=20 >>=20 >> That said, I think that doing both forking and early media is hard. = Lets assume we are using a signaling gateway that is not a media gateway = to translate between a SIP call on one side and whatever is happening = over on the browser side. The basic issue is the browser initiating the = communications needs to be able to start receiving multiple RTP streams = before it even has signaling information to tell it how many it might = receive. To simplify this problem, Cary and my draft proposes not = allowing forking on the SIP side of the signaling gateway but still = allowing early media. If you wanted to do do forking in this case, one = would need a SBC that processed media and turned the forked medial legs = into one media leg.=20 > SBS or b2bua - in this case rtcweb to SIP ua. Yep, that's my way of = thinking.=20 >>=20 >> What I'm trying to say is I agree that early media + forking is hard, = and the way I would like to simplify that is not allow forking. Note = that none of this has much to do with if the PeerConnection object knows = if media is early or late - what it needs to deal with is receiving RTP = regardless os if the SIP signaling GW had sent it any signaling that = indicated what had been in the SIP answer of the SIP side of a signaling = GW.=20 >=20 > Agree.=20 >=20 > /O From oej@edvina.net Tue Sep 20 14:17: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 9A28E21F8C0E for ; Tue, 20 Sep 2011 14:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 rIy0BC6Igdef for ; Tue, 20 Sep 2011 14:17:07 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id C931B21F8C19 for ; Tue, 20 Sep 2011 14:17:06 -0700 (PDT) Received: from [IPv6:2001:470:1f15:d79:1921:6f02:2098:710d] (unknown [IPv6:2001:470:1f15:d79:1921:6f02:2098:710d]) by smtp7.webway.se (Postfix) with ESMTPA id 37156754BCE4; Tue, 20 Sep 2011 21:19:31 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <16825C99-401A-40AF-9721-CAF99C6FE7C2@cisco.com> Date: Tue, 20 Sep 2011 23:19:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <548B5B90-F168-4B0D-818C-042B184C00B8@edvina.net> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <16825C99-401A-40AF-9721-CAF99C6FE7C2@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1244.3) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 21:17:07 -0000 20 sep 2011 kl. 22:39 skrev Cullen Jennings: >>>=20 >>> Simplification is good - just make sure that it is possible to = gateway to a SIP call to 1-800-go-fedex. A simplification that broke = that would, in my personal opinion, would not be acceptable. (and I = think that early media is a bit more than just a billing artifact but = that's a longer story). You agree? >> Absolutely, but if the call is in UP state on the rtcweb side as soon = as the PSTN/SIP gateway receives early media we will have no issue with = sending DTMF in early media, which is what you are trying to trick me = with :-) >=20 > really I was not going to mention DTMF :-)=20 Background to the fedex/DTMF hints: Fedex for some reason got a deal not only to send early media from a = commercial company, but also have an IVR server and request DTMF while = still not answering the call. This forced a code change in quite a lot = of SIP servers... ;-) /O= From HKaplan@acmepacket.com Tue Sep 20 14:43: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 C3C3A1F0C91 for ; Tue, 20 Sep 2011 14:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Iv79g3WvTqNC for ; Tue, 20 Sep 2011 14:43:04 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 51C051F0C67 for ; Tue, 20 Sep 2011 14:43:04 -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; Tue, 20 Sep 2011 17:45:30 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 20 Sep 2011 17:45:29 -0400 From: Hadriel Kaplan To: Roman Shpount Thread-Topic: [rtcweb] Minimal SDP negotiation mechanism Thread-Index: AQHMd96dDsyA7D2L20yFLQluaSt5yg== Date: Tue, 20 Sep 2011 21:45:29 +0000 Message-ID: <1F30D31F-322D-4FF1-BBA5-F9F1B1A06576@acmepacket.com> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2EB@ESESSCMS0356.eemea.ericsson.se> <1A61D589-1C23-4364-AA4A-60338D8C5859@edvina.net> 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: <414608C81EB65B4C840893186F0B5EC5@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 21:43:08 -0000 Yup, that pretty much sums it up. :) Some minor comments inline... On Sep 20, 2011, at 10:53 AM, Roman Shpount wrote: > There are actually three related issues here: >=20 > 1. As mentioned earlier, a single offer in SIP can create multiple dialog= s with independent answers. Each dialog is independent from each other and = it is up to end user device to choose how to render it (mix audio, play the= audio from the latest, display multiple videos side by side). These dialog= s can be early (created by a provisional response) or final (created by a s= uccess response), but this distinction typically does not affect the media = plane. There are a number of common use cases for forking with multiple ans= wers such as service announcements (play some announcement from a media ser= ver using an early dialog then start playing audio from the call using anot= her dialog), color ring back (play custom music while dialing the user), fi= nd me/follow me (where call can be answered by the desk and cell phone crea= ting two final dialogs). One of the biggest design issues with such multipl= e answer fork scenarios is that there is no way to map received media to th= e actual answer, since there is nothing in the answer SDP which identifies = the response RTP stream. So far the discussion in rtcweb has been that ICE will be required. As suc= h, you can actually correlate received media with the SDP, because the user= name in the STUN connectivity checks from the remote peers will be uniquely= indicated in the SDP from them, so media received on the same 5-tuple is f= rom that peer. (once you get the SDP answer(s) of course, which per ICE sho= uld be rather quickly) If we don't require ICE, we're still gonna require symmetric RTP, so the SD= P answer's c/m-line info could be used to correlate the media in many cases= . > 2. The second scenario is non-standard, but very widely used -- in the sa= me dialog, different responses are send in the provisional and final SIP re= sponses. This is usually a result of forking being masked by a B2BUA or SBC= . Even though this is non-standard this is usually trivial to implement, si= nce all that needs to be done is to reinitialize the media stream based on = the new answer. >=20 > 3. Even when multiple answers are not used, multiple different media stre= ams can be sent based on the offer. First of all, it is common to receive m= edia before the signaling response is received. Second, standard requires t= hat offerer should be ready to receive media once the offer is sent and the= re is nothing that prevents multiple media streams from being sent to it. F= urthermore, multiple answers only define what media and where should be sen= t to the answerer, but in no way specifies how many remote parties, from wh= ich addresses, and what type of media will send the media to the offerer. N= ew media streams with new SSRC from new addresses with new media types pres= ent in the offer can be added at any time without the offer/answer exchange= . Typically this is supported in such a way that only the newest media stre= am, after probation interval, is played and older media streams are ignored= , but other more robust solutions are possible. >=20 > If we plan to interop with existing VoIP solutions, we will need to suppo= rt 1 and 2, as well as define the expected behavior for 3. > _____________ > Roman Shpount >=20 From dzonatas@gmail.com Tue Sep 20 14:48: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 868C41F0CA6 for ; Tue, 20 Sep 2011 14:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.812 X-Spam-Level: X-Spam-Status: No, score=-3.812 tagged_above=-999 required=5 tests=[AWL=-0.213, 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 aXoZ3+p9B4jw for ; Tue, 20 Sep 2011 14:48:56 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A3EE61F0C87 for ; Tue, 20 Sep 2011 14:48:56 -0700 (PDT) Received: by iaby26 with SMTP id y26so1242676iab.31 for ; Tue, 20 Sep 2011 14:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=u5SZxWfy3K/0vieUyfxyHLqCPoI15lzO07as0g4QISs=; b=RNc+WY1/gJ6GqUp1wqvLj19GUUHQuz5kNAVwVJYs9O+6MZYFmBFqDD/a69Ippgk2tq YHQ6YsQ/ozYIB+y00mv+0LJzHw1u4tCk9JZ9hZ1DchoM3dZNPD3hCS2ejDdz6CIWLuCS fWi9jeLbrdQuBe8G1yHsRrdjoaKZLkhhOU8Bo= Received: by 10.231.60.139 with SMTP id p11mr2183032ibh.73.1316555475329; Tue, 20 Sep 2011 14:51:15 -0700 (PDT) Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id ee29sm3785313ibb.9.2011.09.20.14.51.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 14:51:14 -0700 (PDT) Message-ID: <4E790B59.2010202@gmail.com> Date: Tue, 20 Sep 2011 14:53:29 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <16825C99-401A-40AF-9721-CAF99C6FE7C2@cisco.com> In-Reply-To: <16825C99-401A-40AF-9721-CAF99C6FE7C2@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 21:48:57 -0000 On 09/20/2011 01:39 PM, Cullen Jennings wrote: > On Sep 20, 2011, at 2:17 PM, Olle E. Johansson wrote: > > >> 20 sep 2011 kl. 22:07 skrev Cullen Jennings: >> >> >>> On Sep 20, 2011, at 7:07 AM, Olle E. Johansson wrote: >>> >>> >>>> 20 sep 2011 kl. 15:00 skrev Harald Alvestrand: >>>> >>>> >>>>> Once we start requiring that the PeerConnection know the difference between "early" media and "late" media, it seems to me we're slipping down a slippery slope. >>>>> >>>> The difference between early and late media is purely a billing decision in PSTN. I don't think we should separate these on the rtcweb side. It's a PSTN gateway issue, not something to be bothered with in rtcweb. >>>> >>>> "The campaign to simplify call states" >>>> >>> Simplification is good - just make sure that it is possible to gateway to a SIP call to 1-800-go-fedex. A simplification that broke that would, in my personal opinion, would not be acceptable. (and I think that early media is a bit more than just a billing artifact but that's a longer story). You agree? >>> >> Absolutely, but if the call is in UP state on the rtcweb side as soon as the PSTN/SIP gateway receives early media we will have no issue with sending DTMF in early media, which is what you are trying to trick me with :-) >> > really I was not going to mention DTMF :-) > > I was thinking a a call where the browser initiates the call, sends something to the web2sip signaling gateway that sends a SIP invite to the PSTN GW. Now the PSTN gateway sends a 180 and starts ICE. The PSTN GW sounds like a room pressure aware device that may encounter said vacuum space on return. That resolves the potential error on GLARE exceptions. Instead of "stable", the mobile units wants ubiquity with real-time GLARE-to-FIXATED states, smoothly. Or; in return, the display unit and mobile unit become actors in use-cases (and used-cases), so we clarified (the two) for rtp-usage. JIT repository is FIXATED when there is no HTTP sent/delivered due to non-expired certificates. Browsers that have no encryption provided by the certificate is not obligated to store such bytecode in non-obvious encryption; thus, raises the bar a little on reason to federate to FIXATED-known headers; no X-, no 0day. JIT repository that stay FIXATED for more than one day are then valuable. The sites' bytecodes simply tune-out the origin servers that deal only with unified user-agents, as the FIXATED state cares more about the agent than the user (note-well vs. E911 recommendations). SIP presents RTCWeb with many ways to undo, untwist, or simply focus on the user more, yet professionally there is no FIXATED state, or we have no professional reason why such FIXATED state of JIT does not exist and displays continue to consume power while on-the-... federated signal. Elevators that just want the SSRC for MMUSIC, there are professionally known geolocations for that range and length of signal. We think of treats, not tricks. > Then the PSTN GW starts sending RTP with the fedex prompts in them and then it eventually sends a 200. The key thing is the browser needed to be able to receive RTP before the signaling gateway received the 200. As long as we are on the same page there, it's good with me. The PSTN GW sends the RTP directly to the the browser but sends the SIP to the signaling gateway. > > > >> Now, if we force early media which is supposed to be one-way, not many implementations would support fedex. I don't see this as a problem if we just forget the early-media and late-media difference and just talk about media and if it's up or not up. That would handle ringback as well. >> > I could care less about if the media is 1 way or two way. I just care about hearing the prompts when I call 1-800-fedex. (I care about early media, not one way media :-) > > >> In my head, rtcweb is only the handset of a phone. The phone knows about early media, but the handset just has a mike and a speaker and it's simply on or off. >> > sure - not problem with that > > >> >> >>> That said, I think that doing both forking and early media is hard. Lets assume we are using a signaling gateway that is not a media gateway to translate between a SIP call on one side and whatever is happening over on the browser side. The basic issue is the browser initiating the communications needs to be able to start receiving multiple RTP streams before it even has signaling information to tell it how many it might receive. To simplify this problem, Cary and my draft proposes not allowing forking on the SIP side of the signaling gateway but still allowing early media. If you wanted to do do forking in this case, one would need a SBC that processed media and turned the forked medial legs into one media leg. >>> >> SBS or b2bua - in this case rtcweb to SIP ua. Yep, that's my way of thinking. >> >>> What I'm trying to say is I agree that early media + forking is hard, and the way I would like to simplify that is not allow forking. Note that none of this has much to do with if the PeerConnection object knows if media is early or late - what it needs to deal with is receiving RTP regardless os if the SIP signaling GW had sent it any signaling that indicated what had been in the SIP answer of the SIP side of a signaling GW. >>> >> Agree. >> >> /O >> > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- --- The wheel. From HKaplan@acmepacket.com Tue Sep 20 15:15: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 7E8351F0C4C for ; Tue, 20 Sep 2011 15:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 lCh6i0tYWg4Y for ; Tue, 20 Sep 2011 15:15:07 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id DDA241F0C3D for ; Tue, 20 Sep 2011 15:15:06 -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; Tue, 20 Sep 2011 18:17:29 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 20 Sep 2011 18:17:29 -0400 From: Hadriel Kaplan To: "Olle E. Johansson" Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism Thread-Index: AQHMd+MUG3xcAcKuRUyQ8UuctWvEaQ== Date: Tue, 20 Sep 2011 22:17:27 +0000 Message-ID: <6464AF3F-D87A-4A47-BA3E-C9D3D23D7596@acmepacket.com> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <16825C99-401A-40AF-9721-CAF99C6FE7C2@cisco.com> <548B5B90-F168-4B0D-818C-042B184C00B8@edvina.net> In-Reply-To: <548B5B90-F168-4B0D-818C-042B184C00B8@edvina.net> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 22:15:07 -0000 On Sep 20, 2011, at 5:19 PM, Olle E. Johansson wrote: > Background to the fedex/DTMF hints: >=20 > Fedex for some reason got a deal not only to send early media from a comm= ercial company, but also have an IVR server and request DTMF while still no= t answering the call. This forced a code change in quite a lot of SIP serve= rs... ;-) And it's a lot bigger list than just FedEx. American Airlines, United Airl= ines, the IRS, 1-800-CALL-ATT, etc. (American Airlines is usually the cano= nical example people refer to) -hadriel From HKaplan@acmepacket.com Tue Sep 20 15:33: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 BA01A1F0C56 for ; Tue, 20 Sep 2011 15:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, J_CHICKENPOX_52=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 dKID-x82r1EQ for ; Tue, 20 Sep 2011 15:33:56 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 358741F0C43 for ; Tue, 20 Sep 2011 15:33:55 -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; Tue, 20 Sep 2011 18:36:21 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 20 Sep 2011 18:36:21 -0400 From: Hadriel Kaplan To: Cullen Jennings Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism Thread-Index: AQHMd+W4GbLdjZqw9U+hWOGtS5YVCQ== Date: Tue, 20 Sep 2011 22:36:21 +0000 Message-ID: <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> In-Reply-To: <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 22:33:56 -0000 On Sep 20, 2011, at 4:07 PM, Cullen Jennings wrote: > That said, I think that doing both forking and early media is hard. Lets = assume we are using a signaling gateway that is not a media gateway to tran= slate between a SIP call on one side and whatever is happening over on the = browser side. The basic issue is the browser initiating the communications = needs to be able to start receiving multiple RTP streams before it even has= signaling information to tell it how many it might receive. Not really - there will be signaling, because there has to be SDP answers e= ven just to get ICE to work before the media starts flowing in many NAT cas= es. And even in practice in SIP there're usually SDP answers in 18x to ope= n "gates", and to get upstream DTMF. So if the concern is just that there'= s no signaling to tell the browser there are multiple RTP streams coming, I= think that can be allayed. =20 The really hard part is knowing which stream to use/render/send-to, imho. = And putting that decision in the gateway isn't good - the best decider of t= hat is probably the JS in the browser. > To simplify this problem, Cary and my draft proposes not allowing forking= on the SIP side of the signaling gateway but still allowing early media. I= f you wanted to do do forking in this case, one would need a SBC that proce= ssed media and turned the forked medial legs into one media leg.=20 Obviously you can request that a request not be forked, using caller-prefs,= but you can't "not allow" forking on the SIP side. That would make it not= SIP. I know forking is hard, but that's life. It's not appropriate for t= his WG to make fundamental changes/limitations to the SIP protocol, just be= cause some of it's "hard" for a browser.=20 -hadriel From dwing@cisco.com Tue Sep 20 16:33: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 7FDA31F0C5D for ; Tue, 20 Sep 2011 16:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.286 X-Spam-Level: X-Spam-Status: No, score=-103.286 tagged_above=-999 required=5 tests=[AWL=-0.687, 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 XUUjTK7LLugL for ; Tue, 20 Sep 2011 16:33:10 -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 CB7BC1F0C36 for ; Tue, 20 Sep 2011 16:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=927; q=dns/txt; s=iport; t=1316561736; x=1317771336; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=w1rw02x9/QN5infkjrhMyMyjxLgtQ1HSzho7mIQrtmg=; b=K0n7huSmS8mQWyUqyFmJvO6jNvDPMieoqLdjRArWbAXtyta1pqendSW4 wxZ3hiF3qwKQ5RA/nEZ1Tfp9J2cwVpq+tEd8tVbrvOS1UzCZrRECrJv2l ZgxW9QiWBunwfHnMMHWfyoEN6MmoTURjX8SSdmQsPA65KQsAVo4jItQNO w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsAAA0jeU6rRDoJ/2dsb2JhbAAoGphygWyNBXiBUwEBAQEBAQEICgEXED8FBwEDAgkPAgQBAQEnBxkjCgkIAQEEEwsXh1UGJJR2AZ4ghn0Eh3CdKQ X-IronPort-AV: E=Sophos;i="4.68,413,1312156800"; d="scan'208";a="3302630" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 20 Sep 2011 23:35:36 +0000 Received: from dwingWS ([128.107.106.61]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8KNZZFR008844; Tue, 20 Sep 2011 23:35:35 GMT From: "Dan Wing" To: "'Tim Panton'" References: <4E67C3F7.7020304@jesup.org> <4E67F003.6000108@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852233E8554C@ESESSCMS0356.eemea.ericsson.se> <4E6A56D4.2030602@skype.net> <4E6A81EC.3080002@jesup.org>, <4E6AE22A.2070106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7C5@ESESSCMS0356.eemea.ericsson.se>, <4E6C16FF.1000706@jesup.org> <4E6CB9F7.2060208@mozilla.com> <4E6DB7F4.3090404@skype.net> <09b501c c726d$66655360$332ffa 20$@com> <52B1B3C9-A5D2-473A-9A7F-FC7EE6EAD259@phonefromhere.com> In-Reply-To: <52B1B3C9-A5D2-473A-9A7F-FC7EE6EAD259@phonefromhere.com> Date: Tue, 20 Sep 2011 16:35:35 -0700 Message-ID: <14cf01cc77ed$ff2808b0$fd781a10$@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: AcxzjUrVUk6hk7meSNao0M0K0YEQCgEYJ9yQ Content-Language: en-us Cc: rtcweb@ietf.org Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 20 Sep 2011 23:33:11 -0000 > -----Original Message----- > From: Tim Panton [mailto:tim@phonefromhere.com] > Sent: Thursday, September 15, 2011 2:53 AM > To: Dan Wing > Cc: 'Matthew Kaufman'; 'Timothy B. Terriberry'; rtcweb@ietf.org > Subject: Re: [rtcweb] AVPF [was: Encryption mandate (and offer/answer)] > > > On 14 Sep 2011, at 00:32, Dan Wing wrote: > >> > > > > SDES is also not as secure as DTLS-SRTP, reference RFC5479. > > > > -d > > > I had my mind rather forcibly changed on this by reading this: > https://www.owasp.org/index.php/File:SSL_paved_with_good_intentions.pdf > and > http://www.slate.com/id/2265204/ > > Basically any key exchange that depends for it's security on https: is > worthless. DTLS-SRTP does not validate certificates at all like HTTPS. -d > Tim (as usual speaking for himself) > > P.S. I particularly enjoyed the idea of embedding logos in X509 certs > (seems this is valid).= From pravindran@sonusnet.com Tue Sep 20 19:09: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 F12FA21F89BA for ; Tue, 20 Sep 2011 19:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_52=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 8o3He121I20s for ; Tue, 20 Sep 2011 19:09:07 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 65C3121F851F for ; Tue, 20 Sep 2011 19:08:53 -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 p8L2Bm3V002054; Tue, 20 Sep 2011 22:11:48 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Sep 2011 22:11:17 -0400 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, 21 Sep 2011 07:41:08 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0E5E@sonusinmail02.sonusnet.com> In-Reply-To: <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism Thread-Index: AQHMd+W4GbLdjZqw9U+hWOGtS5YVCZVXDZYg References: <4E777500.5030201@alvestrand.no><69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com><7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se><4E788458.1090108@alvestrand.no><7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se><4E788E5C.9090306@alvestrand.no><11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net><27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> From: "Ravindran Parthasarathi" To: "Hadriel Kaplan" , "Cullen Jennings" X-OriginalArrivalTime: 21 Sep 2011 02:11:17.0363 (UTC) FILETIME=[BF1F3430:01CC7803] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 02:09:12 -0000 Forking in SIP does not apply in the literal sense to lot of SIP applications (ISDN-SIP gateway, End-point which can't perform mixing). In case of ISDN-SIP gateway, SIP callleg has to handle all forked dialogs till 200 OK is received from anyone of the UAS and reject all other dialogs with CANCEL, the media plane update is depend upon the implementation whether to override the last SDP in media plane in case mixing is not possible. I'm saying in this mail thread to highlight forking handling in browser (as a SIP UA application) is not an exception and it is the decision which has to be taken by any SIP application development (and not SIP framework) for that matter.=20 SIP application forking behavior depends upon RTP model (endpoint or mixer). In case browser acts only as endpoint, I agree with Cullen that forking shall be handled by browser without application aware and no need of API or callback.=20 The counter argument may be that my innovative mixing application in browser is stopped by this API model. In the generic SIP framework, the callbacks are provided to handle this situation, default callback function (browser as endpoint) are provided to reduce the application awareness. From the API perspective, offer & answer state machine is not required to be handled in application but we required to know whether the application prefers which media model whether as end-point or mixer and let end-point model be default. IMO, it is browser API design which belongs to W3C. Please correct me here in case this API design is somehow related to IETF. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Hadriel Kaplan >Sent: Wednesday, September 21, 2011 4:06 AM >To: Cullen Jennings >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP >negotiation mechanism > > >On Sep 20, 2011, at 4:07 PM, Cullen Jennings wrote: > >> That said, I think that doing both forking and early media is hard. >Lets assume we are using a signaling gateway that is not a media gateway >to translate between a SIP call on one side and whatever is happening >over on the browser side. The basic issue is the browser initiating the >communications needs to be able to start receiving multiple RTP streams >before it even has signaling information to tell it how many it might >receive. > >Not really - there will be signaling, because there has to be SDP >answers even just to get ICE to work before the media starts flowing in >many NAT cases. And even in practice in SIP there're usually SDP >answers in 18x to open "gates", and to get upstream DTMF. So if the >concern is just that there's no signaling to tell the browser there are >multiple RTP streams coming, I think that can be allayed. > >The really hard part is knowing which stream to use/render/send-to, >imho. And putting that decision in the gateway isn't good - the best >decider of that is probably the JS in the browser. > > >> To simplify this problem, Cary and my draft proposes not allowing >forking on the SIP side of the signaling gateway but still allowing >early media. If you wanted to do do forking in this case, one would need >a SBC that processed media and turned the forked medial legs into one >media leg. > >Obviously you can request that a request not be forked, using caller- >prefs, but you can't "not allow" forking on the SIP side. That would >make it not SIP. I know forking is hard, but that's life. It's not >appropriate for this WG to make fundamental changes/limitations to the >SIP protocol, just because some of it's "hard" for a browser. > >-hadriel > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From roman@telurix.com Tue Sep 20 19:18: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 841AC21F8C47 for ; Tue, 20 Sep 2011 19:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=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 XiBiBqouJNky for ; Tue, 20 Sep 2011 19:18:15 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C62E21F8C46 for ; Tue, 20 Sep 2011 19:18:15 -0700 (PDT) Received: by gxk19 with SMTP id 19so1015134gxk.31 for ; Tue, 20 Sep 2011 19:20:42 -0700 (PDT) Received: by 10.236.201.129 with SMTP id b1mr1271860yho.19.1316571642505; Tue, 20 Sep 2011 19:20:42 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id z53sm4654104yhj.7.2011.09.20.19.20.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 19:20:41 -0700 (PDT) Received: by gyd12 with SMTP id 12so1013303gyd.31 for ; Tue, 20 Sep 2011 19:20:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.29.66 with SMTP id i2mr592956pbh.375.1316571640897; Tue, 20 Sep 2011 19:20:40 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Tue, 20 Sep 2011 19:20:40 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0E5E@sonusinmail02.sonusnet.com> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF510F0E5E@sonusinmail02.sonusnet.com> Date: Tue, 20 Sep 2011 22:20:40 -0400 Message-ID: From: Roman Shpount To: Ravindran Parthasarathi Content-Type: multipart/alternative; boundary=bcaec520e88bfa20fc04ad6a38c9 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 02:18:16 -0000 --bcaec520e88bfa20fc04ad6a38c9 Content-Type: text/plain; charset=ISO-8859-1 Small correction to what you are saying -- new dialogs cannot be stopped using CANCEL (this will stop all dialogs). They can only be stopped using BYE. I would consider it very unfortunate if we decide not to support forking in RTC. It needs to be handled, and not in signaling, but by defining what to do with multiple incoming media RTP streams and multiple answers. The simplest model would be ignore everything except the RTP media defined in the last answer and have an ability to update the answer to the last offer. Alternative would be to create a new PeerConnection based on a new answer (this is API change so should probably go to W3C). _____________ Roman Shpount On Tue, Sep 20, 2011 at 10:11 PM, Ravindran Parthasarathi < pravindran@sonusnet.com> wrote: > Forking in SIP does not apply in the literal sense to lot of SIP > applications (ISDN-SIP gateway, End-point which can't perform mixing). > In case of ISDN-SIP gateway, SIP callleg has to handle all forked > dialogs till 200 OK is received from anyone of the UAS and reject all > other dialogs with CANCEL, the media plane update is depend upon the > implementation whether to override the last SDP in media plane in case > mixing is not possible. I'm saying in this mail thread to highlight > forking handling in browser (as a SIP UA application) is not an > exception and it is the decision which has to be taken by any SIP > application development (and not SIP framework) for that matter. > > SIP application forking behavior depends upon RTP model (endpoint or > mixer). In case browser acts only as endpoint, I agree with Cullen that > forking shall be handled by browser without application aware and no > need of API or callback. > > The counter argument may be that my innovative mixing application in > browser is stopped by this API model. In the generic SIP framework, the > callbacks are provided to handle this situation, default callback > function (browser as endpoint) are provided to reduce the application > awareness. From the API perspective, offer & answer state machine is not > required to be handled in application but we required to know whether > the application prefers which media model whether as end-point or mixer > and let end-point model be default. IMO, it is browser API design which > belongs to W3C. Please correct me here in case this API design is > somehow related to IETF. > > Thanks > Partha > > >-----Original Message----- > >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On > Behalf > >Of Hadriel Kaplan > >Sent: Wednesday, September 21, 2011 4:06 AM > >To: Cullen Jennings > >Cc: rtcweb@ietf.org > >Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP > >negotiation mechanism > > > > > >On Sep 20, 2011, at 4:07 PM, Cullen Jennings wrote: > > > >> That said, I think that doing both forking and early media is hard. > >Lets assume we are using a signaling gateway that is not a media > gateway > >to translate between a SIP call on one side and whatever is happening > >over on the browser side. The basic issue is the browser initiating the > >communications needs to be able to start receiving multiple RTP streams > >before it even has signaling information to tell it how many it might > >receive. > > > >Not really - there will be signaling, because there has to be SDP > >answers even just to get ICE to work before the media starts flowing in > >many NAT cases. And even in practice in SIP there're usually SDP > >answers in 18x to open "gates", and to get upstream DTMF. So if the > >concern is just that there's no signaling to tell the browser there are > >multiple RTP streams coming, I think that can be allayed. > > > >The really hard part is knowing which stream to use/render/send-to, > >imho. And putting that decision in the gateway isn't good - the best > >decider of that is probably the JS in the browser. > > > > > >> To simplify this problem, Cary and my draft proposes not allowing > >forking on the SIP side of the signaling gateway but still allowing > >early media. If you wanted to do do forking in this case, one would > need > >a SBC that processed media and turned the forked medial legs into one > >media leg. > > > >Obviously you can request that a request not be forked, using caller- > >prefs, but you can't "not allow" forking on the SIP side. That would > >make it not SIP. I know forking is hard, but that's life. It's not > >appropriate for this WG to make fundamental changes/limitations to the > >SIP protocol, just because some of it's "hard" for a browser. > > > >-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 > --bcaec520e88bfa20fc04ad6a38c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Small correction to what you are saying -- new dialogs cannot be stopped us= ing CANCEL (this will stop all dialogs). They can only be stopped using BYE= .

I would consider it very unfortunate if we decide not to support f= orking in RTC. It needs to be handled, and not in signaling, but by definin= g what to do with multiple incoming media RTP streams and multiple answers.= The simplest model would be ignore everything except the RTP media defined= in the last answer and have an ability to update the answer to the last of= fer. Alternative would be to create a new PeerConnection based on a new ans= wer (this is API change so should probably go to W3C).
_____________
Roman Shpount


On Tue, Sep 20, 2011 at 10:11 PM, Ravind= ran Parthasarathi <pravindran@sonusnet.com> wrote:
Forking in SIP does not apply in the literal sense to lot of SIP
applications (ISDN-SIP gateway, End-point which can't perform mixing).<= br> In case of ISDN-SIP gateway, SIP callleg has to handle all forked
dialogs till 200 OK is received from anyone of the UAS and reject all
other dialogs with CANCEL, the media plane update is depend upon the
implementation whether to override the last SDP in media plane in case
mixing is not possible. I'm saying in this mail thread to highlight
forking handling in browser (as a SIP UA application) is not an
exception and it is the decision which has to be taken by any SIP
application development (and not SIP framework) for that matter.

SIP application forking behavior depends upon RTP model (endpoint or
mixer). In case browser acts only as endpoint, I agree with Cullen that
forking shall be handled by browser without application aware and no
need of API or callback.

The counter argument may be that my innovative mixing application in
browser is stopped by this API model. =A0In the generic SIP framework, the<= br> callbacks are provided to handle this situation, default callback
function (browser as endpoint) are provided to reduce the application
awareness. From the API perspective, offer & answer state machine is no= t
required to be handled in application but we required to know whether
the application prefers which media model whether as end-point or mixer
and let end-point model be default. IMO, it is browser API design which
belongs to W3C. Please correct me here in case this API design is
somehow related to IETF.

Thanks
Partha

>-----Original Message-----
>From: rtcweb-bounces@ietf.or= g [mailto:rtcweb-bounces@iet= f.org] On
Behalf
>Of Hadriel Kaplan
>Sent: Wednesday, September 21, 2011 4:06 AM
>To: Cullen Jennings
>Cc: rtcweb@ietf.org
>Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP >negotiation mechanism
>
>
>On Sep 20, 2011, at 4:07 PM, Cullen Jennings wrote:
>
>> That said, I think that doing both forking and early media is hard= .
>Lets assume we are using a signaling gateway that is not a media
gateway
>to translate between a SIP call on one side and whatever is happening >over on the browser side. The basic issue is the browser initiating the=
>communications needs to be able to start receiving multiple RTP streams=
>before it even has signaling information to tell it how many it might >receive.
>
>Not really - there will be signaling, because there has to be SDP
>answers even just to get ICE to work before the media starts flowing in=
>many NAT cases. =A0And even in practice in SIP there're usually SDP=
>answers in 18x to open "gates", and to get upstream DTMF. =A0= So if the
>concern is just that there's no signaling to tell the browser there= are
>multiple RTP streams coming, I think that can be allayed.
>
>The really hard part is knowing which stream to use/render/send-to,
>imho. =A0And putting that decision in the gateway isn't good - the = best
>decider of that is probably the JS in the browser.
>
>
>> To simplify this problem, Cary and my draft proposes not allowing<= br> >forking on the SIP side of the signaling gateway but still allowing
>early media. If you wanted to do do forking in this case, one would
need
>a SBC that processed media and turned the forked medial legs into one >media leg.
>
>Obviously you can request that a request not be forked, using caller- >prefs, but you can't "not allow" forking on the SIP side.= =A0That would
>make it not SIP. =A0I know forking is hard, but that's life. =A0It&= #39;s not
>appropriate for this WG to make fundamental changes/limitations to the<= br> >SIP protocol, just because some of it's "hard" for a brow= ser.
>
>-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

--bcaec520e88bfa20fc04ad6a38c9-- From oej@edvina.net Tue Sep 20 23:16: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 8DED621F8B6D for ; Tue, 20 Sep 2011 23:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_52=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 ShzBXeuNQGpL for ; Tue, 20 Sep 2011 23:16:16 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 8977021F8B59 for ; Tue, 20 Sep 2011 23:16:16 -0700 (PDT) Received: from [IPv6:2001:470:1f15:d79:1921:6f02:2098:710d] (unknown [IPv6:2001:470:1f15:d79:1921:6f02:2098:710d]) by smtp7.webway.se (Postfix) with ESMTPA id D9769754BCE4; Wed, 21 Sep 2011 06:18:39 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> Date: Wed, 21 Sep 2011 08:18:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9F6A723B-8386-40F6-8ABC-4935F42B7D36@edvina.net> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1244.3) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 06:16:17 -0000 21 sep 2011 kl. 00:36 skrev Hadriel Kaplan: >=20 > On Sep 20, 2011, at 4:07 PM, Cullen Jennings wrote: >=20 >> That said, I think that doing both forking and early media is hard. = Lets assume we are using a signaling gateway that is not a media gateway = to translate between a SIP call on one side and whatever is happening = over on the browser side. The basic issue is the browser initiating the = communications needs to be able to start receiving multiple RTP streams = before it even has signaling information to tell it how many it might = receive. >=20 > Not really - there will be signaling, because there has to be SDP = answers even just to get ICE to work before the media starts flowing in = many NAT cases. And even in practice in SIP there're usually SDP = answers in 18x to open "gates", and to get upstream DTMF. So if the = concern is just that there's no signaling to tell the browser there are = multiple RTP streams coming, I think that can be allayed. =20 >=20 > The really hard part is knowing which stream to use/render/send-to, = imho. And putting that decision in the gateway isn't good - the best = decider of that is probably the JS in the browser. Food for thought. >=20 >=20 >> To simplify this problem, Cary and my draft proposes not allowing = forking on the SIP side of the signaling gateway but still allowing = early media. If you wanted to do do forking in this case, one would need = a SBC that processed media and turned the forked medial legs into one = media leg.=20 >=20 > Obviously you can request that a request not be forked, using = caller-prefs, but you can't "not allow" forking on the SIP side. That = would make it not SIP. I know forking is hard, but that's life. It's = not appropriate for this WG to make fundamental changes/limitations to = the SIP protocol, just because some of it's "hard" for a browser.=20 But it will be appropriate to avoid SIP as a requirement within the = RTCweb architecture because of that. I'm not saying that a new SIP = dialect can't be built - but I think it's another WG's task.=20 /O= From pravindran@sonusnet.com Tue Sep 20 23:23: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 163A121F8C1A for ; Tue, 20 Sep 2011 23:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=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 cRR5Pb8pK8ps for ; Tue, 20 Sep 2011 23:23:24 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id DAC9521F8C0C for ; Tue, 20 Sep 2011 23:23:23 -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 p8L6QKQ5006549; Wed, 21 Sep 2011 02:26:20 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Sep 2011 02:25:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC7827.4BC34839" Date: Wed, 21 Sep 2011 11:55:45 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0E6B@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism Thread-Index: Acx4BRNOQgN6BStIT/S6yHJQj92ghQAH1idA References: <4E777500.5030201@alvestrand.no><69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com><7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se><4E788458.1090108@alvestrand.no><7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se><4E788E5C.9090306@alvestrand.no><11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net><27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com><6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF510F0E5E@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: "Roman Shpount" X-OriginalArrivalTime: 21 Sep 2011 06:25:48.0745 (UTC) FILETIME=[4D932B90:01CC7827] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 06:23:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC7827.4BC34839 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roman, =20 Thanks for the correction. I agree with you that there is no need to mention that forking is not support in RTCWeb. Your simple model works for browser as RTP End-point. One problem with the generic statement of multiple answer is that it may violate offer/answer model itself. For example: 18x and 200 having different answer for INVITE offer (standard implementation violation of offer/answer ;-)) =20 Hope we are in the same page that forking related API and its parameters shall be decided by W3C =20 Thanks Partha =20 From: Roman Shpount [mailto:roman@telurix.com]=20 Sent: Wednesday, September 21, 2011 7:51 AM To: Ravindran Parthasarathi Cc: Hadriel Kaplan; Cullen Jennings; rtcweb@ietf.org Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism =20 Small correction to what you are saying -- new dialogs cannot be stopped using CANCEL (this will stop all dialogs). They can only be stopped using BYE. I would consider it very unfortunate if we decide not to support forking in RTC. It needs to be handled, and not in signaling, but by defining what to do with multiple incoming media RTP streams and multiple answers. The simplest model would be ignore everything except the RTP media defined in the last answer and have an ability to update the answer to the last offer. Alternative would be to create a new PeerConnection based on a new answer (this is API change so should probably go to W3C). _____________ Roman Shpount On Tue, Sep 20, 2011 at 10:11 PM, Ravindran Parthasarathi wrote: Forking in SIP does not apply in the literal sense to lot of SIP applications (ISDN-SIP gateway, End-point which can't perform mixing). In case of ISDN-SIP gateway, SIP callleg has to handle all forked dialogs till 200 OK is received from anyone of the UAS and reject all other dialogs with CANCEL, the media plane update is depend upon the implementation whether to override the last SDP in media plane in case mixing is not possible. I'm saying in this mail thread to highlight forking handling in browser (as a SIP UA application) is not an exception and it is the decision which has to be taken by any SIP application development (and not SIP framework) for that matter. SIP application forking behavior depends upon RTP model (endpoint or mixer). In case browser acts only as endpoint, I agree with Cullen that forking shall be handled by browser without application aware and no need of API or callback. The counter argument may be that my innovative mixing application in browser is stopped by this API model. In the generic SIP framework, the callbacks are provided to handle this situation, default callback function (browser as endpoint) are provided to reduce the application awareness. From the API perspective, offer & answer state machine is not required to be handled in application but we required to know whether the application prefers which media model whether as end-point or mixer and let end-point model be default. IMO, it is browser API design which belongs to W3C. Please correct me here in case this API design is somehow related to IETF. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf >Of Hadriel Kaplan >Sent: Wednesday, September 21, 2011 4:06 AM >To: Cullen Jennings >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP >negotiation mechanism > > >On Sep 20, 2011, at 4:07 PM, Cullen Jennings wrote: > >> That said, I think that doing both forking and early media is hard. >Lets assume we are using a signaling gateway that is not a media gateway >to translate between a SIP call on one side and whatever is happening >over on the browser side. The basic issue is the browser initiating the >communications needs to be able to start receiving multiple RTP streams >before it even has signaling information to tell it how many it might >receive. > >Not really - there will be signaling, because there has to be SDP >answers even just to get ICE to work before the media starts flowing in >many NAT cases. And even in practice in SIP there're usually SDP >answers in 18x to open "gates", and to get upstream DTMF. So if the >concern is just that there's no signaling to tell the browser there are >multiple RTP streams coming, I think that can be allayed. > >The really hard part is knowing which stream to use/render/send-to, >imho. And putting that decision in the gateway isn't good - the best >decider of that is probably the JS in the browser. > > >> To simplify this problem, Cary and my draft proposes not allowing >forking on the SIP side of the signaling gateway but still allowing >early media. If you wanted to do do forking in this case, one would need >a SBC that processed media and turned the forked medial legs into one >media leg. > >Obviously you can request that a request not be forked, using caller- >prefs, but you can't "not allow" forking on the SIP side. That would >make it not SIP. I know forking is hard, but that's life. It's not >appropriate for this WG to make fundamental changes/limitations to the >SIP protocol, just because some of it's "hard" for a browser. > >-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 =20 ------_=_NextPart_001_01CC7827.4BC34839 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roman,

 

Thanks for the correction. I agree with you that there is = no need to mention that forking is not support in RTCWeb. Your simple model = works for browser as RTP End-point. One problem with the generic statement of multiple answer is that it may violate offer/answer model itself. For = example: 18x and 200 having different answer for INVITE offer (standard = implementation violation of offer/answer ;-))

 

Hope we are in the same page that forking related API and = its parameters shall be decided by W3C

 

Thanks

Partha

 

From:= Roman = Shpount [mailto:roman@telurix.com]
Sent: Wednesday, September 21, 2011 7:51 AM
To: Ravindran Parthasarathi
Cc: Hadriel Kaplan; Cullen Jennings; rtcweb@ietf.org
Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal = SDP negotiation mechanism

 

Small correction to = what you are saying -- new dialogs cannot be stopped using CANCEL (this will stop = all dialogs). They can only be stopped using BYE.

I would consider it very unfortunate if we decide not to support forking = in RTC. It needs to be handled, and not in signaling, but by defining what = to do with multiple incoming media RTP streams and multiple answers. The = simplest model would be ignore everything except the RTP media defined in the = last answer and have an ability to update the answer to the last offer. = Alternative would be to create a new PeerConnection based on a new answer (this is = API change so should probably go to W3C).
_____________
Roman Shpount

On Tue, Sep 20, 2011 at 10:11 PM, Ravindran = Parthasarathi <pravindran@sonusnet.com> wrote:

Forking in SIP does not apply in the literal sense = to lot of SIP
applications (ISDN-SIP gateway, End-point which can't perform = mixing).
In case of ISDN-SIP gateway, SIP callleg has to handle all forked
dialogs till 200 OK is received from anyone of the UAS and reject = all
other dialogs with CANCEL, the media plane update is depend upon the
implementation whether to override the last SDP in media plane in = case
mixing is not possible. I'm saying in this mail thread to highlight
forking handling in browser (as a SIP UA application) is not an
exception and it is the decision which has to be taken by any SIP
application development (and not SIP framework) for that matter.

SIP application forking behavior depends upon RTP model (endpoint or
mixer). In case browser acts only as endpoint, I agree with Cullen = that
forking shall be handled by browser without application aware and no
need of API or callback.

The counter argument may be that my innovative mixing application in
browser is stopped by this API model.  In the generic SIP = framework, the
callbacks are provided to handle this situation, default callback
function (browser as endpoint) are provided to reduce the = application
awareness. From the API perspective, offer & answer state machine is = not
required to be handled in application but we required to know = whether
the application prefers which media model whether as end-point or = mixer
and let end-point model be default. IMO, it is browser API design = which
belongs to W3C. Please correct me here in case this API design is
somehow related to IETF.

Thanks
Partha

>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
Behalf
>Of Hadriel Kaplan
>Sent: Wednesday, September 21, 2011 4:06 AM
>To: Cullen Jennings
>Cc: rtcweb@ietf.org
>Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal = SDP
>negotiation mechanism
>
>
>On Sep 20, 2011, at 4:07 PM, Cullen Jennings wrote:
>
>> That said, I think that doing both forking and early media is = hard.
>Lets assume we are using a signaling gateway that is not a media
gateway
>to translate between a SIP call on one side and whatever is = happening
>over on the browser side. The basic issue is the browser initiating = the
>communications needs to be able to start receiving multiple RTP = streams
>before it even has signaling information to tell it how many it = might
>receive.
>
>Not really - there will be signaling, because there has to be = SDP
>answers even just to get ICE to work before the media starts flowing = in
>many NAT cases.  And even in practice in SIP there're usually = SDP
>answers in 18x to open "gates", and to get upstream DTMF.  So if the
>concern is just that there's no signaling to tell the browser there = are
>multiple RTP streams coming, I think that can be allayed.
>
>The really hard part is knowing which stream to = use/render/send-to,
>imho.  And putting that decision in the gateway isn't good - = the best
>decider of that is probably the JS in the browser.
>
>
>> To simplify this problem, Cary and my draft proposes not = allowing
>forking on the SIP side of the signaling gateway but still = allowing
>early media. If you wanted to do do forking in this case, one = would
need
>a SBC that processed media and turned the forked medial legs into = one
>media leg.
>
>Obviously you can request that a request not be forked, using = caller-
>prefs, but you can't "not allow" forking on the SIP side.  That would
>make it not SIP.  I know forking is hard, but that's life. =  It's not
>appropriate for this WG to make fundamental changes/limitations to = the
>SIP protocol, just because some of it's "hard" for a = browser.
>
>-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

 

------_=_NextPart_001_01CC7827.4BC34839-- From saul@ag-projects.com Tue Sep 20 23:58: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 9B63421F8C61 for ; Tue, 20 Sep 2011 23:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vy1l3CtUWT-c for ; Tue, 20 Sep 2011 23:57:59 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id B09F721F8C37 for ; Tue, 20 Sep 2011 23:57:58 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 49076B01B5; Wed, 21 Sep 2011 09:00:23 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id A894FB0057; Wed, 21 Sep 2011 09:00:10 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0E6B@sonusinmail02.sonusnet.com> Date: Wed, 21 Sep 2011 09:00:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8508ACC4-75A0-4556-8474-66175539F102@ag-projects.com> References: <4E777500.5030201@alvestrand.no><69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com><7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se><4E788458.1090108@alvestrand.no><7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se><4E788E5C.9090306@alvestrand.no><11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net><27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com><6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com><2E239D6FCD033C4BAF15F386A979BF510F0E5E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F0E6B@sonusinmail02.sonusnet.com> To: "Ravindran Parthasarathi" X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 06:58:00 -0000 On Sep 21, 2011, at 8:25 AM, Ravindran Parthasarathi wrote: > Hi Roman, > =20 > Thanks for the correction. I agree with you that there is no need to = mention that forking is not support in RTCWeb. Your simple model works = for browser as RTP End-point. One problem with the generic statement of = multiple answer is that it may violate offer/answer model itself. For = example: 18x and 200 having different answer for INVITE offer (standard = implementation violation of offer/answer ;-)) > =20 I think that the case discussed before was that you may receive several = 18x responses because the request forked in the SIP side. So, if more = than one of these 18x responses do have an SDP, do we create a = PeerConnection for each? One for the first? The last? -- Sa=FAl Ibarra Corretg=E9 AG Projects From harald@alvestrand.no Tue Sep 20 23:59: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 0478321F8CBC for ; Tue, 20 Sep 2011 23:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.261 X-Spam-Level: X-Spam-Status: No, score=-108.261 tagged_above=-999 required=5 tests=[AWL=2.338, 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 7JdEVRRkgeyl for ; Tue, 20 Sep 2011 23:59:42 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1B65021F8C37 for ; Tue, 20 Sep 2011 23:59:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7224939E0A7; Wed, 21 Sep 2011 09:02:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbMHfwaXK61J; Wed, 21 Sep 2011 09:02:08 +0200 (CEST) Received: from [192.168.0.2] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id DAA0A39E088; Wed, 21 Sep 2011 09:02:08 +0200 (CEST) Message-ID: <4E798BF0.8030407@alvestrand.no> Date: Wed, 21 Sep 2011 09:02:08 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Cullen Jennings References: <4E777500.5030201@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] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 06:59:43 -0000 On 09/20/2011 10:08 PM, Cullen Jennings wrote: > I think this sounds about right to me - I have been thinking about a draft along the lines of this and showing how it maps to SIP. Keep in mind there are also cases where one sides sends an OFFER, gets an ANSWER, but that ANSWER has an error. Yes, I discussed this at our team yesterday - it seems to me that the offer/answer model only gives you 2 options here: - Send another OFFER and hope for a more appropriate ANSWER - Give up and signal that the connection is closed We don't have a message that fits in the SDP offer/answer model that allows you to inform the correspondent that the ANSWER was erroneous; this may argue that the PeerConnection needs to inform the Javascript layer and let that layer decide what to do. > I think another key component is that a signaling GW needs to pass along an opaque blob that gets passed back to it so you can signaling GW that are only transaction state full and don't have to retain state for the duration of the communications. Certainly desirable (for gateways that don't want to mess with blob internals). So far, it has seemed to us that the operation line + the SDP blob forms exactly that type of blob. > You also need some identifier information so that a JS application participating in multiple sessions can know what session a given piece of SDP goes with. When the message goes between JS and PeerConnection, there is such an identifier: The PeerConnection object itself. Do we need more? If the ID needs to be passed outside of the JS execution context, we need a globally unique identifier. But I'm not sure we need one all the time, and if a specific application needs it, it can generate one. > > On Sep 19, 2011, at 10:59 AM, Harald Alvestrand wrote: > >> I am looking at the WEBRTC API spec, which specifies a rudimentary negotiation framework: SDP objects prefixed by the string "SDP". >> >> It seems clear to me that this needs at least information about whether something is an offer or an answer, and some way to complete the transaction when an offer is sent and something prevents it from completing. >> Until we know we need more, what about the following, to be specified in the WEBRTC API? >> >> SDP objects are sent through the API, prefixed with either of >> >> SDP OFFER >> SDP ANSWER >> >> Alternatively, one can pass >> >> SDP ERROR >> >> to reply to an SDP OFFER when something goes wrong. >> >> If one gets an OFFER and sends out an ANSWER, state changes. >> If OFFER gets an ANSWER back, state changes. >> In all other cases, state is as before. >> >> We need to handle glare - when one sends an OFFER and gets back an OFFER, reply with SDP ERROR, enter a "glare" state, wait a bit, and send out an offer again. >> >> Do we really have to have anything else? >> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > From randell-ietf@jesup.org Wed Sep 21 00:08: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 B8DD121F8A71 for ; Wed, 21 Sep 2011 00:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 VdFMJe85pelQ for ; Wed, 21 Sep 2011 00:08: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 6222921F8B3E for ; Wed, 21 Sep 2011 00:08:49 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R6Gxg-0002wb-LO for rtcweb@ietf.org; Wed, 21 Sep 2011 02:11:16 -0500 Message-ID: <4E798D47.5030905@jesup.org> Date: Wed, 21 Sep 2011 03:07:51 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2EB@ESESSCMS0356.eemea.ericsson.se> <1A61D589-1C23-4364-AA4A-60338D8C5859@edvina.net> In-Reply-To: <1A61D589-1C23-4364-AA4A-60338D8C5859@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Forking & Early Media - Proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 07:08:50 -0000 NOTE: Attached below is a proposed set of forking/early-media and clipping-avoidance rules, so don't glance and delete! :-) Also note: I started writing this earlier today, so it was largely done before much of today's discussion on forking. I'll note that I include in this a method to minimize chances of answer-time clipping. (For any who don't know (if there are any), this is where the first fraction of a second after pickup is lost while answering, starting codecs, doing ICE, etc.) On 9/20/2011 9:40 AM, Olle E. Johansson wrote: > 20 sep 2011 kl. 15:15 skrev Christer Holmberg: > >>>> Once we start requiring that the PeerConnection know the >>>> difference between "early" media and "late" media, it seems >>>> to me we're slipping down a slippery slope. >>> The difference between early and late media is purely a >>> billing decision in PSTN. I don't think we should separate >>> these on the rtcweb side. It's a PSTN gateway issue, not >>> something to be bothered with in rtcweb. >> It's not about knowing the difference between "early" and "late" media - it's about whether the API and browser need to support multiple SIMULTANOUS SDP answers - or whether we assume that the JS SIP app will always, at any given time, only provide ONE SDP answer to the API and browser. > I just wanted to get rid of the early/late media discussion. As you state, the forking issue with getting multiple responses is a separate issue. > > Do we have any use cases using forking? Is forking a desired feature or something that SIP brought in? No, this is something inherent in a person you want to converse with possibly being in different places. Different phones in a home, different computers in a home or out of it (your desktop, your laptop, your tablet, your work computer, your Android phone) - when someone wants to talk to you on Skype or what have you, often the service will want to offer the connection to any and all devices you're logged into the service from. So, it forks the request. We'd have this issue even if we totally disallow SIP and disallow PSTN connectivity. If you require that the website/server handle this and only provide one answer, you're much more likely to clip the answer (lose audio right after accept while the channels are being opened). Two things in particular appear here. One is early media (I want to send media to you but no one has accepted). I do not propose that rtcweb generate early media; some sort of "alerting" notification is enough (equivalent to 180). (Realize that means no custom callback tones or video, or weird cases like sitting on hold or in an IVR while not actually "in" a call). If so, we only have to worry about interop cases - calling out to legacy, or *maybe* a call forked in rtcweb where one of the forks goes to a legacy device or gateway that sends early media. The other is choosing which answer to accept if multiple arrive; that can be up to the application I think (though 99% likely the app will want to use the first answer). I don't think we have to *mandate* that the first answer is the one we use though I can't think of any cases where we wouldn't, but I'm pretty sure they exist and I wouldn't want to outlaw them for no reason). If it makes any use-cases easier to mandate the first answer, that may change my opinion. If you're using SIP (JS or not) that might affect the answer, of course. While waiting for an acceptance, it makes *lots* of sense to "warm up" the connection(s) so that when the call is accepted there's minimal delay or pickup loss. "warm up" means to do an ICE exchange and possibly even instantiate codecs, etc. This is complicated by not knowing the final answer until the user decides how to answer, but you could warm up the likely streams/codecs in most cases, and drop some if needed on ACCEPT. In the forking case, you could warm up connections to some or all possible answers. (Pacing may be an issue here, but often there are 5-20 seconds to do it in.) Implicit in this is separating ANSWERs from "acceptance", and verifying on "acceptance" that the correct ANSWER is used (for example, we warm up audio and video, and the person answers audio-only, or for some reason chooses a different codec). So, to summarize in psuedo-spec language: 0) I'm assuming an Offer-Answer model here, though not assuming SDP. If you want, read "SDP ANSWER" for "ANSWER", etc to map to Harald's proposals. Note that I add "ACCEPT". 0.1) Rough mapping to SIP: a) INVITE -> OFFER b) 183 -> ANSWER c) 180 -> ANSWER-with-no-media-streams c) 200 -> ANSWER (may be suppressed) + ACCEPT 0.2) I'm assuming OFFERs and ANSWERs and ACCEPTs are delivered on a reliable, in-order channel. 1) webrtc clients WILL NOT send early media [See below; I see no real need for webrtc<->webrtc client connections to send early media, but SIP/PSTN interop cases may require it, so I have an alternative below] 2) when a webrtc client receives a OFFER, it MAY generate a speculative ANSWER in order to allow pre-starting the PeerConnection in a disabled state. If pre-started, NO media shall be sent until the call has been ACCEPTED. Note that the OFFERer may receive data before seeing the ACCEPT. 3) if the ANSWERer generated a speculative ANSWER, it may replace that with an alternative ANSWER before sending ACCEPT. This alternative SHOULD use the same connection address as the original, and if so the existing PeerConnection established or being established SHOULD be retained, but the mediastream configuration changed to match the new ANSWER. 4) the OFFERer SHOULD pre-start PeerConnections on a speculative ANSWER, or they MAY wait until an ACCEPT and then start the last ANSWER from that source. If multiple sources supply speculative ANSWERs, the OFFERer MAY pre-start some, none or all of them as it wishes. [Open question: do we pre-start MediaStreams in each pre-starting PeerConnection, or do (can) we defer this until ACCEPT?] 5) when the OFFERer receives an ACCEPT, it MAY close other PeerConnections opened speculatively. 6) when an ANSWERer sends an accept, it MAY begin sending media immediately if the PeerConnection was pre-started. It SHOULD be ready to receive media before sending the ACCEPT. 7) servers handling signalling for webrtc clients MAY fork a call offer to multiple webrtc clients 8) if a call is forked, the webrtc client MAY receive either a single ANSWER and ACCEPT, or MAY receive multiple ANSWERs with one or more ACCEPTs, depending on how the server works. The provides a way to minimize the chances of start-of-call clipping, and handles forking with minimal clipping (with cooperation of the app). Note that there may be a implementation limit on the number of PeerConnections that can be "warmed up" before an ACCEPT. Yes, if we remove 1) and replace it with (probably lower down) N) webrtc clients MAY send "early media" on a pre-started PeerConnection but MUST NOT send any media without explicit action or consent of the user. webrtc clients MAY play the early media. or N) webrtc media gateways MAY send "early media" on a pre-started PeerConnection, and webrtc clients receiving "early media" MAY play it, and MAY send media (such as DTMF) but MUST NOT send any media without explicit action or consent of the user. (and you have to change 2) above) you get something that is pretty interoperable with legacy SIP devices and especially PSTN gateways or border controllers, including the infamous American Airlines DTMF trick. This assumes a WebRTC<->legacy media gateway is in use (note that all the above is about PeerConnections). I have not tried to figure out how non-gatewayed legacy would work into this, but it should be doable. -- Randell Jesup randell-ietf@jesup.org From oej@edvina.net Wed Sep 21 00:23: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 1CFC421F8B58 for ; Wed, 21 Sep 2011 00:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.006, 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 g5cZwIFDxYOY for ; Wed, 21 Sep 2011 00:23:45 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 6007221F8B53 for ; Wed, 21 Sep 2011 00:23:45 -0700 (PDT) Received: from [192.168.40.76] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 51C55754BCE4; Wed, 21 Sep 2011 07:26:11 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <4E798D47.5030905@jesup.org> Date: Wed, 21 Sep 2011 09:26:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1AD30F47-44DE-4D4E-8FC4-FA652212A050@edvina.net> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2EB@ESESSCMS0356.eemea.ericsson.se> <1A61D589-1C23-4364-AA4A-60338D8C5859@edvina.net> <4E798D47.5030905@jesup.org> To: Randell Jesup X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Forking & Early Media - Proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 07:23:47 -0000 Randell, If you want to go down this whole route and include all this application = stuff in rtcweb, we might as well include all of SIP, because all of = these issues have been worked on in the SIP world for a long time.=20 Personally, I see rtcweb as a much lower layer than you do, which in my = world excludes all this complexity. SIP has been around for many years, and some of the discussion you bring = to the table hasn't been solved yet or is poorly implemented in end = points since they don't understand the complexity. I see no point in = trying to solve all of that again with yet another signalling protocol. We keep going back and forth on the signaling issue here - is it part of = RTCweb? If yes, then we'll have forking, early media, DTMF and all that = luggage including complex ISDN signalling scenarios that are just part = of the German PSTN network and a requirement to have in RTCweb since it = works in the ISDN. You'll have reqiuirements that the browse just HAS to = support five different SIP Subscribe event packages - or the rtcweb = version. If we put signalling out of scope and let the application builder handle = signaling and/or start a separate working group that can define "SIP = lite" I believe we can make progress in rtcweb by focusing on a limited = set of issues. Darn. I feel like the old employee saying "we tried that years ago, it = did not work." to kill all the inspired people that belive they can make = a change. My apologies. Prove me wrong :-) /O 21 sep 2011 kl. 09:07 skrev Randell Jesup: > NOTE: Attached below is a proposed set of forking/early-media > and clipping-avoidance rules, so don't glance and delete! :-) >=20 > Also note: I started writing this earlier today, so it was largely > done before much of today's discussion on forking. I'll note that > I include in this a method to minimize chances of answer-time > clipping. (For any who don't know (if there are any), this is > where the first fraction of a second after pickup is lost while > answering, starting codecs, doing ICE, etc.) >=20 >=20 > On 9/20/2011 9:40 AM, Olle E. Johansson wrote: >> 20 sep 2011 kl. 15:15 skrev Christer Holmberg: >>=20 >>>>> Once we start requiring that the PeerConnection know the >>>>> difference between "early" media and "late" media, it seems >>>>> to me we're slipping down a slippery slope. >>>> The difference between early and late media is purely a >>>> billing decision in PSTN. I don't think we should separate >>>> these on the rtcweb side. It's a PSTN gateway issue, not >>>> something to be bothered with in rtcweb. >>> It's not about knowing the difference between "early" and "late" = media - it's about whether the API and browser need to support multiple = SIMULTANOUS SDP answers - or whether we assume that the JS SIP app will = always, at any given time, only provide ONE SDP answer to the API and = browser. >> I just wanted to get rid of the early/late media discussion. As you = state, the forking issue with getting multiple responses is a separate = issue. >>=20 >> Do we have any use cases using forking? Is forking a desired feature = or something that SIP brought in? >=20 > No, this is something inherent in a person you want to converse with > possibly being in different places. Different phones in a home, > different computers in a home or out of it (your desktop, your laptop, > your tablet, your work computer, your Android phone) - when someone > wants to talk to you on Skype or what have you, often the service will > want to offer the connection to any and all devices you're logged into > the service from. So, it forks the request. We'd have this issue > even if we totally disallow SIP and disallow PSTN connectivity. If > you require that the website/server handle this and only provide one > answer, you're much more likely to clip the answer (lose audio right > after accept while the channels are being opened). >=20 > Two things in particular appear here. One is early media (I want to > send media to you but no one has accepted). I do not propose that > rtcweb generate early media; some sort of "alerting" notification is > enough (equivalent to 180). (Realize that means no custom callback > tones or video, or weird cases like sitting on hold or in an IVR while > not actually "in" a call). If so, we only have to worry about interop > cases - calling out to legacy, or *maybe* a call forked in rtcweb > where one of the forks goes to a legacy device or gateway that sends > early media. >=20 > The other is choosing which answer to accept if multiple arrive; that > can be up to the application I think (though 99% likely the app will > want to use the first answer). I don't think we have to *mandate* > that the first answer is the one we use though I can't think of any > cases where we wouldn't, but I'm pretty sure they exist and I wouldn't > want to outlaw them for no reason). If it makes any use-cases easier > to mandate the first answer, that may change my opinion. If you're > using SIP (JS or not) that might affect the answer, of course. >=20 > While waiting for an acceptance, it makes *lots* of sense to "warm up" > the connection(s) so that when the call is accepted there's minimal > delay or pickup loss. "warm up" means to do an ICE exchange and > possibly even instantiate codecs, etc. This is complicated by not > knowing the final answer until the user decides how to answer, but you > could warm up the likely streams/codecs in most cases, and drop some > if needed on ACCEPT. In the forking case, you could warm up > connections to some or all possible answers. (Pacing may be an issue > here, but often there are 5-20 seconds to do it in.) >=20 > Implicit in this is separating ANSWERs from "acceptance", and > verifying on "acceptance" that the correct ANSWER is used (for > example, we warm up audio and video, and the person answers > audio-only, or for some reason chooses a different codec). >=20 >=20 > So, to summarize in psuedo-spec language: >=20 > 0) I'm assuming an Offer-Answer model here, though not assuming SDP. > If you want, read "SDP ANSWER" for "ANSWER", etc to map to = Harald's > proposals. Note that I add "ACCEPT". > 0.1) Rough mapping to SIP: > a) INVITE -> OFFER > b) 183 -> ANSWER > c) 180 -> ANSWER-with-no-media-streams > c) 200 -> ANSWER (may be suppressed) + ACCEPT > 0.2) I'm assuming OFFERs and ANSWERs and ACCEPTs are delivered on > a reliable, in-order channel. >=20 > 1) webrtc clients WILL NOT send early media > [See below; I see no real need for webrtc<->webrtc client = connections > to send early media, but SIP/PSTN interop cases may require it, so > I have an alternative below] > 2) when a webrtc client receives a OFFER, it MAY generate a = speculative > ANSWER in order to allow pre-starting the PeerConnection in a = disabled > state. If pre-started, NO media shall be sent until the call has = been > ACCEPTED. Note that the OFFERer may receive data before seeing > the ACCEPT. > 3) if the ANSWERer generated a speculative ANSWER, it may replace that > with an alternative ANSWER before sending ACCEPT. This alternative > SHOULD use the same connection address as the original, and if so > the existing PeerConnection established or being established SHOULD > be retained, but the mediastream configuration changed to match > the new ANSWER. > 4) the OFFERer SHOULD pre-start PeerConnections on a speculative = ANSWER, or > they MAY wait until an ACCEPT and then start the last ANSWER from = that > source. If multiple sources supply speculative ANSWERs, the OFFERer > MAY pre-start some, none or all of them as it wishes. > [Open question: do we pre-start MediaStreams in each pre-starting > PeerConnection, or do (can) we defer this until ACCEPT?] > 5) when the OFFERer receives an ACCEPT, it MAY close other = PeerConnections > opened speculatively. > 6) when an ANSWERer sends an accept, it MAY begin sending media = immediately > if the PeerConnection was pre-started. It SHOULD be ready to = receive > media before sending the ACCEPT. > 7) servers handling signalling for webrtc clients MAY fork a call = offer > to multiple webrtc clients > 8) if a call is forked, the webrtc client MAY receive either a single > ANSWER and ACCEPT, or MAY receive multiple ANSWERs with one or more > ACCEPTs, depending on how the server works. >=20 > The provides a way to minimize the chances of start-of-call clipping, > and handles forking with minimal clipping (with cooperation of the > app). Note that there may be a implementation limit on the number of > PeerConnections that can be "warmed up" before an ACCEPT. >=20 > Yes, if we remove 1) and replace it with (probably lower down) >=20 > N) webrtc clients MAY send "early media" on a pre-started = PeerConnection > but MUST NOT send any media without explicit action or consent of = the > user. webrtc clients MAY play the early media. >=20 > or >=20 > N) webrtc media gateways MAY send "early media" on a pre-started = PeerConnection, > and webrtc clients receiving "early media" MAY play it, and MAY send > media (such as DTMF) but MUST NOT send any media without explicit > action or consent of the user. >=20 > (and you have to change 2) above) >=20 > you get something that is pretty interoperable with legacy SIP devices > and especially PSTN gateways or border controllers, including the = infamous > American Airlines DTMF trick. This assumes a WebRTC<->legacy media = gateway > is in use (note that all the above is about PeerConnections). I have = not > tried to figure out how non-gatewayed legacy would work into this, but = it > should be doable. >=20 >=20 > --=20 > Randell Jesup > randell-ietf@jesup.org >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From stefan.lk.hakansson@ericsson.com Wed Sep 21 00:37: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 E8D9421F8C49 for ; Wed, 21 Sep 2011 00:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=-0.037, 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 2YNM3jlIPNs9 for ; Wed, 21 Sep 2011 00:37: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 CF60421F8C48 for ; Wed, 21 Sep 2011 00:37:41 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-72-4e7994d8b400 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B2.88.02839.8D4997E4; Wed, 21 Sep 2011 09:40:09 +0200 (CEST) Received: from [150.132.141.36] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 09:40:08 +0200 Message-ID: <4E7994D7.60102@ericsson.com> Date: Wed, 21 Sep 2011 09:40:07 +0200 From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Emil Ivov References: <4E76E8E8.2050102@ericsson.com> <4E788E00.9020909@ericsson.com> <4E78A467.7040409@jitsi.org> In-Reply-To: <4E78A467.7040409@jitsi.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 07:37:43 -0000 On 2011-09-20 16:34, Emil Ivov wrote: > На 20.09.11 14:58, Stefan Håkansson LK написа: >> I think we should skip both these use cases for the time being. >> >> I think we have more than enough to design and agree on to get real-time >> audio and video (with recording) and p2p data. There are design choices >> to make and agree on all over the place (from user consent to RTP). > > I am not sure I understand the we-already-have-too-much-on-our-plate > argument. If Desktop Sharing is declared optional then the specification > could move at its own pace without blocking other specs or implementations. > >> Besides I think that the most obvious (WebEx-like if you want) use case >> for A is document sharing and slide presentations - and we all know that >> there are several such services available already. So the pieces to >> build them are already available. > > We already have more than several ways of doing VoIP and video calls, > many of which already work in browsers. Obviously, the argument hasn't > prevented us from starting RTCWEB. I should have said that "the pieces to build them are already available _in browsers without the need for using extensions or plugins_" or something similar - I think this is what is put out as the differentiating factor in the rtcweb charter. Anyway, I seem to be rather lonely in my corner of the room, but I maintain my opinion that we should defer this to a later stage. > > Emil > >> >> So my 2 cents say: let's push this into phase 2, and focus on getting >> phase 1 out in a timely manner :) Sorry for not being enthusiastic. >> >> On 2011-09-19 09:02, Magnus Westerlund wrote: >>> WG, >>> >>> There where some discussion in the Interim meeting last week about a >>> Screen/Application/Desktop sharing support use case. My take away from >>> the discussion is that this use cases is likely well enough understood >>> to actually start a consensus call now. However, to us WG chairs it was >>> clear that the use case in question actually needs to be split into two >>> parts. >>> >>> A) Where the RTCWEB enabled browser can use a local application window, >>> the whole desktop or a Screen as a media source that can be encoded and >>> transported over the peerConnection for displaying/playback at the peer. >>> >>> B) Where a remote peer can provide one or more input types such as mouse >>> and keyboard to control the local system, not only including the >>> browser, but also other operating system resources. This clearly can >>> only happen after additional consent, most likely on a per occasion >>> consent. >>> >>> My interpretation is that A only allows for application sharing in >>> conferencing contexts, like in the WEBEX session the Interim meeting was >>> held with where we shared slides. Where the combination of A and B is >>> providing for VNC/Remote desktop. >>> >>> Thus the question to the WG is the following. >>> >>> 1) Do you support or object the inclusion of use case A, B or Both in >>> our Use case document? >>> >>> 2) Do you have additional comments for or against either of the use cases? >>> >>> >>> As WG chair >>> >>> 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 s.choi@computer.or.kr Wed Sep 21 00:57: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 7799F21F848D for ; Wed, 21 Sep 2011 00:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 vRD+2TjJp5bZ for ; Wed, 21 Sep 2011 00:57:08 -0700 (PDT) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id C3EBA21F8476 for ; Wed, 21 Sep 2011 00:57:07 -0700 (PDT) Received: by wyh15 with SMTP id 15so2566012wyh.27 for ; Wed, 21 Sep 2011 00:59:35 -0700 (PDT) Received: by 10.227.198.143 with SMTP id eo15mr367369wbb.2.1316591975057; Wed, 21 Sep 2011 00:59:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.81.98 with HTTP; Wed, 21 Sep 2011 00:59:15 -0700 (PDT) In-Reply-To: <4E788A9C.40105@alvestrand.no> References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <4E787D56.8060106@alvestrand.no> <4E788A9C.40105@alvestrand.no> From: Soo-Hyun Choi Date: Wed, 21 Sep 2011 16:59:15 +0900 Message-ID: To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-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: Wed, 21 Sep 2011 07:57:09 -0000 Harald, >> One of the critical metrics of a delay-based CC algo is an accurate >> measurement of inter-packet interval (IPI) and timely report of IPI to >> the sender so it can update the send rate correctly, which we all >> agreed in this email thread. Although everyone in this list seemed to >> aware of this, I have highlighted again that the relatively >> course-grained RTCP carrying the IPI measurement data can cause >> instability at the encoder's output bitrate due to the following >> reason. > > The draft's suggestion is to avoid the need for communicating all the IPI > information from the receiver to the sender by doing part of the processing > and estimation at the receiver. I think we need to send the resulting > information quickly when it changes, but don't need to send it so often when > it remains stable. What "quickly" means in this context is a good question - > 0.1 second? 1 second? Certainly less than 5 seconds? Sure - one may not need to send the receiver report every so often when network is stable. But the question is "how long stable is stable?". Perhaps, the definition of "stable" might fall into unquantifiable term, too? Anyway, when I said "quickly", I meant "at least once in an every RTT" (borrowing from the TCP SACK analogy), in which the use of the standard RTCP RR is not suitable in this level of granularity. >> >> I would like to ask to this list (or Harald) if suggesting alternative >> CC algo idea could fit into the RTCWEB Charter's scope - if so, I >> could elaborate more by writing an I-D or so. In the mean time, you >> could check my document at http://tfwc.hackerslab.eu/ if you are >> interested. > > I am certainly looking for input on where we can best have this discussion, > too! > Algorithm design is outside of RTCWEB's charter, but I think > requirements/criteria for what "good enough" means for RTCWEB is inside it. > Question: Isn't your draft also proposing a new CC mechanism in the context of RTCWEB? Kind regards, Soo-Hyun From magnus.westerlund@ericsson.com Wed Sep 21 01:17: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 CD56F21F8A56 for ; Wed, 21 Sep 2011 01:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 vW0-B86qKX2E for ; Wed, 21 Sep 2011 01:17:14 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E681B21F8A71 for ; Wed, 21 Sep 2011 01:17:13 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-25-4e799e1d62d7 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 79.AE.20773.D1E997E4; Wed, 21 Sep 2011 10:19:41 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 10:19:41 +0200 Message-ID: <4E799E18.30000@ericsson.com> Date: Wed, 21 Sep 2011 10:19:36 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> In-Reply-To: <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 08:17:14 -0000 Hi, (as individual) If I interpret this correctly, you are arguing that an RTCWEB implementation shall support a remote end-point that doesn't support RTCP. My question on that topic is: What about congestion control against these end-points? I personally have assumed RTCP with reasonable RTCP bandwidth and minimal interval (not 5 second) being needed to have even medium time scale (Several RTTs) adaptation. I see congestion control for media as a MUST have due to the attack vector that exist in RTCWEB implementations. A Webservice that has sufficient amount of users visiting it can create additional PeerConnections beyond what is necessary for the service that is the front. These additional PeerConnections can be used to create traffic load over selected paths in the Internet by selecting a good pairs of peers to establish these overload streams. If there is no congestion control, or at least isn't reasonably fair sharing it could push large amount of other traffic out of the way on the paths selected by the attacker to be targeted. In addition it is needed to prevent the media quality to be very bad due to overloading a path by one self. There is still paths that potentially have issues even with a single G.711 voice stream, such as a GPRS link to a cellular. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Sep 21 01:20: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 5249E21F8C9B for ; Wed, 21 Sep 2011 01:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.519 X-Spam-Level: X-Spam-Status: No, score=-106.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 iCTWPR6gwmWy for ; Wed, 21 Sep 2011 01:20:29 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id EA81221F8C9A for ; Wed, 21 Sep 2011 01:20:28 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-3f-4e799edbc00c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 87.A1.02839.BDE997E4; Wed, 21 Sep 2011 10:22:51 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 10:22:37 +0200 Message-ID: <4E799ECC.8030306@ericsson.com> Date: Wed, 21 Sep 2011 10:22:36 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Cullen Jennings References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 08:20:30 -0000 On 2011-09-20 21:58, Cullen Jennings wrote: > > On Sep 20, 2011, at 7:24 AM, Magnus Westerlund wrote: > >> On 2011-09-19 18:59, Harald Alvestrand wrote: >> >>> We need to handle glare - when one sends an OFFER and gets back >>> an OFFER, reply with SDP ERROR, enter a "glare" state, wait a >>> bit, and send out an offer again. >>> >> >> I think that is a bad design for glare handling. I agree it needs >> to be handled. I think the ICE version of glare handling could work >> pretty well here. Any offer needs to include a random 32 bit >> number. If the end-point receive an offer in relation to a >> peer-connection while it has an outstanding offer then it compares >> these codes. Who ever has the greatest numerical value wins and >> that offer is handled the other is responded with an error stating >> GLARE. Thus there is no extra delay and more clear resolution of >> the glare case. >> >> Cheers >> >> Magnus Westerlund > > I think it has to be possible to gateway what happens here to what > happens in SIP with glare - I suspect that more or less puts us on > using the SIP glare mechanism. I agree with that it needs to be possible to gateway with SIP. I will think about if my proposal really is that difficult to interact with SIP. And why, did you design such a poor glare handling algorithm for SIP? ;-) Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From harald@alvestrand.no Wed Sep 21 01:21: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 11E7C21F8C9A for ; Wed, 21 Sep 2011 01:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.494 X-Spam-Level: X-Spam-Status: No, score=-108.494 tagged_above=-999 required=5 tests=[AWL=2.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFfM5cCb82rO for ; Wed, 21 Sep 2011 01:21:05 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 68D6321F8CA5 for ; Wed, 21 Sep 2011 01:21:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6B1A739E0A7; Wed, 21 Sep 2011 10:23:29 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RauMMkut1yCe; Wed, 21 Sep 2011 10:23:28 +0200 (CEST) Received: from [192.168.0.2] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C7B3939E088; Wed, 21 Sep 2011 10:23:28 +0200 (CEST) Message-ID: <4E799F00.8030602@alvestrand.no> Date: Wed, 21 Sep 2011 10:23:28 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Soo-Hyun Choi References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <4E787D56.8060106@alvestrand.no> <4E788A9C.40105@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] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-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: Wed, 21 Sep 2011 08:21:06 -0000 On 09/21/2011 09:59 AM, Soo-Hyun Choi wrote: > Harald, > >>> One of the critical metrics of a delay-based CC algo is an accurate >>> measurement of inter-packet interval (IPI) and timely report of IPI to >>> the sender so it can update the send rate correctly, which we all >>> agreed in this email thread. Although everyone in this list seemed to >>> aware of this, I have highlighted again that the relatively >>> course-grained RTCP carrying the IPI measurement data can cause >>> instability at the encoder's output bitrate due to the following >>> reason. >> The draft's suggestion is to avoid the need for communicating all the IPI >> information from the receiver to the sender by doing part of the processing >> and estimation at the receiver. I think we need to send the resulting >> information quickly when it changes, but don't need to send it so often when >> it remains stable. What "quickly" means in this context is a good question - >> 0.1 second? 1 second? Certainly less than 5 seconds? > Sure - one may not need to send the receiver report every so often > when network is stable. But the question is "how long stable is > stable?". Perhaps, the definition of "stable" might fall into > unquantifiable term, too? Anyway, when I said "quickly", I meant "at > least once in an every RTT" (borrowing from the TCP SACK analogy), in > which the use of the standard RTCP RR is not suitable in this level of > granularity. I think receiver->sender reporting every RTT (or every packet, which is frequently less frequent) is overkill, but that's a statement with a lot of gut feeling and very few numbers behind it. One advantage we have in RTCWEB is that we can assume that if audio and video work OK across the network, we're in a good place. We don't have to worry about getting gigabyte file transfers to utilize 90% of the link - even thogh we have to worry about audio and video functioning while those gigabyte transfers are taking place. >>> I would like to ask to this list (or Harald) if suggesting alternative >>> CC algo idea could fit into the RTCWEB Charter's scope - if so, I >>> could elaborate more by writing an I-D or so. In the mean time, you >>> could check my document at http://tfwc.hackerslab.eu/ if you are >>> interested. >> I am certainly looking for input on where we can best have this discussion, >> too! >> Algorithm design is outside of RTCWEB's charter, but I think >> requirements/criteria for what "good enough" means for RTCWEB is inside it. >> > Question: Isn't your draft also proposing a new CC mechanism in the > context of RTCWEB? No, to quote from the draft: It is published to aid the discussion on mandatory-to-implement flow control for RTCWEB applications; initial discussion is expected in the RTCWEB WG's mailing list. It's describing an algorithm that already exists outside of the IETF. It seems to have succeeded in stimulating the discussion. If the conclusion of the discussion is that something along these lines should be standardized, I hope the ADs and chairs of the IETF can give us guidance on where the discussion of this standardization should take place. From harald@alvestrand.no Wed Sep 21 01:38: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 6D6C621F8B56 for ; Wed, 21 Sep 2011 01:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.686 X-Spam-Level: X-Spam-Status: No, score=-108.686 tagged_above=-999 required=5 tests=[AWL=1.913, 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 Y4pFt8uAHKDx for ; Wed, 21 Sep 2011 01:38:18 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id BE86F21F8AF9 for ; Wed, 21 Sep 2011 01:38:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 81D6039E0A7 for ; Wed, 21 Sep 2011 10:40:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niQXpOWSPvBb for ; Wed, 21 Sep 2011 10:40:46 +0200 (CEST) Received: from [192.168.0.2] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 0313139E088 for ; Wed, 21 Sep 2011 10:40:45 +0200 (CEST) Message-ID: <4E79A30D.4050306@alvestrand.no> Date: Wed, 21 Sep 2011 10:40:45 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E76E8E8.2050102@ericsson.com> In-Reply-To: <4E76E8E8.2050102@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [rtcweb] Sample implementation of screensharing (Re: Call for Consensus on Use Case for Screen/Application/Desktop sharing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 08:38:19 -0000 For your info / full disclosure / shameless plug: Today's announcement of "Google+ Hangouts with Extras" includes an implementation of window sharing, which indeed encodes a window as a video stream and sends it over the network. Here's the help page: http://www.google.com/support/plus/bin/static.py?page=guide.cs&guide=1257349&topic=1651691 So we know that we can make one design approach work in our browser plugin.... Harald On 09/19/2011 09:02 AM, Magnus Westerlund wrote: > WG, > > There where some discussion in the Interim meeting last week about a > Screen/Application/Desktop sharing support use case. My take away from > the discussion is that this use cases is likely well enough understood > to actually start a consensus call now. However, to us WG chairs it was > clear that the use case in question actually needs to be split into two > parts. > > A) Where the RTCWEB enabled browser can use a local application window, > the whole desktop or a Screen as a media source that can be encoded and > transported over the peerConnection for displaying/playback at the peer. > > B) Where a remote peer can provide one or more input types such as mouse > and keyboard to control the local system, not only including the > browser, but also other operating system resources. This clearly can > only happen after additional consent, most likely on a per occasion > consent. > > My interpretation is that A only allows for application sharing in > conferencing contexts, like in the WEBEX session the Interim meeting was > held with where we shared slides. Where the combination of A and B is > providing for VNC/Remote desktop. > > Thus the question to the WG is the following. > > 1) Do you support or object the inclusion of use case A, B or Both in > our Use case document? > > 2) Do you have additional comments for or against either of the use cases? > > > As WG chair > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Frgatan 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 HKaplan@acmepacket.com Wed Sep 21 01:59: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 72D5B21F8C0C for ; Wed, 21 Sep 2011 01:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 JcXJQ+BcYKRP for ; Wed, 21 Sep 2011 01:59:51 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id CB14121F8BF8 for ; Wed, 21 Sep 2011 01:59:50 -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; Wed, 21 Sep 2011 05:02:16 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 21 Sep 2011 05:02:16 -0400 From: Hadriel Kaplan To: Magnus Westerlund Thread-Topic: [rtcweb] STUN for keep-alive - RTCP-less applications Thread-Index: AQHMeD0o3MP/2iiGskyr4mcVoApBAA== Date: Wed, 21 Sep 2011 09:02:16 +0000 Message-ID: <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> In-Reply-To: <4E799E18.30000@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="iso-8859-1" Content-ID: <7D9E390C31C9B542960ECB4CD34D45A2@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 08:59:51 -0000 On Sep 21, 2011, at 4:19 AM, Magnus Westerlund wrote: > If I interpret this correctly, you are arguing that an RTCWEB > implementation shall support a remote end-point that doesn't support RTCP= . Yes, although we could make that allowance/exception for audio only - in fa= ct, G.711 only if it comes down to it. Ultimately there is no indication in SIP/SDP that an device does not suppor= t RTCP. So what would you have the Rtcweb browser do? Once it starts send= ing media if it doesn't receive RTCP within time X then terminate the sessi= on automatically? Would users be ok with that? > I see congestion control for media as a MUST have due to the attack > vector that exist in RTCWEB implementations. A Webservice that has > sufficient amount of users visiting it can create additional > PeerConnections beyond what is necessary for the service that is the > front. These additional PeerConnections can be used to create traffic > load over selected paths in the Internet by selecting a good pairs of > peers to establish these overload streams. If there is no congestion > control, or at least isn't reasonably fair sharing it could push large > amount of other traffic out of the way on the paths selected by the > attacker to be targeted. If I understand your concern correctly, you're worried about the case of a = malicious site controlling unsuspecting users as a botnet, making calls to = each other and flooding the network paths between? That can happen anyway: all ends are under control of the malicious site, s= o ICE will succeed... and even if the media layer starts throttling itself = in a few seconds, the script can just keep creating/destroying PeerConnecti= ons, feeding new SDP to trigger port number changes, etc. And do so for vid= eo and audio and data channels concurrently or intermixed. -hadriel From harald@alvestrand.no Wed Sep 21 02:05: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 00FEB21F8C82 for ; Wed, 21 Sep 2011 02:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.845 X-Spam-Level: X-Spam-Status: No, score=-108.845 tagged_above=-999 required=5 tests=[AWL=1.754, 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 mmYC6cWv+ez3 for ; Wed, 21 Sep 2011 02:05:22 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 163CA21F8C88 for ; Wed, 21 Sep 2011 02:05:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D838139E0A7 for ; Wed, 21 Sep 2011 11:07:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhbyh8eP1yGD for ; Wed, 21 Sep 2011 11:07:49 +0200 (CEST) Received: from [192.168.0.2] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id F0B8539E088 for ; Wed, 21 Sep 2011 11:07:48 +0200 (CEST) Message-ID: <4E79A964.2050007@alvestrand.no> Date: Wed, 21 Sep 2011 11:07:48 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 09:05:23 -0000 On 09/20/2011 09:28 AM, Sal Ibarra Corretg wrote: > On Sep 20, 2011, at 12:59 AM, Roman Shpount wrote: > >> Randell, >> >> What I fail to understand is in what way would adding signaling to the web browser would make things easy to build? How is what you are proposing better then 2 or 3 well written samples? >> >> On the other hand, if you decide to build such simple signaling interface, depending on what use case you are trying to address you will end up with very different libraries. You have to decide how complex you want to make this library on the server vs the client side. You will need to decide if the purpose of this library is to simplify browser-to-browser or browser-to-PSTN calls. There is going to be a large number of very complex decisions none of which have obvious answers and will greatly affect the overall library design. >> >> Most importantly, I think this is a misconception that you can build something that can be developed in 20 lines or less and be useful. Real-time communication is order of magnitude more complex then most of the web related applications. You need to deal with multiple event sources, deal with event collisions, negotiation failures, call state machines. And this is what required for the basic call setups. Once you start dealing with transfers, conferences, call status monitoring, things become even more complex. It is almost impossible to develop something that is simple to use that serves more then one or two specific use cases. If we try to invent something like this we might never finish. > +1. > > If we add some signaling protocol to the browser to ease web developers then someone might say "why don't we also add X, Y and Z". The browser only needs the media plane, the signaling can be elsewhere, and it's far better to have it elsewhere. > > As Roman pointed out, RTC applications are not something that can nor should be done in 20 lines of JS. It's just complex. If people want to make simple apps they can build a simple JS library using an invented simple protocol. But RTCWeb shouldn't encourage this IMHO. Let me just say that I totally disagree on this point. The developers of applications that need audio and video capabilities are not RTC developers. Their main focus and main skill set will lie elsewhere. In a little more than 20 lines of code, it is possible to set up a call using a variant form of the existing W3C API. I know, I have seen the code. Other examples (in a slightly different variant) are part of the Ericsson demo. What's perhaps more important is that none of those 20+ lines mention anything about codecs, bit rates, congestion control or any of the numerous other issues we've been hashing out. With the API we support, simple things MUST be simple. Complex things must be possible. From HKaplan@acmepacket.com Wed Sep 21 02:12: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 DA26121F8498 for ; Wed, 21 Sep 2011 02:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_31=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 ZpKAhU2Hkn7x for ; Wed, 21 Sep 2011 02:12:15 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2D821F886A for ; Wed, 21 Sep 2011 02:12:15 -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; Wed, 21 Sep 2011 05:14:42 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 21 Sep 2011 05:14:42 -0400 From: Hadriel Kaplan To: Harald Alvestrand Thread-Topic: [rtcweb] Sample implementation of screensharing (Re: Call for Consensus on Use Case for Screen/Application/Desktop sharing) Thread-Index: AQHMeD7lx0RY4lYoFkijofC2vcsPAQ== Date: Wed, 21 Sep 2011 09:14:42 +0000 Message-ID: <1C5A72D7-1D7F-434A-A1EA-1F1747CE5394@acmepacket.com> References: <4E76E8E8.2050102@ericsson.com> <4E79A30D.4050306@alvestrand.no> In-Reply-To: <4E79A30D.4050306@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="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Sample implementation of screensharing (Re: Call for Consensus on Use Case for Screen/Application/Desktop sharing) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 09:12:16 -0000 Cool. I like the "Watch YouTube clips together" feature. It's so romantic= . Actually, the youtube video should be mashed together with this: http://home.comcast.net/~jps201/mst3k_files/mst3kbackg.jpg as well as the "Group Chat" feature so folks can do MST3K commentaries of t= he youtube video they're watching. Then call the mashup "Bad-AttiTubes". :) -hadriel On Sep 21, 2011, at 4:40 AM, Harald Alvestrand wrote: > For your info / full disclosure / shameless plug: >=20 > Today's announcement of "Google+ Hangouts with Extras" includes an implem= entation of window sharing, which indeed encodes a window as a video stream= and sends it over the network. >=20 > Here's the help page: >=20 > http://www.google.com/support/plus/bin/static.py?page=3Dguide.cs&guide=3D= 1257349&topic=3D1651691 >=20 > So we know that we can make one design approach work in our browser plugi= n.... >=20 > Harald From harald@alvestrand.no Wed Sep 21 02:17: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 D1AF021F8B9D for ; Wed, 21 Sep 2011 02:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.98 X-Spam-Level: X-Spam-Status: No, score=-108.98 tagged_above=-999 required=5 tests=[AWL=1.619, 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 ufrJE8Kv3L+R for ; Wed, 21 Sep 2011 02:17:23 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E7D0521F8B92 for ; Wed, 21 Sep 2011 02:17:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B738839E0A7; Wed, 21 Sep 2011 11:19:50 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5lvkAlHGSYE; Wed, 21 Sep 2011 11:19:48 +0200 (CEST) Received: from [192.168.0.2] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 25A0D39E088; Wed, 21 Sep 2011 11:19:48 +0200 (CEST) Message-ID: <4E79AC33.4000900@alvestrand.no> Date: Wed, 21 Sep 2011 11:19:47 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Magnus Westerlund References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> <4E77949B.4010603@alvestrand.no> <4E78A4FB.1050504@ericsson.com> In-Reply-To: <4E78A4FB.1050504@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 09:17:23 -0000 On 09/20/2011 04:36 PM, Magnus Westerlund wrote: > On 2011-09-19 21:14, Harald Alvestrand wrote: >> On 09/19/2011 06:00 PM, Magnus Westerlund wrote: >>> We need to standardize a number of Transport protocol functionalities >>> for the RTCWEB data transport solution. To the degree that I do like to >>> resurface some of my earlier suggestions around this. Why not use DCCP >>> with TFRC or TCP like congestion control tunneled over UDP. >>> >>> The whole specification is ready. Which avoids any hiccup with the >>> transport people and IESG. >> The last few times this has surfaced, the conversation has turned >> suddenly silent when I've asked where to find a DCCP-over-TFRC stack I >> can experiment with.... are there any out there that are "production ready"? > To my knowledge there is a DCCP stack in Linux. Exactly it status is > unknown to me and which of the CC it supports. There has been also > additional projects for implementations. I checked out the Linux stack, and concluded that it was: a) not supporting DCCP over UDP b) not possible to extract it and embed it in a browser The only project I could find for userspace DCCP was untouched for at least 3 years, and did not compile. > I would note that no implementation exist of DTLS with a CC algorithm > and additional mechanism. Thus that would be a from scratch > implementation effort without any input what has been done so far. > > And if we can in fact decide early on something fully specified you have > a lot of time to implement this before the rest are standards ready. My worry is that without the ability to experiment, I have no way of verifying that the protocol satisfies the properties we are attributing to it. Also, we *know* we'll be shipping products well ahead of the standards' final approval, with appropriate warnings that things *will* change between product versions. We don't have "a lot of time". >> The pseudoTCP stacks in libjingle have seen service for a long time.... >> > Well, that is addressing another set of requirements namely the reliable > data transport. Lets not confuse the two sets. We appear to have > interest in both unreliable and reliable data transport. Yup, I pulled that in as an example of "code maturity". > Regarding pseudoTCP we still need a specification for it. I think for > example the psuedo header used in the checksum needs specification in > TCP over UDP. It might not be a big spec, but someone needs to write it > and find a home for it. I would note that we are somewhat limited in > this WG to actually do protocol work. It will have to seek approval elsewhere, if needed. > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Frgatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > From harald@alvestrand.no Wed Sep 21 02:48: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 B9A7221F8BA4 for ; Wed, 21 Sep 2011 02:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.096 X-Spam-Level: X-Spam-Status: No, score=-109.096 tagged_above=-999 required=5 tests=[AWL=1.503, 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 EurG7Rxc9uDI for ; Wed, 21 Sep 2011 02:48:58 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1C89D21F8BA7 for ; Wed, 21 Sep 2011 02:48:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F170639E0A7; Wed, 21 Sep 2011 11:51:25 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WESjO5J6dxQJ; Wed, 21 Sep 2011 11:51:25 +0200 (CEST) Received: from [192.168.0.2] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 81D5139E088; Wed, 21 Sep 2011 11:51:25 +0200 (CEST) Message-ID: <4E79B39D.8030901@alvestrand.no> Date: Wed, 21 Sep 2011 11:51:25 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Magnus Westerlund References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> In-Reply-To: <4E78940C.4040405@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 09:48:58 -0000 On 09/20/2011 03:24 PM, Magnus Westerlund wrote: > On 2011-09-19 18:59, Harald Alvestrand wrote: > >> We need to handle glare - when one sends an OFFER and gets back an >> OFFER, reply with SDP ERROR, enter a "glare" state, wait a bit, and send >> out an offer again. >> > I think that is a bad design for glare handling. I agree it needs to be > handled. I think the ICE version of glare handling could work pretty > well here. Any offer needs to include a random 32 bit number. If the > end-point receive an offer in relation to a peer-connection while it has > an outstanding offer then it compares these codes. Who ever has the > greatest numerical value wins and that offer is handled the other is > responded with an error stating GLARE. Thus there is no extra delay and > more clear resolution of the glare case. Hm... thinking about it, I think this can be incorporated. The reason it works is that the signalling channel is supposed to guarantee reliable, ordered delivery, so we know that both parties agree that a glare condition exists. (actually, that condition doesn't hold for ICE, so I'm a bit surprised it works there.) If we specify that the random number is 1 < N < MAXINT, we can even incorporate the SIP interworking case by saying that a gateway can force the party into GLARE by specifying one of the edge cases - whatever makes interworking happy. From ibc@aliax.net Wed Sep 21 03: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 4BF2421F845C for ; Wed, 21 Sep 2011 03:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 zymS2vZdLwZM for ; Wed, 21 Sep 2011 03:21:43 -0700 (PDT) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9F88721F8C46 for ; Wed, 21 Sep 2011 03:21:43 -0700 (PDT) Received: by vws11 with SMTP id 11so3326575vws.27 for ; Wed, 21 Sep 2011 03:24:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.199.67 with SMTP id er3mr118758vcb.17.1316600651594; Wed, 21 Sep 2011 03:24:11 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Wed, 21 Sep 2011 03:24:11 -0700 (PDT) In-Reply-To: <4E777414.1040801@mozilla.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> <4E777414.1040801@mozilla.com> Date: Wed, 21 Sep 2011 12:24:11 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Timothy B. Terriberry" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 10:21:44 -0000 2011/9/19 Timothy B. Terriberry : > Perhaps I'm confused, but doesn't MSRP rely on reliable, in-order deliver= y? Right, MSRP is supossed to work over TCP or TLS. In fact, TLS usage is a "SHOULD" and TCP is just supposed to be used for debugging purposes. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Sep 21 03: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 CEDCF21F8C68 for ; Wed, 21 Sep 2011 03:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 FVByYMmV+NLn for ; Wed, 21 Sep 2011 03:26:26 -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 36F6021F8C4A for ; Wed, 21 Sep 2011 03:26:26 -0700 (PDT) Received: by vws5 with SMTP id 5so2178774vws.31 for ; Wed, 21 Sep 2011 03:28:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.9.129 with SMTP id l1mr114220vcl.87.1316600934147; Wed, 21 Sep 2011 03:28:54 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Wed, 21 Sep 2011 03:28:54 -0700 (PDT) In-Reply-To: References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> <4E777414.1040801@mozilla.com> Date: Wed, 21 Sep 2011 12:28:54 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Timothy B. Terriberry" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 10:26:26 -0000 2011/9/21 I=C3=B1aki Baz Castillo : > 2011/9/19 Timothy B. Terriberry : >> Perhaps I'm confused, but doesn't MSRP rely on reliable, in-order delive= ry? > > Right, MSRP is supossed to work over TCP or TLS. In fact, TLS usage is > a "SHOULD" and TCP is just supposed to be used for debugging purposes. Using a reliable transport means that, in case both peers are behind NAT, a MSRP Relay server (RFC 4976) is required. So as in the case of a "RTCweb default signaling protocol" I wonder: would we expect a 'mod_msrp' module for Apache? :) (I don't). Regards. --=20 I=C3=B1aki Baz Castillo From csp@csperkins.org Wed Sep 21 03: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 0136221F8C72 for ; Wed, 21 Sep 2011 03:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.527 X-Spam-Level: X-Spam-Status: No, score=-103.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 Rg5olmNWUj0w for ; Wed, 21 Sep 2011 03:45:10 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id 0991321F8C07 for ; Wed, 21 Sep 2011 03:45:10 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R6KL3-0002wS-nu; Wed, 21 Sep 2011 10:47:37 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <4E79AC33.4000900@alvestrand.no> Date: Wed, 21 Sep 2011 11:47:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0075AB47-3DFF-4000-9057-CA0628DF711A@csperkins.org> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> <4E77949B.4010603@alvestrand.no> <4E78A4FB.1050504@ericsson.com> <4E79AC33.4000900@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.1084) Cc: "" Subject: Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 10:45:11 -0000 On 21 Sep 2011, at 10:19, Harald Alvestrand wrote: > On 09/20/2011 04:36 PM, Magnus Westerlund wrote: >> On 2011-09-19 21:14, Harald Alvestrand wrote: >>> On 09/19/2011 06:00 PM, Magnus Westerlund wrote: >>>> We need to standardize a number of Transport protocol = functionalities for the RTCWEB data transport solution. To the degree = that I do like to resurface some of my earlier suggestions around this. = Why not use DCCP with TFRC or TCP like congestion control tunneled over = UDP. >>>>=20 >>>> The whole specification is ready. Which avoids any hiccup with the = transport people and IESG. >>>=20 >>> The last few times this has surfaced, the conversation has turned = suddenly silent when I've asked where to find a DCCP-over-TFRC stack I = can experiment with.... are there any out there that are "production = ready"? >>=20 >> To my knowledge there is a DCCP stack in Linux. Exactly it status is = unknown to me and which of the CC it supports. There has been also = additional projects for implementations. >=20 > I checked out the Linux stack, and concluded that it was: > a) not supporting DCCP over UDP > b) not possible to extract it and embed it in a browser > The only project I could find for userspace DCCP was untouched for at = least 3 years, and did not compile. Agreed. The Linux DCCP code seems reasonably mature, but doesn't support = the UDP encapsulation. The user-space DCCP-TP code is not in a good = state to build upon. >> I would note that no implementation exist of DTLS with a CC algorithm = and additional mechanism. Thus that would be a from scratch = implementation effort without any input what has been done so far. >>=20 >> And if we can in fact decide early on something fully specified you = have a lot of time to implement this before the rest are standards = ready. >=20 > My worry is that without the ability to experiment, I have no way of = verifying that the protocol satisfies the properties we are attributing = to it. This is a little pessimistic. The Linux DCCP code can certainly be used = for lab-based experiments, and these can be made to give a reasonable = idea of the performance of DCCP with the existing CCIDs. Not perfect, = sure, but should be good enough to show whether the basic idea is worth = exploring further.=20 The main reason to consider DCCP-over-UDP isn't running code though, = it's the solid specification. I'd argue that it will be easier to start = with the DCCP spec, profile it down to what's needed by this group, plug = in a new congestion control algorithm (CCID), and implement the result, = than it would be to start both the specification and implementation = efforts from scratch. As a congestion-controlled, connection-oriented, = unreliable datagram service, there's not a lot in DCCP that we wouldn't = want for RTCWeb (and those bits we might want to modify, such as the = congestion control algorithm, are things where DCCP supports = extensions). > Also, we *know* we'll be shipping products well ahead of the = standards' final approval, with appropriate warnings that things *will* = change between product versions. We don't have "a lot of time". >>> The pseudoTCP stacks in libjingle have seen service for a long = time.... >>>=20 >> Well, that is addressing another set of requirements namely the = reliable data transport. Lets not confuse the two sets. We appear to = have interest in both unreliable and reliable data transport. >=20 > Yup, I pulled that in as an example of "code maturity". >=20 >> Regarding pseudoTCP we still need a specification for it. I think for = example the psuedo header used in the checksum needs specification in = TCP over UDP. It might not be a big spec, but someone needs to write it = and find a home for it. I would note that we are somewhat limited in = this WG to actually do protocol work. >=20 > It will have to seek approval elsewhere, if needed. >=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 --=20 Colin Perkins http://csperkins.org/ From HKaplan@acmepacket.com Wed Sep 21 04:22: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 1823C21F8A58 for ; Wed, 21 Sep 2011 04:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 YNQerMMKa4hT for ; Wed, 21 Sep 2011 04:22:19 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id F139721F8876 for ; Wed, 21 Sep 2011 04:22: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; Wed, 21 Sep 2011 07:24:46 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 21 Sep 2011 07:24:46 -0400 From: Hadriel Kaplan To: Harald Alvestrand Thread-Topic: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) Thread-Index: AQHMeFEQ7TNY7RqJnUiNIyKjjxBJyw== Date: Wed, 21 Sep 2011 11:24:46 +0000 Message-ID: <1AF68A74-EF46-4F78-999C-C37BFAA9FC31@acmepacket.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <4E79A964.2050007@alvestrand.no> In-Reply-To: <4E79A964.2050007@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="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 11:22:20 -0000 On Sep 21, 2011, at 5:07 AM, Harald Alvestrand wrote: > The developers of applications that need audio and video capabilities are= not RTC developers. Their main focus and main skill set will lie elsewhere= . I agree. That's why JS libraries exist, though, isn't it? > In a little more than 20 lines of code, it is possible to set up a call u= sing a variant form of the existing W3C API. I know, I have seen the code. = Other examples (in a slightly different variant) are part of the Ericsson d= emo. Well, to be fair, the Ericsson code has this at the top of the main HTML pa= ge's script: And that separate JS is another ~100 lines of code. =20 And that "signaling" code doesn't appear to actually handle the rendezvous = function of signaling - you have to email the other party a cookified URL t= o reach you at for the particular session. (I think) And it doesn't appear to handle terminating a session (other than by closin= g the browser window). But then, it's just a demo. [note: I'm not disparaging the demo - it's a cool demo] > What's perhaps more important is that none of those 20+ lines mention any= thing about codecs, bit rates, congestion control or any of the numerous ot= her issues we've been hashing out. Right, nor should they - the browsers should do that stuff internally, and = only if the JS actually wants/needs to get involved somehow should it need = to (through callbacks/whatever). No one's been saying the JS needs to be responsible for codecs, bit rates, = congestion control, or anything much media related. We've only been arguing about: 1) Using SDP and the SDP offer/answer as the media API 2) Whether there should be a "default" signaling component built in as well= , or let JS libraries handle it > With the API we support, simple things MUST be simple. Complex things mus= t be possible. Yes, it should be "as simple as it can be, but no simpler". The tricky par= t's always figuring out what that means. :) Why isn't this simple enough: -hadriel From mperumal@cisco.com Wed Sep 21 04:32: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 E5CA821F8AFD for ; Wed, 21 Sep 2011 04:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfO22JsBfaWK for ; Wed, 21 Sep 2011 04:32:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A065321F84FD for ; Wed, 21 Sep 2011 04:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=3362; q=dns/txt; s=iport; t=1316604883; x=1317814483; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Qz8ouOQsGxFo0snUOQUI38A2lpATgYeaBvmAdKUhkUw=; b=asr0om6unkJ1gKyLL25Tb5hlCmxtaXwJBB8p92aoz7Yh1YxR2bE7UVkv GMEvKj/BbzwUaIS7ccuTrHkuWd7NjkLcOpdj3XW+anU3CpvpbX3aF0dYe QHrm2ZAQkRXkRA5qHotlOz9PAu5lxUTUC39iluEKySgqIjNgOgNqiQmnw k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAAAFfLeU5Io8UR/2dsb2JhbABCmHeOaXiBUwEBAQEDAQEBDwEdCjQLDAQCAQgOAwQBAQsGFwEGASYfCQgCBAEKCAgRCYdblhQBnh2GHWAEh26RB4wQ X-IronPort-AV: E=Sophos;i="4.68,417,1312156800"; d="scan'208";a="116442002" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 21 Sep 2011 11:34:41 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8LBYakU028874; Wed, 21 Sep 2011 11:34:40 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, 21 Sep 2011 17:04:39 +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, 21 Sep 2011 17:04:37 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020672BCFD@XMB-BGL-414.cisco.com> In-Reply-To: <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism Thread-Index: AQHMd+W4GbLdjZqw9U+hWOGtS5YVCZVXrypA References: <4E777500.5030201@alvestrand.no><69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com><7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se><4E788458.1090108@alvestrand.no><7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se><4E788E5C.9090306@alvestrand.no><11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net><27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Hadriel Kaplan" , "Cullen Jennings (fluffy)" X-OriginalArrivalTime: 21 Sep 2011 11:34:39.0887 (UTC) FILETIME=[72FF09F0:01CC7852] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 11:32:16 -0000 |Not really - there will be signaling, because there has to=20 |be SDP answers even just to get ICE to work before the media=20 |starts flowing in many NAT cases. And even in practice in=20 |SIP there're usually SDP answers in 18x to open "gates", and=20 |to get upstream DTMF. So if the concern is just that there's |no signaling to tell the browser there are multiple RTP streams |coming, I think that can be allayed. I think it is further allayed with ICE because ICE requires that early media be not sent until the ICE connectivity check is done and a valid candidate pair is selected -- it requires implementations to delay alerting the called party until this point (in the case of a PSTN gateway, this would mean that the setup message into the PSTN is delayed until this point). So, the RTCWeb app would have to just create a single PeerConnection object for receiving/transmitting a media stream once this procedure is completed. =20 Of course there is complexity in the SIP/PSTN interworking gateway, but it doesn't look the RTCWeb app would have worry about it. Muthu |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hadriel Kaplan |Sent: Wednesday, September 21, 2011 4:06 AM |To: Cullen Jennings (fluffy) |Cc: rtcweb@ietf.org |Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism | | |On Sep 20, 2011, at 4:07 PM, Cullen Jennings wrote: | |> That said, I think that doing both forking and early media is hard. Lets assume we are using a |signaling gateway that is not a media gateway to translate between a SIP call on one side and whatever |is happening over on the browser side. The basic issue is the browser initiating the communications |needs to be able to start receiving multiple RTP streams before it even has signaling information to |tell it how many it might receive. | |Not really - there will be signaling, because there has to be SDP answers even just to get ICE to work |before the media starts flowing in many NAT cases. And even in practice in SIP there're usually SDP |answers in 18x to open "gates", and to get upstream DTMF. So if the concern is just that there's no |signaling to tell the browser there are multiple RTP streams coming, I think that can be allayed. | |The really hard part is knowing which stream to use/render/send-to, imho. And putting that decision |in the gateway isn't good - the best decider of that is probably the JS in the browser. | | |> To simplify this problem, Cary and my draft proposes not allowing forking on the SIP side of the |signaling gateway but still allowing early media. If you wanted to do do forking in this case, one |would need a SBC that processed media and turned the forked medial legs into one media leg. | |Obviously you can request that a request not be forked, using caller-prefs, but you can't "not allow" |forking on the SIP side. That would make it not SIP. I know forking is hard, but that's life. It's |not appropriate for this WG to make fundamental changes/limitations to the SIP protocol, just because |some of it's "hard" for a browser. | |-hadriel | |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From HKaplan@acmepacket.com Wed Sep 21 04:42: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 0EE5121F88B6 for ; Wed, 21 Sep 2011 04:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 NIEglTtJ+j2v for ; Wed, 21 Sep 2011 04:42:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E1C3521F88A0 for ; Wed, 21 Sep 2011 04:42: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; Wed, 21 Sep 2011 07:45:13 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 21 Sep 2011 07:45:13 -0400 From: Hadriel Kaplan To: Colin Perkins Thread-Topic: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: AQHMeFPsDHEA8PUAeUCkHcUjuUOWdg== Date: Wed, 21 Sep 2011 11:45:13 +0000 Message-ID: <05D1C2F6-96C3-44E3-9FC2-AD2C893C9FC6@acmepacket.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> <4E77949B.4010603@alvestrand.no> <4E78A4FB.1050504@ericsson.com> <4E79AC33.4000900@alvestrand.no> <0075AB47-3DFF-4000-9057-CA0628DF711A@csperkins.org> In-Reply-To: <0075AB47-3DFF-4000-9057-CA0628DF711A@csperkins.org> 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: <7F7555315BA8EA408BE150243DA5C5DB@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 11:42:47 -0000 Just to make sure I'm on the same wavelength, you're talking about: 1) Defining PseudoTCP over UDP (a la libnice and jingle) for stream-oriente= d reliable data delivery. 2) Defining DDCP over UDP for message-oriented unreliable data delivery. 3) Requiring the browser to implement and only expose those two options for= the "data" stream type and not raw UDP, so that we can enforce congestion = control of the data channel. (oh, and the option for it to be PseudoTCP/DTL= S/UDP or DCCP/DTLS/UDP) Correct? -hadriel On Sep 21, 2011, at 6:47 AM, Colin Perkins wrote: > On 21 Sep 2011, at 10:19, Harald Alvestrand wrote: >> On 09/20/2011 04:36 PM, Magnus Westerlund wrote: >>> On 2011-09-19 21:14, Harald Alvestrand wrote: >>>> On 09/19/2011 06:00 PM, Magnus Westerlund wrote: >>>>> We need to standardize a number of Transport protocol functionalities= for the RTCWEB data transport solution. To the degree that I do like to re= surface some of my earlier suggestions around this. Why not use DCCP with T= FRC or TCP like congestion control tunneled over UDP. >>>>>=20 >>>>> The whole specification is ready. Which avoids any hiccup with the tr= ansport people and IESG. >>>>=20 >>>> The last few times this has surfaced, the conversation has turned sudd= enly silent when I've asked where to find a DCCP-over-TFRC stack I can expe= riment with.... are there any out there that are "production ready"? >>>=20 >>> To my knowledge there is a DCCP stack in Linux. Exactly it status is un= known to me and which of the CC it supports. There has been also additional= projects for implementations. >>=20 >> I checked out the Linux stack, and concluded that it was: >> a) not supporting DCCP over UDP >> b) not possible to extract it and embed it in a browser >> The only project I could find for userspace DCCP was untouched for at le= ast 3 years, and did not compile. >=20 > Agreed. The Linux DCCP code seems reasonably mature, but doesn't support = the UDP encapsulation. The user-space DCCP-TP code is not in a good state t= o build upon. >=20 >>> I would note that no implementation exist of DTLS with a CC algorithm a= nd additional mechanism. Thus that would be a from scratch implementation e= ffort without any input what has been done so far. >>>=20 >>> And if we can in fact decide early on something fully specified you hav= e a lot of time to implement this before the rest are standards ready. >>=20 >> My worry is that without the ability to experiment, I have no way of ver= ifying that the protocol satisfies the properties we are attributing to it. >=20 > This is a little pessimistic. The Linux DCCP code can certainly be used f= or lab-based experiments, and these can be made to give a reasonable idea o= f the performance of DCCP with the existing CCIDs. Not perfect, sure, but s= hould be good enough to show whether the basic idea is worth exploring furt= her.=20 >=20 > The main reason to consider DCCP-over-UDP isn't running code though, it's= the solid specification. I'd argue that it will be easier to start with th= e DCCP spec, profile it down to what's needed by this group, plug in a new = congestion control algorithm (CCID), and implement the result, than it woul= d be to start both the specification and implementation efforts from scratc= h. As a congestion-controlled, connection-oriented, unreliable datagram ser= vice, there's not a lot in DCCP that we wouldn't want for RTCWeb (and those= bits we might want to modify, such as the congestion control algorithm, ar= e things where DCCP supports extensions). >=20 >> Also, we *know* we'll be shipping products well ahead of the standards' = final approval, with appropriate warnings that things *will* change between= product versions. We don't have "a lot of time". >>>> The pseudoTCP stacks in libjingle have seen service for a long time...= . >>>>=20 >>> Well, that is addressing another set of requirements namely the reliabl= e data transport. Lets not confuse the two sets. We appear to have interest= in both unreliable and reliable data transport. >>=20 >> Yup, I pulled that in as an example of "code maturity". >>=20 >>> Regarding pseudoTCP we still need a specification for it. I think for e= xample the psuedo header used in the checksum needs specification in TCP ov= er UDP. It might not be a big spec, but someone needs to write it and find = a home for it. I would note that we are somewhat limited in this WG to actu= ally do protocol work. >>=20 >> It will have to seek approval elsewhere, if needed. >>=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 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From csp@csperkins.org Wed Sep 21 05:07: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 02EB021F8B3E for ; Wed, 21 Sep 2011 05:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.532 X-Spam-Level: X-Spam-Status: No, score=-103.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 ctMgtS5YlFtS for ; Wed, 21 Sep 2011 05:07:23 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id D250921F8AFD for ; Wed, 21 Sep 2011 05:07:22 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R6Lcc-00041Q-b9; Wed, 21 Sep 2011 12:09:50 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <05D1C2F6-96C3-44E3-9FC2-AD2C893C9FC6@acmepacket.com> Date: Wed, 21 Sep 2011 13:09:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8E8D4F16-AE3B-4E45-88C3-C795B0DE71A6@csperkins.org> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> <4E77949B.4010603@alvestrand.no> <4E78A4FB.1050504@ericsson.com> <4E79AC33.4000900@alvestrand.no> <0075AB47-3DFF-4000-9057-CA0628DF711A@csperkins.org> <05D1C2F6-96C3-44E3-9FC2-AD2C893C9FC6@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: "" Subject: Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 12:07:24 -0000 Yes, essentially (plus RTP over UDP for the media, of course). Colin On 21 Sep 2011, at 12:45, Hadriel Kaplan wrote: > Just to make sure I'm on the same wavelength, you're talking about: > 1) Defining PseudoTCP over UDP (a la libnice and jingle) for = stream-oriented reliable data delivery. > 2) Defining DDCP over UDP for message-oriented unreliable data = delivery. > 3) Requiring the browser to implement and only expose those two = options for the "data" stream type and not raw UDP, so that we can = enforce congestion control of the data channel. (oh, and the option for = it to be PseudoTCP/DTLS/UDP or DCCP/DTLS/UDP) >=20 > Correct? >=20 > -hadriel >=20 >=20 > On Sep 21, 2011, at 6:47 AM, Colin Perkins wrote: >=20 >> On 21 Sep 2011, at 10:19, Harald Alvestrand wrote: >>> On 09/20/2011 04:36 PM, Magnus Westerlund wrote: >>>> On 2011-09-19 21:14, Harald Alvestrand wrote: >>>>> On 09/19/2011 06:00 PM, Magnus Westerlund wrote: >>>>>> We need to standardize a number of Transport protocol = functionalities for the RTCWEB data transport solution. To the degree = that I do like to resurface some of my earlier suggestions around this. = Why not use DCCP with TFRC or TCP like congestion control tunneled over = UDP. >>>>>>=20 >>>>>> The whole specification is ready. Which avoids any hiccup with = the transport people and IESG. >>>>>=20 >>>>> The last few times this has surfaced, the conversation has turned = suddenly silent when I've asked where to find a DCCP-over-TFRC stack I = can experiment with.... are there any out there that are "production = ready"? >>>>=20 >>>> To my knowledge there is a DCCP stack in Linux. Exactly it status = is unknown to me and which of the CC it supports. There has been also = additional projects for implementations. >>>=20 >>> I checked out the Linux stack, and concluded that it was: >>> a) not supporting DCCP over UDP >>> b) not possible to extract it and embed it in a browser >>> The only project I could find for userspace DCCP was untouched for = at least 3 years, and did not compile. >>=20 >> Agreed. The Linux DCCP code seems reasonably mature, but doesn't = support the UDP encapsulation. The user-space DCCP-TP code is not in a = good state to build upon. >>=20 >>>> I would note that no implementation exist of DTLS with a CC = algorithm and additional mechanism. Thus that would be a from scratch = implementation effort without any input what has been done so far. >>>>=20 >>>> And if we can in fact decide early on something fully specified you = have a lot of time to implement this before the rest are standards = ready. >>>=20 >>> My worry is that without the ability to experiment, I have no way of = verifying that the protocol satisfies the properties we are attributing = to it. >>=20 >> This is a little pessimistic. The Linux DCCP code can certainly be = used for lab-based experiments, and these can be made to give a = reasonable idea of the performance of DCCP with the existing CCIDs. Not = perfect, sure, but should be good enough to show whether the basic idea = is worth exploring further.=20 >>=20 >> The main reason to consider DCCP-over-UDP isn't running code though, = it's the solid specification. I'd argue that it will be easier to start = with the DCCP spec, profile it down to what's needed by this group, plug = in a new congestion control algorithm (CCID), and implement the result, = than it would be to start both the specification and implementation = efforts from scratch. As a congestion-controlled, connection-oriented, = unreliable datagram service, there's not a lot in DCCP that we wouldn't = want for RTCWeb (and those bits we might want to modify, such as the = congestion control algorithm, are things where DCCP supports = extensions). >>=20 >>> Also, we *know* we'll be shipping products well ahead of the = standards' final approval, with appropriate warnings that things *will* = change between product versions. We don't have "a lot of time". >>>>> The pseudoTCP stacks in libjingle have seen service for a long = time.... >>>>>=20 >>>> Well, that is addressing another set of requirements namely the = reliable data transport. Lets not confuse the two sets. We appear to = have interest in both unreliable and reliable data transport. >>>=20 >>> Yup, I pulled that in as an example of "code maturity". >>>=20 >>>> Regarding pseudoTCP we still need a specification for it. I think = for example the psuedo header used in the checksum needs specification = in TCP over UDP. It might not be a big spec, but someone needs to write = it and find a home for it. I would note that we are somewhat limited in = this WG to actually do protocol work. >>>=20 >>> It will have to seek approval elsewhere, if needed. >>>=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 >>=20 >>=20 >> --=20 >> Colin Perkins >> http://csperkins.org/ From HKaplan@acmepacket.com Wed Sep 21 05:10: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 442D321F8B73 for ; Wed, 21 Sep 2011 05:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 Hyep4xeTDxsE for ; Wed, 21 Sep 2011 05:10:14 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 961B521F8AF9 for ; Wed, 21 Sep 2011 05:10:14 -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; Wed, 21 Sep 2011 08:12:20 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 21 Sep 2011 08:12:20 -0400 From: Hadriel Kaplan To: Colin Perkins Thread-Topic: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] Thread-Index: AQHMeFe1JM5xuK/2UEGsR/sv4LARig== Date: Wed, 21 Sep 2011 12:12:20 +0000 Message-ID: <6295ADCD-BB33-4B8A-B6A9-01D3FC3E0FA8@acmepacket.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> <4E77949B.4010603@alvestrand.no> <4E78A4FB.1050504@ericsson.com> <4E79AC33.4000900@alvestrand.no> <0075AB47-3DFF-4000-9057-CA0628DF711A@csperkins.org> <05D1C2F6-96C3-44E3-9FC2-AD2C893C9FC6@acmepacket.com> <8E8D4F16-AE3B-4E45-88C3-C795B0DE71A6@csperkins.org> In-Reply-To: <8E8D4F16-AE3B-4E45-88C3-C795B0DE71A6@csperkins.org> 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] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 12:10:15 -0000 OK, makes sense. -hadriel On Sep 21, 2011, at 8:09 AM, Colin Perkins wrote: > Yes, essentially (plus RTP over UDP for the media, of course). >=20 > Colin >=20 >=20 > On 21 Sep 2011, at 12:45, Hadriel Kaplan wrote: >> Just to make sure I'm on the same wavelength, you're talking about: >> 1) Defining PseudoTCP over UDP (a la libnice and jingle) for stream-orie= nted reliable data delivery. >> 2) Defining DDCP over UDP for message-oriented unreliable data delivery. >> 3) Requiring the browser to implement and only expose those two options = for the "data" stream type and not raw UDP, so that we can enforce congesti= on control of the data channel. (oh, and the option for it to be PseudoTCP/= DTLS/UDP or DCCP/DTLS/UDP) >>=20 >> Correct? >>=20 >> -hadriel From oej@edvina.net Wed Sep 21 05:10: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 C5F7F21F8C35 for ; Wed, 21 Sep 2011 05:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=-0.144, 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 ljClX+epYM+A for ; Wed, 21 Sep 2011 05:10:44 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3349B21F8B73 for ; Wed, 21 Sep 2011 05:10:44 -0700 (PDT) Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 7D0F2754BCE5; Wed, 21 Sep 2011 12:13:10 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Wed, 21 Sep 2011 14:13:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <86AAA5D9-C19E-406F-A1BE-9CD4C5200FDC@edvina.net> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> <4E777414.1040801@mozilla.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1244.3) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 12:10:44 -0000 21 sep 2011 kl. 12:28 skrev I=F1aki Baz Castillo: > 2011/9/21 I=F1aki Baz Castillo : >> 2011/9/19 Timothy B. Terriberry : >>> Perhaps I'm confused, but doesn't MSRP rely on reliable, in-order = delivery? >>=20 >> Right, MSRP is supossed to work over TCP or TLS. In fact, TLS usage = is >> a "SHOULD" and TCP is just supposed to be used for debugging = purposes. >=20 > Using a reliable transport means that, in case both peers are behind > NAT, a MSRP Relay server (RFC 4976) is required. So as in the case of > a "RTCweb default signaling protocol" I wonder: would we expect a > 'mod_msrp' module for Apache? :) (I don't). Nothing says the relay has to be in the web server.=20 As a side note: the first SIP proxy I tested was in fact an Apache = module. /O= From magnus.westerlund@ericsson.com Wed Sep 21 05:15: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 C360021F8C51 for ; Wed, 21 Sep 2011 05:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.52 X-Spam-Level: X-Spam-Status: No, score=-106.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 9okMgoi6w7E4 for ; Wed, 21 Sep 2011 05:15:09 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id AB0D621F8C44 for ; Wed, 21 Sep 2011 05:15:08 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-3a-4e79d5e0f4cc Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1B.83.02839.0E5D97E4; Wed, 21 Sep 2011 14:17:36 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Wed, 21 Sep 2011 14:17:35 +0200 Message-ID: <4E79D5DF.4050402@ericsson.com> Date: Wed, 21 Sep 2011 14:17:35 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> In-Reply-To: <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 12:15:09 -0000 On 2011-09-21 11:02, Hadriel Kaplan wrote: > > On Sep 21, 2011, at 4:19 AM, Magnus Westerlund wrote: > >> If I interpret this correctly, you are arguing that an RTCWEB >> implementation shall support a remote end-point that doesn't >> support RTCP. > > Yes, although we could make that allowance/exception for audio only - > in fact, G.711 only if it comes down to it. Well, I don't know if we can argue that one past the Transport Area Director? I know I can argue 400 bps as an acceptable non congestion controlled rate. And that is because that is the equivalent of a full backed off TCP connection that sends one full Ethernet frame every 30 seconds. We probably can argue 4kbps also as an acceptable rate. But getting to the next magnitude is more problematic, especially in the light that there still exist a reasonable large number of access links around the world that don't have more than a few 10kbps in capacity. > > Ultimately there is no indication in SIP/SDP that an device does not > support RTCP. So what would you have the Rtcweb browser do? Once it > starts sending media if it doesn't receive RTCP within time X then > terminate the session automatically? Would users be ok with that? I think that must be part of the adaptation/congestion control algorithm. IF you don't get transport feedback you must stop sending. A TCP connection that doesn't get ACKs will also not send. Well, it is a transport failure and you would have to indicate that connection is lost or something like this. > > >> I see congestion control for media as a MUST have due to the >> attack vector that exist in RTCWEB implementations. A Webservice >> that has sufficient amount of users visiting it can create >> additional PeerConnections beyond what is necessary for the service >> that is the front. These additional PeerConnections can be used to >> create traffic load over selected paths in the Internet by >> selecting a good pairs of peers to establish these overload >> streams. If there is no congestion control, or at least isn't >> reasonably fair sharing it could push large amount of other traffic >> out of the way on the paths selected by the attacker to be >> targeted. > > If I understand your concern correctly, you're worried about the case > of a malicious site controlling unsuspecting users as a botnet, > making calls to each other and flooding the network paths between? Yes. > > That can happen anyway: all ends are under control of the malicious > site, so ICE will succeed... and even if the media layer starts > throttling itself in a few seconds, the script can just keep > creating/destroying PeerConnections, feeding new SDP to trigger port > number changes, etc. And do so for video and audio and data channels > concurrently or intermixed. Yes, ICE is not a protection against this. And you are correct that if you can start at rate higher than your "fair" share and then get throttled down to the fair rate, then Congestion Control provides less of a protection against this attack than if you start at or below your fair share. But, you don't have knowledge about the acceptable rate prior to actually sending. That combined with the issue of slow starting media makes it a hard nut to crakc. I don't have really good answer to the issue and it is clear that some compromise will be reached. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From randell-ietf@jesup.org Wed Sep 21 06:29: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 B2C2421F8BBB for ; Wed, 21 Sep 2011 06:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 zIR3PKtdV6LQ for ; Wed, 21 Sep 2011 06:29:54 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id D7D5821F8B9F for ; Wed, 21 Sep 2011 06:29:54 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R6MuV-0000mZ-CL for rtcweb@ietf.org; Wed, 21 Sep 2011 08:32:23 -0500 Message-ID: <4E79E698.2090905@jesup.org> Date: Wed, 21 Sep 2011 09:28:56 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <4E787D56.8060106@alvestrand.no> <4E788A9C.40105@alvestrand.no> <4E799F00.8030602@alvestrand.no> In-Reply-To: <4E799F00.8030602@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] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-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: Wed, 21 Sep 2011 13:29:55 -0000 On 9/21/2011 4:23 AM, Harald Alvestrand wrote: > I think receiver->sender reporting every RTT (or every packet, which > is frequently less frequent) is overkill, but that's a statement with > a lot of gut feeling and very few numbers behind it. > > One advantage we have in RTCWEB is that we can assume that if audio > and video work OK across the network, we're in a good place. We don't > have to worry about getting gigabyte file transfers to utilize 90% of > the link - even thogh we have to worry about audio and video > functioning while those gigabyte transfers are taking place. Agreed. Also, in practice the TCP flows we're competing with are rarely long-lived high-bandwidth flows like GB file transfers. Normally they're flurries of short-lived TCP (which is important to consider since these short-lived flows can suddenly cause buffering without warning). As for 1 feedback/RTT, I agree. And if you wanted to use one feedback/RTT, I'd put the feedback in a TCP header extension or design an RTP equivalent that can carry it in the reverse-direction media flow (when available). But that's a different argument. -- Randell Jesup randell-ietf@jesup.org From gettysjim@gmail.com Wed Sep 21 06:41: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 13BBB21F8CC0 for ; Wed, 21 Sep 2011 06:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQTsqde0pQzN for ; Wed, 21 Sep 2011 06:41:26 -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 EB87A21F8C9E for ; Wed, 21 Sep 2011 06:41:25 -0700 (PDT) Received: by qyk33 with SMTP id 33so1784840qyk.10 for ; Wed, 21 Sep 2011 06:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=h4HXIG+sjryH9KidRYbeE9f1xLn5tMSnPMBdOG6o+UE=; b=KzDxupOiSuj3k87N0JcrECvprobmonezEcI4NP2XM+onuBu8/fL7YQ1JXXDpm7mfDL EoMnDltf1EMe1Y16ZeZqKSXCIJjBrvmMLTb7TWmw6cvQvtthWynGL4gtzzNjQrsQVGHd cN6ssxPo6LjJ3vwkbrPG1wSzeMDRmOgXGwrwQ= Received: by 10.229.70.130 with SMTP id d2mr572228qcj.130.1316612634143; Wed, 21 Sep 2011 06:43:54 -0700 (PDT) Received: from [172.30.45.80] (c-98-229-130-122.hsd1.ma.comcast.net. [98.229.130.122]) by mx.google.com with ESMTPS id cc12sm4915786qab.16.2011.09.21.06.43.52 (version=SSLv3 cipher=OTHER); Wed, 21 Sep 2011 06:43:53 -0700 (PDT) Sender: Jim Gettys Message-ID: <4E79EA16.7070909@freedesktop.org> Date: Wed, 21 Sep 2011 09:43:50 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Randell Jesup References: <4E649FBD.1090001@alvestrand.no> <4E734E89.5010105@ericsson.com> <4E766C4C.2020201@jesup.org> <4E787D56.8060106@alvestrand.no> <4E788A9C.40105@alvestrand.no> <4E799F00.8030602@alvestrand.no> <4E79E698.2090905@jesup.org> In-Reply-To: <4E79E698.2090905@jesup.org> Content-Type: multipart/alternative; boundary="------------090004020604090401020108" Cc: rtcweb@ietf.org Subject: Re: [rtcweb] An input for discussing congestion control (Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-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: Wed, 21 Sep 2011 13:41:27 -0000 This is a multi-part message in MIME format. --------------090004020604090401020108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 09/21/2011 09:28 AM, Randell Jesup wrote: > On 9/21/2011 4:23 AM, Harald Alvestrand wrote: >> I think receiver->sender reporting every RTT (or every packet, which >> is frequently less frequent) is overkill, but that's a statement with >> a lot of gut feeling and very few numbers behind it. >> >> One advantage we have in RTCWEB is that we can assume that if audio >> and video work OK across the network, we're in a good place. We don't >> have to worry about getting gigabyte file transfers to utilize 90% of >> the link - even thogh we have to worry about audio and video >> functioning while those gigabyte transfers are taking place. > > Agreed. Also, in practice the TCP flows we're competing with are > rarely long-lived > high-bandwidth flows like GB file transfers. Normally they're > flurries of short-lived TCP > (which is important to consider since these short-lived flows can > suddenly cause buffering > without warning). You get to deal with some of each. Both cause havoc in the face of bufferbloat. The long lived flows keep the buffers in your OS/Home router/broadband gear near full, inserting lots of delay. This includes doing backups (local or remote), uploading videos, downloading videos to disk, bittorrent, etc. The netalyzr data is quite grim, particularly when you realise it's a lower bound on the problem (the netalyzr test is sensitive to cross traffic and more importantly, tops out by the time it gets to 20Mbps). http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-another/ As far as the transient bufferbloat problem caused by web traffic, and why IW10 is a problem in my view at this time, see: http://www.ietf.org/id/draft-gettys-iw10-considered-harmful-00.txt > > As for 1 feedback/RTT, I agree. And if you wanted to use one > feedback/RTT, I'd put the feedback in > a TCP header extension or design an RTP equivalent that can carry it > in the reverse-direction > media flow (when available). But that's a different argument. > I like timestamps, if only to make it easy to tell the user: you are losing, and it's because of your broken network. For TCP, the TCP timestamp option is on by default in Linux, and I think may be on by default on other modern systems (anyone have any data?). - Jim Other protocols may not be so nice. --------------090004020604090401020108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/21/2011 09:28 AM, Randell Jesup wrote:
On 9/21/2011 4:23 AM, Harald Alvestrand wrote:
I think receiver->sender reporting every RTT (or every packet, which is frequently less frequent) is overkill, but that's a statement with a lot of gut feeling and very few numbers behind it.

One advantage we have in RTCWEB is that we can assume that if audio and video work OK across the network, we're in a good place. We don't have to worry about getting gigabyte file transfers to utilize 90% of the link - even thogh we have to worry about audio and video functioning while those gigabyte transfers are taking place.

Agreed.  Also, in practice the TCP flows we're competing with are rarely long-lived
high-bandwidth flows like GB file transfers.  Normally they're flurries of short-lived TCP
(which is important to consider since these short-lived flows can suddenly cause buffering
without warning).

You get to deal with some of each. Both cause havoc in the face of bufferbloat.  The long lived flows keep the buffers in your OS/Home router/broadband gear near full, inserting lots of delay.  This includes doing backups (local or remote), uploading videos, downloading videos to disk, bittorrent, etc. The netalyzr data is quite grim, particularly when you realise it's a lower bound on the problem (the netalyzr test is sensitive to cross traffic and more importantly, tops out by the time it gets to 20Mbps).

http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-another/

As far as the transient bufferbloat problem caused by web traffic, and why IW10 is a problem in my view at this time, see:

http://www.ietf.org/id/draft-gettys-iw10-considered-harmful-00.txt


As for 1 feedback/RTT, I agree.  And if you wanted to use one feedback/RTT, I'd put the feedback in
a TCP header extension or design an RTP equivalent that can carry it in the reverse-direction
media flow (when available).  But that's a different argument.

I like timestamps, if only to make it easy to tell the user: you are losing, and it's because of your broken network.

For TCP, the TCP timestamp option is on by default in Linux, and I think may be on by default on other modern systems (anyone have any data?).
                        - Jim


Other protocols may not be so nice.
--------------090004020604090401020108-- From saul@ag-projects.com Wed Sep 21 06:46: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 C748B21F8C99 for ; Wed, 21 Sep 2011 06:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.708 X-Spam-Level: X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbOgdA-RNviJ for ; Wed, 21 Sep 2011 06:46:06 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3835521F8C96 for ; Wed, 21 Sep 2011 06:46:06 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 020CAB01B5; Wed, 21 Sep 2011 15:48:33 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 5CB41B0057; Wed, 21 Sep 2011 15:48:33 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <05D1C2F6-96C3-44E3-9FC2-AD2C893C9FC6@acmepacket.com> Date: Wed, 21 Sep 2011 15:48:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5C49AE82-C0B2-4F6F-A0C7-44DC64D30009@ag-projects.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> <4E77949B.4010603@alvestrand.no> <4E78A4FB.1050504@ericsson.com> <4E79AC33.4000900@alvestrand.no> <0075AB47-3DFF-4000-9057-CA0628DF711A@csperkins.org> <05D1C2F6-96C3-44E3-9FC2-AD2C893C9FC6@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: "" , Colin Perkins Subject: Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 13:46:06 -0000 Hi, On Sep 21, 2011, at 1:45 PM, Hadriel Kaplan wrote: >=20 > Just to make sure I'm on the same wavelength, you're talking about: > 1) Defining PseudoTCP over UDP (a la libnice and jingle) for = stream-oriented reliable data delivery. > 2) Defining DDCP over UDP for message-oriented unreliable data = delivery. > 3) Requiring the browser to implement and only expose those two = options for the "data" stream type and not raw UDP, so that we can = enforce congestion control of the data channel. (oh, and the option for = it to be PseudoTCP/DTLS/UDP or DCCP/DTLS/UDP) >=20 I'm not familiar with DDCP, but MSRP requires a reliable transport = AFAIK, so would DDCP be appropriate for that purpose, for example? I = guess that Pseudo TCP would. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Wed Sep 21 06:49: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 3C4B921F8CD6 for ; Wed, 21 Sep 2011 06:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 8wH-mq1C-FkF for ; Wed, 21 Sep 2011 06:49:48 -0700 (PDT) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id A5BE921F8CD4 for ; Wed, 21 Sep 2011 06:49:48 -0700 (PDT) Received: by vws11 with SMTP id 11so3649611vws.27 for ; Wed, 21 Sep 2011 06:52:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.213.132 with SMTP id gw4mr179085vcb.52.1316613137094; Wed, 21 Sep 2011 06:52:17 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Wed, 21 Sep 2011 06:52:16 -0700 (PDT) In-Reply-To: <86AAA5D9-C19E-406F-A1BE-9CD4C5200FDC@edvina.net> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> <4E777414.1040801@mozilla.com> <86AAA5D9-C19E-406F-A1BE-9CD4C5200FDC@edvina.net> Date: Wed, 21 Sep 2011 15:52:16 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 13:49:49 -0000 2011/9/21 Olle E. Johansson : >> Using a reliable transport means that, in case both peers are behind >> NAT, a MSRP Relay server (RFC 4976) is required. So as in the case of >> a "RTCweb default signaling protocol" I wonder: would we expect a >> 'mod_msrp' module for Apache? :) (I don't). > > Nothing says the relay has to be in the web server. I expect that WebRTC is an added value for webs, and 99% of webs in the world are hosted in a shared datacenter. --=20 I=C3=B1aki Baz Castillo From roman@telurix.com Wed Sep 21 07:43: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 00D941F0C4C for ; Wed, 21 Sep 2011 07:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_56=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 tebT8+5vEkiR for ; Wed, 21 Sep 2011 07:43:06 -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 D10D11F0C36 for ; Wed, 21 Sep 2011 07:43:05 -0700 (PDT) Received: by ywa6 with SMTP id 6so1467504ywa.31 for ; Wed, 21 Sep 2011 07:45:34 -0700 (PDT) Received: by 10.236.80.66 with SMTP id j42mr5719399yhe.98.1316616334092; Wed, 21 Sep 2011 07:45:34 -0700 (PDT) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx.google.com with ESMTPS id d5sm3566656yhl.19.2011.09.21.07.45.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Sep 2011 07:45:33 -0700 (PDT) Received: by gwj18 with SMTP id 18so1792107gwj.27 for ; Wed, 21 Sep 2011 07:45:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.20.135 with SMTP id n7mr793681pbe.375.1316616332045; Wed, 21 Sep 2011 07:45:32 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Wed, 21 Sep 2011 07:45:31 -0700 (PDT) In-Reply-To: <8508ACC4-75A0-4556-8474-66175539F102@ag-projects.com> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF510F0E5E@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F0E6B@sonusinmail02.sonusnet.com> <8508ACC4-75A0-4556-8474-66175539F102@ag-projects.com> Date: Wed, 21 Sep 2011 10:45:31 -0400 Message-ID: From: Roman Shpount To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Content-Type: multipart/alternative; boundary=bcaec5215915c6f08404ad74a0bc Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 14:43:07 -0000 --bcaec5215915c6f08404ad74a0bc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We should have an option to clone (or conditionally clone) the PeerConnection based on the new answer as well as provide an answer update to the exiting PeerConnection. In the first case, application can create a separate media connection to a forked response and render it separately. In the second, application can start rendering input from a new answer as well as sending media to it. This way we can address all the possible scenarios and leave control in the application developer's hands. As far as offer/answer is concerned RTC should be able to interop with it, but I would assume we should be able to add new features and functionality if they would enable us to build new applications or interop with existing deployments. Processing answer updates or offer failures is not described i= n offer.answer but it will not break interoperability of RTC with any offer/answer solutions _____________ Roman Shpount On Wed, Sep 21, 2011 at 3:00 AM, Sa=FAl Ibarra Corretg=E9 wrote: > > On Sep 21, 2011, at 8:25 AM, Ravindran Parthasarathi wrote: > > > Hi Roman, > > > > Thanks for the correction. I agree with you that there is no need to > mention that forking is not support in RTCWeb. Your simple model works fo= r > browser as RTP End-point. One problem with the generic statement of multi= ple > answer is that it may violate offer/answer model itself. For example: 18x > and 200 having different answer for INVITE offer (standard implementation > violation of offer/answer ;-)) > > > > I think that the case discussed before was that you may receive several 1= 8x > responses because the request forked in the SIP side. So, if more than on= e > of these 18x responses do have an SDP, do we create a PeerConnection for > each? One for the first? The last? > > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects > > > > --bcaec5215915c6f08404ad74a0bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We should have an option to clone (or conditionally clone) the PeerConnecti= on based on the new answer as well as provide an answer update to the exiti= ng PeerConnection. In the first case, application can create a separate med= ia connection to a forked response and render it separately. In the second,= application can start rendering input from a new answer as well as sending= media to it. This way we can address all the possible scenarios and leave = control in the application developer's hands.

As far as offer/answer is concerned RTC should be able to interop with = it, but I would assume we should be able to add new features and functional= ity if they would enable us to build new applications or interop with exist= ing deployments. Processing answer updates or offer failures is not describ= ed in offer.answer but it will not break interoperability of RTC with any o= ffer/answer solutions
_____________
Roman Shpount


On Wed, Sep 21, 2011 at 3:00 AM, Sa=FAl = Ibarra Corretg=E9 <saul@ag-projects.com> wrote:

On Sep 21, 2011, at 8:25 AM, Ravindran Parthasarathi wrote:

> Hi Roman,
>
> Thanks for the correction. I agree with you that there is no need to m= ention that forking is not support in RTCWeb. Your simple model works for b= rowser as RTP End-point. One problem with the generic statement of multiple= answer is that it may violate offer/answer model itself. For example: 18x = and 200 having different answer for INVITE offer (standard implementation v= iolation of offer/answer ;-))
>

I think that the case discussed before was that you may receive sever= al 18x responses because the request forked in the SIP side. So, if more th= an one of these 18x responses do have an SDP, do we create a PeerConnection= for each? One for the first? The last?

--
Sa=FAl Ibarra Corretg=E9
AG Projects




--bcaec5215915c6f08404ad74a0bc-- From roman@telurix.com Wed Sep 21 07:57: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 6A5AB1F0C75 for ; Wed, 21 Sep 2011 07:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EVzdM0Yz-59 for ; Wed, 21 Sep 2011 07:57: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 E0A9D1F0C70 for ; Wed, 21 Sep 2011 07:57:46 -0700 (PDT) Received: by gyd12 with SMTP id 12so1481354gyd.31 for ; Wed, 21 Sep 2011 08:00:15 -0700 (PDT) Received: by 10.150.66.11 with SMTP id o11mr1040479yba.433.1316617215357; Wed, 21 Sep 2011 08:00:15 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id x23sm1972539ybd.20.2011.09.21.08.00.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Sep 2011 08:00:15 -0700 (PDT) Received: by ywa6 with SMTP id 6so1483994ywa.31 for ; Wed, 21 Sep 2011 08:00:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.5.162 with SMTP id t2mr1484676pbt.241.1316617213193; Wed, 21 Sep 2011 08:00:13 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Wed, 21 Sep 2011 08:00:11 -0700 (PDT) In-Reply-To: <4E798D47.5030905@jesup.org> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2EB@ESESSCMS0356.eemea.ericsson.se> <1A61D589-1C23-4364-AA4A-60338D8C5859@edvina.net> <4E798D47.5030905@jesup.org> Date: Wed, 21 Sep 2011 11:00:11 -0400 Message-ID: From: Roman Shpount To: Randell Jesup Content-Type: multipart/alternative; boundary=bcaec52159a54c2eb104ad74d5d6 Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Forking & Early Media - Proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 14:57:48 -0000 --bcaec52159a54c2eb104ad74d5d6 Content-Type: text/plain; charset=ISO-8859-1 Randell, Are we going to create multiple PeerConnections in case of forking when multiple ANSWER + ACCEPT are received? _____________ Roman Shpount On Wed, Sep 21, 2011 at 3:07 AM, Randell Jesup wrote: > NOTE: Attached below is a proposed set of forking/early-media > and clipping-avoidance rules, so don't glance and delete! :-) > > Also note: I started writing this earlier today, so it was largely > done before much of today's discussion on forking. I'll note that > I include in this a method to minimize chances of answer-time > clipping. (For any who don't know (if there are any), this is > where the first fraction of a second after pickup is lost while > answering, starting codecs, doing ICE, etc.) > > > On 9/20/2011 9:40 AM, Olle E. Johansson wrote: > >> 20 sep 2011 kl. 15:15 skrev Christer Holmberg: >> >> Once we start requiring that the PeerConnection know the >>>>> difference between "early" media and "late" media, it seems >>>>> to me we're slipping down a slippery slope. >>>>> >>>> The difference between early and late media is purely a >>>> billing decision in PSTN. I don't think we should separate >>>> these on the rtcweb side. It's a PSTN gateway issue, not >>>> something to be bothered with in rtcweb. >>>> >>> It's not about knowing the difference between "early" and "late" media - >>> it's about whether the API and browser need to support multiple SIMULTANOUS >>> SDP answers - or whether we assume that the JS SIP app will always, at any >>> given time, only provide ONE SDP answer to the API and browser. >>> >> I just wanted to get rid of the early/late media discussion. As you >> state, the forking issue with getting multiple responses is a separate >> issue. >> >> Do we have any use cases using forking? Is forking a desired feature or >> something that SIP brought in? >> > > No, this is something inherent in a person you want to converse with > possibly being in different places. Different phones in a home, > different computers in a home or out of it (your desktop, your laptop, > your tablet, your work computer, your Android phone) - when someone > wants to talk to you on Skype or what have you, often the service will > want to offer the connection to any and all devices you're logged into > the service from. So, it forks the request. We'd have this issue > even if we totally disallow SIP and disallow PSTN connectivity. If > you require that the website/server handle this and only provide one > answer, you're much more likely to clip the answer (lose audio right > after accept while the channels are being opened). > > Two things in particular appear here. One is early media (I want to > send media to you but no one has accepted). I do not propose that > rtcweb generate early media; some sort of "alerting" notification is > enough (equivalent to 180). (Realize that means no custom callback > tones or video, or weird cases like sitting on hold or in an IVR while > not actually "in" a call). If so, we only have to worry about interop > cases - calling out to legacy, or *maybe* a call forked in rtcweb > where one of the forks goes to a legacy device or gateway that sends > early media. > > The other is choosing which answer to accept if multiple arrive; that > can be up to the application I think (though 99% likely the app will > want to use the first answer). I don't think we have to *mandate* > that the first answer is the one we use though I can't think of any > cases where we wouldn't, but I'm pretty sure they exist and I wouldn't > want to outlaw them for no reason). If it makes any use-cases easier > to mandate the first answer, that may change my opinion. If you're > using SIP (JS or not) that might affect the answer, of course. > > While waiting for an acceptance, it makes *lots* of sense to "warm up" > the connection(s) so that when the call is accepted there's minimal > delay or pickup loss. "warm up" means to do an ICE exchange and > possibly even instantiate codecs, etc. This is complicated by not > knowing the final answer until the user decides how to answer, but you > could warm up the likely streams/codecs in most cases, and drop some > if needed on ACCEPT. In the forking case, you could warm up > connections to some or all possible answers. (Pacing may be an issue > here, but often there are 5-20 seconds to do it in.) > > Implicit in this is separating ANSWERs from "acceptance", and > verifying on "acceptance" that the correct ANSWER is used (for > example, we warm up audio and video, and the person answers > audio-only, or for some reason chooses a different codec). > > > So, to summarize in psuedo-spec language: > > 0) I'm assuming an Offer-Answer model here, though not assuming SDP. > If you want, read "SDP ANSWER" for "ANSWER", etc to map to Harald's > proposals. Note that I add "ACCEPT". > 0.1) Rough mapping to SIP: > a) INVITE -> OFFER > b) 183 -> ANSWER > c) 180 -> ANSWER-with-no-media-streams > c) 200 -> ANSWER (may be suppressed) + ACCEPT > 0.2) I'm assuming OFFERs and ANSWERs and ACCEPTs are delivered on > a reliable, in-order channel. > > 1) webrtc clients WILL NOT send early media > [See below; I see no real need for webrtc<->webrtc client connections > to send early media, but SIP/PSTN interop cases may require it, so > I have an alternative below] > 2) when a webrtc client receives a OFFER, it MAY generate a speculative > ANSWER in order to allow pre-starting the PeerConnection in a disabled > state. If pre-started, NO media shall be sent until the call has been > ACCEPTED. Note that the OFFERer may receive data before seeing > the ACCEPT. > 3) if the ANSWERer generated a speculative ANSWER, it may replace that > with an alternative ANSWER before sending ACCEPT. This alternative > SHOULD use the same connection address as the original, and if so > the existing PeerConnection established or being established SHOULD > be retained, but the mediastream configuration changed to match > the new ANSWER. > 4) the OFFERer SHOULD pre-start PeerConnections on a speculative ANSWER, or > they MAY wait until an ACCEPT and then start the last ANSWER from that > source. If multiple sources supply speculative ANSWERs, the OFFERer > MAY pre-start some, none or all of them as it wishes. > [Open question: do we pre-start MediaStreams in each pre-starting > PeerConnection, or do (can) we defer this until ACCEPT?] > 5) when the OFFERer receives an ACCEPT, it MAY close other PeerConnections > opened speculatively. > 6) when an ANSWERer sends an accept, it MAY begin sending media immediately > if the PeerConnection was pre-started. It SHOULD be ready to receive > media before sending the ACCEPT. > 7) servers handling signalling for webrtc clients MAY fork a call offer > to multiple webrtc clients > 8) if a call is forked, the webrtc client MAY receive either a single > ANSWER and ACCEPT, or MAY receive multiple ANSWERs with one or more > ACCEPTs, depending on how the server works. > > The provides a way to minimize the chances of start-of-call clipping, > and handles forking with minimal clipping (with cooperation of the > app). Note that there may be a implementation limit on the number of > PeerConnections that can be "warmed up" before an ACCEPT. > > Yes, if we remove 1) and replace it with (probably lower down) > > N) webrtc clients MAY send "early media" on a pre-started PeerConnection > but MUST NOT send any media without explicit action or consent of the > user. webrtc clients MAY play the early media. > > or > > N) webrtc media gateways MAY send "early media" on a pre-started > PeerConnection, > and webrtc clients receiving "early media" MAY play it, and MAY send > media (such as DTMF) but MUST NOT send any media without explicit > action or consent of the user. > > (and you have to change 2) above) > > you get something that is pretty interoperable with legacy SIP devices > and especially PSTN gateways or border controllers, including the infamous > American Airlines DTMF trick. This assumes a WebRTC<->legacy media gateway > is in use (note that all the above is about PeerConnections). I have not > tried to figure out how non-gatewayed legacy would work into this, but it > should be doable. > > > -- > Randell Jesup > randell-ietf@jesup.org > > ______________________________**_________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/**listinfo/rtcweb > --bcaec52159a54c2eb104ad74d5d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Randell,

Are we going to create multiple PeerConnections in case of = forking when multiple ANSWER + ACCEPT are received?
______= _______
Roman Shpount


On Wed, Sep 21, 2011 at 3:07 AM, Randell= Jesup <rand= ell-ietf@jesup.org> wrote:
NOTE: Attached below is a proposed set of forking/early-media
and clipping-avoidance rules, so don't glance and delete! =A0:-)

Also note: I started writing this earlier today, so it was largely
done before much of today's discussion on forking. =A0I'll note tha= t
I include in this a method to minimize chances of answer-time
clipping. =A0(For any who don't know (if there are any), this is
where the first fraction of a second after pickup is lost while
answering, starting codecs, doing ICE, etc.)


On 9/20/2011 9:40 AM, Olle E. Johansson wrote:
=A020 sep 2011 kl. 15:15 skrev Christer Holmberg:

=A0Once we start requiring that the PeerConnection know the
=A0difference between "early" media and "late" media, i= t seems
=A0to me we're slipping down a slippery slope.
=A0The difference between early and late media is purely a
=A0billing decision in PSTN. I don't think we should separate
=A0these on the rtcweb side. It's a PSTN gateway issue, not
=A0something to be bothered with in rtcweb.
=A0It's not about knowing the difference between "early" and = "late" media - it's about whether the API and browser need to= support multiple SIMULTANOUS SDP answers - or whether we assume that the J= S SIP app will always, at any given time, only provide ONE SDP answer to th= e API and browser.
=A0I just wanted to get rid of the early/late media discussion. As you stat= e, the forking issue with getting multiple responses is a separate issue.
=A0Do we have any use cases using forking? Is forking a desired feature or = something that SIP brought in?

No, this is something inherent in a person you want to converse with
possibly being in different places. =A0Different phones in a home,
different computers in a home or out of it (your desktop, your laptop,
your tablet, your work computer, your Android phone) - when someone
wants to talk to you on Skype or what have you, often the service will
want to offer the connection to any and all devices you're logged into<= br> the service from. =A0So, it forks the request. =A0We'd have this issue<= br> even if we totally disallow SIP and disallow PSTN connectivity. =A0If
you require that the website/server handle this and only provide one
answer, you're much more likely to clip the answer (lose audio right after accept while the channels are being opened).

Two things in particular appear here. =A0One is early media (I want to
send media to you but no one has accepted). =A0I do not propose that
rtcweb generate early media; some sort of "alerting" notification= is
enough (equivalent to 180). =A0(Realize that means no custom callback
tones or video, or weird cases like sitting on hold or in an IVR while
not actually "in" a call). =A0If so, we only have to worry about = interop
cases - calling out to legacy, or *maybe* a call forked in rtcweb
where one of the forks goes to a legacy device or gateway that sends
early media.

The other is choosing which answer to accept if multiple arrive; that
can be up to the application I think (though 99% likely the app will
want to use the first answer). =A0I don't think we have to *mandate* that the first answer is the one we use though I can't think of any
cases where we wouldn't, but I'm pretty sure they exist and I would= n't
want to outlaw them for no reason). =A0If it makes any use-cases easier
to mandate the first answer, that may change my opinion. =A0If you're using SIP (JS or not) that might affect the answer, of course.

While waiting for an acceptance, it makes *lots* of sense to "warm up&= quot;
the connection(s) so that when the call is accepted there's minimal
delay or pickup loss. =A0"warm up" means to do an ICE exchange an= d
possibly even instantiate codecs, etc. =A0This is complicated by not
knowing the final answer until the user decides how to answer, but you
could warm up the likely streams/codecs in most cases, and drop some
if needed on ACCEPT. =A0In the forking case, you could warm up
connections to some or all possible answers. =A0(Pacing may be an issue
here, but often there are 5-20 seconds to do it in.)

Implicit in this is separating ANSWERs from "acceptance", and
verifying on "acceptance" that the correct ANSWER is used (for example, we warm up audio and video, and the person answers
audio-only, or for some reason chooses a different codec).


So, to summarize in psuedo-spec language:

0) =A0 I'm assuming an Offer-Answer model here, though not assuming SDP= .
=A0 =A0 If you want, read "SDP ANSWER" for "ANSWER", e= tc to map to Harald's
=A0 =A0 proposals. =A0Note that I add "ACCEPT".
0.1) Rough mapping to SIP:
=A0 =A0 a) INVITE -> =A0OFFER
=A0 =A0 b) 183 -> =A0ANSWER
=A0 =A0 c) 180 -> =A0ANSWER-with-no-media-streams
=A0 =A0 c) 200 -> =A0ANSWER (may be suppressed) + ACCEPT
0.2) I'm assuming OFFERs and ANSWERs and ACCEPTs are delivered on
=A0 =A0 a reliable, in-order channel.

1) webrtc clients WILL NOT send early media
=A0 [See below; I see no real need for webrtc<->webrtc client connec= tions
=A0 =A0to send early media, but SIP/PSTN interop cases may require it, so<= br> =A0 =A0I have an alternative below]
2) when a webrtc client receives a OFFER, it MAY generate a speculative
=A0 ANSWER in order to allow pre-starting the PeerConnection in a disabled=
=A0 state. =A0If pre-started, NO media shall be sent until the call has be= en
=A0 ACCEPTED. =A0Note that the OFFERer may receive data before seeing
=A0 the ACCEPT.
3) if the ANSWERer generated a speculative ANSWER, it may replace that
=A0 with an alternative ANSWER before sending ACCEPT. =A0This alternative<= br> =A0 SHOULD use the same connection address as the original, and if so
=A0 the existing PeerConnection established or being established SHOULD =A0 be retained, but the mediastream configuration changed to match
=A0 the new ANSWER.
4) the OFFERer SHOULD pre-start PeerConnections on a speculative ANSWER, or=
=A0 they MAY wait until an ACCEPT and then start the last ANSWER from that=
=A0 source. =A0If multiple sources supply speculative ANSWERs, the OFFERer=
=A0 MAY pre-start some, none or all of them as it wishes.
=A0 [Open question: do we pre-start MediaStreams in each pre-starting
=A0 =A0PeerConnection, or do (can) we defer this until ACCEPT?]
5) when the OFFERer receives an ACCEPT, it MAY close other PeerConnections<= br> =A0 opened speculatively.
6) when an ANSWERer sends an accept, it MAY begin sending media immediately=
=A0 if the PeerConnection was pre-started. =A0It SHOULD be ready to receiv= e
=A0 media before sending the ACCEPT.
7) servers handling signalling for webrtc clients MAY fork a call offer
=A0 to multiple webrtc clients
8) if a call is forked, the webrtc client MAY receive either a single
=A0 ANSWER and ACCEPT, or MAY receive multiple ANSWERs with one or more =A0 ACCEPTs, depending on how the server works.

The provides a way to minimize the chances of start-of-call clipping,
and handles forking with minimal clipping (with cooperation of the
app). =A0Note that there may be a implementation limit on the number of
PeerConnections that can be "warmed up" before an ACCEPT.

Yes, if we remove 1) and replace it with (probably lower down)

N) webrtc clients MAY send "early media" on a pre-started PeerCon= nection
=A0 but MUST NOT send any media without explicit action or consent of the<= br> =A0 user. =A0webrtc clients MAY play the early media.

or

N) webrtc media gateways MAY send "early media" on a pre-started = PeerConnection,
=A0 and webrtc clients receiving "early media" MAY play it, and = MAY send
=A0 media (such as DTMF) but MUST NOT send any media without explicit
=A0 action or consent of the user.

=A0(and you have to change 2) above)

you get something that is pretty interoperable with legacy SIP devices
and especially PSTN gateways or border controllers, including the infamous<= br> American Airlines DTMF trick. =A0This assumes a WebRTC<->legacy media= gateway
is in use (note that all the above is about PeerConnections). =A0I have not=
tried to figure out how non-gatewayed legacy would work into this, but it should be doable.


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

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

--bcaec52159a54c2eb104ad74d5d6-- From randell-ietf@jesup.org Wed Sep 21 08:35: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 0E72F5E800C for ; Wed, 21 Sep 2011 08:35:24 -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 GC6BOJ0IQR7c for ; Wed, 21 Sep 2011 08:35:23 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 92D085E800A for ; Wed, 21 Sep 2011 08:35:23 -0700 (PDT) Received: from [165.123.243.248] (helo=[10.10.8.117]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R6Orw-0005Ng-8p for rtcweb@ietf.org; Wed, 21 Sep 2011 10:37:52 -0500 Message-ID: <4E7A04D1.3060903@jesup.org> Date: Wed, 21 Sep 2011 08:37:53 -0700 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2EB@ESESSCMS0356.eemea.ericsson.se> <1A61D589-1C23-4364-AA4A-60338D8C5859@edvina.net> <4E798D47.5030905@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] Forking & Early Media - Proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 15:35:24 -0000 On 9/21/2011 8:00 AM, Roman Shpount wrote: > Randell, > > Are we going to create multiple PeerConnections in case of forking > when multiple ANSWER + ACCEPT are received? That would be up to the application in my proposal. I stated that on ACCEPT the OFFERer MAY close any 'warm' PeerConnections: 5) when the OFFERer receives an ACCEPT, it MAY close other PeerConnections opened speculatively. I didn't specify, but there's no requirement on multiple ACCEPT to close the other connections, so it's up to the app. -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Wed Sep 21 08:47: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 1EFA021F8B03 for ; Wed, 21 Sep 2011 08:47:31 -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 GHwaM49wlIN4 for ; Wed, 21 Sep 2011 08:47:30 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id A53BF21F8B01 for ; Wed, 21 Sep 2011 08:47:30 -0700 (PDT) Received: from [165.123.243.248] (helo=[10.10.8.117]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R6P3f-0003H7-Cn for rtcweb@ietf.org; Wed, 21 Sep 2011 10:49:59 -0500 Message-ID: <4E7A07A8.4040407@jesup.org> Date: Wed, 21 Sep 2011 08:50:00 -0700 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> In-Reply-To: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rtcweb] Data transfer X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 15:47:31 -0000 [ Old response that was sitting on my laptop in drafts... Feel free to ignore] On 9/15/2011 11:32 PM, Olle E. Johansson wrote: > A comment on the list made me go back and re-read the charter. One > thing I had missed is the data transfer part of rtcweb. > > "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." > Most of the discussions on the list has been about the media. What are > the ideas for data transfer? Applications? See the Use Case document: some obvious ones are games, remote-assistance, web conference with screen sharing or whiteboards, file transfer while talking, etc. Unreliable data channels will be included, and while there isn't express consensus yet I very much want (and think we'll have) reliable data channels, probably based on TCP-over-UDP (over DTLS). > To me, this seems like an interesting feature. If it's a plain data > transfer session, a bidirectional session, it's a way to open a > session from Javascript to any server, acting as an rtcweb client, > which is different from the current sandbox model. I could have missed > this discussion, but if not, I think this is an interesting topic to > bring up. It is a way to open channels to another machine, though in response to a user request to do so (which is the domain of the security arena here). Note that the audio and video channels are "data" channels as well, though perhaps the JS would be kept from direct access to the sources, and thus limit them as channels for exporting data from JS. Note that if we allow webrtc clients to *send* "early" data OR early media in response to an OFFER, it is a potential information leak and security risk to evaluate. For example, if the JS app is gathering typing data from an information compromise (real case, won't go into details), it could feed it out in realtime using "early data" in response to an OFFER that's never communicated to the user. Now, this may not be a valid concern since I think there are plenty of other ways for an malevolent app to export data once it has it - just trying to make sure we've considered the leak and decided it's safe, IF we want to support sending early media/data. -- Randell Jesup randell-ietf@jesup.org From bernard_aboba@hotmail.com Wed Sep 21 09:01: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 5B24D1F0CAD for ; Wed, 21 Sep 2011 09:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.235, 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 3tVKLgu+ainC for ; Wed, 21 Sep 2011 09:01:15 -0700 (PDT) Received: from blu0-omc3-s9.blu0.hotmail.com (blu0-omc3-s9.blu0.hotmail.com [65.55.116.84]) by ietfa.amsl.com (Postfix) with ESMTP id BEE4A1F0CA9 for ; Wed, 21 Sep 2011 09:01:15 -0700 (PDT) Received: from BLU152-W7 ([65.55.116.74]) by blu0-omc3-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Sep 2011 09:03:44 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_40d3c9b8-6b22-449c-9575-5354d683ec60_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: , Date: Wed, 21 Sep 2011 09:03:44 -0700 Importance: Normal In-Reply-To: <4E7994D7.60102@ericsson.com> References: <4E76E8E8.2050102@ericsson.com> <4E788E00.9020909@ericsson.com>, <4E78A467.7040409@jitsi.org>, <4E7994D7.60102@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 21 Sep 2011 16:03:44.0685 (UTC) FILETIME=[0A0BB5D0:01CC7878] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 16:01:16 -0000 --_40d3c9b8-6b22-449c-9575-5354d683ec60_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stefan said:=20 > Anyway=2C I seem to be rather lonely in my corner of the room=2C but I=20 > maintain my opinion that we should defer this to a later stage. [BA] You are not lonely (at least with respect to deferring discussion of = scenario B).=20 I believe that we can include scenario A within the use case document and security document=2C and see how much this affects the requirements and security issues (I expect not too much).=20 However=2C I am in favor of deferring scenario B rather than adding it. Th= is scenario has potentially major security implications=2C which could slow pr= ogress on other items. To me=2C this is a good reason to defer it. If we keep ad= ding major work items=2C the overall schedule will slip=2C and that is quite dan= gerous.=20 = --_40d3c9b8-6b22-449c-9575-5354d683ec60_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Stefan said:

>=3B Anyway=2C I seem to be rather lonely in my= corner of the room=2C but I
>=3B maintain my opinion that we should = defer this to a later stage.

[BA] =3B You are not lonely (at lea= st with respect to deferring discussion of scenario B).

I believe t= hat we can include scenario A within the use case document
and security = document=2C and see how much this affects the requirements and
security = issues (I expect not too much).

However=2C I am in favor of deferri= ng scenario B rather than adding it. =3B This
scenario has potential= ly major security implications=2C which could slow progress
on other ite= ms. =3B To me=2C this is a good reason to defer it. =3B If we keep = adding
major work items=2C the overall schedule will slip=2C and that is= quite dangerous.

= --_40d3c9b8-6b22-449c-9575-5354d683ec60_-- From emil@sip-communicator.org Wed Sep 21 11:47: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 DFA7821F8C36 for ; Wed, 21 Sep 2011 11:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 VpC2AHOAB4DR for ; Wed, 21 Sep 2011 11:47:10 -0700 (PDT) Received: from mail-ew0-f42.google.com (mail-ew0-f42.google.com [209.85.215.42]) by ietfa.amsl.com (Postfix) with ESMTP id 035F721F8C32 for ; Wed, 21 Sep 2011 11:47:09 -0700 (PDT) Received: by ewy1 with SMTP id 1so1888738ewy.15 for ; Wed, 21 Sep 2011 11:49:37 -0700 (PDT) Received: by 10.216.169.74 with SMTP id m52mr1352205wel.33.1316630977338; Wed, 21 Sep 2011 11:49:37 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPS id fa3sm7992933wbb.3.2011.09.21.11.49.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Sep 2011 11:49:36 -0700 (PDT) Message-ID: <4E7A31BE.4050500@jitsi.org> Date: Wed, 21 Sep 2011 20:49:34 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; bg; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: Bernard Aboba References: <4E76E8E8.2050102@ericsson.com> <4E788E00.9020909@ericsson.com>, <4E78A467.7040409@jitsi.org>, <4E7994D7.60102@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 18:47:11 -0000 =D0=9D=D0=B0 21.09.11 18:03, Bernard Aboba =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: > Stefan said: >=20 >> Anyway, I seem to be rather lonely in my corner of the room, but I >> maintain my opinion that we should defer this to a later stage. >=20 > [BA] You are not lonely (at least with respect to deferring discussion= > of scenario B). >=20 > I believe that we can include scenario A within the use case document > and security document, and see how much this affects the requirements a= nd > security issues (I expect not too much). >=20 > However, I am in favor of deferring scenario B rather than adding it. = This > scenario has potentially major security implications, which could slow > progress > on other items. To me, this is a good reason to defer it. If we keep > adding > major work items, the overall schedule will slip, and that is quite > dangerous. Why would the schedule slip? If this is an optional extension, as everyone agrees it should be, how could it delay the main specs and implementations? Even if there are indeed some unforeseen grave security issues (which I am not all that sure about), then it they would only delay release of this extension, wouldn't they? Emil -- http://jitsi.org From bernard_aboba@hotmail.com Wed Sep 21 11:59: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 58E1D1F0C64 for ; Wed, 21 Sep 2011 11:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.354 X-Spam-Level: X-Spam-Status: No, score=-102.354 tagged_above=-999 required=5 tests=[AWL=0.244, 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 fqsg2x-1encD for ; Wed, 21 Sep 2011 11:59:24 -0700 (PDT) Received: from blu0-omc3-s35.blu0.hotmail.com (blu0-omc3-s35.blu0.hotmail.com [65.55.116.110]) by ietfa.amsl.com (Postfix) with ESMTP id C3CEB1F0C52 for ; Wed, 21 Sep 2011 11:59:24 -0700 (PDT) Received: from BLU152-W56 ([65.55.116.73]) by blu0-omc3-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Sep 2011 12:01:53 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_e8d63647-3105-4bc1-8597-0dbe8917627d_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: Date: Wed, 21 Sep 2011 12:01:53 -0700 Importance: Normal In-Reply-To: <4E7A31BE.4050500@jitsi.org> References: <4E76E8E8.2050102@ericsson.com> <4E788E00.9020909@ericsson.com>, <4E78A467.7040409@jitsi.org>, <4E7994D7.60102@ericsson.com> , <4E7A31BE.4050500@jitsi.org> MIME-Version: 1.0 X-OriginalArrivalTime: 21 Sep 2011 19:01:53.0774 (UTC) FILETIME=[ED3D40E0:01CC7890] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 18:59:25 -0000 --_e8d63647-3105-4bc1-8597-0dbe8917627d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Why would the schedule slip? If this is an optional extension=2C as > everyone agrees it should be=2C how could it delay the main specs and > implementations? Even if there are indeed some unforeseen grave security > issues (which I am not all that sure about)=2C then it they would only > delay release of this extension=2C wouldn't they? [BA] Even if scenario B is optional=2C we will still need to do the work to= analyze the security implications and integrate it within the overall architecture. Unless all work on scen= ario B were to be separated out into a separate series of work items with no impact on existing ones (w= hich I believe would require a charter change)=2C adding scenario B would potentially affect other more = basic deliverables.=20 = --_e8d63647-3105-4bc1-8597-0dbe8917627d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B Why would the schedule slip? If this is an optional extension=2C as<= br>
>=3B everyone agrees it should be=2C how could it delay the main = specs and
>=3B implementations? Even if there are indeed some unforese= en grave security
>=3B issues (which I am not all that sure about)=2C = then it they would only
>=3B delay release of this extension=2C wouldn= 't they?

[BA] Even if scenario B is optional=2C we will still need t= o do the work to analyze the security implications
and integrate it with= in the overall architecture. =3B =3B Unless all work on scenario B = were to be separated
out into a separate series of work items with no im= pact on existing ones (which I believe would require
a charter change)= =2C adding scenario B would potentially affect other more basic deliverable= s.

= --_e8d63647-3105-4bc1-8597-0dbe8917627d_-- From emil@sip-communicator.org Wed Sep 21 12:12: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 183B311E811B for ; Wed, 21 Sep 2011 12:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 KinuiSQlbbkh for ; Wed, 21 Sep 2011 12:12:19 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id DDFCD11E810B for ; Wed, 21 Sep 2011 12:12:18 -0700 (PDT) Received: by wyg24 with SMTP id 24so2388190wyg.31 for ; Wed, 21 Sep 2011 12:14:47 -0700 (PDT) Received: by 10.227.4.75 with SMTP id 11mr203483wbq.80.1316632487669; Wed, 21 Sep 2011 12:14:47 -0700 (PDT) Received: from camionet.local (shm67-5-88-165-90-188.fbx.proxad.net. [88.165.90.188]) by mx.google.com with ESMTPS id fa7sm8034613wbb.26.2011.09.21.12.14.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Sep 2011 12:14:46 -0700 (PDT) Message-ID: <4E7A37A6.8020701@jitsi.org> Date: Wed, 21 Sep 2011 21:14:46 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; bg; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: Bernard Aboba References: <4E76E8E8.2050102@ericsson.com> <4E788E00.9020909@ericsson.com>, <4E78A467.7040409@jitsi.org>, <4E7994D7.60102@ericsson.com> , <4E7A31BE.4050500@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Call for Consensus on Use Case for Screen/Application/Desktop sharing X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 19:12:20 -0000 =D0=9D=D0=B0 21.09.11 21:01, Bernard Aboba =D0=BD=D0=B0=D0=BF=D0=B8=D1=81= =D0=B0: >> Why would the schedule slip? If this is an optional extension, as >> everyone agrees it should be, how could it delay the main specs and >> implementations? Even if there are indeed some unforeseen grave securi= ty >> issues (which I am not all that sure about), then it they would only >> delay release of this extension, wouldn't they? >=20 > [BA] Even if scenario B is optional, we will still need to do the work > to analyze the security implications > and integrate it within the overall architecture. Unless all work on > scenario B were to be separated > out into a separate series of work items with no impact on existing one= s > (which I believe would require > a charter change), adding scenario B would potentially affect other mor= e > basic deliverables. Mmmm ... I am still not sure I am seeing it. I am probably missing something though, so would you mind being a bit more specific? What security issues do we expect that would be completely different from what already needs to be handled with audio and video acquisition? Emil --=20 http://jitsi.org From HKaplan@acmepacket.com Wed Sep 21 12:28: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 2FA211F0C3E for ; Wed, 21 Sep 2011 12:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 NpIip0ZOyrlM for ; Wed, 21 Sep 2011 12:28:06 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8A11621F86A1 for ; Wed, 21 Sep 2011 12:28:06 -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; Wed, 21 Sep 2011 15:30:35 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 21 Sep 2011 15:30:34 -0400 From: Hadriel Kaplan To: Magnus Westerlund Thread-Topic: [rtcweb] STUN for keep-alive - RTCP-less applications Thread-Index: AQHMeJTub4qgCfdVkkmpwdeGsRq+9g== Date: Wed, 21 Sep 2011 19:30:34 +0000 Message-ID: <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> In-Reply-To: <4E79D5DF.4050402@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: "" Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 19:28:07 -0000 On Sep 21, 2011, at 8:17 AM, Magnus Westerlund wrote: > On 2011-09-21 11:02, Hadriel Kaplan wrote: >>=20 >> On Sep 21, 2011, at 4:19 AM, Magnus Westerlund wrote: >>=20 >>> If I interpret this correctly, you are arguing that an RTCWEB=20 >>> implementation shall support a remote end-point that doesn't >>> support RTCP. >>=20 >> Yes, although we could make that allowance/exception for audio only - >> in fact, G.711 only if it comes down to it. >=20 > Well, I don't know if we can argue that one past the Transport Area > Director? Hmmm=85 how about by pointing out this is RTP over UDP and not TCP, and tha= t we're following RFC 3550, which does not mandate reception of RTCP to con= tinue the session? I would think a Transport Area AD would know how UDP wo= rks. ;) > I know I can argue 400 bps as an acceptable non congestion > controlled rate. And that is because that is the equivalent of a full > backed off TCP connection that sends one full Ethernet frame every 30 > seconds. We probably can argue 4kbps also as an acceptable rate. But > getting to the next magnitude is more problematic, especially in the > light that there still exist a reasonable large number of access links > around the world that don't have more than a few 10kbps in capacity. Then the call quality will suck and the user will hang up. BTW, are you suggesting that even with G.711, that rtcweb do some form of c= ongestion control based on the RTCP packets? At that point we're not even = talking about RTP/AVP for PCMU/PCMA then are we? This is some new profile,= not AVP. -hadriel From csp@csperkins.org Wed Sep 21 13:31: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 8FBE721F8BBD for ; Wed, 21 Sep 2011 13:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.552 X-Spam-Level: X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 eC60BWLPdgvl for ; Wed, 21 Sep 2011 13:31:53 -0700 (PDT) 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 B021521F8BBC for ; Wed, 21 Sep 2011 13:31:53 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R6TUs-0006MN-jw; Wed, 21 Sep 2011 20:34:22 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Colin Perkins In-Reply-To: <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> Date: Wed, 21 Sep 2011 21:34:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79 D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: "" Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 20:31:54 -0000 On 21 Sep 2011, at 20:30, Hadriel Kaplan wrote: > On Sep 21, 2011, at 8:17 AM, Magnus Westerlund wrote: >> On 2011-09-21 11:02, Hadriel Kaplan wrote: >>> On Sep 21, 2011, at 4:19 AM, Magnus Westerlund wrote: >>>> If I interpret this correctly, you are arguing that an RTCWEB=20 >>>> implementation shall support a remote end-point that doesn't >>>> support RTCP. >>>=20 >>> Yes, although we could make that allowance/exception for audio only = - in fact, G.711 only if it comes down to it. >>=20 >> Well, I don't know if we can argue that one past the Transport Area >> Director? >=20 > Hmmm=85 how about by pointing out this is RTP over UDP and not TCP, = and that we're following RFC 3550, which does not mandate reception of = RTCP to continue the session? I would think a Transport Area AD would = know how UDP works. ;) >=20 >=20 >> I know I can argue 400 bps as an acceptable non congestion >> controlled rate. And that is because that is the equivalent of a full >> backed off TCP connection that sends one full Ethernet frame every 30 >> seconds. We probably can argue 4kbps also as an acceptable rate. But >> getting to the next magnitude is more problematic, especially in the >> light that there still exist a reasonable large number of access = links >> around the world that don't have more than a few 10kbps in capacity. >=20 > Then the call quality will suck and the user will hang up. >=20 > BTW, are you suggesting that even with G.711, that rtcweb do some form = of congestion control based on the RTCP packets? At that point we're = not even talking about RTP/AVP for PCMU/PCMA then are we? This is some = new profile, not AVP. Well, the AVP spec [RFC3551, page 5] does say: If best-effort service is being used, RTP receivers SHOULD monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Packet loss is considered acceptable if a TCP flow across the same network path and experiencing the same network conditions would achieve an average throughput, measured on a reasonable timescale, that is not less than the RTP flow is achieving. This condition can be satisfied by implementing congestion control mechanisms to adapt the transmission rate (or the number of layers subscribed for a layered multicast session), or by arranging for a receiver to leave the session if the loss rate is unacceptably high. The comparison to TCP cannot be specified exactly, but is intended as an "order-of-magnitude" comparison in timescale and throughput. The timescale on which TCP throughput is measured is the round- trip time of the connection. In essence, this requirement states that it is not acceptable to deploy an application (using RTP or any other transport protocol) on the best-effort Internet which consumes bandwidth arbitrarily and does not compete fairly with TCP within an order of magnitude. --=20 Colin Perkins http://csperkins.org/ From HKaplan@acmepacket.com Wed Sep 21 14:17: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 5740111E8159 for ; Wed, 21 Sep 2011 14:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 dhq8BQIdSWvI for ; Wed, 21 Sep 2011 14:17:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 784AA11E80AA for ; Wed, 21 Sep 2011 14:17:26 -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; Wed, 21 Sep 2011 17:19:55 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 21 Sep 2011 17:19:54 -0400 From: Hadriel Kaplan To: Colin Perkins Thread-Topic: [rtcweb] STUN for keep-alive - RTCP-less applications Thread-Index: AQHMeKQ0revNZCpKZk2vREKrpukpxg== Date: Wed, 21 Sep 2011 21:19:54 +0000 Message-ID: <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> In-Reply-To: <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> 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: <2D9CE48B683F3C4AB37CF3715E2CB2AA@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 21:17:27 -0000 We still don't need RTCP for that - use received RTP sequence number gaps, = if necessary. (yeah it assumes symmetric path and bandwidth, and bi-dir med= ia) But anyway, there is no means of "dialing-down" G.711. It's not adaptive. = Or are we saying the sender should start skipping samples and hope the rec= eiver does PLC? Really, the user will hang up if call quality sucks. We don't need to be s= marter than humans. -hadriel On Sep 21, 2011, at 4:34 PM, Colin Perkins wrote: > On 21 Sep 2011, at 20:30, Hadriel Kaplan wrote: >>=20 >> BTW, are you suggesting that even with G.711, that rtcweb do some form o= f congestion control based on the RTCP packets? At that point we're not ev= en talking about RTP/AVP for PCMU/PCMA then are we? This is some new profi= le, not AVP. >=20 >=20 > Well, the AVP spec [RFC3551, page 5] does say: >=20 > If best-effort service is being used, RTP receivers SHOULD monitor > packet loss to ensure that the packet loss rate is within > acceptable parameters. Packet loss is considered acceptable if a > TCP flow across the same network path and experiencing the same > network conditions would achieve an average throughput, measured > on a reasonable timescale, that is not less than the RTP flow is > achieving. This condition can be satisfied by implementing > congestion control mechanisms to adapt the transmission rate (or > the number of layers subscribed for a layered multicast session), > or by arranging for a receiver to leave the session if the loss > rate is unacceptably high. >=20 > The comparison to TCP cannot be specified exactly, but is intended > as an "order-of-magnitude" comparison in timescale and throughput. > The timescale on which TCP throughput is measured is the round- > trip time of the connection. In essence, this requirement states > that it is not acceptable to deploy an application (using RTP or > any other transport protocol) on the best-effort Internet which > consumes bandwidth arbitrarily and does not compete fairly with > TCP within an order of magnitude. >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 From ibc@aliax.net Wed Sep 21 14:20: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 9BC7111E80BA for ; Wed, 21 Sep 2011 14:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 sEtoK02pcOhh for ; Wed, 21 Sep 2011 14:20:10 -0700 (PDT) Received: from mail-vw0-f42.google.com (mail-vw0-f42.google.com [209.85.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 027EE11E80AA for ; Wed, 21 Sep 2011 14:20:09 -0700 (PDT) Received: by vwl1 with SMTP id 1so2997855vwl.15 for ; Wed, 21 Sep 2011 14:22:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.175.229 with SMTP id cd5mr1137884vdc.363.1316640158939; Wed, 21 Sep 2011 14:22:38 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Wed, 21 Sep 2011 14:22:38 -0700 (PDT) In-Reply-To: <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> Date: Wed, 21 Sep 2011 23:22:38 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" , Colin Perkins Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 21:20:11 -0000 2011/9/21 Hadriel Kaplan : > We don't need to be smarter than humans. I expected we are all humans XD --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Wed Sep 21 14:32: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 4F1531F0C95 for ; Wed, 21 Sep 2011 14:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=-0.076, 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 N9RYzsjJimju for ; Wed, 21 Sep 2011 14:32:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B77831F0C94 for ; Wed, 21 Sep 2011 14:32: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; Wed, 21 Sep 2011 17:35:15 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 21 Sep 2011 17:35:15 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [rtcweb] STUN for keep-alive - RTCP-less applications Thread-Index: AQHMeKZZDjZ3r0NXq06eQd2WHucenA== Date: Wed, 21 Sep 2011 21:35:14 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@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: <6CF260FAC3546C4E908A41A9DAD3D266@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" , Colin Perkins Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 21:32:47 -0000 Oh I dunno... I suspect some members on this list are Eliza programs, becau= se I can predict their responses. ;) On Sep 21, 2011, at 5:22 PM, I=F1aki Baz Castillo wrote: > 2011/9/21 Hadriel Kaplan : >> We don't need to be smarter than humans. >=20 > I expected we are all humans XD >=20 > --=20 > I=F1aki Baz Castillo > From csp@csperkins.org Wed Sep 21 14:33: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 A069711E8106 for ; Wed, 21 Sep 2011 14:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.554 X-Spam-Level: X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 jUwPxEvIvHpb for ; Wed, 21 Sep 2011 14:33:48 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id BCA9511E80FB for ; Wed, 21 Sep 2011 14:33:48 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R6USk-00055t-n0; Wed, 21 Sep 2011 21:36:14 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> Date: Wed, 21 Sep 2011 22:36:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <77ADCDD1-E397-4FF6-B572-BA23167CEF9A@csperkins.org> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79 D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: "" Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 21 Sep 2011 21:33:49 -0000 No, as it says, you stop sending if you can't adjust and the loss rate = is too high. And, sure, the user will probably hang-up anyway if the = quality is bad, but it's worthwhile having a sanity check to drop the = call if they don't, whether implemented based on RTCP reports or = otherwise. Colin On 21 Sep 2011, at 22:19, Hadriel Kaplan wrote: > We still don't need RTCP for that - use received RTP sequence number = gaps, if necessary. (yeah it assumes symmetric path and bandwidth, and = bi-dir media) >=20 > But anyway, there is no means of "dialing-down" G.711. It's not = adaptive. Or are we saying the sender should start skipping samples and = hope the receiver does PLC? >=20 > Really, the user will hang up if call quality sucks. We don't need to = be smarter than humans. >=20 > -hadriel >=20 >=20 > On Sep 21, 2011, at 4:34 PM, Colin Perkins wrote: >=20 >> On 21 Sep 2011, at 20:30, Hadriel Kaplan wrote: >>>=20 >>> BTW, are you suggesting that even with G.711, that rtcweb do some = form of congestion control based on the RTCP packets? At that point = we're not even talking about RTP/AVP for PCMU/PCMA then are we? This is = some new profile, not AVP. >>=20 >>=20 >> Well, the AVP spec [RFC3551, page 5] does say: >>=20 >> If best-effort service is being used, RTP receivers SHOULD = monitor >> packet loss to ensure that the packet loss rate is within >> acceptable parameters. Packet loss is considered acceptable if a >> TCP flow across the same network path and experiencing the same >> network conditions would achieve an average throughput, measured >> on a reasonable timescale, that is not less than the RTP flow is >> achieving. This condition can be satisfied by implementing >> congestion control mechanisms to adapt the transmission rate (or >> the number of layers subscribed for a layered multicast session), >> or by arranging for a receiver to leave the session if the loss >> rate is unacceptably high. >>=20 >> The comparison to TCP cannot be specified exactly, but is = intended >> as an "order-of-magnitude" comparison in timescale and = throughput. >> The timescale on which TCP throughput is measured is the round- >> trip time of the connection. In essence, this requirement states >> that it is not acceptable to deploy an application (using RTP or >> any other transport protocol) on the best-effort Internet which >> consumes bandwidth arbitrarily and does not compete fairly with >> TCP within an order of magnitude. >>=20 >>=20 >> --=20 >> Colin Perkins >> http://csperkins.org/ From magnus.westerlund@ericsson.com Thu Sep 22 00:45: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 5624221F8D64 for ; Thu, 22 Sep 2011 00:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 aeXE3Z9vD7yX for ; Thu, 22 Sep 2011 00:45:56 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5962721F8D60 for ; Thu, 22 Sep 2011 00:45:56 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-86-4e7ae84a3451 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.115.81]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 34.99.02839.A48EA7E4; Thu, 22 Sep 2011 09:48:26 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 09:48:20 +0200 Message-ID: <4E7AE83E.9090508@ericsson.com> Date: Thu, 22 Sep 2011 09:48:14 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> In-Reply-To: <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "" , Colin Perkins Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 07:45:57 -0000 On 2011-09-21 23:19, Hadriel Kaplan wrote: > > We still don't need RTCP for that - use received RTP sequence number > gaps, if necessary. (yeah it assumes symmetric path and bandwidth, > and bi-dir media) That doesn't really work without RTCP. You are assuming that path load is symmetric so that any loss in A-B direction will be correspondingly reflected on the flow in B-A direction. That is certainly not a common property for IP paths. Thus without RTCP the sender has no knowledge about what packet loss rate his flow is seeing. > > But anyway, there is no means of "dialing-down" G.711. It's not > adaptive. Or are we saying the sender should start skipping samples > and hope the receiver does PLC? Well, switch to a lower bandwidth codec. > > Really, the user will hang up if call quality sucks. We don't need > to be smarter than humans. Well, the complications with G.711 is that there can be quite significant loss before you don't understand anything. But, if I interpret http://www.rfc-editor.org/rfc/rfc3714.txt correctly for reasonably long paths we will in fact talk about such high packet loss rates the call will be use less. However, that is still not the only issue here. I agree that as long as there is a human in the other end listening to the flow that is fine. But if you don't have a human listening the premise of RTCWEB is that you will be able to establish data flows across a path that is in fact not connected to the rendering element in the other end. Thus no user will detect the high packet loss and turn of the flow. It will continue and be a DoS attack on the congested link because this flow takes significantly more than its fair share. That is my issue. We are coming back to the most difficult trade-offs for RTCWEB. Legacy interoperability vs Security. We have several different aspects which makes legacy interoperability with a too simple device a big security risk. Media transmission consent -> Requiring ICE support Path Overload DoS concerns -> Requiring Congestion Control for both media and data. RTCWEB deployment model and concerns for privacy and confenditality -> Media security (what level is still not agreed on) All of the above are clear barriers against legacy interoperability. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From randell-ietf@jesup.org Thu Sep 22 00:54: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 900C021F8D01 for ; Thu, 22 Sep 2011 00:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 slsMsEdfphOg for ; Thu, 22 Sep 2011 00:54:22 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id BF02B21F8CFB for ; Thu, 22 Sep 2011 00:54:22 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R6e9N-0001AB-CK for rtcweb@ietf.org; Thu, 22 Sep 2011 02:56:53 -0500 Message-ID: <4E7AE975.1010105@jesup.org> Date: Thu, 22 Sep 2011 03:53:25 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> <4E77949B.4010603@alvestrand.no> <4E78A4FB.1050504@ericsson.com> <4E79AC33.4000900@alvestrand.no> <0075AB47-3DFF-4000-9057-CA0628DF711A@csperkins.org> <05D1C2F6-96C3-44E3-9FC2-AD2C893C9FC6@acmepacket.com> In-Reply-To: <05D1C2F6-96C3-44E3-9FC2-AD2C893C9FC6@acmepacket.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] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 07:54:23 -0000 On 9/21/2011 7:45 AM, Hadriel Kaplan wrote: > Just to make sure I'm on the same wavelength, you're talking about: > 1) Defining PseudoTCP over UDP (a la libnice and jingle) for stream-oriented reliable data delivery. I would also consider SCTP-over-UDP in place of PseudoTCP-over-UDP for reliable data delivery. Similar arguments apply as for DCCP (solid specification), and in addition the FreeBSD implementation apparently supports SCTP-over-UDP and is very portable, so good working code is available to start. SCTP also has other benefits, like optional out-of-order delivery, and a datagram ('message') orientation. > 2) Defining DDCP over UDP for message-oriented unreliable data delivery. > 3) Requiring the browser to implement and only expose those two options for the "data" stream type and not raw UDP, so that we can enforce congestion control of the data channel. (oh, and the option for it to be PseudoTCP/DTLS/UDP or DCCP/DTLS/UDP) This is certainly an option. I'll note it means we'll run congestion control on the data channels separately from media and from other data channels - this is similar to how opening multiple TCP connections works. I was hoping I could find a way to include all the data channels in a single congestion-control framework with the media channels, which would allow the application optional control over the allocation of bits between media and data. (I.e. a long-running file transfer could starve the media channels eventually in bufferbloat situations.) For DCCP (since it allows replacing the congestion-control algorithm) we may still be able to meet my hopes for unreliable data; but reliable data is still a bit out in the cold. Randell > Correct? > > -hadriel > > > On Sep 21, 2011, at 6:47 AM, Colin Perkins wrote: > >> On 21 Sep 2011, at 10:19, Harald Alvestrand wrote: >>> On 09/20/2011 04:36 PM, Magnus Westerlund wrote: >>>> On 2011-09-19 21:14, Harald Alvestrand wrote: >>>>> On 09/19/2011 06:00 PM, Magnus Westerlund wrote: >>>>>> We need to standardize a number of Transport protocol functionalities for the RTCWEB data transport solution. To the degree that I do like to resurface some of my earlier suggestions around this. Why not use DCCP with TFRC or TCP like congestion control tunneled over UDP. >>>>>> >>>>>> The whole specification is ready. Which avoids any hiccup with the transport people and IESG. >>>>> The last few times this has surfaced, the conversation has turned suddenly silent when I've asked where to find a DCCP-over-TFRC stack I can experiment with.... are there any out there that are "production ready"? >>>> To my knowledge there is a DCCP stack in Linux. Exactly it status is unknown to me and which of the CC it supports. There has been also additional projects for implementations. >>> I checked out the Linux stack, and concluded that it was: >>> a) not supporting DCCP over UDP >>> b) not possible to extract it and embed it in a browser >>> The only project I could find for userspace DCCP was untouched for at least 3 years, and did not compile. >> Agreed. The Linux DCCP code seems reasonably mature, but doesn't support the UDP encapsulation. The user-space DCCP-TP code is not in a good state to build upon. >> >>>> I would note that no implementation exist of DTLS with a CC algorithm and additional mechanism. Thus that would be a from scratch implementation effort without any input what has been done so far. >>>> >>>> And if we can in fact decide early on something fully specified you have a lot of time to implement this before the rest are standards ready. >>> My worry is that without the ability to experiment, I have no way of verifying that the protocol satisfies the properties we are attributing to it. >> This is a little pessimistic. The Linux DCCP code can certainly be used for lab-based experiments, and these can be made to give a reasonable idea of the performance of DCCP with the existing CCIDs. Not perfect, sure, but should be good enough to show whether the basic idea is worth exploring further. >> >> The main reason to consider DCCP-over-UDP isn't running code though, it's the solid specification. I'd argue that it will be easier to start with the DCCP spec, profile it down to what's needed by this group, plug in a new congestion control algorithm (CCID), and implement the result, than it would be to start both the specification and implementation efforts from scratch. As a congestion-controlled, connection-oriented, unreliable datagram service, there's not a lot in DCCP that we wouldn't want for RTCWeb (and those bits we might want to modify, such as the congestion control algorithm, are things where DCCP supports extensions). >> >>> Also, we *know* we'll be shipping products well ahead of the standards' final approval, with appropriate warnings that things *will* change between product versions. We don't have "a lot of time". >>>>> The pseudoTCP stacks in libjingle have seen service for a long time.... >>>>> >>>> Well, that is addressing another set of requirements namely the reliable data transport. Lets not confuse the two sets. We appear to have interest in both unreliable and reliable data transport. >>> Yup, I pulled that in as an example of "code maturity". >>> >>>> Regarding pseudoTCP we still need a specification for it. I think for example the psuedo header used in the checksum needs specification in TCP over UDP. It might not be a big spec, but someone needs to write it and find a home for it. I would note that we are somewhat limited in this WG to actually do protocol work. >>> It will have to seek approval elsewhere, if needed. >>> >>> -- Randell Jesup randell-ietf@jesup.org From internet-drafts@ietf.org Thu Sep 22 00:54: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 D148221F8D12; Thu, 22 Sep 2011 00:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 X5bRbzXMxDmY; Thu, 22 Sep 2011 00:54:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC7C21F8CFB; Thu, 22 Sep 2011 00:54:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110922075433.17483.59128.idtracker@ietfa.amsl.com> Date: Thu, 22 Sep 2011 00:54:33 -0700 Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-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: Thu, 22 Sep 2011 07:54:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browse= rs Working Group of the IETF. Title : Security Considerations for RTC-Web Author(s) : Eric Rescorla Filename : draft-ietf-rtcweb-security-00.txt Pages : 20 Date : 2011-09-21 The Real-Time Communications on the Web (RTC-Web) working group is tasked with standardizing protocols for real-time communications between Web browsers. The major use cases for RTC-Web technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP- based soft phones) RTC-Web communications are directly controlled by some Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, = capturing any activity which passed in front of their camera. This document defines the RTC-Web threat model and defines an architecture which provides security within that threat model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-rtcweb-security-00.txt From HKaplan@acmepacket.com Thu Sep 22 03:58: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 9BC5021F8C76 for ; Thu, 22 Sep 2011 03:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 bSGxSQ5SLTJX for ; Thu, 22 Sep 2011 03:58:04 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8378321F8C6B for ; Thu, 22 Sep 2011 03:58:04 -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, 22 Sep 2011 07:00:34 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 22 Sep 2011 07:00:34 -0400 From: Hadriel Kaplan To: Magnus Westerlund Thread-Topic: [rtcweb] STUN for keep-alive - RTCP-less applications Thread-Index: AQHMeRbZIKUT9mUbYkyr0iQzRJ1k0w== Date: Thu, 22 Sep 2011 11:00:32 +0000 Message-ID: <0C42CC63-CA1A-4F64-B522-BC1DAB477471@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> In-Reply-To: <4E7AE83E.9090508@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: "" , Colin Perkins Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 10:58:05 -0000 On Sep 22, 2011, at 3:48 AM, Magnus Westerlund wrote: > On 2011-09-21 23:19, Hadriel Kaplan wrote: >>=20 >> We still don't need RTCP for that - use received RTP sequence number >> gaps, if necessary. (yeah it assumes symmetric path and bandwidth, >> and bi-dir media) >=20 > That doesn't really work without RTCP. You are assuming that path load > is symmetric so that any loss in A-B direction will be correspondingly > reflected on the flow in B-A direction. That is certainly not a common > property for IP paths. Thus without RTCP the sender has no knowledge > about what packet loss rate his flow is seeing. That would be the part where I said "(yeah it assumes symmetric path and ba= ndwidth, and bi-dir media)". :) >> But anyway, there is no means of "dialing-down" G.711. It's not >> adaptive. Or are we saying the sender should start skipping samples >> and hope the receiver does PLC? >=20 > Well, switch to a lower bandwidth codec. That's not really possible in the PSTN. :( One could drop it to AMR or G.729 in some cases, but those are under royalt= y so I doubt an rtcweb browser will do them. >> Really, the user will hang up if call quality sucks. We don't need >> to be smarter than humans. >=20 > However, that is still not the only issue here. I agree that as long as > there is a human in the other end listening to the flow that is fine. >=20 > But if you don't have a human listening the premise of RTCWEB is that > you will be able to establish data flows across a path that is in fact > not connected to the rendering element in the other end. Thus no user > will detect the high packet loss and turn of the flow. It will continue > and be a DoS attack on the congested link because this flow takes > significantly more than its fair share. >=20 > That is my issue. Right, but as I said previously, if the concern is a malicious server/JS, i= t can do it anyway even with congestion control. If the concern is just that the far-end is dead or terminated the call but = the local side didn't get the memo, we can solve that other ways. > We are coming back to the most difficult trade-offs for RTCWEB. Legacy > interoperability vs Security. We have several different aspects which > makes legacy interoperability with a too simple device a big security ris= k. >=20 > Media transmission consent -> Requiring ICE support > Path Overload DoS concerns -> Requiring Congestion Control for both > media and data. > RTCWEB deployment model and concerns for privacy and confenditality -> > Media security (what level is still not agreed on) >=20 > All of the above are clear barriers against legacy interoperability. Yup. I don't doubt we'll need some form of media-plane gateway either in t= he web server or separate to interop with legacy - I'm just trying to keep = it from becoming so expensive and complicated that it would be cheaper/easi= er/better to use SIP softclients or plugins instead. -hadriel From ibc@aliax.net Thu Sep 22 04:02: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 5E0D321F8C42 for ; Thu, 22 Sep 2011 04:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 hvm97VoL6CS3 for ; Thu, 22 Sep 2011 04:02:36 -0700 (PDT) Received: from mail-vw0-f42.google.com (mail-vw0-f42.google.com [209.85.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id A69F921F8C31 for ; Thu, 22 Sep 2011 04:02:36 -0700 (PDT) Received: by vwl1 with SMTP id 1so3460162vwl.15 for ; Thu, 22 Sep 2011 04:05:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.29.75 with SMTP id i11mr1692791vdh.296.1316689262459; Thu, 22 Sep 2011 04:01:02 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Thu, 22 Sep 2011 04:01:02 -0700 (PDT) In-Reply-To: <4E7AE83E.9090508@ericsson.com> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> Date: Thu, 22 Sep 2011 13:01:02 +0200 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: "" , Colin Perkins Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 11:02:37 -0000 2011/9/22 Magnus Westerlund : > All of the above are clear barriers against legacy interoperability. Hi Magnus, what do you exacly mean with "legacy interoperability"? If you mean interoperability with SIP or XMPP I don't think that is "legacy" as both protocols define extended features for the media plane (including security concerns). It's true that some very-basic SIP deployments and devices just use RTP without ICE, media security and so, but that's not a written rule. Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Thu Sep 22 04:05: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 EA5C221F8CF9 for ; Thu, 22 Sep 2011 04:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 C2NzVHUjShmk for ; Thu, 22 Sep 2011 04:05:51 -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 5AC3E21F8CE0 for ; Thu, 22 Sep 2011 04:05:51 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so463621vcb.31 for ; Thu, 22 Sep 2011 04:08:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.180.6 with SMTP id bs6mr484764vcb.122.1316689701851; Thu, 22 Sep 2011 04:08:21 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Thu, 22 Sep 2011 04:08:21 -0700 (PDT) In-Reply-To: <0C42CC63-CA1A-4F64-B522-BC1DAB477471@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> <0C42CC63-CA1A-4F64-B522-BC1DAB477471@acmepacket.com> Date: Thu, 22 Sep 2011 13:08:21 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" , Colin Perkins Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 11:05:52 -0000 2011/9/22 Hadriel Kaplan : >> All of the above are clear barriers against legacy interoperability. > > Yup. =C2=A0I don't doubt we'll need some form of media-plane gateway eith= er in the web server or separate to interop with legacy - I'm just trying t= o keep it from becoming so expensive and complicated that it would be cheap= er/easier/better to use SIP softclients or plugins instead. I can understand that some requirements can be imposed to RTCweb environments in the media plane, but try at least to make it compatible with VoIP networks out there. For example, requiring SRTP o ZRTP could make sense (anyhow I don't see why that should be a requirement in a local intranet in which plain-RTP is already used for SIP communication). If WebRTC forces the creation of media gateways when intercommunicating with other RTP worlds (SIP, XMPP) that's not good at all. Adding requirements it's ok, making it impossible by design is not. Regards. --=20 I=C3=B1aki Baz Castillo From mperumal@cisco.com Thu Sep 22 05:17: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 5298C21F8770 for ; Thu, 22 Sep 2011 05:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.488 X-Spam-Level: X-Spam-Status: No, score=-10.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93UDqiskM5nu for ; Thu, 22 Sep 2011 05:17:12 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BC4D221F8783 for ; Thu, 22 Sep 2011 05:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=4169; q=dns/txt; s=iport; t=1316693983; x=1317903583; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=eB8KdeVhTj917A78g/UA6pVEyS8RFcBxMXOooAG6H4E=; b=iVCB9lIciMglibdLy4ktOxy0DaArnoKJYZr0GTGQiwljdtYtWg675YN8 mwlb0wxOAHtGVwI7ENGkvwiMiDDfgltBxpcgLfVf1G2thLHiRJJd0zgxi tVMGyLNJMTS3zImCT4HJHFF8Sfshj1CE+2cRBNJqYhoYqwvLoQlCAG3+Y o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswAANwme05Io8UQ/2dsb2JhbABCmQmOd3iBUwEBAQEDDAYBHUkMAgICAQgRBAEBCwYJAgwBBgEaKwkIAQEECwgIGp4yAZ43AoN7B4IZYASHQS6RCYwP X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="55694708" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 22 Sep 2011 12:19:17 +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 p8MCJ1SA021240; Thu, 22 Sep 2011 12:19:17 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, 22 Sep 2011 17:49:14 +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, 22 Sep 2011 17:49:11 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020672C04A@XMB-BGL-414.cisco.com> In-Reply-To: <4E784C38.2010909@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] consent freshness [was RE: STUN for keep-alive] Thread-Index: Acx3bd9fEcquWi4ZQ0+xMYLnTrDIXgAAvfFA References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se><4E70D2E6.1000809@alvestrand.no><7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se><092401cc749b$8fd64940$af82dbc0$@com><4E765E4A.3050801@alvestrand.no><0ced01cc76de$28731630$79594290$@com> <4E77613B.4020805@ericsson.com> <1D062974A4845E4D8A343C6538049202066497EF@XMB-BGL-414.cisco.com> <4E784C38.2010909@ericsson.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Magnus Westerlund" X-OriginalArrivalTime: 22 Sep 2011 12:19:14.0278 (UTC) FILETIME=[D7787860:01CC7921] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 12:17:13 -0000 |That is a possibility, but I think one can start by ensuring=20 |that one actually check for ones own traffic being reported=20 |back. That gives you some entropy. Which is a slightly longer=20 |context gives you good verification that you are not contining |sending into a location where there receiver you intended to |have sent to moves away. Agree it would suffice in general. However, for cases like double hold = (SDP offer with a=3Dinactive) where you would be neither sending nor = receiving media the attacker can keep replaying the RTCP packets with an = empty report block (that no zero entropy) making you think the other end = is still alive. Of course, you may ultimately disconnect the call but it could mean a = DOS attack..=20 Muthu |-----Original Message----- |From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] |Sent: Tuesday, September 20, 2011 1:48 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: Dan Wing (dwing); rtcweb@ietf.org |Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive] | |On 2011-09-19 18:41, Muthu Arul Mozhi Perumal (mperumal) wrote: |> Another aspect to consider: As per RFC 3550, the bare minimal valid |> RTCP packet is a compound RTCP packet containing: - An RR packet with |> the reception report count set to 0 (RC=3D0) and - An SDES packet = with |> CNAME |> |> Such a packet would look like this: |> |> 0 1 2 3 0 1 2 3 |> 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 |> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |> header |V=3D2|P| RC=3D0 | PT=3DRR=3D201 | length |> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |> SSRC of packet sender | |> = +=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+ |> header |V=3D2|P| SC=3D1 | PT=3DSDES=3D202 | length |> | = +=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+ |> chunk | SSRC of packet sender |> | 1 |> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |> CNAME=3D1 | length |user & domain padded to 32-bit | |> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |> |> I've seen endpoints sending/accepting such a packet as an indication |> for session liveliness. However, there is no entropy at all in this |> packet. Suppose an attacker manages to bring the receiver down and |> captures such a RTCP packet. The attacker can keep replaying it (from |> the spoofed source transport address) to make the sender believe that |> the receiver is still alive and muted. | |well, the reasonable assumption if you are using this for consent |freshness is to verify that your flow is reported on in a reasonable |way. That do provide some entropy in sequence number and Last SR field |in the report block as I wrote in my other email. | |> |> Perhaps, RTCWeb apps should try to negotiate an RTCP extension |> carrying a monotonically increasing number that must be part of every |> RTCP report together with SRTCP, for replay attack protection. | |That is a possibility, but I think one can start by ensuring that one |actually check for ones own traffic being reported back. That gives you |some entropy. Which is a slightly longer context gives you good |verification that you are not contining sending into a location where |there receiver you intended to have sent to moves away. | |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 |---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Sep 22 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 97E8921F8CDD for ; Thu, 22 Sep 2011 05:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.374 X-Spam-Level: X-Spam-Status: No, score=-106.374 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 2z4xbM9xz-jQ for ; Thu, 22 Sep 2011 05:19:44 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A6B0921F8CDC for ; Thu, 22 Sep 2011 05:19:43 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-97-4e7b287647b3 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 41.1A.20773.6782B7E4; Thu, 22 Sep 2011 14:22:14 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 14:22:13 +0200 Message-ID: <4E7B286E.80900@ericsson.com> Date: Thu, 22 Sep 2011 14:22:06 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "" , Colin Perkins Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 12:19:44 -0000 On 2011-09-22 13:01, Iñaki Baz Castillo wrote: > 2011/9/22 Magnus Westerlund : >> All of the above are clear barriers against legacy interoperability. > > Hi Magnus, what do you exacly mean with "legacy interoperability"? All cases when the involved nodes aren't all implemented against the RTCWEB specification. > > If you mean interoperability with SIP or XMPP I don't think that is > "legacy" as both protocols define extended features for the media > plane (including security concerns). It's true that some very-basic > SIP deployments and devices just use RTP without ICE, media security > and so, but that's not a written rule. I would say both SIP and XMPP based applications are legacy from an RTCWEB perspective. 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 Sep 22 05:28: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 D2D0521F8C45 for ; Thu, 22 Sep 2011 05:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 XHR2kHNX-uYj for ; Thu, 22 Sep 2011 05:28:06 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id BD31A21F8C1E for ; Thu, 22 Sep 2011 05:28:05 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-77-4e7b2a6cfafd Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 83.A1.02839.C6A2B7E4; Thu, 22 Sep 2011 14:30:36 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 14:30:35 +0200 Message-ID: <4E7B2A65.6090106@ericsson.com> Date: Thu, 22 Sep 2011 14:30:29 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> <0C42CC63-CA1A-4F64-B522-BC1DAB477471@acmepacket.com> In-Reply-To: <0C42CC63-CA1A-4F64-B522-BC1DAB477471@acmepacket.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "" , Colin Perkins Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 12:28:06 -0000 On 2011-09-22 13:00, Hadriel Kaplan wrote: > > On Sep 22, 2011, at 3:48 AM, Magnus Westerlund wrote: > >> On 2011-09-21 23:19, Hadriel Kaplan wrote: >>> But anyway, there is no means of "dialing-down" G.711. It's not >>> adaptive. Or are we saying the sender should start skipping >>> samples and hope the receiver does PLC? >> >> Well, switch to a lower bandwidth codec. > > That's not really possible in the PSTN. :( One could drop it to AMR > or G.729 in some cases, but those are under royalty so I doubt an > rtcweb browser will do them. Yes, I agree that there will be cases where one doesn't have a choice between hanging up. But, I think that must be part of the map. > > >>> Really, the user will hang up if call quality sucks. We don't >>> need to be smarter than humans. >> >> However, that is still not the only issue here. I agree that as >> long as there is a human in the other end listening to the flow >> that is fine. >> >> But if you don't have a human listening the premise of RTCWEB is >> that you will be able to establish data flows across a path that is >> in fact not connected to the rendering element in the other end. >> Thus no user will detect the high packet loss and turn of the flow. >> It will continue and be a DoS attack on the congested link because >> this flow takes significantly more than its fair share. >> >> That is my issue. > > Right, but as I said previously, if the concern is a malicious > server/JS, it can do it anyway even with congestion control. If the > concern is just that the far-end is dead or terminated the call but > the local side didn't get the memo, we can solve that other ways. For the first part, I think we will need some protection against this case, especially opening high bandwidth flows. Having a startup rate of 64 kbps is likely working in so many network that it isn't unreasonable. And when it comes to open new PeerConnections, one protection from the browser side is to have a memory of what media rates that was last used. So if one open a new connection after terminating one that was limited to 20kbps just seconds before, then you are very conservative when starting a new peerConnection. On the last issue, do you have a suggestion for how to achieve this that isn't RTCP? > > >> We are coming back to the most difficult trade-offs for RTCWEB. >> Legacy interoperability vs Security. We have several different >> aspects which makes legacy interoperability with a too simple >> device a big security risk. >> >> Media transmission consent -> Requiring ICE support Path Overload >> DoS concerns -> Requiring Congestion Control for both media and >> data. RTCWEB deployment model and concerns for privacy and >> confenditality -> Media security (what level is still not agreed >> on) >> >> All of the above are clear barriers against legacy >> interoperability. > > Yup. I don't doubt we'll need some form of media-plane gateway > either in the web server or separate to interop with legacy - I'm > just trying to keep it from becoming so expensive and complicated > that it would be cheaper/easier/better to use SIP softclients or > plugins instead. > I understand and support that we shouldn't have unnecessary complications for legacy interop. However, but I don't see it being done by compromising security to the level where RTCWEB can't be deployed even for browser to browser usage. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Sep 22 05:35: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 7E6D921F8B80 for ; Thu, 22 Sep 2011 05:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 xauzuwqAO7xB for ; Thu, 22 Sep 2011 05:35:10 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BB8FA21F8C0B for ; Thu, 22 Sep 2011 05:35:09 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-75-4e7b2c12177f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B5.DC.20773.21C2B7E4; Thu, 22 Sep 2011 14:37:38 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 14:37:38 +0200 Message-ID: <4E7B2C04.4010204@ericsson.com> Date: Thu, 22 Sep 2011 14:37:24 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Muthu Arul Mozhi Perumal (mperumal)" References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se><4E70D2E6.1000809@alvestrand.no><7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se><092401cc749b$8fd64940$af82dbc0$@com><4E765E4A.3050801@alvestrand.no><0ced01cc76de$28731630$79594290$@com> <4E77613B.4020805@ericsson.com> <1D062974A4845E4D8A343C6538049202066497EF@XMB-BGL-414.cisco.com> <4E784C38.2010909@ericsson.com> <1D062974A4845E4D8A343C65380492020672C04A@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020672C04A@XMB-BGL-414.cisco.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 12:35:11 -0000 On 2011-09-22 14:19, Muthu Arul Mozhi Perumal (mperumal) wrote: > |That is a possibility, but I think one can start by ensuring |that > one actually check for ones own traffic being reported |back. That > gives you some entropy. Which is a slightly longer |context gives you > good verification that you are not contining |sending into a location > where there receiver you intended to |have sent to moves away. > > Agree it would suffice in general. However, for cases like double > hold (SDP offer with a=inactive) where you would be neither sending > nor receiving media the attacker can keep replaying the RTCP packets > with an empty report block (that no zero entropy) making you think > the other end is still alive. > > Of course, you may ultimately disconnect the call but it could mean a > DOS attack.. If neither party is actually transmitting media then the only traffic is RTCP in either directions. Thus one RTCP compound packet per SSRC per regular reporting interval. Unless you have an app that open a lot of media streams that is usually pretty low bit-rate. And if you actually have a lot of streams, then the bit-rate will saturate at the configured RTCP rate. But I would note this is in fact a potential attack vector if one can set the RTCP bit-rate arbitrary high. Secondly, I think in those cases a timer on the inactivity from both parties should be considered to terminate the session. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Sep 22 05:43: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 C684521F8C54 for ; Thu, 22 Sep 2011 05:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 K0WKJ05lJCkG for ; Thu, 22 Sep 2011 05:43:04 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A142021F8C4F for ; Thu, 22 Sep 2011 05:43:03 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a1-4e7b2deecb43 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1E.5E.20773.EED2B7E4; Thu, 22 Sep 2011 14:45:34 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 14:45:34 +0200 Message-ID: <4E7B2DDB.903@ericsson.com> Date: Thu, 22 Sep 2011 14:45:15 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "rtcweb@ietf.org" , EKR References: <20110922075433.17483.59128.idtracker@ietfa.amsl.com> In-Reply-To: <20110922075433.17483.59128.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-security-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: Thu, 22 Sep 2011 12:43:05 -0000 Hi EKR, (As an individual) Thanks for posting the draft. I am missing a few security issues that I think should be considered. 1. The attempt to overload the links in an domain by concentrating traffic on the domain by choosing peer-pairs. Not that I think there is any real protection against this other than limit the flows to their "fair" share. 2. Configuring RTCP or other automatically sent traffic to high bit-rates. Especially under conditions where continued consent can't be determined. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From fluffy@cisco.com Thu Sep 22 06:14: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 25CB121F8C70 for ; Thu, 22 Sep 2011 06:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.115 X-Spam-Level: X-Spam-Status: No, score=-103.115 tagged_above=-999 required=5 tests=[AWL=-0.516, 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 nAP2HRKiXTPz for ; Thu, 22 Sep 2011 06:14:52 -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 E8E7121F8C56 for ; Thu, 22 Sep 2011 06:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1368; q=dns/txt; s=iport; t=1316697444; x=1317907044; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=UNfn66p8HKBbKKs1C/c5DCA9sVv7WjuaGbkDZY+Igys=; b=akOoGPYe3Hz2Iwfkm6WE50GoCzpNFDJ/ts0kM1CyJEEF0OA92UFYmm+H oTKjfMRxHwjSF3XLgUQZvkJFZ82W8nuezsjDVDxShh64eG+bCOFaW0Z// qw/Is2fwkyPD1We1YoAxhbclBtW+1+WUD/N1spuGZL5a/+F6cqBas5F4P w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMQ0e06rRDoI/2dsb2JhbABCqAB4gVMBAQEBAxIBJzIKAxALDjhXBiwJni4BnjaGHWAEh3GLX4UfjC8 X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="3660140" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 22 Sep 2011 13:17:24 +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 p8MDHNuo029665; Thu, 22 Sep 2011 13:17:23 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> Date: Thu, 22 Sep 2011 07:17:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3A175754-2318-4512-98C5-F8742A82067E@cisco.com> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 13:14:54 -0000 On Sep 20, 2011, at 4:36 PM, Hadriel Kaplan wrote: >>=20 >> To simplify this problem, Cary and my draft proposes not allowing = forking on the SIP side of the signaling gateway but still allowing = early media. If you wanted to do do forking in this case, one would need = a SBC that processed media and turned the forked medial legs into one = media leg.=20 >=20 > Obviously you can request that a request not be forked, using = caller-prefs, but you can't "not allow" forking on the SIP side. That = would make it not SIP. I know forking is hard, but that's life. It's = not appropriate for this WG to make fundamental changes/limitations to = the SIP protocol, just because some of it's "hard" for a browser.=20 I'll note that Cary and my draft has been putting serious limitation on = SIP since the beginning and we have yet to receive a comment on that. = You do realize the outcome of this decision would be that you needed an = SBC between the SIP to WEB Gateway and any SIP network that forked so = that SBC could isolate the other side from the forks. As full = disclosure, really, I don't own any ACME stock :-)=20 Clearly one could support forking in the browsers and equally obviously, = that complicates things fairly significantly. The question will be if = the complexity is worth the end user gain in functionality.=20 From HKaplan@acmepacket.com Thu Sep 22 06:32: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 938F621F8C89 for ; Thu, 22 Sep 2011 06:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 3XQPITrumh7d for ; Thu, 22 Sep 2011 06:32:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id F3ED421F8C77 for ; Thu, 22 Sep 2011 06:32:30 -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, 22 Sep 2011 09:34:58 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 22 Sep 2011 09:34:58 -0400 From: Hadriel Kaplan To: Magnus Westerlund Thread-Topic: [rtcweb] STUN for keep-alive - RTCP-less applications Thread-Index: AQHMeSxrIKUT9mUbYkyr0iQzRJ1k0w== Date: Thu, 22 Sep 2011 13:34:58 +0000 Message-ID: <4D8061B7-16C5-439C-8911-E4F2046999B7@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> <0C42CC63-CA1A-4F64-B522-BC1DAB477471@acmepacket.com> <4E7B2A65.6090106@ericsson.com> In-Reply-To: <4E7B2A65.6090106@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: <3F294D36C0A43245A9F1FE9C27BA8C96@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" , Colin Perkins Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 13:32:31 -0000 On Sep 22, 2011, at 8:30 AM, Magnus Westerlund wrote: >> If the >> concern is just that the far-end is dead or terminated the call but >> the local side didn't get the memo, we can solve that other ways. >=20 > On the last issue, do you have a suggestion for how to achieve this that > isn't RTCP? If we assume that a gateway to legacy has to handle ICE termination anyway,= then it can send STUN indications during the call. The rtcweb browser can use those to see the far end is alive and expecting = media on the 5-tuple. If we're worried about those being faked/spoofed by malicious server/JS, we= can modify the indication mechanism (which could also allay ekr's concerns= about consent refresh). >> Yup. I don't doubt we'll need some form of media-plane gateway >> either in the web server or separate to interop with legacy - I'm >> just trying to keep it from becoming so expensive and complicated >> that it would be cheaper/easier/better to use SIP softclients or >> plugins instead. >>=20 >=20 > I understand and support that we shouldn't have unnecessary > complications for legacy interop. However, but I don't see it being done > by compromising security to the level where RTCWEB can't be deployed > even for browser to browser usage. Welllll... could we just require specific user consent for calls to/from le= gacy? -hadriel From fluffy@cisco.com Thu Sep 22 06:42: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 9471121F8AFA for ; Thu, 22 Sep 2011 06:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.111 X-Spam-Level: X-Spam-Status: No, score=-103.111 tagged_above=-999 required=5 tests=[AWL=-0.512, 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 oOCi7n3mKG-S for ; Thu, 22 Sep 2011 06:42:12 -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 E5B3221F8AF8 for ; Thu, 22 Sep 2011 06:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2706; q=dns/txt; s=iport; t=1316699084; x=1317908684; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=FJh0KYhhWXBXCnWBbHjjsouh/BLzZhfEBJPnBpT7ZFg=; b=krJBK2/jRyDNbKdAmUtIMFEMW5iuIagNdlh22/mr1rDEcHadJ4F2Trl4 a9Q4Eyd/T+340wrBu2CsT2lu40ypKzTQ0+C8i/Z3MapChe6KQ8XLDTHNs Ptyx48ZlYkGsQgh+ZVlsVY1ClVzaj4ZdjTxUzel3/P+ICj+prqAtwuw1K s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG46e06rRDoJ/2dsb2JhbABCqAB4gVMBAQEBAgESASc/BQtRVwYxAQOHVpZWAZ4uhh1gBIdxi1+FH4wv X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="3653065" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 22 Sep 2011 13:44:44 +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 p8MDihF1003326; Thu, 22 Sep 2011 13:44:43 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E799ECC.8030306@ericsson.com> Date: Thu, 22 Sep 2011 07:44:43 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 13:42:13 -0000 On Sep 21, 2011, at 2:22 AM, Magnus Westerlund wrote: > And why, did you design such a poor glare handling algorithm for SIP? = ;-) So, the SIP glare algorithm leaves much to be desired, no questions = about it. I'm going to claim I was not there at the time until someone = proves otherwise then switch my story to I was drunk not stupid. (in = fairness we were trying to be backwards compatible with 2543 equipment). Anyways, I've been bouncing ideas around with folks on how we might = improve the situation. Here is a proposal that might improve it for SIP = and could also be leveraged by RTCWeb.=20 First, to review the current situation, the current algorithm is: When two sides detect glare, they each pick a random integer from 1 to = 10 and tell the other side to retry in that many seconds. two obvious = problems with this: 1) it introduces, on average, over 7 seconds of = delay which is a long time for a user 2) it has a non trivial chance of = having glare a second time and needing to be repeat I'm proposing an extension that would go something like this: Both sides always include a random tie breaker number in their SDP that = is used for glare resolution. If both sides support this and have the = number, then glare is resolved by whoever has the lowest number.=20 If neither side supports this, obviously the current things is what = happens.=20 if one side supports it but the other does not, the side that supports = it tells the other side to retry after 0 seconds. So effectively it = causes the other side to always "win" the tie and retry first. This = reduces the latency of the glare resolution to the end user. The other = side that does not support the new algorithm will still send a retry = after some random number form 1 to 10 seconds. However, the side that = supports this new mechanisms might want to decide that under some = conditions, ti can short circuit that timer and retry sooner than that. = It's not exactly clear to me when to short circuit this. Could it short = circuit after receiving the retied transaction from the other side plus = a one RTT delay? Could we just retry after 3 RTT or so knowing the other = side won the race and was retying immediately?=20 Even if the UA just runs out the full retry time, this algorithm still = reduces the average delay significantly for cases where only one side = supports it and gets really fast when both sides support it.=20 Thoughts? I suspect this would need an SDP extension to carry the tie breaker = number or even if we used an existing number, it seems like we still = need something that indicates support for this new extension.=20 From tim@phonefromhere.com Thu Sep 22 06:55: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 8F3D321F8C54 for ; Thu, 22 Sep 2011 06:55:14 -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 lFUT24mrFBCy for ; Thu, 22 Sep 2011 06:55:14 -0700 (PDT) Received: from zimbra.westhawk.co.uk (zimbra.westhawk.co.uk [192.67.4.167]) by ietfa.amsl.com (Postfix) with ESMTP id 0381821F8C1E for ; Thu, 22 Sep 2011 06:55:14 -0700 (PDT) Received: from [10.10.3.9] (unknown [216.38.153.2]) by zimbra.westhawk.co.uk (Postfix) with ESMTP id DC3FF37A90A; Thu, 22 Sep 2011 15:10:33 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Tim Panton In-Reply-To: Date: Thu, 22 Sep 2011 06:57:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <57CCCB06-F4C3-4E23-AF09-B7B5285C5FAE@phonefromhere.com> References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1244.3) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 13:55:14 -0000 On 22 Sep 2011, at 06:44, Cullen Jennings wrote: >=20 > On Sep 21, 2011, at 2:22 AM, Magnus Westerlund wrote: >=20 >> And why, did you design such a poor glare handling algorithm for SIP? = ;-) >=20 > So, the SIP glare algorithm leaves much to be desired, no questions = about it. I'm going to claim I was not there at the time until someone = proves otherwise then switch my story to I was drunk not stupid. (in = fairness we were trying to be backwards compatible with 2543 equipment). Which is an important lesson for rtcweb, backward compatibility has = longterm costs. At the risk of showing my ignorance - why are we expecting glare to be a = problem?=20 To my mind glare only happens when you have a locked resource e.g. a = busy line or number . Rtcweb does not contain either of those concepts, what's the = resource that is being competed for here ? Tim (speaking entirely for his own ignorance)= From mperumal@cisco.com Thu Sep 22 06:58: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 EB2DD21F8BF0 for ; Thu, 22 Sep 2011 06:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.494 X-Spam-Level: X-Spam-Status: No, score=-10.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfkmixRKbHqu for ; Thu, 22 Sep 2011 06:58:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id D2AB621F8C1E for ; Thu, 22 Sep 2011 06:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2564; q=dns/txt; s=iport; t=1316700048; x=1317909648; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=rRaAaTPWqjR3mT8ixs93dmsPNmP1dBkGt6wQyC/3bvc=; b=diuMfQIUTM5sRs0WJPWbdVvHK5E/6bvOdvWg032Xg+2zEX6z2BnNc2nB ABMcFqhEVxXuyjoNgip/mGT9OOpv2bueGr0au88DfyZRlKP+8EMxwH1yh aqvN/wJ5IgnegDfUvzONMUyaFxySCVghKzorgcCJ9eJb9P6SszXAx5r6i E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswAAAE/e05Io8UQ/2dsb2JhbABCmQmOd3iBUwEBAQEDDAYBHUkMAgICAQgRBAEBCwYXAQYBGisJCAEBBAsICBqeLAGeLgKDVYJGYASHQS6RCYwP X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="116695197" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 22 Sep 2011 14:00:42 +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 p8ME0fUY008312; Thu, 22 Sep 2011 14:00:41 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, 22 Sep 2011 19:30:41 +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, 22 Sep 2011 19:30:40 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020672C08F@XMB-BGL-414.cisco.com> In-Reply-To: <4E7B2C04.4010204@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] consent freshness [was RE: STUN for keep-alive] Thread-Index: Acx5JG/Kh8QlUKqfRCq9SmI82jVcxwACrnwg References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se><4E70D2E6.1000809@alvestrand.no><7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se><092401cc749b$8fd64940$af82dbc0$@com><4E765E4A.3050801@alvestrand.no><0ced01cc76de$28731630$79594290$@com> <4E77613B.4020805@ericsson.com> <1D062974A4845E4D8A343C6538049202066497EF@XMB-BGL-414.cisco.com> <4E784C38.2010909@ericsson.com> <1D062974A4845E4D8A343C65380492020672C04A@XMB-BGL-414.cisco.com> <4E7B2C04.401 0204@eri csson.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Magnus Westerlund" X-OriginalArrivalTime: 22 Sep 2011 14:00:41.0543 (UTC) FILETIME=[03C36570:01CC7930] Cc: rtcweb@ietf.org Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 13:58:18 -0000 |Secondly, I think in those cases a timer on the inactivity |from both parties should be considered to terminate the session. If the timer is based on RTP inactivity it would terminate the session. = If it is based on RTCP inactivity (which many implementations do) it = wouldn't. Muthu |-----Original Message----- |From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] |Sent: Thursday, September 22, 2011 6:07 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: Dan Wing (dwing); rtcweb@ietf.org |Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive] | |On 2011-09-22 14:19, Muthu Arul Mozhi Perumal (mperumal) wrote: |> |That is a possibility, but I think one can start by ensuring |that |> one actually check for ones own traffic being reported |back. That |> gives you some entropy. Which is a slightly longer |context gives you |> good verification that you are not contining |sending into a location |> where there receiver you intended to |have sent to moves away. |> |> Agree it would suffice in general. However, for cases like double |> hold (SDP offer with a=3Dinactive) where you would be neither sending |> nor receiving media the attacker can keep replaying the RTCP packets |> with an empty report block (that no zero entropy) making you think |> the other end is still alive. |> |> Of course, you may ultimately disconnect the call but it could mean a |> DOS attack.. | |If neither party is actually transmitting media then the only traffic = is |RTCP in either directions. Thus one RTCP compound packet per SSRC per |regular reporting interval. Unless you have an app that open a lot of |media streams that is usually pretty low bit-rate. And if you actually |have a lot of streams, then the bit-rate will saturate at the = configured |RTCP rate. But I would note this is in fact a potential attack vector = if |one can set the RTCP bit-rate arbitrary high. | |Secondly, I think in those cases a timer on the inactivity from both |parties should be considered to terminate the session. | |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 |---------------------------------------------------------------------- From HKaplan@acmepacket.com Thu Sep 22 07:02: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 3754321F8BFE for ; Thu, 22 Sep 2011 07:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 Zru2UccxtcVG for ; Thu, 22 Sep 2011 07:02:15 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7062521F8BC5 for ; Thu, 22 Sep 2011 07:02:15 -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, 22 Sep 2011 10:04:46 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 22 Sep 2011 10:04:46 -0400 From: Hadriel Kaplan To: Cullen Jennings Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism Thread-Index: AQHMeTCVYKm8GHKucEylDB38nl0SPA== Date: Thu, 22 Sep 2011 14:04:45 +0000 Message-ID: References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> <3A175754-2318-4512-98C5-F8742A82067E@cisco.com> In-Reply-To: <3A175754-2318-4512-98C5-F8742A82067E@cisco.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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 14:02:16 -0000 On Sep 22, 2011, at 9:17 AM, Cullen Jennings wrote: > I'll note that Cary and my draft has been putting serious limitation on S= IP since the beginning and we have yet to receive a comment on that. You do= realize the outcome of this decision would be that you needed an SBC betwe= en the SIP to WEB Gateway and any SIP network that forked so that SBC could= isolate the other side from the forks. As full disclosure, really, I don't= own any ACME stock :-)=20 Oh, I think we'll be busy enough. ;) Choosing the right fork is really hard. (or so it seems when I sit down at = fancy restaurants) > Clearly one could support forking in the browsers and equally obviously, = that complicates things fairly significantly. The question will be if the c= omplexity is worth the end user gain in functionality.=20 Ignoring the issue of not being SIP anymore, I think you'll want forking in= the end. Even in XMPP people have asked for it now and then. But anyway sorry I didn't read Cary and your draft before. Would you like = comments now? :) First, I assume you mean draft-cbran-rtcweb-protocols-00. You have the following as optional: o INVITEs without an offer o re-INVITEs o forking o S/MIME o SIPS URI Scheme My comments: S/MIME has never seen the light of day and would be removed if we ever rais= ed 3261 to the soon-to-be-second-and-final level of maturity, so sure. INVITEs without offers can be ignored in terms of generating them from rtcw= eb, but rtcweb has to be able to receive them. (I would think Cisco in part= icular would demand this ;) Re-INVITEs again may not need to be generated by rtcweb, but have to be abl= e to be received. (it's not hard is it?) Forking is needed to eat our own dogfood with. SIPS is sadly rare, but ironically I would think the rtcweb model is one we= 'd actually want and use it in (because we could require HTTPS be used, and= it probably would even happen!). Last comment: you gave me a good chuckle, making 4474/4916 required. :) -hadriel From ekr@rtfm.com Thu Sep 22 07:06: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 BE7F221F8CBF for ; Thu, 22 Sep 2011 07:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.907 X-Spam-Level: X-Spam-Status: No, score=-102.907 tagged_above=-999 required=5 tests=[AWL=0.070, 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 FRNHysQ9+S13 for ; Thu, 22 Sep 2011 07:06:13 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD4CA21F8C9D for ; Thu, 22 Sep 2011 07:06:12 -0700 (PDT) Received: by wyh21 with SMTP id 21so855921wyh.31 for ; Thu, 22 Sep 2011 07:08:43 -0700 (PDT) Received: by 10.227.3.15 with SMTP id 15mr714873wbl.33.1316700523230; Thu, 22 Sep 2011 07:08:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.151.205 with HTTP; Thu, 22 Sep 2011 07:08:23 -0700 (PDT) In-Reply-To: <4E7B2DDB.903@ericsson.com> References: <20110922075433.17483.59128.idtracker@ietfa.amsl.com> <4E7B2DDB.903@ericsson.com> From: Eric Rescorla Date: Thu, 22 Sep 2011 07:08:23 -0700 Message-ID: To: Magnus Westerlund Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-security-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: Thu, 22 Sep 2011 14:06:13 -0000 Thanks. for pointing these out. I will add them to my TODO list to write up= . On Thu, Sep 22, 2011 at 5:45 AM, Magnus Westerlund wrote: > Hi EKR, > > (As an individual) > > Thanks for posting the draft. > > I am missing a few security issues that I think should be considered. > > 1. The attempt to overload the links in an domain by concentrating > traffic on the domain by choosing peer-pairs. Not that I think there is > any real protection against this other than limit the flows to their > "fair" share. > > 2. Configuring RTCP or other automatically sent traffic to high > bit-rates. Especially under conditions where continued consent can't be > determined. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287 > F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > From HKaplan@acmepacket.com Thu Sep 22 07:38: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 E2FF221F8CF9 for ; Thu, 22 Sep 2011 07:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 TNWQExrwKt3H for ; Thu, 22 Sep 2011 07:38:03 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3A77A21F8CB3 for ; Thu, 22 Sep 2011 07:38:03 -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, 22 Sep 2011 10:40:34 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 22 Sep 2011 10:40:33 -0400 From: Hadriel Kaplan To: Tim Panton Thread-Topic: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism Thread-Index: AQHMeTWV0qH9FzhU+EGg85SkO4gvfg== Date: Thu, 22 Sep 2011 14:40:33 +0000 Message-ID: <0FA1CB26-592C-4550-B449-AA2814817E51@acmepacket.com> References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> <57CCCB06-F4C3-4E23-AF09-B7B5285C5FAE@phonefromhere.com> In-Reply-To: <57CCCB06-F4C3-4E23-AF09-B7B5285C5FAE@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="us-ascii" Content-ID: <1F461A43CC94CB408B3D1057DACA68D7@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 14:38:07 -0000 On Sep 22, 2011, at 9:57 AM, Tim Panton wrote: > At the risk of showing my ignorance - why are we expecting glare to be a = problem?=20 > To my mind glare only happens when you have a locked resource e.g. a busy= line > or number . Rtcweb does not contain either of those concepts, what's the = resource > that is being competed for here ? The resource being competed for is SDP state/media info of the same session= . If both sides send a new SDP offer during the session at the same time, = one side has to win. One would think this would be ultra-rare, but in SIP it happens a lot in so= me deployments.=20 -hadriel From roman@telurix.com Thu Sep 22 07:47: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 5CDCC21F8505 for ; Thu, 22 Sep 2011 07:47:10 -0700 (PDT) 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.235, 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 bnno3emCDTdJ for ; Thu, 22 Sep 2011 07:47:09 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAB221F84D6 for ; Thu, 22 Sep 2011 07:47:09 -0700 (PDT) Received: by yxt33 with SMTP id 33so2448801yxt.31 for ; Thu, 22 Sep 2011 07:49:41 -0700 (PDT) Received: by 10.150.69.26 with SMTP id r26mr240821yba.322.1316702980746; Thu, 22 Sep 2011 07:49:40 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id q16sm4295838ybf.8.2011.09.22.07.49.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 07:49:40 -0700 (PDT) Received: by yxt33 with SMTP id 33so2448787yxt.31 for ; Thu, 22 Sep 2011 07:49:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.34.138 with SMTP id z10mr4478920pbi.105.1316702979362; Thu, 22 Sep 2011 07:49:39 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Thu, 22 Sep 2011 07:49:39 -0700 (PDT) In-Reply-To: References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> <3A175754-2318-4512-98C5-F8742A82067E@cisco.com> Date: Thu, 22 Sep 2011 10:49:39 -0400 Message-ID: From: Roman Shpount To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=bcaec52163035c0e8c04ad88cd82 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 14:47:10 -0000 --bcaec52163035c0e8c04ad88cd82 Content-Type: text/plain; charset=ISO-8859-1 Since we are commenting on this draft, I, as I've previously stated on this list, really would not like to see SIP as something directly supported by Web RTC, especially a version of SIP lite described in this draft. If we decide to build SIP into RTC, I would assume we would need a secure channel for signaling, so we will need TLS transport. Also, if we plan to use ICE, SIP messages will be larger then the SIP standard limit set for UDP transport, so even in the cases of non secure connections we will need TCP for signaling, not UDP with STUN keep alives. If we decide to implement SIP over TCP from behind NAT we will need to fix RFC 5626 to provide a contact for calls and transactions that can be recovered after a TCP connection reset. As far as I know this standard assumes that GRUU is used for call contacts, and is recovered using new registrations, but does nor provide any guidance on what suppose to happen with transaction responses if connection is reset. After we fix this spec, industry will have to go and implement signaling servers that support such functionality (ASFAK there are none in existence) and proxy it to normal SIP. I believe, at this point it would actually be easier to build a JavaScript library + HTTP(S) to SIP proxy. _____________ Roman Shpount On Thu, Sep 22, 2011 at 10:04 AM, Hadriel Kaplan wrote: > > On Sep 22, 2011, at 9:17 AM, Cullen Jennings wrote: > > > I'll note that Cary and my draft has been putting serious limitation on > SIP since the beginning and we have yet to receive a comment on that. You do > realize the outcome of this decision would be that you needed an SBC between > the SIP to WEB Gateway and any SIP network that forked so that SBC could > isolate the other side from the forks. As full disclosure, really, I don't > own any ACME stock :-) > > Oh, I think we'll be busy enough. ;) > > Choosing the right fork is really hard. (or so it seems when I sit down at > fancy restaurants) > > > > Clearly one could support forking in the browsers and equally obviously, > that complicates things fairly significantly. The question will be if the > complexity is worth the end user gain in functionality. > > Ignoring the issue of not being SIP anymore, I think you'll want forking in > the end. Even in XMPP people have asked for it now and then. > > But anyway sorry I didn't read Cary and your draft before. Would you like > comments now? :) > First, I assume you mean draft-cbran-rtcweb-protocols-00. > > You have the following as optional: > o INVITEs without an offer > o re-INVITEs > o forking > o S/MIME > o SIPS URI Scheme > > My comments: > S/MIME has never seen the light of day and would be removed if we ever > raised 3261 to the soon-to-be-second-and-final level of maturity, so sure. > INVITEs without offers can be ignored in terms of generating them from > rtcweb, but rtcweb has to be able to receive them. (I would think Cisco in > particular would demand this ;) > Re-INVITEs again may not need to be generated by rtcweb, but have to be > able to be received. (it's not hard is it?) > Forking is needed to eat our own dogfood with. > SIPS is sadly rare, but ironically I would think the rtcweb model is one > we'd actually want and use it in (because we could require HTTPS be used, > and it probably would even happen!). > > Last comment: you gave me a good chuckle, making 4474/4916 required. :) > > -hadriel > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec52163035c0e8c04ad88cd82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Since we are commenting on this draft, I, as I've previously stated on = this list, really would not like to see SIP as something directly supported= by Web RTC, especially a version of SIP lite described in this draft.

If we decide to build SIP into RTC, I would assume we would need a secu= re channel for signaling, so we will need TLS transport. Also, if we plan t= o use ICE, SIP messages will be larger then the SIP standard limit set for = UDP transport, so even in the cases of non secure connections we will need = TCP for signaling, not UDP with STUN keep alives. If we decide to implement= SIP over TCP from behind NAT we will need to fix RFC 5626 to provide a con= tact for calls and transactions that can be recovered after a TCP connectio= n reset. As far as I know this standard assumes that GRUU is used for call = contacts, and is recovered using new registrations, but does nor provide an= y guidance on what suppose to happen with transaction responses if connecti= on is reset. After we fix this spec, industry will have to go and implement= signaling servers that support such functionality (ASFAK there are none in= existence) and proxy it to normal SIP. I believe, at this point it would a= ctually be easier to build a JavaScript library + HTTP(S) to SIP proxy.
_____________
Roman Shpount


On Thu, Sep 22, 2011 at 10:04 AM, Hadrie= l Kaplan <HK= aplan@acmepacket.com> wrote:

On Sep 22, 2011, at 9:17 AM, Cullen Jennings wrote:

> I'll note that Cary and my draft has been putting serious limitati= on on SIP since the beginning and we have yet to receive a comment on that.= You do realize the outcome of this decision would be that you needed an SB= C between the SIP to WEB Gateway and any SIP network that forked so that SB= C could isolate the other side from the forks. As full disclosure, really, = I don't own any ACME stock :-)

Oh, I think we'll be busy enough. ;)

Choosing the right fork is really hard. (or so it seems when I sit down at = fancy restaurants)


> Clearly one could support forking in the browsers and equally obviousl= y, that complicates things fairly significantly. The question will be if th= e complexity is worth the end user gain in functionality.

Ignoring the issue of not being SIP anymore, I think you'll want = forking in the end. =A0Even in XMPP people have asked for it now and then.<= br>
But anyway sorry I didn't read Cary and your draft before. =A0Would you= like comments now? =A0:)
First, I assume you mean draft-cbran-rtcweb-protocols-00.

You have the following as optional:
=A0 o =A0INVITEs without an offer
=A0 o =A0re-INVITEs
=A0 o =A0forking
=A0 o =A0S/MIME
=A0 o =A0SIPS URI Scheme

My comments:
S/MIME has never seen the light of day and would be removed if we ever rais= ed 3261 to the soon-to-be-second-and-final level of maturity, so sure.
INVITEs without offers can be ignored in terms of generating them from rtcw= eb, but rtcweb has to be able to receive them. (I would think Cisco in part= icular would demand this ;)
Re-INVITEs again may not need to be generated by rtcweb, but have to be abl= e to be received. (it's not hard is it?)
Forking is needed to eat our own dogfood with.
SIPS is sadly rare, but ironically I would think the rtcweb model is one we= 'd actually want and use it in (because we could require HTTPS be used,= and it probably would even happen!).

Last comment: you gave me a good chuckle, making 4474/4916 required. =A0:)<= br>
-hadriel

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

--bcaec52163035c0e8c04ad88cd82-- From roman@telurix.com Thu Sep 22 07:53: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 EF56721F8B12 for ; Thu, 22 Sep 2011 07:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.753 X-Spam-Level: X-Spam-Status: No, score=-2.753 tagged_above=-999 required=5 tests=[AWL=0.223, 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 gwPkvuKRX2LF for ; Thu, 22 Sep 2011 07:53:02 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E27DB21F8B10 for ; Thu, 22 Sep 2011 07:53:00 -0700 (PDT) Received: by qyk32 with SMTP id 32so6318724qyk.10 for ; Thu, 22 Sep 2011 07:55:31 -0700 (PDT) Received: by 10.229.180.104 with SMTP id bt40mr1742586qcb.184.1316703331263; Thu, 22 Sep 2011 07:55:31 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx.google.com with ESMTPS id hn10sm8448079qab.20.2011.09.22.07.55.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 07:55:31 -0700 (PDT) Received: by gxk19 with SMTP id 19so2463749gxk.31 for ; Thu, 22 Sep 2011 07:55:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.5.1 with SMTP id o1mr4519045pbo.20.1316703329021; Thu, 22 Sep 2011 07:55:29 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Thu, 22 Sep 2011 07:55:27 -0700 (PDT) In-Reply-To: <0FA1CB26-592C-4550-B449-AA2814817E51@acmepacket.com> References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> <57CCCB06-F4C3-4E23-AF09-B7B5285C5FAE@phonefromhere.com> <0FA1CB26-592C-4550-B449-AA2814817E51@acmepacket.com> Date: Thu, 22 Sep 2011 10:55:27 -0400 Message-ID: From: Roman Shpount To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=bcaec5314b51336e3104ad88e2f3 Cc: "" Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 14:53:04 -0000 --bcaec5314b51336e3104ad88e2f3 Content-Type: text/plain; charset=ISO-8859-1 If we are planning to support SIP, then standard way of dealing with glare actually works fairly well. We would probably not get as much glare even with SIP if we would not use re-INVITEs for keep alive messages (SIP session timers). If we do not plan to support SIP, all we need is an ability in the API to cancel an offer and leave glare resolution to signaling. In general glare is unavoidable, for instance in case were both parties in the call decide for some reason to switch the video on. _____________ Roman Shpount On Thu, Sep 22, 2011 at 10:40 AM, Hadriel Kaplan wrote: > > On Sep 22, 2011, at 9:57 AM, Tim Panton wrote: > > > At the risk of showing my ignorance - why are we expecting glare to be a > problem? > > To my mind glare only happens when you have a locked resource e.g. a busy > line > > or number . Rtcweb does not contain either of those concepts, what's the > resource > > that is being competed for here ? > > The resource being competed for is SDP state/media info of the same > session. If both sides send a new SDP offer during the session at the same > time, one side has to win. > > One would think this would be ultra-rare, but in SIP it happens a lot in > some deployments. > > -hadriel > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec5314b51336e3104ad88e2f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If we are planning to support SIP, then standard way of dealing with glare = actually works fairly well. We would probably not get as much glare even wi= th SIP if we would not use re-INVITEs for keep alive messages (SIP session = timers). If we do not plan to support SIP, all we need is an ability in the= API to cancel an offer and leave glare resolution to signaling. In general= glare is unavoidable, for instance in case were both parties in the call d= ecide for some reason to switch the video on.
_____________
Roman Shpount


On Thu, Sep 22, 2011 at 10:40 AM, Hadrie= l Kaplan <HK= aplan@acmepacket.com> wrote:

On Sep 22, 2011, at 9:57 AM, Tim Panton wrote:

> At the risk of showing my ignorance - why are we expecting glare to be= a problem?
> To my mind glare only happens when you have a locked resource e.g. a b= usy line
> or number . Rtcweb does not contain either of those concepts, what'= ;s the resource
> that is being competed for here ?

The resource being competed for is SDP state/media info of the same s= ession. =A0If both sides send a new SDP offer during the session at the sam= e time, one side has to win.

One would think this would be ultra-rare, but in SIP it happens a lot in so= me deployments.

-hadriel

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

--bcaec5314b51336e3104ad88e2f3-- From magnus.westerlund@ericsson.com Thu Sep 22 08:09: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 56EB621F8B2E for ; Thu, 22 Sep 2011 08:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.525 X-Spam-Level: X-Spam-Status: No, score=-106.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 RAAK34c5jjg9 for ; Thu, 22 Sep 2011 08:09:16 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 22BCA21F8B4E for ; Thu, 22 Sep 2011 08:09:15 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-aa-4e7b503309a0 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4E.78.20773.3305B7E4; Thu, 22 Sep 2011 17:11:47 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 17:11:46 +0200 Message-ID: <4E7B5026.70707@ericsson.com> Date: Thu, 22 Sep 2011 17:11:34 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Cullen Jennings References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 15:09:17 -0000 Hi, Here is an analysis of what happens including Cullen's SIP side optimization if one uses a random value attached to the offer as tiebreaker and interop with SIP. Lets start with the general scenario. A <-RTCWEB-> WS/SGW <-SIP-> B So lets look at the glare conditions that can occur. a) Initially in regards to the creation of a PeerConnection/call where both sides attempt to create a session with its peer. b) During a re-Offer/re-inivite in an existing session. However, I don't think this really matters for the glare resolution mechanism. It might effect which SIP messages are sent in which case. Secondly the glare condition will be detected in various cases depending on in what state of signalling the glare occurs. 1) If A sends an offer that left A, but not arrived at the GW, while B's are on its way between the GW and A. 2) IF A sends an offer that has passed the GW, while B's are on its way between B and the GW. 3) Both A and Bs Offers are at the GW while neither has been forwarded. 4) Like 2) but B supports Cullen's behavior. In case 1, entity A (a RTCWEB browser) will receive the Offer from B when itself has an outstanding offer. It perform the local tie-breaking of the SDP and determine that either A or Bs Offer is the winning. If A wins it just discards B, alternatively send an error (but that doesn't appear necessary). If B wins it abandons its Offer and process B's. In case 1, the GW when A's Offer arrive at the GW, it has already sent B's offer with its tie-breaking value. It immediately determine who won the tie-breaking and then continue acting according to it. If A's won then it sends a 491 with a significant large delay value. Then it sends A's offer with some small delay just as it got lucky with a low value. If B won, then it just discards A's Offer and waits for A's answer to B's offer. In case 2) the GW could look for a tie-breaker value according to Cullen's proposal and if present then determine the winner. Considering that the quickest way to resolve the tie-breaking towards the RTCWEB client if the value isn't present is to fold for the RTCWEB client's behalf. Thus set B's tie-breker value to max. Then respond with a 491 with delay 0 to B. When B come back with an new offer it assigns this the highest tie-breaker value and send it to A. A will then abort its offer and accept B's. In case 2) in B, it will be completely in the SIP domain and it will respond with a 491 with a random delay value back to the GW. The GW will consume this message when it arrives. In case 3) the GW can avoid having the SIP UA (B) know there was any glare at all. This by setting the tie-breaking value for B's offer to MAX assuring it wins over A, and then send it to A to replace the offer. In case 4) the GW will have sent a tie-breaker value with A's offer to B in the SDP. B's offer with a tie-breaker value arrives at the GW. The GW determine who wins. If B wins it forwards B's offer to A. If A wins it will do something to make B's offer being canceled. Maybe a 491 answer is the simplest. Except that it will not be retired. In case 4) the UA (B) will have sent an invite with a tie-breaker value. When A's Invite with a tie-breaking value arrive it can perform the tie-breaking. If A wins then it immediately process it as if no outstanding Invite exist. (Question: how will the proxies react on that B responds immediately?). If B wins it sends a 491 for A's Invite. Then it continues waiting for the response. So independent of the optimization this can work as long as a GW is allowed to override a random selection mechanism in cases where the other protocol will resolve quicker if it does. I think the optimization makes sense, but is more a question of fixing SIP than really being needed for RTCWEB. I also wonder why not a SIP header for the tie-breaking? There appear also to be some more cases to analyze in detail and to figure out if the scheme breaks with some middleboxes. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From randell-ietf@jesup.org Thu Sep 22 08:10: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 69AB821F8BAB for ; Thu, 22 Sep 2011 08:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 DxrvHLfKGYcz for ; Thu, 22 Sep 2011 08:10:13 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 115BF21F8B6E for ; Thu, 22 Sep 2011 08:10:03 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R6kx0-0000xH-JB for rtcweb@ietf.org; Thu, 22 Sep 2011 10:12:34 -0500 Message-ID: <4E7B4F91.8090409@jesup.org> Date: Thu, 22 Sep 2011 11:09:05 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se><4E70D2E6.1000809@alvestrand.no><7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se><092401cc749b$8fd64940$af82dbc0$@com><4E765E4A.3050801@alvestrand.no><0ced01cc76de$28731630$79594290$@com> <4E77613B.4020805@ericsson.com> <1D062974A4845E4D8A343C6538049202066497EF@XMB-BGL-414.cisco.com> <4E784C38.2010909@ericsson.com> <1D062974A4845E4D8A343C65380492020672C04A@XMB-BGL-414.cisco.com> <4E7B2C04.401 0204@eri csson.com> <1D062974A4845E4D8A343C65380492020672C08F@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020672C08F@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] consent freshness [was RE: STUN for keep-alive] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 15:10:15 -0000 On 9/22/2011 10:00 AM, Muthu Arul Mozhi Perumal (mperumal) wrote: > |Secondly, I think in those cases a timer on the inactivity > |from both parties should be considered to terminate the session. > > If the timer is based on RTP inactivity it would terminate the session. If it is based on RTCP inactivity (which many implementations do) it wouldn't. There certainly may be use-cases where media in one (or both) directions are inactive or DTX-muted for considerable periods of time - remember, many of the use-cases (and unknown interesting future uses) aren't "phone calls". In particular, I have some interesting use-cases bubbling in the back of my brain where the data channel remains open at low/no activity and the media channels are inactive or non-existant for long periods, or where data traffic predominates and media are often inactive. -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Thu Sep 22 08:28: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 2C0D121F8BB9 for ; Thu, 22 Sep 2011 08:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 THq4cTgC2BWX for ; Thu, 22 Sep 2011 08:28:48 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 76D3321F8BB2 for ; Thu, 22 Sep 2011 08:28:47 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R6lF3-0004An-EV; Thu, 22 Sep 2011 10:31:14 -0500 Message-ID: <4E7B53F0.6000807@jesup.org> Date: Thu, 22 Sep 2011 11:27:44 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> <4E77949B.4010603@alvestrand.no> <4E78A4FB.1050504@ericsson.com> <4E79AC33.4000900@alvestrand.no> <0075AB47-3DFF-4000-9057-CA0628DF711A@csperkins.org> <05D1C2F6-96C3-44E3-9FC2-AD2C893C9FC6@acmepacket.com> <4E7AE975.1010105@jesup.org> In-Reply-To: <4E7AE975.1010105@jesup.org> Content-Type: multipart/alternative; boundary="------------080306080700000201090602" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: [rtcweb] SCTP for data channels in rtcweb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 15:28:49 -0000 This is a multi-part message in MIME format. --------------080306080700000201090602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/22/2011 3:53 AM, Randell Jesup wrote: > On 9/21/2011 7:45 AM, Hadriel Kaplan wrote: >> Just to make sure I'm on the same wavelength, you're talking about: >> 1) Defining PseudoTCP over UDP (a la libnice and jingle) for >> stream-oriented reliable data delivery. > > I would also consider SCTP-over-UDP in place of PseudoTCP-over-UDP for > reliable > data delivery. Similar arguments apply as for DCCP (solid > specification), and > in addition the FreeBSD implementation apparently supports > SCTP-over-UDP and is > very portable, so good working code is available to start. SCTP also > has other > benefits, like optional out-of-order delivery, and a datagram > ('message') orientation. I'm in touch with the SCTP-over-UDP draft authors, and received this: so you want a reliable and unreliable datagram service. You can use SCTP for both: 1. Standard SCTP/UDP for a reliable datagram service. 2. SCTP/UDP with the PR-SCTP extension and using a policy which doesn't do retransmissions. This is also implemented in the FreeBSD implementation and the derived ones, like the one for Mac OS X, Userspace and so on. There is also an RFC for running DTLS/SCTP which also applies to DTLS/SCTP/UDP to secure the traffic. We also have running code for it as you can get a patch for OpenSSL from http://sctp.fh-muenster.de/dtls-patches.html It has been submitted to the OpenSSL maintainers for inclusion in OpenSSL 1.0.1. Please let us know if you have any further question. So, overall this seems *very* promising - both in terms of a single framework to use for all the data channels (one interface/API, etc), existing congestion control (unfortunately TCP-like -- loss-based -- but oh well), and a working, open -over-UDP/-over-DTLS spec and implementation. I'd still love to tie the congestion control into the unified control we're looking at for the media streams, but I think we can make this work well even without that. -- Randell Jesup randell-ietf@jesup.org --------------080306080700000201090602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 9/22/2011 3:53 AM, Randell Jesup wrote:
On 9/21/2011 7:45 AM, Hadriel Kaplan wrote:
Just to make sure I'm on the same wavelength, you're talking about:
1) Defining PseudoTCP over UDP (a la libnice and jingle) for stream-oriented reliable data delivery.

I would also consider SCTP-over-UDP in place of PseudoTCP-over-UDP for reliable
data delivery.  Similar arguments apply as for DCCP (solid specification), and
in addition the FreeBSD implementation apparently supports SCTP-over-UDP and is
very portable, so good working code is available to start.  SCTP also has other
benefits, like optional out-of-order delivery, and a datagram ('message') orientation. 

I'm in touch with the SCTP-over-UDP draft authors, and received this:
so you want a reliable and unreliable datagram service. You can use SCTP for both:
1. Standard SCTP/UDP for a reliable datagram service.
2. SCTP/UDP with the PR-SCTP extension and using a policy which doesn't do
   retransmissions. This is also implemented in the FreeBSD implementation
   and the derived ones, like the one for Mac OS X, Userspace and so on.

There is also an RFC for running DTLS/SCTP which also applies to DTLS/SCTP/UDP
to secure the traffic. We also have running code for it as you can get a
patch for OpenSSL from
http://sctp.fh-muenster.de/dtls-patches.html
It has been submitted to the OpenSSL maintainers for inclusion in OpenSSL 1.0.1.

Please let us know if you have any further question.
So, overall this seems *very* promising - both in terms of a single framework to use
for all the data channels (one interface/API, etc), existing congestion control
(unfortunately TCP-like -- loss-based -- but oh well), and a working, open 
-over-UDP/-over-DTLS spec and implementation.

I'd still love to tie the congestion control into the unified control we're looking
at for the media streams, but I think we can make this work well even without that.


-- 
Randell Jesup
randell-ietf@jesup.org
--------------080306080700000201090602-- From john.elwell@siemens-enterprise.com Thu Sep 22 08:38: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 3870311E8081 for ; Thu, 22 Sep 2011 08:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.996 X-Spam-Level: X-Spam-Status: No, score=-102.996 tagged_above=-999 required=5 tests=[AWL=-0.397, 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 If5ZMZHI7CFN for ; Thu, 22 Sep 2011 08:38:01 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 82AB41F0C3C for ; Thu, 22 Sep 2011 08:38:00 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 862A923F044F; Thu, 22 Sep 2011 17:40:29 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 22 Sep 2011 17:40:29 +0200 From: "Elwell, John" To: "Olle E. Johansson" , Randell Jesup Date: Thu, 22 Sep 2011 17:40:28 +0200 Thread-Topic: [rtcweb] Forking & Early Media - Proposal Thread-Index: Acx4L8EqfqmFHuc/TySQHMO4P4PdvQBDUR/g Message-ID: References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2EB@ESESSCMS0356.eemea.ericsson.se> <1A61D589-1C23-4364-AA4A-60338D8C5859@edvina.net> <4E798D47.5030905@jesup.org> <1AD30F47-44DE-4D4E-8FC4-FA652212A050@edvina.net> In-Reply-To: <1AD30F47-44DE-4D4E-8FC4-FA652212A050@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 15:38:02 -0000 =20 > -----Original Message----- > From: rtcweb-bounces@ietf.org=20 > [mailto:rtcweb-bounces@ietf.org] On Behalf Of Olle E. Johansson > Sent: 21 September 2011 08:26 > To: Randell Jesup > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Forking & Early Media - Proposal >=20 > Randell, >=20 > If you want to go down this whole route and include all this=20 > application stuff in rtcweb, we might as well include all of=20 > SIP, because all of these issues have been worked on in the=20 > SIP world for a long time.=20 >=20 > Personally, I see rtcweb as a much lower layer than you do,=20 > which in my world excludes all this complexity. [JRE] I think the point that Randell was trying to make was that forking mi= ght be a requirement even for browser-to-browser calls. If so, what he prop= oses makes sense. If not, SIP entities (e.g., gateways) need to hide forkin= g, so that the RTC-Web environment doesn't need to take it into account. Ev= en then, I rather like Randell's idea of a speculative answer and separatin= g answer from accept, because the speculative answer can help to avoid clip= ping, which can give rise to user complaints. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. >=20 > SIP has been around for many years, and some of the=20 > discussion you bring to the table hasn't been solved yet or=20 > is poorly implemented in end points since they don't=20 > understand the complexity. I see no point in trying to solve=20 > all of that again with yet another signalling protocol. >=20 > We keep going back and forth on the signaling issue here - is=20 > it part of RTCweb? If yes, then we'll have forking, early=20 > media, DTMF and all that luggage including complex ISDN=20 > signalling scenarios that are just part of the German PSTN=20 > network and a requirement to have in RTCweb since it works in=20 > the ISDN. You'll have reqiuirements that the browse just HAS=20 > to support five different SIP Subscribe event packages - or=20 > the rtcweb version. >=20 > If we put signalling out of scope and let the application=20 > builder handle signaling and/or start a separate working=20 > group that can define "SIP lite" I believe we can make=20 > progress in rtcweb by focusing on a limited set of issues. >=20 > Darn. I feel like the old employee saying "we tried that=20 > years ago, it did not work." to kill all the inspired people=20 > that belive they can make a change. My apologies. Prove me wrong :-) >=20 > /O >=20 >=20 >=20 > 21 sep 2011 kl. 09:07 skrev Randell Jesup: >=20 > > NOTE: Attached below is a proposed set of forking/early-media > > and clipping-avoidance rules, so don't glance and delete! :-) > >=20 > > Also note: I started writing this earlier today, so it was largely > > done before much of today's discussion on forking. I'll note that > > I include in this a method to minimize chances of answer-time > > clipping. (For any who don't know (if there are any), this is > > where the first fraction of a second after pickup is lost while > > answering, starting codecs, doing ICE, etc.) > >=20 > >=20 > > On 9/20/2011 9:40 AM, Olle E. Johansson wrote: > >> 20 sep 2011 kl. 15:15 skrev Christer Holmberg: > >>=20 > >>>>> Once we start requiring that the PeerConnection know the > >>>>> difference between "early" media and "late" media, it seems > >>>>> to me we're slipping down a slippery slope. > >>>> The difference between early and late media is purely a > >>>> billing decision in PSTN. I don't think we should separate > >>>> these on the rtcweb side. It's a PSTN gateway issue, not > >>>> something to be bothered with in rtcweb. > >>> It's not about knowing the difference between "early" and=20 > "late" media - it's about whether the API and browser need to=20 > support multiple SIMULTANOUS SDP answers - or whether we=20 > assume that the JS SIP app will always, at any given time,=20 > only provide ONE SDP answer to the API and browser. > >> I just wanted to get rid of the early/late media=20 > discussion. As you state, the forking issue with getting=20 > multiple responses is a separate issue. > >>=20 > >> Do we have any use cases using forking? Is forking a=20 > desired feature or something that SIP brought in? > >=20 > > No, this is something inherent in a person you want to converse with > > possibly being in different places. Different phones in a home, > > different computers in a home or out of it (your desktop,=20 > your laptop, > > your tablet, your work computer, your Android phone) - when someone > > wants to talk to you on Skype or what have you, often the=20 > service will > > want to offer the connection to any and all devices you're=20 > logged into > > the service from. So, it forks the request. We'd have this issue > > even if we totally disallow SIP and disallow PSTN connectivity. If > > you require that the website/server handle this and only provide one > > answer, you're much more likely to clip the answer (lose audio right > > after accept while the channels are being opened). > >=20 > > Two things in particular appear here. One is early media (I want to > > send media to you but no one has accepted). I do not propose that > > rtcweb generate early media; some sort of "alerting" notification is > > enough (equivalent to 180). (Realize that means no custom callback > > tones or video, or weird cases like sitting on hold or in=20 > an IVR while > > not actually "in" a call). If so, we only have to worry=20 > about interop > > cases - calling out to legacy, or *maybe* a call forked in rtcweb > > where one of the forks goes to a legacy device or gateway that sends > > early media. > >=20 > > The other is choosing which answer to accept if multiple=20 > arrive; that > > can be up to the application I think (though 99% likely the app will > > want to use the first answer). I don't think we have to *mandate* > > that the first answer is the one we use though I can't think of any > > cases where we wouldn't, but I'm pretty sure they exist and=20 > I wouldn't > > want to outlaw them for no reason). If it makes any=20 > use-cases easier > > to mandate the first answer, that may change my opinion. If you're > > using SIP (JS or not) that might affect the answer, of course. > >=20 > > While waiting for an acceptance, it makes *lots* of sense=20 > to "warm up" > > the connection(s) so that when the call is accepted there's minimal > > delay or pickup loss. "warm up" means to do an ICE exchange and > > possibly even instantiate codecs, etc. This is complicated by not > > knowing the final answer until the user decides how to=20 > answer, but you > > could warm up the likely streams/codecs in most cases, and drop some > > if needed on ACCEPT. In the forking case, you could warm up > > connections to some or all possible answers. (Pacing may=20 > be an issue > > here, but often there are 5-20 seconds to do it in.) > >=20 > > Implicit in this is separating ANSWERs from "acceptance", and > > verifying on "acceptance" that the correct ANSWER is used (for > > example, we warm up audio and video, and the person answers > > audio-only, or for some reason chooses a different codec). > >=20 > >=20 > > So, to summarize in psuedo-spec language: > >=20 > > 0) I'm assuming an Offer-Answer model here, though not=20 > assuming SDP. > > If you want, read "SDP ANSWER" for "ANSWER", etc to map=20 > to Harald's > > proposals. Note that I add "ACCEPT". > > 0.1) Rough mapping to SIP: > > a) INVITE -> OFFER > > b) 183 -> ANSWER > > c) 180 -> ANSWER-with-no-media-streams > > c) 200 -> ANSWER (may be suppressed) + ACCEPT > > 0.2) I'm assuming OFFERs and ANSWERs and ACCEPTs are delivered on > > a reliable, in-order channel. > >=20 > > 1) webrtc clients WILL NOT send early media > > [See below; I see no real need for webrtc<->webrtc client=20 > connections > > to send early media, but SIP/PSTN interop cases may=20 > require it, so > > I have an alternative below] > > 2) when a webrtc client receives a OFFER, it MAY generate a=20 > speculative > > ANSWER in order to allow pre-starting the PeerConnection=20 > in a disabled > > state. If pre-started, NO media shall be sent until the=20 > call has been > > ACCEPTED. Note that the OFFERer may receive data before seeing > > the ACCEPT. > > 3) if the ANSWERer generated a speculative ANSWER, it may=20 > replace that > > with an alternative ANSWER before sending ACCEPT. This=20 > alternative > > SHOULD use the same connection address as the original, and if so > > the existing PeerConnection established or being=20 > established SHOULD > > be retained, but the mediastream configuration changed to match > > the new ANSWER. > > 4) the OFFERer SHOULD pre-start PeerConnections on a=20 > speculative ANSWER, or > > they MAY wait until an ACCEPT and then start the last=20 > ANSWER from that > > source. If multiple sources supply speculative ANSWERs,=20 > the OFFERer > > MAY pre-start some, none or all of them as it wishes. > > [Open question: do we pre-start MediaStreams in each pre-starting > > PeerConnection, or do (can) we defer this until ACCEPT?] > > 5) when the OFFERer receives an ACCEPT, it MAY close other=20 > PeerConnections > > opened speculatively. > > 6) when an ANSWERer sends an accept, it MAY begin sending=20 > media immediately > > if the PeerConnection was pre-started. It SHOULD be=20 > ready to receive > > media before sending the ACCEPT. > > 7) servers handling signalling for webrtc clients MAY fork=20 > a call offer > > to multiple webrtc clients > > 8) if a call is forked, the webrtc client MAY receive=20 > either a single > > ANSWER and ACCEPT, or MAY receive multiple ANSWERs with=20 > one or more > > ACCEPTs, depending on how the server works. > >=20 > > The provides a way to minimize the chances of start-of-call=20 > clipping, > > and handles forking with minimal clipping (with cooperation of the > > app). Note that there may be a implementation limit on the=20 > number of > > PeerConnections that can be "warmed up" before an ACCEPT. > >=20 > > Yes, if we remove 1) and replace it with (probably lower down) > >=20 > > N) webrtc clients MAY send "early media" on a pre-started=20 > PeerConnection > > but MUST NOT send any media without explicit action or=20 > consent of the > > user. webrtc clients MAY play the early media. > >=20 > > or > >=20 > > N) webrtc media gateways MAY send "early media" on a=20 > pre-started PeerConnection, > > and webrtc clients receiving "early media" MAY play it,=20 > and MAY send > > media (such as DTMF) but MUST NOT send any media without explicit > > action or consent of the user. > >=20 > > (and you have to change 2) above) > >=20 > > you get something that is pretty interoperable with legacy=20 > SIP devices > > and especially PSTN gateways or border controllers,=20 > including the infamous > > American Airlines DTMF trick. This assumes a=20 > WebRTC<->legacy media gateway > > is in use (note that all the above is about=20 > PeerConnections). I have not > > tried to figure out how non-gatewayed legacy would work=20 > into this, but it > > should be doable. > >=20 > >=20 > > --=20 > > Randell Jesup > > randell-ietf@jesup.org > >=20 > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > --- > * Olle E Johansson - oej@edvina.net > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > = From magnus.westerlund@ericsson.com Thu Sep 22 08:47: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 7F05D21F8B09 for ; Thu, 22 Sep 2011 08:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.526 X-Spam-Level: X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 AV9tY8LCRSs0 for ; Thu, 22 Sep 2011 08:47:42 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id ABFDC21F8B08 for ; Thu, 22 Sep 2011 08:47:41 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-30-4e7b593423f8 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 55.CD.20773.4395B7E4; Thu, 22 Sep 2011 17:50:12 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 17:50:13 +0200 Message-ID: <4E7B5932.9020800@ericsson.com> Date: Thu, 22 Sep 2011 17:50:10 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> <0C42CC63-CA1A-4F64-B522-BC1DAB477471@acmepacket.com> <4E7B2A65.6090106@ericsson.com> <4D8061B7-16C5-439C-8911-E4F2046999B7@acmepacket.com> In-Reply-To: <4D8061B7-16C5-439C-8911-E4F2046999B7@acmepacket.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "" , Colin Perkins Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 15:47:42 -0000 On 2011-09-22 15:34, Hadriel Kaplan wrote: > > On Sep 22, 2011, at 8:30 AM, Magnus Westerlund wrote: > >>> If the concern is just that the far-end is dead or terminated the >>> call but the local side didn't get the memo, we can solve that >>> other ways. >> >> On the last issue, do you have a suggestion for how to achieve this >> that isn't RTCP? > > If we assume that a gateway to legacy has to handle ICE termination > anyway, then it can send STUN indications during the call. The rtcweb > browser can use those to see the far end is alive and expecting media > on the 5-tuple. If we're worried about those being faked/spoofed by > malicious server/JS, we can modify the indication mechanism (which > could also allay ekr's concerns about consent refresh). Yes, the question is if the indications are sufficient as their security properties even when signed are a bit different from the STUN request with answer. > > >>> Yup. I don't doubt we'll need some form of media-plane gateway >>> either in the web server or separate to interop with legacy - >>> I'm just trying to keep it from becoming so expensive and >>> complicated that it would be cheaper/easier/better to use SIP >>> softclients or plugins instead. >>> >> >> I understand and support that we shouldn't have unnecessary >> complications for legacy interop. However, but I don't see it being >> done by compromising security to the level where RTCWEB can't be >> deployed even for browser to browser usage. > > Welllll... could we just require specific user consent for calls > to/from legacy? > No, I don't think so. The user is not capable of determining the difference between the two consent types. I am not certain that a random picked person on this very mailing list will be able to explain it and get agreement on the implications from the others in the first try. What we might have is some other security indications for some set of behaviors. But as the assumption discussion have showed it will not be easy. Having sounded quite negative, I still think it is worth spending some time discussing the trade-offs that can be made. But I rather error on the side of better security initially and then go back and change things if we realize that it can be done. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Sep 22 08:51: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 C29D521F8772 for ; Thu, 22 Sep 2011 08:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.527 X-Spam-Level: X-Spam-Status: No, score=-106.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 U3ZhJ1U5xmQR for ; Thu, 22 Sep 2011 08:51: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 020B021F8540 for ; Thu, 22 Sep 2011 08:51:54 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-a3-4e7b5a31dc6f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9C.64.02839.13A5B7E4; Thu, 22 Sep 2011 17:54:25 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Thu, 22 Sep 2011 17:54:25 +0200 Message-ID: <4E7B5A2F.8020102@ericsson.com> Date: Thu, 22 Sep 2011 17:54:23 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se><4E70D2E6.1000809@alvestrand.no><7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se><092401cc749b$8fd64940$af82dbc0$@com><4E765E4A.3050801@alvestrand.no><0ced01cc76de$28731630$79594290$@com> <4E77613B.4020805@ericsson.com> <1D062974A4845E4D8A343C6538049202066497EF@XMB-BGL-414.cisco.com> <4E784C38.2010909@ericsson.com> <1D062974A4845E4D8A343C65380492020672C04A@XMB-BGL-414.cisco.com> <4E7B2C04.401 0204@eri csson.com> <1D062974A4845E4D8A343C65380492020672C08F@XMB-BGL-414.cisco.com> <4E7B4F91.8090409@jesup.org> In-Reply-To: <4E7B4F91.8090409@jesup.org> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 15:51:56 -0000 On 2011-09-22 17:09, Randell Jesup wrote: > On 9/22/2011 10:00 AM, Muthu Arul Mozhi Perumal (mperumal) wrote: >> |Secondly, I think in those cases a timer on the inactivity |from >> both parties should be considered to terminate the session. >> >> If the timer is based on RTP inactivity it would terminate the >> session. If it is based on RTCP inactivity (which many >> implementations do) it wouldn't. > > There certainly may be use-cases where media in one (or both) > directions are inactive or DTX-muted for considerable periods of time > - remember, many of the use-cases (and unknown interesting future > uses) aren't "phone calls". > > In particular, I have some interesting use-cases bubbling in the back > of my brain where the data channel remains open at low/no activity > and the media channels are inactive or non-existant for long periods, > or where data traffic predominates and media are often inactive. > > Yes, I definitely believe you. Which only points that we will need to consider issues like how much background traffic that occurs just from having the PeerConnection up and being ready for sending media. Maybe mandate maximum levels when in practice inactive. It also has implication I think on the continued media consent. As the point raised Muthu is that when none sends media, there is in fact zero entropy in the RTCP RR compound packets. Thus RTCP can't be used for that. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From randell-ietf@jesup.org Thu Sep 22 09:46: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 8781C21F8BD3 for ; Thu, 22 Sep 2011 09:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 x75lunRTjy00 for ; Thu, 22 Sep 2011 09:46:39 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id C77B421F8B78 for ; Thu, 22 Sep 2011 09:46:39 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R6mSV-0000kS-Jt for rtcweb@ietf.org; Thu, 22 Sep 2011 11:49:11 -0500 Message-ID: <4E7B6635.6070308@jesup.org> Date: Thu, 22 Sep 2011 12:45:41 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> <4E77949B.4010603@alvestrand.no> <4E78A4FB.1050504@ericsson.com> <4E79AC33.4000900@alvestrand.no> <0075AB47-3DFF-4000-9057-CA0628DF711A@csperkins.org> <05D1C2F6-96C3-44E3-9FC2-AD2C893C9FC6@acmepacket.com> <4E7AE975.1010105@jesup.org> <4E7B53F0.6000807@jesup.org> In-Reply-To: <4E7B53F0.6000807@jesup.org> 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] SCTP for data channels in rtcweb X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 16:46:40 -0000 On 9/22/2011 11:27 AM, Randell Jesup wrote: > On 9/22/2011 3:53 AM, Randell Jesup wrote: >> On 9/21/2011 7:45 AM, Hadriel Kaplan wrote: >>> Just to make sure I'm on the same wavelength, you're talking about: >>> 1) Defining PseudoTCP over UDP (a la libnice and jingle) for >>> stream-oriented reliable data delivery. >> >> I would also consider SCTP-over-UDP in place of PseudoTCP-over-UDP >> for reliable >> data delivery. Similar arguments apply as for DCCP (solid >> specification), and >> in addition the FreeBSD implementation apparently supports >> SCTP-over-UDP and is >> very portable, so good working code is available to start. SCTP also >> has other >> benefits, like optional out-of-order delivery, and a datagram >> ('message') orientation. > > I'm in touch with the SCTP-over-UDP draft authors, and received this: > > so you want a reliable and unreliable datagram service. You can use SCTP for both: > 1. Standard SCTP/UDP for a reliable datagram service. > 2. SCTP/UDP with the PR-SCTP extension and using a policy which doesn't do > retransmissions. This is also implemented in the FreeBSD implementation > and the derived ones, like the one for Mac OS X, Userspace and so on. > > There is also an RFC for running DTLS/SCTP which also applies to DTLS/SCTP/UDP > to secure the traffic. We also have running code for it as you can get a > patch for OpenSSL from > http://sctp.fh-muenster.de/dtls-patches.html > It has been submitted to the OpenSSL maintainers for inclusion in OpenSSL 1.0.1. > > Please let us know if you have any further question. > > So, overall this seems *very* promising - both in terms of a single framework to use > for all the data channels (one interface/API, etc), existing congestion control > (unfortunately TCP-like -- loss-based -- but oh well), and a working, open > -over-UDP/-over-DTLS spec and implementation. They also inform me that there are alternative CC implementations in the BSD code, and the CC code it replaceable/overridable, so even better. > I'd still love to tie the congestion control into the unified control we're looking > at for the media streams, but I think we can make this work well even without that. > > > -- > Randell Jesup > randell-ietf@jesup.org > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb -- Randell Jesup randell-ietf@jesup.org From randell-ietf@jesup.org Thu Sep 22 09:51: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 2739D21F84D2 for ; Thu, 22 Sep 2011 09:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 7dKnlTbOVFLf for ; Thu, 22 Sep 2011 09:51:57 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9545621F84D9 for ; Thu, 22 Sep 2011 09:51:57 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R6mXd-0003j7-E9 for rtcweb@ietf.org; Thu, 22 Sep 2011 11:54:29 -0500 Message-ID: <4E7B6774.7040601@jesup.org> Date: Thu, 22 Sep 2011 12:51:00 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se><1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se><4E70D2E6.1000809@alvestrand.no><7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se><092401cc749b$8fd64940$af82dbc0$@com><4E765E4A.3050801@alvestrand.no><0ced01cc76de$28731630$79594290$@com> <4E77613B.4020805@ericsson.com> <1D062974A4845E4D8A343C6538049202066497EF@XMB-BGL-414.cisco.com> <4E784C38.2010909@ericsson.com> <1D062974A4845E4D8A343C65380492020672C04A@XMB-BGL-414.cisco.com> <4E7B2C04.401 0204@eri csson.com> <1D062974A4845E4D8A343C65380492020672C08F@XMB-BGL-414.cisco.com> <4E7B4F91.8090409@jesup.org> <4E7B5A2F.8020102@ericss on.com> In-Reply-To: <4E7B5A2F.8020102@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] consent freshness [was RE: STUN for keep-alive] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 16:51:58 -0000 On 9/22/2011 11:54 AM, Magnus Westerlund wrote: > On 2011-09-22 17:09, Randell Jesup wrote: >> There certainly may be use-cases where media in one (or both) >> directions are inactive or DTX-muted for considerable periods of time >> - remember, many of the use-cases (and unknown interesting future >> uses) aren't "phone calls". >> >> In particular, I have some interesting use-cases bubbling in the back >> of my brain where the data channel remains open at low/no activity >> and the media channels are inactive or non-existant for long periods, >> or where data traffic predominates and media are often inactive. > Yes, I definitely believe you. Which only points that we will need to > consider issues like how much background traffic that occurs just from > having the PeerConnection up and being ready for sending media. Maybe > mandate maximum levels when in practice inactive. > > It also has implication I think on the continued media consent. As the > point raised Muthu is that when none sends media, there is in fact zero > entropy in the RTCP RR compound packets. Thus RTCP can't be used for that. I wonder: could we create a default reliable data channel in all PeerConnections that's used (solely?) for a heartbeat/"consent freshness"? In that case, we get to define the heartbeat and can mandate enough entropy. (Receiving data on reliable SCTP (or TCP) over DTLS might be enough right there.) -- Randell Jesup randell-ietf@jesup.org From harald@alvestrand.no Thu Sep 22 10:35: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 A829D1F0C3D for ; Thu, 22 Sep 2011 10:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.778 X-Spam-Level: X-Spam-Status: No, score=-108.778 tagged_above=-999 required=5 tests=[AWL=1.821, 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 B7XHHGnM+6IF for ; Thu, 22 Sep 2011 10:35:24 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C29501F0C3C for ; Thu, 22 Sep 2011 10:35:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 186ED39E0AF; Thu, 22 Sep 2011 19:37:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4nt5RLWUitY; Thu, 22 Sep 2011 19:37:54 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 7C2DF39E098; Thu, 22 Sep 2011 19:37:54 +0200 (CEST) Message-ID: <4E7B7272.7020204@alvestrand.no> Date: Thu, 22 Sep 2011 19:37:54 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Cullen Jennings References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 17:35:24 -0000 On 09/22/11 15:44, Cullen Jennings wrote: > On Sep 21, 2011, at 2:22 AM, Magnus Westerlund wrote: > >> And why, did you design such a poor glare handling algorithm for SIP? ;-) > So, the SIP glare algorithm leaves much to be desired, no questions about it. I'm going to claim I was not there at the time until someone proves otherwise then switch my story to I was drunk not stupid. (in fairness we were trying to be backwards compatible with 2543 equipment). > > Anyways, I've been bouncing ideas around with folks on how we might improve the situation. Here is a proposal that might improve it for SIP and could also be leveraged by RTCWeb. > > First, to review the current situation, the current algorithm is: > > When two sides detect glare, they each pick a random integer from 1 to 10 and tell the other side to retry in that many seconds. two obvious problems with this: 1) it introduces, on average, over 7 seconds of delay which is a long time for a user 2) it has a non trivial chance of having glare a second time and needing to be repeat > > I'm proposing an extension that would go something like this: > > Both sides always include a random tie breaker number in their SDP that is used for glare resolution. If both sides support this and have the number, then glare is resolved by whoever has the lowest number. > > If neither side supports this, obviously the current things is what happens. > > if one side supports it but the other does not, the side that supports it tells the other side to retry after 0 seconds. So effectively it causes the other side to always "win" the tie and retry first. This reduces the latency of the glare resolution to the end user. The other side that does not support the new algorithm will still send a retry after some random number form 1 to 10 seconds. However, the side that supports this new mechanisms might want to decide that under some conditions, ti can short circuit that timer and retry sooner than that. It's not exactly clear to me when to short circuit this. Could it short circuit after receiving the retied transaction from the other side plus a one RTT delay? Could we just retry after 3 RTT or so knowing the other side won the race and was retying immediately? > > Even if the UA just runs out the full retry time, this algorithm still reduces the average delay significantly for cases where only one side supports it and gets really fast when both sides support it. > > Thoughts? > > I suspect this would need an SDP extension to carry the tie breaker number or even if we used an existing number, it seems like we still need something that indicates support for this new extension. > Seems like it could be a really short I-D, but definitely needs to be written up. Magnus' analysis worries me a bit, because it seems to assume specific functionality in the gateway (tracking of state and ability to generate SIP messages depending on state). It seems reasonably simple to build a gateway, but we quickly get to the point where we have to write standards for the gateway function .... which could lead us down rather deep ratholes. From ibc@aliax.net Thu Sep 22 11:18: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 9989221F8C5F for ; Thu, 22 Sep 2011 11:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 3kQ9txcdsPkH for ; Thu, 22 Sep 2011 11:18:30 -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 BA9441F0C65 for ; Thu, 22 Sep 2011 11:18:20 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so863945vcb.31 for ; Thu, 22 Sep 2011 11:20:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.9.129 with SMTP id l1mr642864vcl.87.1316715652597; Thu, 22 Sep 2011 11:20:52 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Thu, 22 Sep 2011 11:20:52 -0700 (PDT) In-Reply-To: <4E7B7272.7020204@alvestrand.no> References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> <4E7B7272.7020204@alvestrand.no> Date: Thu, 22 Sep 2011 20:20:52 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 18:18:30 -0000 2011/9/22 Harald Alvestrand : > Magnus' analysis worries me a bit, because it seems to assume specific > functionality in the gateway (tracking of state and ability to generate S= IP > messages depending on state). > It seems reasonably simple to build a gateway, but we quickly get to the > point where we have to write standards for the gateway function .... whic= h > could lead us down rather deep ratholes. Are we assuming that a media gateway will be required for RTP/media communication between a WebRTC client (web browser) and a SIP node? If such decision is taken IMHO it's sad. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Thu Sep 22 11:20: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 9BA6421F8C37 for ; Thu, 22 Sep 2011 11:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 OgvbP79MVb79 for ; Thu, 22 Sep 2011 11:20:59 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id E990421F8C36 for ; Thu, 22 Sep 2011 11:20:58 -0700 (PDT) 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 p8MIO0YY020390; Thu, 22 Sep 2011 14:24:00 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Sep 2011 14:22:59 -0400 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: Thu, 22 Sep 2011 23:52:49 +0530 Message-ID: <2E239D6FCD033C4BAF15F386A979BF510F0F58@sonusinmail02.sonusnet.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rtcweb] RTCWeb default signaling protocol [was RE: Aboutdefining a signaling protocol for WebRTC (or not)] Thread-Index: AQHMd1pqLHvBWHS2NkWGn3FMeQaTY5VZuBKQ References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com><05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> From: "Ravindran Parthasarathi" To: "Hadriel Kaplan" X-OriginalArrivalTime: 22 Sep 2011 18:22:59.0793 (UTC) FILETIME=[A87DC410:01CC7954] Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: Aboutdefining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 18:20:59 -0000 Hadriel, Please read inline. Thanks Partha >-----Original Message----- >From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >Sent: Tuesday, September 20, 2011 11:29 AM >To: Ravindran Parthasarathi >Cc: Roman Shpount; Randell Jesup; >Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: >Aboutdefining a signaling protocol for WebRTC (or not)] > > >On Sep 20, 2011, at 1:27 AM, Ravindran Parthasarathi wrote: > >> I agree with you in case you wish to have all class 5 services in this >architecture. In the web game server wherein the basic call has to be >established between two parties, this complexity is not required. > >OK, let's take the game example... only 2-player games would be able to >use a simple rtcweb-SIP agent. Anything more than 2-player would want >to use the multi-party "conferencing" model of rtcweb, which can't even >be signaled with SIP today as far as I can tell. (not that I've thought >about it too much, but I can't see how it would without some changes to >SIP) >=20 In fact rtcweb client shall acts as conference un-aware client in the conference model and game server acts as conference server. I have worked in 3-party conference using SIP in the endpoint but I have never seen endpoint acts as conference server. So, I may be missing something here > > >> One of the main aim of the RTCWeb default signaling protocol is to >make two party real-time communication easy with less development effort >for any web developer. > >Why doesn't using JS libraries provide that ease of development, >assuming there's a good "signaling agent" JS library for whatever >communication model the deployer wants/needs? If there isn't a good JS >library, then one would wonder why we think all browsers will have a >good built-in signaling agent instead. > The disadvantage with JS is that each server has to provide its own instance of JS library. It may be possible to have plugin instead of JS but it will defeat the purpose of RTCWeb charter. >-hadriel > > > > From fluffy@cisco.com Thu Sep 22 11:54: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 D6E9A21F8B9C for ; Thu, 22 Sep 2011 11:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.107 X-Spam-Level: X-Spam-Status: No, score=-103.107 tagged_above=-999 required=5 tests=[AWL=-0.508, 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 puk+jWvmxE-Z for ; Thu, 22 Sep 2011 11:54:42 -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 55A8A21F8B8E for ; Thu, 22 Sep 2011 11:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1962; q=dns/txt; s=iport; t=1316717834; x=1317927434; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=CXzNpQJmg78rIHx308y0kjVRq+Cd8oK2Gl8yHjHO6Wc=; b=dl2DdRq0XPT+jjTjiyG/qKPyYY+ywFJtMUWQehpuHzfU4DEikrujiLgC PJv41ZTDgLmepZs+8gsQqxHtrddYd8k3KixvIqO1xv/zv54m80UjCIpZg rIqgwtf+PukWF01wyi7I2+3IbT3H6Vp+nanCmsKFHxvJN4slpgR2aB1Xo I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOuEe06rRDoH/2dsb2JhbAA6CKgCeIFTAQEBAQIBEgEnPxALGC5XBjWHVpcXAZ4mg1iCRWAEh3GLX4UfjC8 X-IronPort-AV: E=Sophos;i="4.68,424,1312156800"; d="scan'208";a="3724505" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 22 Sep 2011 18:57: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 p8MIuxZt013829; Thu, 22 Sep 2011 18:56:59 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <57CCCB06-F4C3-4E23-AF09-B7B5285C5FAE@phonefromhere.com> Date: Thu, 22 Sep 2011 12:56:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> <57CCCB06-F4C3-4E23-AF09-B7B5285C5FAE@phonefromhere.com> To: Tim Panton X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 18:54:43 -0000 On Sep 22, 2011, at 7:57 AM, Tim Panton wrote: >=20 > On 22 Sep 2011, at 06:44, Cullen Jennings wrote: >=20 >>=20 >> On Sep 21, 2011, at 2:22 AM, Magnus Westerlund wrote: >>=20 >>> And why, did you design such a poor glare handling algorithm for = SIP? ;-) >>=20 >> So, the SIP glare algorithm leaves much to be desired, no questions = about it. I'm going to claim I was not there at the time until someone = proves otherwise then switch my story to I was drunk not stupid. (in = fairness we were trying to be backwards compatible with 2543 equipment). >=20 > Which is an important lesson for rtcweb, backward compatibility has = longterm costs. >=20 > At the risk of showing my ignorance - why are we expecting glare to be = a problem?=20 > To my mind glare only happens when you have a locked resource e.g. a = busy line > or number . Rtcweb does not contain either of those concepts, what's = the resource > that is being competed for here ? >=20 > Tim (speaking entirely for his own ignorance) Tim, it happens a fair amount in our playing around with browser = deployments. Imagine you and I both using browsers and have an audio = call set up. We are talking an I say "hey, lets, add video", then we = both go and push our "enable video" buttons at roughly the same time. In = this case we often get glare.=20 Part of the reasons is that the signaling path is not really fast as it = involves waiting for web servers to deal with sending notifications down = to other side. It's hard to guess what the signaling delay will be but = it easy to imagine that it will be over 200 ms in many cases and pretty = easy to imagine that both of use would would click the add video button = within 1/4 of second of each other.=20 The glare we are talking about here is any time browser A has sent an = SDP offer to the other side, but before A has received an SDP answer, = the other side sends A and SDP offer.=20 From roman@telurix.com Thu Sep 22 12:04: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 1717A1F0C63 for ; Thu, 22 Sep 2011 12:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.763 X-Spam-Level: X-Spam-Status: No, score=-2.763 tagged_above=-999 required=5 tests=[AWL=0.213, 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 yKAMrnrbdxmx for ; Thu, 22 Sep 2011 12:04:43 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCC11F0C3C for ; Thu, 22 Sep 2011 12:04:43 -0700 (PDT) Received: by iaby26 with SMTP id y26so3887677iab.31 for ; Thu, 22 Sep 2011 12:07:15 -0700 (PDT) Received: by 10.43.135.10 with SMTP id ie10mr2866041icc.91.1316718435223; Thu, 22 Sep 2011 12:07:15 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id ee29sm12262977ibb.9.2011.09.22.12.07.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 12:07:14 -0700 (PDT) Received: by yxt33 with SMTP id 33so2681253yxt.31 for ; Thu, 22 Sep 2011 12:07:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.36.232 with SMTP id t8mr5922353pbj.54.1316718432937; Thu, 22 Sep 2011 12:07:12 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Thu, 22 Sep 2011 12:07:12 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0F58@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F0F58@sonusinmail02.sonusnet.com> Date: Thu, 22 Sep 2011 15:07:12 -0400 Message-ID: From: Roman Shpount To: Ravindran Parthasarathi Content-Type: multipart/alternative; boundary=bcaec520e81776e6ae04ad8c6677 Cc: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: Aboutdefining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 19:04:44 -0000 --bcaec520e81776e6ae04ad8c6677 Content-Type: text/plain; charset=ISO-8859-1 Partha, I would consider the fact that each server has its own JS library a huge advantage -- each server needs to interop with its own library. If we want to add extensions, we can add them in the server and JS, and not worry about creating a new standard and going through an interop. _____________ Roman Shpount On Thu, Sep 22, 2011 at 2:22 PM, Ravindran Parthasarathi < pravindran@sonusnet.com> wrote: > Hadriel, > > Please read inline. > > Thanks > Partha > > >-----Original Message----- > >From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > >Sent: Tuesday, September 20, 2011 11:29 AM > >To: Ravindran Parthasarathi > >Cc: Roman Shpount; Randell Jesup; > >Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: > >Aboutdefining a signaling protocol for WebRTC (or not)] > > > > > >On Sep 20, 2011, at 1:27 AM, Ravindran Parthasarathi wrote: > > > >> I agree with you in case you wish to have all class 5 services in > this > >architecture. In the web game server wherein the basic call has to be > >established between two parties, this complexity is not required. > > > >OK, let's take the game example... only 2-player games would be able to > >use a simple rtcweb-SIP agent. Anything more than 2-player would want > >to use the multi-party "conferencing" model of rtcweb, which can't even > >be signaled with SIP today as far as I can tell. (not that I've thought > >about it too much, but I can't see how it would without some changes to > >SIP) > > > In fact rtcweb client shall acts as conference un-aware client > in the conference model and game server acts as conference server. I > have worked in 3-party conference using SIP in the endpoint but I have > never seen endpoint acts as conference server. So, I may be missing > something here > > > > > > >> One of the main aim of the RTCWeb default signaling protocol is to > >make two party real-time communication easy with less development > effort > >for any web developer. > > > >Why doesn't using JS libraries provide that ease of development, > >assuming there's a good "signaling agent" JS library for whatever > >communication model the deployer wants/needs? If there isn't a good JS > >library, then one would wonder why we think all browsers will have a > >good built-in signaling agent instead. > > > The disadvantage with JS is that each server has to provide its > own instance of JS library. It may be possible to have plugin instead of > JS but it will defeat the purpose of RTCWeb charter. > > >-hadriel > > > > > > > > > > --bcaec520e81776e6ae04ad8c6677 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Partha,

I would consider the fact that each server has its own JS li= brary a huge advantage -- each server needs to interop with its own library= . If we want to add extensions, we can add them in the server and JS, and n= ot worry about creating a new standard and going through an interop.
_____________
Roman Shpount


On Thu, Sep 22, 2011 at 2:22 PM, Ravindr= an Parthasarathi <pravindran@sonusnet.com> wrote:
Hadriel,

Please read inline.

Thanks
Partha

>-----Original Message-----
>From: Hadriel Kaplan [mailto:= HKaplan@acmepacket.com]
>Sent: Tuesday, September 20, 2011 11:29 AM
>To: Ravindran Parthasarathi
>Cc: Roman Shpount; Randell Jesup; <rtcweb@ietf.org>
>Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE:
>Aboutdefining a signaling protocol for WebRTC (or not)]
>
>
>On Sep 20, 2011, at 1:27 AM, Ravindran Parthasarathi wrote:
>
>> I agree with you in case you wish to have all class 5 services in<= br> this
>architecture. In the web game server wherein the basic call has to be >established between two parties, this complexity is not required.
>
>OK, let's take the game example... only 2-player games would be abl= e to
>use a simple rtcweb-SIP agent. =A0Anything more than 2-player would wan= t
>to use the multi-party "conferencing" model of rtcweb, which = can't even
>be signaled with SIP today as far as I can tell. (not that I've tho= ught
>about it too much, but I can't see how it would without some change= s to
>SIP)
>
<partha> In fact rtcweb client shall acts as conference un-aware clie= nt
in the conference model and game server acts as conference server. I
have worked in 3-party conference using SIP in the endpoint but I have
never seen endpoint acts as conference server. So, I may be missing
something here </partha>

>
>
>> One of the main aim of the RTCWeb default signaling protocol is to=
>make two party real-time communication easy with less development
effort
>for any web developer.
>
>Why doesn't using JS libraries provide that ease of development, >assuming there's a good "signaling agent" JS library for = whatever
>communication model the deployer wants/needs? =A0If there isn't a g= ood JS
>library, then one would wonder why we think all browsers will have a >good built-in signaling agent instead.
>
<partha>The disadvantage with JS is that each server has to provide i= ts
own instance of JS library. It may be possible to have plugin instead of JS but it will defeat the purpose of RTCWeb charter. </partha>

>-hadriel
>
>
>
>


--bcaec520e81776e6ae04ad8c6677-- From dzonatas@gmail.com Thu Sep 22 12:06: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 EC89521F85D1 for ; Thu, 22 Sep 2011 12:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.81 X-Spam-Level: X-Spam-Status: No, score=-3.81 tagged_above=-999 required=5 tests=[AWL=-0.211, 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 D5QPN9lFj9+M for ; Thu, 22 Sep 2011 12:06:53 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 284C521F853A for ; Thu, 22 Sep 2011 12:06:53 -0700 (PDT) Received: by yxt33 with SMTP id 33so2682984yxt.31 for ; Thu, 22 Sep 2011 12:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=p2KEJyC8QNoFYcYd88XfqMHv/NmGcvT48zjmJ2NB0iI=; b=IFOwzRFEkpGhSDoIzJQtODQ8pKZ9J4FKaNDGAZSwBnFel9jd2qtF5d4FgdhWi6x/qq yLPxjnls4xqNu8ET+fgnILYfMTo+pH8GpmkomEBIs9aa+KibJbjc755Uig/S8YYMOWCQ ta/PPby46xHUuRb6OiDxb5A4OlU+Yl5mQrbmI= Received: by 10.236.77.233 with SMTP id d69mr15851136yhe.84.1316718565250; Thu, 22 Sep 2011 12:09:25 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id x65sm12677976yhh.26.2011.09.22.12.09.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 12:09:24 -0700 (PDT) Message-ID: <4E7B886C.3060303@gmail.com> Date: Thu, 22 Sep 2011 12:11:40 -0700 From: Dzonatas Sol User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> <4E7B7272.7020204@alvestrand.no> In-Reply-To: <4E7B7272.7020204@alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 19:06:54 -0000 On 09/22/2011 10:37 AM, Harald Alvestrand wrote: > On 09/22/11 15:44, Cullen Jennings wrote: >> On Sep 21, 2011, at 2:22 AM, Magnus Westerlund wrote: >> >>> And why, did you design such a poor glare handling algorithm for >>> SIP? ;-) >> So, the SIP glare algorithm leaves much to be desired, no questions >> about it. I'm going to claim I was not there at the time until >> someone proves otherwise then switch my story to I was drunk not >> stupid. (in fairness we were trying to be backwards compatible with >> 2543 equipment). >> >> Anyways, I've been bouncing ideas around with folks on how we might >> improve the situation. Here is a proposal that might improve it for >> SIP and could also be leveraged by RTCWeb. >> >> First, to review the current situation, the current algorithm is: >> >> When two sides detect glare, they each pick a random integer from 1 >> to 10 and tell the other side to retry in that many seconds. two >> obvious problems with this: 1) it introduces, on average, over 7 >> seconds of delay which is a long time for a user 2) it has a non >> trivial chance of having glare a second time and needing to be repeat >> >> I'm proposing an extension that would go something like this: >> >> Both sides always include a random tie breaker number in their SDP >> that is used for glare resolution. If both sides support this and >> have the number, then glare is resolved by whoever has the lowest >> number. >> >> If neither side supports this, obviously the current things is what >> happens. >> >> if one side supports it but the other does not, the side that >> supports it tells the other side to retry after 0 seconds. So >> effectively it causes the other side to always "win" the tie and >> retry first. This reduces the latency of the glare resolution to the >> end user. The other side that does not support the new algorithm will >> still send a retry after some random number form 1 to 10 seconds. >> However, the side that supports this new mechanisms might want to >> decide that under some conditions, ti can short circuit that timer >> and retry sooner than that. It's not exactly clear to me when to >> short circuit this. Could it short circuit after receiving the retied >> transaction from the other side plus a one RTT delay? Could we just >> retry after 3 RTT or so knowing the other side won the race and was >> retying immediately? >> >> Even if the UA just runs out the full retry time, this algorithm >> still reduces the average delay significantly for cases where only >> one side supports it and gets really fast when both sides support it. >> >> Thoughts? >> >> I suspect this would need an SDP extension to carry the tie breaker >> number or even if we used an existing number, it seems like we still >> need something that indicates support for this new extension. >> > Seems like it could be a really short I-D, but definitely needs to be > written up. > > Magnus' analysis worries me a bit, because it seems to assume specific > functionality in the gateway (tracking of state and ability to > generate SIP messages depending on state). > It seems reasonably simple to build a gateway, but we quickly get to > the point where we have to write standards for the gateway function > .... which could lead us down rather deep ratholes. May seem like that for mobiles, and even for mobile applications even if the unit is stationary. I think we can talk about gateways easier than blackboxes, especially the kind that are mostly like on-board each future car and have relatively stationary apps (from concept car to "printed" driverless vehicles that rolls itself to destination of the build order). The initial roll-off: best done with nothing explosive, so we get into suspend-states and solid-states. Both lead to gateways, so my perspective is the browser on the gateway rather than the browser on the mobile. One can "key-in" much like "dial-in", so we can limit ICE here in this model within range of the gateway (on the wire). Capture the moment. If we clone that moment unto the next vehicle then do we worry if the same random number appears the same after suspend? Remember that the "power supply is suspended" yet there is energy from somewhere that completes this initial roll-off. Win? Maybe we can show the fuel icon with an estimated time until refueled again or... until next cybernetic "prime" because you know the-new-owner can than innovate rather than think about scalable self-assembly (i.e. ag), or at least on the run-way this looks more out in the open... for "observation" (as over 200,000 of these clones roll-off each day). Maybe the one ahead should help power the build for the one behind, the digital divide. -- --- The wheel. From ibc@aliax.net Thu Sep 22 12:13: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 EDC8811E808D for ; Thu, 22 Sep 2011 12:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 gqhzQ+u95Mgy for ; Thu, 22 Sep 2011 12:13:56 -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 53B3F11E8083 for ; Thu, 22 Sep 2011 12:13:56 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so914548vcb.31 for ; Thu, 22 Sep 2011 12:16:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.213.132 with SMTP id gw4mr677680vcb.52.1316718987268; Thu, 22 Sep 2011 12:16:27 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Thu, 22 Sep 2011 12:16:27 -0700 (PDT) In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0F58@sonusinmail02.sonusnet.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F0F58@sonusinmail02.sonusnet.com> Date: Thu, 22 Sep 2011 21:16:27 +0200 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: Randell Jesup , rtcweb@ietf.org Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: Aboutdefining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 19:13:57 -0000 2011/9/22 Ravindran Parthasarathi : > The disadvantage with JS is that each server has to provide its > own instance of JS library. And that's the magic of the WWW world: the fact that each provider is free to provide exactly what it needs. That leads to the success of the WWW and allows fast innovation. > It may be possible to have plugin instead of > JS but it will defeat the purpose of RTCWeb charter. A plugin like Flash, Java or ActiveX? sure we want that? --=20 I=C3=B1aki Baz Castillo From fluffy@cisco.com Thu Sep 22 12: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 9EAC011E809D for ; Thu, 22 Sep 2011 12:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.103 X-Spam-Level: X-Spam-Status: No, score=-103.103 tagged_above=-999 required=5 tests=[AWL=-0.504, 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 WuuzJ2s-Fln1 for ; Thu, 22 Sep 2011 12:26:59 -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 0D2A811E809A for ; Thu, 22 Sep 2011 12:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1580; q=dns/txt; s=iport; t=1316719771; x=1317929371; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=INf/q4PbOINKAbXAcw2uaNtU/PDKbTjcXeQ5YZzzqeA=; b=b33hr39cKi6uP2mv+OkDtVFsHLusD9C3y0eqVxjcesVVYV2gqVrAhxKc 3loHMIYz1ahfuPjCIPZS0n4Rl9SV0rCLz2Uu2xTWvU4EZu/YfKJ4FN4Bc gQ4MykCCpUTAcsYqPcFM8HVpie7WtPyKz6HWK+KTHhkFdaBIKEPpj5kUK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGKLe06rRDoG/2dsb2JhbABCqAJ4gVMBAQEBAgEBAQEPASc0CxALRicwBhMih1YGlxcBniyGHWAEh3GLX4UfjC8 X-IronPort-AV: E=Sophos;i="4.68,424,1312156800"; d="scan'208";a="3730070" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 22 Sep 2011 19:29:31 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8MJTUwf013610; Thu, 22 Sep 2011 19:29:30 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 22 Sep 2011 13:29:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5F7F4274-1AF6-4162-A177-51E1CDD0BCCD@cisco.com> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 19:26:59 -0000 In the past, we had too many ways of doing keep alive and it resulted in = poor interoperability when two sides choose different ways - I'd rather = avoid that sort of problem On Sep 14, 2011, at 3:48 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > Assuming we would use ICE for media authorization, it has been = indicated that, for legacy interoperability, a gateway would be required = in many cases (as the legacy entities might not support ICE). >=20 > ICE "bundles" functions together, meaning that if you use STUN for = media authorization purpose (which is a part of the connectivity check = purpose), you will also use STUN for keep-alive purpose (for UDP based = media). >=20 > My question is: would we be able to relax the requirement to use STUN = for keep-alive? Because, eventhough the keep-alives messages aren't = authenticated, and do not trigger responses, a gateway would still have = to process them, and since a gateway typically would serve a large = number of browser clients, that could have quite big performance impact = (the number of STUN keep-alives sent per session of course depend on how = much other media traffic there is, but still). >=20 > So, for RTP based media, one could use RTP, and for UDP based data = channels "dummy" UDP packets (unless there is a protocol on top of UDP = which provides a keep-alive mechanism itself). >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From matthew.kaufman@skype.net Thu Sep 22 12:31: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 5A8941F0C53 for ; Thu, 22 Sep 2011 12:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 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 pCWvsAwQK74N for ; Thu, 22 Sep 2011 12:31:15 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF951F0C3C for ; Thu, 22 Sep 2011 12:31:15 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 8DD2F170E; Thu, 22 Sep 2011 21:33:46 +0200 (CEST) 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=74SyqgQLzXiwZW FFa/1zFepd/0E=; b=vsf0k1ET81S74Y+OZCpvXpugGVEt0aJZdksSLjw2ZzHcjo yTQMb+6FA5iqu9C+bCtpcwWynOM9AysBONXTkTcIYYRBYkrHHLgFy0Q1qQdUgYMM jG2KRa5xSmp6b5xP8IfAbB3fXJasJo7JDZGH0p9VNMGKig4Nw/0mwCuXloIKQ= 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=XDCCcVe0W82rYEc5cRTW8L 9tc/j9QhxqNf/ShegZzl8B+jD95SAFKv5txBp4roEcaybratj5cDV0v7inxzPIMW k/h2sCYt4OY5Soc6UJEMVUEJm9nRqU5vDOzdCLJFKWA+AkQkz31797GEOQRqe1D9 t4uLKKxzbVNkvtKUU6UoY= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 8C1467F6; Thu, 22 Sep 2011 21:33:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 65C731678D03; Thu, 22 Sep 2011 21:33:46 +0200 (CEST) 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 faoXXTRzwwkJ; Thu, 22 Sep 2011 21:33:45 +0200 (CEST) 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 BF1BD1678D02; Thu, 22 Sep 2011 21:33:44 +0200 (CEST) Message-ID: <4E7B8D9D.8060303@skype.net> Date: Thu, 22 Sep 2011 12:33:49 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Cullen Jennings References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> <57CCCB06-F4C3-4E23-AF09-B7B5285C5FAE@phonefromhere.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 19:31:16 -0000 On 9/22/11 11:56 AM, Cullen Jennings wrote: > Tim, it happens a fair amount in our playing around with browser > deployments. You make my own arguments for me. > Imagine you and I both using browsers and have an audio call set up. Sounds great. And the web server has sent down some javascript that was able to query the capabilities and so it knows which audio and video codecs are supported at each end, even before the audio call started. > We are talking an I say "hey, lets, add video", then we both go and > push our "enable video" buttons at roughly the same time. Also good. > In this case we often get glare. You shouldn't. Each side is asking the server to tell the other end to start sending video, and the server knows what codecs and parameters will work, so there's no overlap at all. > Part of the reasons is that the signaling path is not really fast as > it involves waiting for web servers to deal with sending notifications > down to other side. It's hard to guess what the signaling delay will > be but it easy to imagine that it will be over 200 ms in many cases > and pretty easy to imagine that both of use would would click the add > video button within 1/4 of second of each other. The glare we are > talking about here is any time browser A has sent an SDP offer to the > other side, but before A has received an SDP answer, the other side > sends A and SDP offer. See, that's the problem. IF there are SDP offers and answers, they shouldn't be tied to the peer connection object, they should be tied to the objects that represent the devices... that way you would have two separate offer/answer happening, one for each direction. And if you *weren't* using offer/answer, but had instead collected the capabilities ahead of time, then the server could just immediately tell each end to start sending. So instead of a 200 msec delay *and* the risk of glare, you'd have zero delay *and* zero chance of glare. Matthew Kaufman From Michael.Tuexen@lurchi.franken.de Thu Sep 22 12:34: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 D09B51F0C63 for ; Thu, 22 Sep 2011 12:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=0.254, 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 SgtNuhy-PO6p for ; Thu, 22 Sep 2011 12:34:57 -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 219CA1F0C3C for ; Thu, 22 Sep 2011 12:34:56 -0700 (PDT) Received: from [192.168.1.195] (p5481AD2B.dip.t-dialin.net [84.129.173.43]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 142B31C0C0BD6; Thu, 22 Sep 2011 21:37:27 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <5F7F4274-1AF6-4162-A177-51E1CDD0BCCD@cisco.com> Date: Thu, 22 Sep 2011 21:37:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9BC49EB9-A690-4ED2-B0E5-76BC0730A4C5@lurchi.franken.de> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <5F7F4274-1AF6-4162-A177-51E1CDD0BCCD@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] STUN for keep-alive X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 19:34:57 -0000 On Sep 22, 2011, at 9:29 PM, Cullen Jennings wrote: >=20 > In the past, we had too many ways of doing keep alive and it resulted = in poor interoperability when two sides choose different ways - I'd = rather avoid that sort of problem >=20 > On Sep 14, 2011, at 3:48 AM, Christer Holmberg wrote: >=20 >>=20 >> Hi, >>=20 >> Assuming we would use ICE for media authorization, it has been = indicated that, for legacy interoperability, a gateway would be required = in many cases (as the legacy entities might not support ICE). >>=20 >> ICE "bundles" functions together, meaning that if you use STUN for = media authorization purpose (which is a part of the connectivity check = purpose), you will also use STUN for keep-alive purpose (for UDP based = media). >>=20 >> My question is: would we be able to relax the requirement to use STUN = for keep-alive? Because, eventhough the keep-alives messages aren't = authenticated, and do not trigger responses, a gateway would still have = to process them, and since a gateway typically would serve a large = number of browser clients, that could have quite big performance impact = (the number of STUN keep-alives sent per session of course depend on how = much other media traffic there is, but still). >>=20 >> So, for RTP based media, one could use RTP, and for UDP based data = channels "dummy" UDP packets (unless there is a protocol on top of UDP = which provides a keep-alive mechanism itself). ... if you run DTLS/UDP, DTLS provides a HB mechanism: http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-02 Best regards Michael >>=20 >> Regards, >>=20 >> Christer >>=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 From christer.holmberg@ericsson.com Thu Sep 22 12: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 9A2DE21F8B52 for ; Thu, 22 Sep 2011 12:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_52=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 WQgqqLYutLYv for ; Thu, 22 Sep 2011 12:38: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 B458A21F8B53 for ; Thu, 22 Sep 2011 12:38:50 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-cb-4e7b8f5c5af9 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5C.47.02839.C5F8B7E4; Thu, 22 Sep 2011 21:41:16 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 22 Sep 2011 21:41:16 +0200 From: Christer Holmberg To: 'Hadriel Kaplan' , Cullen Jennings Date: Thu, 22 Sep 2011 21:41:15 +0200 Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism Thread-Index: AQHMd+W4GbLdjZqw9U+hWOGtS5YVCZVZys0g Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45FB9@ESESSCMS0356.eemea.ericsson.se> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> In-Reply-To: <6916F9BA-3296-46DD-9F06-01E3928A8184@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 19:38:51 -0000 Hi,=20 >> That said, I think that doing both forking and early media is hard. Lets= assume we are using a signaling gateway that is not a media gateway to tra= nslate between a SIP call on one side and whatever is happening over on the= browser=20 >>de. The basic issue is the browser initiating the communications needs to= be able to start receiving multiple RTP streams before it even has signali= ng information to tell it how many it might receive. > >Not really - there will be signaling, because there has to be SDP answers = even just to get ICE to work before the media starts flowing in many NAT ca= ses. And even in practice in SIP there're usually SDP answers in 18x to op= en=20 >"gates", and to get upstream DTMF. So if the concern is just that there's= no signaling to tell the browser there are multiple RTP streams coming, I = think that can be allayed. =20 > >The really hard part is knowing which stream to use/render/send-to, imho. = And putting that decision in the gateway isn't good - the best decider of = that is probably the JS in the browser. I am not sure whether the JS app would be able to make better decisions tha= n the gateway - and I've never seen a SIP client which would allow the user= to choose which early media to listen to.=20 And, sometimes SBGs, eventhough they allow multiple early dialogs to pass t= owards the user, still only allow media associted with one of the early dia= logs to pass. In my opinion the best thing would be if we could come up with some common = BCP, e.g. saying that media associated with the early dialog on which the l= atest SDP answer was received is considered "active", and will be presented= to the user etc.=20 Or something like that... The network will then have to make sure that SDP answers are forwarded towa= rds the user in a way that the "correct" media will be accepted and present= ed. That was, once again, my input for the annual how-to-support-early-media de= bate :) >>To simplify this problem, Cary and my draft proposes not allowing forking= on the SIP side of the signaling gateway but still allowing early media. I= f you wanted to do do forking in this case, one would need a SBC that proce= ssed=20 >>media and turned the forked medial legs into one media leg.=20 > >Obviously you can request that a request not be forked, using caller-prefs= , but you can't "not allow" forking on the SIP side. That would make it no= t SIP. I know forking is hard, but that's life. It's not appropriate for = this WG=20 >to make fundamental changes/limitations to the SIP protocol, just because = some of it's "hard" for a browser.=20 We need to keep in mind that supporting forking and supporting media from m= ultiple locations are two different things, and I think we need to be very = clear about what we mean when discussing. Regards, Christer From christer.holmberg@ericsson.com Thu Sep 22 12:45: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 5977421F8B64 for ; Thu, 22 Sep 2011 12:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=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 nY6gI4PZQkCM for ; Thu, 22 Sep 2011 12:45: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 A8BF021F8B5E for ; Thu, 22 Sep 2011 12:45:30 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f3-4e7b90f241d8 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F1.71.20773.2F09B7E4; Thu, 22 Sep 2011 21:48:02 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 22 Sep 2011 21:48:02 +0200 From: Christer Holmberg To: 'Roman Shpount' , Ravindran Parthasarathi Date: Thu, 22 Sep 2011 21:48:00 +0200 Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism Thread-Index: Acx4BRN+GpUfNoLrTvGpLg90/8yu1gBWwc+w Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45FBA@ESESSCMS0356.eemea.ericsson.se> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF510F0E5E@sonusinmail02.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: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852233D45FBAESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 19:45:32 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852233D45FBAESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >I would consider it very unfortunate if we decide not to support forking i= n RTC. It needs to be handled, and not in signaling, but by defining what t= o do with multiple incoming media RTP streams and multiple answers. The sim= plest model would be ignore everything except the RTP media defined in the = last >answer and have an ability to update the answer to the last offer. Correct. >Alternative would be to create a new PeerConnection based on a new answer = (this is API change so should probably go to W3C). This is one of the things that maybe should be put in the "nice to have in = a later release" bucket :) Regards, Christer On Tue, Sep 20, 2011 at 10:11 PM, Ravindran Parthasarathi > wrote: Forking in SIP does not apply in the literal sense to lot of SIP applications (ISDN-SIP gateway, End-point which can't perform mixing). In case of ISDN-SIP gateway, SIP callleg has to handle all forked dialogs till 200 OK is received from anyone of the UAS and reject all other dialogs with CANCEL, the media plane update is depend upon the implementation whether to override the last SDP in media plane in case mixing is not possible. I'm saying in this mail thread to highlight forking handling in browser (as a SIP UA application) is not an exception and it is the decision which has to be taken by any SIP application development (and not SIP framework) for that matter. SIP application forking behavior depends upon RTP model (endpoint or mixer). In case browser acts only as endpoint, I agree with Cullen that forking shall be handled by browser without application aware and no need of API or callback. The counter argument may be that my innovative mixing application in browser is stopped by this API model. In the generic SIP framework, the callbacks are provided to handle this situation, default callback function (browser as endpoint) are provided to reduce the application awareness. From the API perspective, offer & answer state machine is not required to be handled in application but we required to know whether the application prefers which media model whether as end-point or mixer and let end-point model be default. IMO, it is browser API design which belongs to W3C. Please correct me here in case this API design is somehow related to IETF. Thanks Partha >-----Original Message----- >From: rtcweb-bounces@ietf.org [mailto:rtcw= eb-bounces@ietf.org] On Behalf >Of Hadriel Kaplan >Sent: Wednesday, September 21, 2011 4:06 AM >To: Cullen Jennings >Cc: rtcweb@ietf.org >Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP >negotiation mechanism > > >On Sep 20, 2011, at 4:07 PM, Cullen Jennings wrote: > >> That said, I think that doing both forking and early media is hard. >Lets assume we are using a signaling gateway that is not a media gateway >to translate between a SIP call on one side and whatever is happening >over on the browser side. The basic issue is the browser initiating the >communications needs to be able to start receiving multiple RTP streams >before it even has signaling information to tell it how many it might >receive. > >Not really - there will be signaling, because there has to be SDP >answers even just to get ICE to work before the media starts flowing in >many NAT cases. And even in practice in SIP there're usually SDP >answers in 18x to open "gates", and to get upstream DTMF. So if the >concern is just that there's no signaling to tell the browser there are >multiple RTP streams coming, I think that can be allayed. > >The really hard part is knowing which stream to use/render/send-to, >imho. And putting that decision in the gateway isn't good - the best >decider of that is probably the JS in the browser. > > >> To simplify this problem, Cary and my draft proposes not allowing >forking on the SIP side of the signaling gateway but still allowing >early media. If you wanted to do do forking in this case, one would need >a SBC that processed media and turned the forked medial legs into one >media leg. > >Obviously you can request that a request not be forked, using caller- >prefs, but you can't "not allow" forking on the SIP side. That would >make it not SIP. I know forking is hard, but that's life. It's not >appropriate for this WG to make fundamental changes/limitations to the >SIP protocol, just because some of it's "hard" for a browser. > >-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 --_000_7F2072F1E0DE894DA4B517B93C6A05852233D45FBAESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

<= SPAN=20 class=3D913554419-22092011>>I would consider it very unfortunate if we decid= e not=20 to support forking in RTC. It needs to be handled, and not in signaling, bu= t by=20 defining what to do with multiple incoming media RTP streams and multiple=20 answers. The simplest model would be ignore everything except the RTP media= =20 defined in the last  
>answer and have an ability to update the answer = to the=20 last offer. 
 
Correct.
 
>Alternative would be to create a new= =20 PeerConnection based on a new answer (this is API change so should probably= go=20 to W3C). 
 
This= is one of=20 the things that maybe should be put in the "nice to have in a later=20 release" bucket :)
 
Regards,
 
Christer
 

 
On Tue, Sep 20, 2011 at 10:11 PM, Ravindran Partha= sarathi=20 <pravindran@sonusnet.com>=20 wrote:
Forking=20 in SIP does not apply in the literal sense to lot of SIP
applications= =20 (ISDN-SIP gateway, End-point which can't perform mixing).
In case of=20 ISDN-SIP gateway, SIP callleg has to handle all forked
dialogs till 20= 0 OK=20 is received from anyone of the UAS and reject all
other dialogs with=20 CANCEL, the media plane update is depend upon the
implementation wheth= er to=20 override the last SDP in media plane in case
mixing is not possible. I= 'm=20 saying in this mail thread to highlight
forking handling in browser (a= s a=20 SIP UA application) is not an
exception and it is the decision which h= as to=20 be taken by any SIP
application development (and not SIP framework) fo= r=20 that matter.

SIP application forking behavior depends upon RTP mod= el=20 (endpoint or
mixer). In case browser acts only as endpoint, I agree wi= th=20 Cullen that
forking shall be handled by browser without application aw= are=20 and no
need of API or callback.

The counter argument may be tha= t my=20 innovative mixing application in
browser is stopped by this API model.= =20  In the generic SIP framework, the
callbacks are provided to hand= le=20 this situation, default callback
function (browser as endpoint) are=20 provided to reduce the application
awareness. From the API perspective= ,=20 offer & answer state machine is not
required to be handled in=20 application but we required to know whether
the application prefers wh= ich=20 media model whether as end-point or mixer
and let end-point model be=20 default. IMO, it is browser API design which
belongs to W3C. Please co= rrect=20 me here in case this API design is
somehow related to=20 IETF.

Thanks
Partha

>-----Original=20 Message-----
>From: rtcweb-bounces@ietf.org [mail= to:rtcweb-bounces@ietf.org]=20 On
Behalf
>Of Hadriel Kaplan
>Sent: Wednesday, September 2= 1,=20 2011 4:06 AM
>To: Cullen Jennings
>Cc: rtcweb@ietf.org
>Subject: Re: [= rtcweb]=20 Forking & Early Media - Was Re: Minimal SDP
>negotiation=20 mechanism
>
>
>On Sep 20, 2011, at 4:07 PM, Cullen Jenn= ings=20 wrote:
>
>> That said, I think that doing both forking and= =20 early media is hard.
>Lets assume we are using a signaling gateway = that=20 is not a media
gateway
>to translate between a SIP call on one s= ide=20 and whatever is happening
>over on the browser side. The basic issu= e is=20 the browser initiating the
>communications needs to be able to star= t=20 receiving multiple RTP streams
>before it even has signaling inform= ation=20 to tell it how many it might
>receive.
>
>Not really - = there=20 will be signaling, because there has to be SDP
>answers even just t= o get=20 ICE to work before the media starts flowing in
>many NAT cases.=20  And even in practice in SIP there're usually SDP
>answers in = 18x=20 to open "gates", and to get upstream DTMF.  So if the
>concern= is=20 just that there's no signaling to tell the browser there are
>multi= ple=20 RTP streams coming, I think that can be allayed.
>
>The reall= y=20 hard part is knowing which stream to use/render/send-to,
>imho.=20  And putting that decision in the gateway isn't good - the=20 best
>decider of that is probably the JS in the=20 browser.
>
>
>> To simplify this problem, Cary and m= y=20 draft proposes not allowing
>forking on the SIP side of the signali= ng=20 gateway but still allowing
>early media. If you wanted to do do for= king=20 in this case, one would
need
>a SBC that processed media and tur= ned=20 the forked medial legs into one
>media leg.
>
>Obviousl= y you=20 can request that a request not be forked, using caller-
>prefs, but= you=20 can't "not allow" forking on the SIP side.  That would
>make i= t not=20 SIP.  I know forking is hard, but that's life.  It's=20 not
>appropriate for this WG to make fundamental changes/limitation= s to=20 the
>SIP protocol, just because some of it's "hard" for a=20 browser.
>
>-hadriel
>
>_________________________= ______________________
>rtcweb=20 mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb
_____= __________________________________________
rtcweb=20 mailing list
rtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb

--_000_7F2072F1E0DE894DA4B517B93C6A05852233D45FBAESESSCMS0356e_-- From fluffy@cisco.com Thu Sep 22 12: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 15C5A21F8B9E for ; Thu, 22 Sep 2011 12:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.948 X-Spam-Level: X-Spam-Status: No, score=-102.948 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, 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 cgYO1OanIWwz for ; Thu, 22 Sep 2011 12:48:42 -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 9E51721F8B5F for ; Thu, 22 Sep 2011 12:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=975; q=dns/txt; s=iport; t=1316721075; x=1317930675; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4HHYkih41Cipyg4/ENXt1AnwJS/BBUidSpTWm0BJcJY=; b=CIUoOxUoGiYNKtL5YsjLOkq6kKzkZdntjKTEZSuGXTFodiZGj/EGCy+P kEAwYa5Tgdh3QlB8OgAY4i5sKCip0aAVtRxb59EDsLJfm4+UUGjkmdrSi r60eGGJjvLsG4ACOTTBQfWuZgBKOa8eO2kSoGsFcnFS8Ly4tnXpbCzTee E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEaRe06rRDoH/2dsb2JhbABCqAJ4gVMBAQEBAgESAWYFCwtGVwYTGweHVpcYAZ4shh1gBIdxi1+FH4wv X-IronPort-AV: E=Sophos;i="4.68,425,1312156800"; d="scan'208";a="3743717" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 22 Sep 2011 19:51:15 +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 p8MJpDT3010674; Thu, 22 Sep 2011 19:51:13 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Thu, 22 Sep 2011 13:51:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <18FFF339-E7EB-4EEB-BCD8-E6728A56A24A@cisco.com> References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> <4E7B7272.7020204@alvestrand.no> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 19:48:43 -0000 On Sep 22, 2011, at 12:20 PM, I=F1aki Baz Castillo wrote: > 2011/9/22 Harald Alvestrand : >> Magnus' analysis worries me a bit, because it seems to assume = specific >> functionality in the gateway (tracking of state and ability to = generate SIP >> messages depending on state). >> It seems reasonably simple to build a gateway, but we quickly get to = the >> point where we have to write standards for the gateway function .... = which >> could lead us down rather deep ratholes. >=20 > Are we assuming that a media gateway will be required for RTP/media > communication between a WebRTC client (web browser) and a SIP node? > If such decision is taken IMHO it's sad. My take is that most people want to make sure that a translator between = SIP and web stuff would only need to look at signalling - it would not = touch the media. I'm working on the asumption that is what any solution = will look like. So, no media GW.=20 From ibc@aliax.net Thu Sep 22 12:50: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 2986C21F8BC4 for ; Thu, 22 Sep 2011 12:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, 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 V5oLu49Jk9g3 for ; Thu, 22 Sep 2011 12:50: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 0BF9221F8BBF for ; Thu, 22 Sep 2011 12:50:30 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so948525vcb.31 for ; Thu, 22 Sep 2011 12:53:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.213.132 with SMTP id gw4mr690162vcb.52.1316721183099; Thu, 22 Sep 2011 12:53:03 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Thu, 22 Sep 2011 12:53:02 -0700 (PDT) In-Reply-To: <18FFF339-E7EB-4EEB-BCD8-E6728A56A24A@cisco.com> References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> <4E7B7272.7020204@alvestrand.no> <18FFF339-E7EB-4EEB-BCD8-E6728A56A24A@cisco.com> Date: Thu, 22 Sep 2011 21:53:02 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 19:50:32 -0000 2011/9/22 Cullen Jennings : > My take is that most people want to make sure that a translator between S= IP and web stuff would only need to look at signalling - it would not touch= the media. I'm working on the asumption that is what any solution will loo= k like. So, no media GW. Yes please :) Thanks a lot. --=20 I=C3=B1aki Baz Castillo From fluffy@cisco.com Thu Sep 22 12:51: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 F319321F8BC4 for ; Thu, 22 Sep 2011 12:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.093 X-Spam-Level: X-Spam-Status: No, score=-103.093 tagged_above=-999 required=5 tests=[AWL=-0.494, 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 zZZV4OR56Eft for ; Thu, 22 Sep 2011 12:51:20 -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 4405621F8BBF for ; Thu, 22 Sep 2011 12:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2357; q=dns/txt; s=iport; t=1316721232; x=1317930832; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tqMSpbYX4ML4MY6sL16eUjU9/zywkQtkog+MLTbngeY=; b=Cx+tJxdfuk/ACaGX+0TU1gjf2DTzZ4MfC0JXAxZTccW9y8HyInIjYymm mplwyuPEth3+agc8cYoBrGnftp76Q+HBZW81+k5Hdy8eGGAiY2MjP18fe 4uLuDR++ghmAn+8/FJnVGzazvKYbpcE4KnnTj0Ppp30UYRHTw1goOehpm Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEaRe06rRDoI/2dsb2JhbABCqAJ4gVMBAQEBAgESASc/BQsLGC5XBjWHVpcYAZ4shh1gBIdxi1+FH4wv X-IronPort-AV: E=Sophos;i="4.68,425,1312156800"; d="scan'208";a="3744075" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 22 Sep 2011 19:53:52 +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 p8MJrp00006326; Thu, 22 Sep 2011 19:53:52 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4E7B8D9D.8060303@skype.net> Date: Thu, 22 Sep 2011 13:53:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <46B4E074-69C8-4B25-8348-F6951FF9725F@cisco.com> References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> <57CCCB06-F4C3-4E23-AF09-B7B5285C5FAE@phonefromhere.com> <4E7B8D9D.8060303@skype.net> To: Matthew Kaufman X-Mailer: Apple Mail (2.1084) Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 19:51:21 -0000 Could you'd like to elaborate on how it works when one of the sides is = an SIP endpoint, or we the two endpoint are at different domains that = are federated? On Sep 22, 2011, at 1:33 PM, Matthew Kaufman wrote: > On 9/22/11 11:56 AM, Cullen Jennings wrote: >> Tim, it happens a fair amount in our playing around with browser = deployments. >=20 > You make my own arguments for me. >=20 >> Imagine you and I both using browsers and have an audio call set up.=20= >=20 > Sounds great. And the web server has sent down some javascript that = was able to query the capabilities and so it knows which audio and video = codecs are supported at each end, even before the audio call started. >=20 >> We are talking an I say "hey, lets, add video", then we both go and = push our "enable video" buttons at roughly the same time. >=20 > Also good. >=20 >> In this case we often get glare.=20 >=20 > You shouldn't. >=20 > Each side is asking the server to tell the other end to start sending = video, and the server knows what codecs and parameters will work, so = there's no overlap at all. >=20 >> Part of the reasons is that the signaling path is not really fast as = it involves waiting for web servers to deal with sending notifications = down to other side. It's hard to guess what the signaling delay will be = but it easy to imagine that it will be over 200 ms in many cases and = pretty easy to imagine that both of use would would click the add video = button within 1/4 of second of each other. The glare we are talking = about here is any time browser A has sent an SDP offer to the other = side, but before A has received an SDP answer, the other side sends A = and SDP offer. >=20 > See, that's the problem. >=20 > IF there are SDP offers and answers, they shouldn't be tied to the = peer connection object, they should be tied to the objects that = represent the devices... that way you would have two separate = offer/answer happening, one for each direction. >=20 > And if you *weren't* using offer/answer, but had instead collected the = capabilities ahead of time, then the server could just immediately tell = each end to start sending. >=20 > So instead of a 200 msec delay *and* the risk of glare, you'd have = zero delay *and* zero chance of glare. >=20 > Matthew Kaufman >=20 From matthew.kaufman@skype.net Thu Sep 22 12:57: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 7C09C1F0C46 for ; Thu, 22 Sep 2011 12:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.713 X-Spam-Level: X-Spam-Status: No, score=-5.713 tagged_above=-999 required=5 tests=[AWL=0.886, 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 ZFK2Q0AvrL0K for ; Thu, 22 Sep 2011 12:57:29 -0700 (PDT) Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id D0CCD1F0C3C for ; Thu, 22 Sep 2011 12:57:28 -0700 (PDT) Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 4DA03170E; Thu, 22 Sep 2011 21:59:59 +0200 (CEST) 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=PEA2ObTBPpjNSN A+gOJrnxlpPoM=; b=ugI/+XX5j3wiNmvULG7xgh45tOrAKttiTmdYfJvefNLh6U mWssiay39gZc0dGgJz17V6sKlq+ZdpQOaYCKGnh3QEWB0SbqvpMjJTakl+iEgCjb 7iNo3rtDTD9GMHa8H6Pda73ZWi2fNU/FLQ7JRCYQwaa2dOLPKfnqFXqG4maJU= 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=gwG6023K00hahzcA30rws2 WkJEzpDGNIpBEVsE14vA8KqGWd3Fc7yBD//4Cfga1jCLA60pjnSMRnypBo1nRKMW rC2UOL/ERUKl8qZ2biKe0Uqksq/CKu7DMF08mC/Cv6qIuAKdyktoVYDMkF7YZS0t 6CEjL/6ImHebT56kn+Mas= Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 4C0427F6; Thu, 22 Sep 2011 21:59:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 271B01678D03; Thu, 22 Sep 2011 21:59:59 +0200 (CEST) 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 Whesn3S0XGUr; Thu, 22 Sep 2011 21:59:58 +0200 (CEST) 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 EC10F1678D02; Thu, 22 Sep 2011 21:59:57 +0200 (CEST) Message-ID: <4E7B93C3.1090101@skype.net> Date: Thu, 22 Sep 2011 13:00:03 -0700 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Cullen Jennings References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> <57CCCB06-F4C3-4E23-AF09-B7B5285C5FAE@phonefromhere.com> <4E7B8D9D.8060303@skype.net> <46B4E074-69C8-4B25-8348-F6951FF9725F@cisco.com> In-Reply-To: <46B4E074-69C8-4B25-8348-F6951FF9725F@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtcweb@ietf.org Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 19:57:29 -0000 On 9/22/11 12:53 PM, Cullen Jennings wrote: > Could you'd like to elaborate on how it works when one of the sides is an SIP endpoint, or we the two endpoint are at different domains that are federated? The server uses its knowledge of the web browser capabilities to generate an SDP offer and/or reply with an SDP answer as appropriate and then requests that the browser begin sending and/or prepare for receiving media as appropriate. This is exactly the same answer as "how does it work when you have an MGCP (or Skinny) device and you want to talk to a SIP endpoint or the other endpoint is at the far side of a SIP trunk" Matthew Kaufman From christer.holmberg@ericsson.com Thu Sep 22 13:02: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 6E05221F8C5B for ; Thu, 22 Sep 2011 13:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=-0.081, 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 JHfTU9nvlhqR for ; Thu, 22 Sep 2011 13:02:04 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A5A7521F8BA0 for ; Thu, 22 Sep 2011 13:02:03 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-b5-4e7b94d3ec29 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D0.92.20773.3D49B7E4; Thu, 22 Sep 2011 22:04:35 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 22 Sep 2011 22:04:34 +0200 From: Christer Holmberg To: 'Cullen Jennings' , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Thu, 22 Sep 2011 22:04:34 +0200 Thread-Topic: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism Thread-Index: Acx5YP+JUCZH0D7BRlGuTIXFoeMPVAAATOvg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45FBC@ESESSCMS0356.eemea.ericsson.se> References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> <4E7B7272.7020204@alvestrand.no> <18FFF339-E7EB-4EEB-BCD8-E6728A56A24A@cisco.com> In-Reply-To: <18FFF339-E7EB-4EEB-BCD8-E6728A56A24A@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] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 20:02:04 -0000 Hi Cullen,=20 >>> Magnus' analysis worries me a bit, because it seems to assume=20 >>> specific functionality in the gateway (tracking of state and ability=20 >>> to generate SIP messages depending on state). >>> It seems reasonably simple to build a gateway, but we quickly get to=20 >>> the point where we have to write standards for the gateway function=20 >>> .... which could lead us down rather deep ratholes. >>=20 >> Are we assuming that a media gateway will be required for RTP/media=20 >> communication between a WebRTC client (web browser) and a SIP node? >> If such decision is taken IMHO it's sad. > >My take is that most people want to make sure that a translator between SI= P and web stuff would only need to look at signalling - it would not touch = the media. I'm working on the asumption that is what any solution will look= like.=20 >So, no media GW.=20 If so, what is your assumption then regarding ICE? That the SIP nodes will = support ICE, or that the browser will be allowed to communicate with the SI= P nodes without enabling ICE? Regards, Christer From randell-ietf@jesup.org Thu Sep 22 13:05: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 4AEFA11E8099 for ; Thu, 22 Sep 2011 13:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 k97TjDnYMt35 for ; Thu, 22 Sep 2011 13:05:11 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id BB55811E8091 for ; Thu, 22 Sep 2011 13:05:11 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R6pYc-0004Ay-Uf for rtcweb@ietf.org; Thu, 22 Sep 2011 15:07:43 -0500 Message-ID: <4E7B94BC.7070203@jesup.org> Date: Thu, 22 Sep 2011 16:04:12 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com><16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com><8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com><4E76E078.5020708@jesup.org><8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com><4E77495E.4000409@jesup.org><4E774F92.4040405@jesup.org><8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com><4E778F1F.9090105@jesup.org><4E77C3EC.9060801@jesup.org> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> <2E239D6FCD033C4BAF15F386A979BF510F0F58@sonusinmail02.sonusnet.com> In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0F58@sonusinmail02.sonusnet.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 default signaling protocol [was RE: Aboutdefining a signaling protocol for WebRTC (or not)] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 20:05:12 -0000 On 9/22/2011 2:22 PM, Ravindran Parthasarathi wrote: > OK, let's take the game example... only 2-player games would be able to > use a simple rtcweb-SIP agent. Anything more than 2-player would want > to use the multi-party "conferencing" model of rtcweb, which can't even > be signaled with SIP today as far as I can tell. (not that I've thought > about it too much, but I can't see how it would without some changes to > SIP) > > In fact rtcweb client shall acts as conference un-aware client > in the conference model and game server acts as conference server. I > have worked in 3-party conference using SIP in the endpoint but I have > never seen endpoint acts as conference server. So, I may be missing > something here I've built videophones that do in-phone 3 or 4 way conferencing (bridging and mixing the audio and video). It can also be done without mixing by forwarding. I'm unclear on if that would be possible in webrtc; is there any way to loop around or mix audio/video from one PeerConnection to another. (You can always turn off AEC and loop the audio... ;-) -- Randell Jesup randell-ietf@jesup.org From fluffy@cisco.com Thu Sep 22 13:35: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 656AA1F0C6D for ; Thu, 22 Sep 2011 13:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=-1.110, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4N2iS7RSxZa for ; Thu, 22 Sep 2011 13:35:25 -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 098191F0C63 for ; Thu, 22 Sep 2011 13:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2078; q=dns/txt; s=iport; t=1316723877; x=1317933477; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4rIYbjI7NFftNctr/LzHwQjCOOEmeq4LhgvnUkRuZok=; b=erWl43iiz1Ie2n7HTEysgWIStEoXcJOgtTrcaynNbP57BA+d1yS7qkav bMTDnGljbUrR7bERjffRJACteOvG+5EBWW7qOLyloFhxbN3a8C1jWmck0 MdpTSGOlkmCUk/boQLu+BuVGuagC/YTs6WQF99db0ogXscNloHIEJEHE+ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF6ce06rRDoI/2dsb2JhbABCqAJ4gVMBAQEBAgESASc/EAtGVwYuB4dWlxoBniaGHWAEh3GLX4UfjC8 X-IronPort-AV: E=Sophos;i="4.68,425,1312156800"; d="scan'208";a="3742677" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 22 Sep 2011 20:37:57 +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 p8MKbuV8031494; Thu, 22 Sep 2011 20:37:56 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233D45FBC@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 22 Sep 2011 14:37:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <271E29CD-D561-4E29-9E2D-DD15B9461F98@cisco.com> References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> <4E7B7272.7020204@alvestrand.no> <18FFF339-E7EB-4EEB-BCD8-E6728A56A24A@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FBC@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 20:35:25 -0000 On Sep 22, 2011, at 2:04 PM, Christer Holmberg wrote: >=20 > Hi Cullen,=20 >=20 >>>> Magnus' analysis worries me a bit, because it seems to assume=20 >>>> specific functionality in the gateway (tracking of state and = ability=20 >>>> to generate SIP messages depending on state). >>>> It seems reasonably simple to build a gateway, but we quickly get = to=20 >>>> the point where we have to write standards for the gateway function=20= >>>> .... which could lead us down rather deep ratholes. >>>=20 >>> Are we assuming that a media gateway will be required for RTP/media=20= >>> communication between a WebRTC client (web browser) and a SIP node? >>> If such decision is taken IMHO it's sad. >>=20 >> My take is that most people want to make sure that a translator = between SIP and web stuff would only need to look at signalling - it = would not touch the media. I'm working on the asumption that is what any = solution will look like.=20 >> So, no media GW.=20 >=20 > If so, what is your assumption then regarding ICE? That the SIP nodes = will support ICE, or that the browser will be allowed to communicate = with the SIP nodes without enabling ICE? I see no way of solving the security problems without having ICE or = something more or less like it. Therefore, I'm working on the assumption = that it will only work if the SIP side supports ICE, or is front ended = by a SBC with media GW that does ICE. In the short term, there will be = some devices that don't do ICE but SIP devices are increasingly having = ICE added. Particularly SIP devices that are internet facing because the = need for NAT traversal.=20 I find requiring ICE to be a very unfortunate assumption to have to make = - obviously it reduces the number of legacy voip devices WebRTC devices = can talk to without an SBC but I don't see any way around this = limitation. Allowing web browsers inside the firewall to send packets to = an arbitrary address that is inside the firewall with no validation that = address speaks RTP is not acceptable.=20 From ibc@aliax.net Thu Sep 22 13:55: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 795101F0C6C for ; Thu, 22 Sep 2011 13:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[AWL=-0.592, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 1HxQdxJtCKGx for ; Thu, 22 Sep 2011 13:55:01 -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 E139F1F0C38 for ; Thu, 22 Sep 2011 13:55:00 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so1005105vcb.31 for ; Thu, 22 Sep 2011 13:57:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.175.229 with SMTP id cd5mr2438818vdc.363.1316725053066; Thu, 22 Sep 2011 13:57:33 -0700 (PDT) Received: by 10.220.94.200 with HTTP; Thu, 22 Sep 2011 13:57:33 -0700 (PDT) In-Reply-To: <271E29CD-D561-4E29-9E2D-DD15B9461F98@cisco.com> References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> <4E7B7272.7020204@alvestrand.no> <18FFF339-E7EB-4EEB-BCD8-E6728A56A24A@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FBC@ESESSCMS0356.eemea.ericsson.se> <271E29CD-D561-4E29-9E2D-DD15B9461F98@cisco.com> Date: Thu, 22 Sep 2011 22:57:33 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 20:55:01 -0000 2011/9/22 Cullen Jennings : > I see no way of solving the security problems without having ICE or somet= hing more or less like it. Therefore, I'm working on the assumption that it= will only work if the SIP side supports ICE, or is front ended by a SBC wi= th media GW that does ICE. In the short term, there will be some devices th= at don't do ICE but SIP devices are increasingly having ICE added. Particul= arly SIP devices that are internet facing because the need for NAT traversa= l. > > I find requiring ICE to be a very unfortunate assumption to have to make = - obviously it reduces the number of legacy voip devices WebRTC devices can= talk to without an SBC but I don't see any way around this limitation. All= owing web browsers inside the firewall to send packets to an arbitrary addr= ess that is inside the firewall with no validation that address speaks RTP = is not acceptable. Hi Cullen, if that is not so a problem in current SIP networks (most of the devices don't support ICE), why should it be so hard and critical for WebRTC browsers? (sorry if I miss something). Also there are cases in which the provider (the SIP provider) does some rewrite in both the SDP offer and answer in order to force the media path through a media gateway (RTP proxy). Would that be not feasible for WebRTC clients? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Thu Sep 22 15:18: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 053D211E80D7 for ; Thu, 22 Sep 2011 15:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 DrYRabckQy2O for ; Thu, 22 Sep 2011 15:18:51 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 49CCD11E80D4 for ; Thu, 22 Sep 2011 15:18:50 -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, 22 Sep 2011 18:21:20 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 22 Sep 2011 18:21:20 -0400 From: Hadriel Kaplan To: Magnus Westerlund Thread-Topic: [rtcweb] STUN for keep-alive - RTCP-less applications Thread-Index: AQHMeXXzIKUT9mUbYkyr0iQzRJ1k0w== Date: Thu, 22 Sep 2011 22:21:19 +0000 Message-ID: <44798144-2170-43CA-AF52-A46B878C3E6F@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> <0C42CC63-CA1A-4F64-B522-BC1DAB477471@acmepacket.com> <4E7B2A65.6090106@ericsson.com> <4D8061B7-16C5-439C-8911-E4F2046999B7@acmepacket.com> <4E7B5932.9020800@ericsson.com> In-Reply-To: <4E7B5932.9020800@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: "" , Colin Perkins Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 22:18:52 -0000 On Sep 22, 2011, at 11:50 AM, Magnus Westerlund wrote: > On 2011-09-22 15:34, Hadriel Kaplan wrote: >>=20 >> On Sep 22, 2011, at 8:30 AM, Magnus Westerlund wrote: >>=20 >>>> If the concern is just that the far-end is dead or terminated the >>>> call but the local side didn't get the memo, we can solve that >>>> other ways. >>>=20 >>> On the last issue, do you have a suggestion for how to achieve this >>> that isn't RTCP? >>=20 >> If we assume that a gateway to legacy has to handle ICE termination >> anyway, then it can send STUN indications during the call. The rtcweb >> browser can use those to see the far end is alive and expecting media >> on the 5-tuple. If we're worried about those being faked/spoofed by >> malicious server/JS, we can modify the indication mechanism (which >> could also allay ekr's concerns about consent refresh). >=20 > Yes, the question is if the indications are sufficient as their security > properties even when signed are a bit different from the STUN request > with answer. When I said "we can modify the indication mechanism", I meant we could exte= nd the way it works. Right now in ICE you send STUN Indications but don't = expect a response. We can change it to be a request/response model instead= , with some random cookie (or just the trans-id) that gets reflected in the= response to prevent spoofing. (but not the full-blown hash integrity stuff= ) -hadriel From HKaplan@acmepacket.com Thu Sep 22 15:52: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 C36F211E80C7 for ; Thu, 22 Sep 2011 15:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 Rym2dD9T7e0a for ; Thu, 22 Sep 2011 15:52:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 253A511E8098 for ; Thu, 22 Sep 2011 15:52:53 -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, 22 Sep 2011 18:55:25 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 22 Sep 2011 18:55:24 -0400 From: Hadriel Kaplan To: Christer Holmberg Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism Thread-Index: AQHMeXq2MKhYCusi80eyAB0xuXvE5w== Date: Thu, 22 Sep 2011 22:55:24 +0000 Message-ID: <8A8889E9-2C33-40DE-90E5-E8F468072F62@acmepacket.com> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FB9@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233D45FB9@ESESSCMS0356.eemea.ericsson.se> 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: <5A821EE3D60FB34C9BC21F241327DD35@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 22:52:54 -0000 On Sep 22, 2011, at 3:41 PM, Christer Holmberg wrote: >> The really hard part is knowing which stream to use/render/send-to, imho= . And putting that decision in the gateway isn't good - the best decider o= f that is probably the JS in the browser. >=20 > I am not sure whether the JS app would be able to make better decisions t= han the gateway - and I've never seen a SIP client which would allow the us= er to choose which early media to listen to.=20 But these aren't phone-call SIP clients - they're browsers. They can show = the multiple video streams in separate windows, for example. They can show= multiple chat sessions per fork too. Or they may just pick the most recen= t one and only display it. That's the nice thing about JS: the JS develope= r decides what the user experience model is like, based on what type of app= lication/service they're providing; as opposed to the IETF/W3C choosing for= them. > In my opinion the best thing would be if we could come up with some commo= n BCP, e.g. saying that media associated with the early dialog on which the= latest SDP answer was received is considered "active", and will be present= ed to the user etc.=20 That's not the whole problem though. Suppose it only forked to two agents:= Robert and Bob. Robert sent a 18x with SDP first and then Bob. So the rt= cweb browser starts off using Robert's, does ICE with Robert, etc., and the= n get's Bob's and starts using Bob's because it's fresher. Now Robert acce= pts the connection and/or Bob rejects it; how does the rtcweb browser rever= t to using Robert? =20 If the answer is "well the rtcweb browser had to keep state information abo= ut Robert's SDP/media info as well as about Bob's", then we're back to the = tricky part about PeerConnection having multiple media peers when it only e= xpected one; if we can solve that, then we've solved the basic issue at han= d. (I think... or I need more coffee) -hadriel From roman@telurix.com Thu Sep 22 16:22: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 DB27B21F8C11 for ; Thu, 22 Sep 2011 16:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOtTYM2J-WiI for ; Thu, 22 Sep 2011 16:22:04 -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 EB3A621F8BF3 for ; Thu, 22 Sep 2011 16:22:03 -0700 (PDT) Received: by ywa6 with SMTP id 6so2865276ywa.31 for ; Thu, 22 Sep 2011 16:24:36 -0700 (PDT) Received: by 10.100.82.6 with SMTP id f6mr2622079anb.52.1316733876211; Thu, 22 Sep 2011 16:24:36 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by mx.google.com with ESMTPS id z6sm34983991anf.22.2011.09.22.16.24.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 16:24:35 -0700 (PDT) Received: by gwj16 with SMTP id 16so2892368gwj.15 for ; Thu, 22 Sep 2011 16:24:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.4.170 with SMTP id l10mr6513267pbl.3.1316733874578; Thu, 22 Sep 2011 16:24:34 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Thu, 22 Sep 2011 16:24:34 -0700 (PDT) In-Reply-To: <8A8889E9-2C33-40DE-90E5-E8F468072F62@acmepacket.com> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FB9@ESESSCMS0356.eemea.ericsson.se> <8A8889E9-2C33-40DE-90E5-E8F468072F62@acmepacket.com> Date: Thu, 22 Sep 2011 19:24:34 -0400 Message-ID: From: Roman Shpount To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=bcaec5215f35dba64304ad8ffebe Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 22 Sep 2011 23:22:05 -0000 --bcaec5215f35dba64304ad8ffebe Content-Type: text/plain; charset=ISO-8859-1 > That's not the whole problem though. Suppose it only forked to two agents: Robert and Bob. Robert sent a 18x with SDP first and then Bob. So the rtcweb browser starts off using Robert's, does ICE with Robert, etc., and then get's Bob's and starts using Bob's because it's fresher. Now Robert accepts the connection and/or Bob rejects it; how does the rtcweb browser revert to using Robert? The rtc browser will update the connection with the answer it got in SIP 200 OK when Robert accepts the connection. There is nothing that prevents RTC from doing update to the final accepted party. This is not ideal but works most of the time. Alternative is when the second answer is received, update the stream with hold and start playing ring back locally. Once call is connected, update to the final answer. _____________ Roman Shpount On Thu, Sep 22, 2011 at 6:55 PM, Hadriel Kaplan wrote: > > On Sep 22, 2011, at 3:41 PM, Christer Holmberg wrote: > > >> The really hard part is knowing which stream to use/render/send-to, > imho. And putting that decision in the gateway isn't good - the best > decider of that is probably the JS in the browser. > > > > I am not sure whether the JS app would be able to make better decisions > than the gateway - and I've never seen a SIP client which would allow the > user to choose which early media to listen to. > > > But these aren't phone-call SIP clients - they're browsers. They can show > the multiple video streams in separate windows, for example. They can show > multiple chat sessions per fork too. Or they may just pick the most recent > one and only display it. That's the nice thing about JS: the JS developer > decides what the user experience model is like, based on what type of > application/service they're providing; as opposed to the IETF/W3C choosing > for them. > > > > In my opinion the best thing would be if we could come up with some > common BCP, e.g. saying that media associated with the early dialog on which > the latest SDP answer was received is considered "active", and will be > presented to the user etc. > > That's not the whole problem though. Suppose it only forked to two agents: > Robert and Bob. Robert sent a 18x with SDP first and then Bob. So the > rtcweb browser starts off using Robert's, does ICE with Robert, etc., and > then get's Bob's and starts using Bob's because it's fresher. Now Robert > accepts the connection and/or Bob rejects it; how does the rtcweb browser > revert to using Robert? > > If the answer is "well the rtcweb browser had to keep state information > about Robert's SDP/media info as well as about Bob's", then we're back to > the tricky part about PeerConnection having multiple media peers when it > only expected one; if we can solve that, then we've solved the basic issue > at hand. (I think... or I need more coffee) > > -hadriel > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec5215f35dba64304ad8ffebe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > That's not the whole problem though. =A0Suppose it only forked to = two=20 agents: Robert and Bob. =A0Robert sent a 18x with SDP first and then Bob.= =20 =A0So the rtcweb browser starts off using Robert's, does ICE with Rober= t,=20 etc., and then get's Bob's and starts using Bob's because it= 9;s fresher.=20 =A0Now Robert accepts the connection and/or Bob rejects it; how does the=20 rtcweb browser revert to using Robert?

The rtc browser will update t= he connection with the answer it got in SIP 200 OK when Robert accepts the = connection. There is nothing that prevents RTC from doing update to the fin= al accepted party. This is not ideal but works most of the time.

Alternative is when the second answer is received, update the stream wi= th hold and start playing ring back locally. Once call is connected, update= to the final answer.
_____________
Roman Shpount


On Thu, Sep 22, 2011 at 6:55 PM, Hadriel= Kaplan <HKa= plan@acmepacket.com> wrote:
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb

--bcaec5215f35dba64304ad8ffebe-- From jovass@adobe.com Thu Sep 22 17: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 B41C421F8493 for ; Thu, 22 Sep 2011 17:56:58 -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 YlYhvwb6Dcig for ; Thu, 22 Sep 2011 17:56:58 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id ABA7621F848D for ; Thu, 22 Sep 2011 17:56:56 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKTnvZ6CmNhwbI6ngIqd5eu7tIULtAyjLR@postini.com; Thu, 22 Sep 2011 17:59:30 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p8N0vnC7025245; Thu, 22 Sep 2011 17:57:50 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id p8N0wA2f001998; Thu, 22 Sep 2011 17:59:13 -0700 (PDT) Received: from nambx03.corp.adobe.com ([10.8.189.93]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Thu, 22 Sep 2011 17:58:42 -0700 From: Jozsef Vass To: Harald Alvestrand , "rtcweb@ietf.org" Date: Thu, 22 Sep 2011 17:58:41 -0700 Thread-Topic: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) Thread-Index: Acx4SYt+ix2J7Wv/QMyG+qfZHzwkrQBQeSqQ Message-ID: <0FEA137C08A9DF4781EEF745038C969430A51F6401@nambx03.corp.adobe.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <4E79A964.2050007@alvestrand.no> In-Reply-To: <4E79A964.2050007@alvestrand.no> 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 Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Sep 2011 00:56:58 -0000 I am in support of having some basic mechanism in the browser as part of rt= cweb to enable developers to quickly and easily setup media between partici= pants. Furthermore, if an API is too complex or too hard to use, people wil= l not use it or misuse it. I can only see a handful of companies developing= advanced calling feature on top of rtcweb, most people just want to have s= omething simple to work without caring too much about the details. Maybe it would be advantages to specify such a very basic use case, e.g., t= argeting gaming. It must work behind NATs using peer-to-peer media transpor= t (but fallback to media relay may not be required). Since it is targeting = closed community, there is no need for interoperability, there is no need f= or SIP, Jingle, etc. At the minimum, this would require a simple service fo= r ip address lookup and to aid NAT and firewall traversal. For example, when a user registers with this service, he/she is assigned an= identifier or blob. In order to communicate with another party, all they n= eed to do is to exchange this information (this can be done using websocket= , etc.) and setup media channel. There should be no need for parsing SDP, e= tc. Jozsef -----Original Message----- From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 Sent: Wednesday, September 21, 2011 2:08 AM To: rtcweb@ietf.org Subject: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE= : About defining a signaling protocol for WebRTC (or not)]) On 09/20/2011 09:28 AM, Sa=FAl Ibarra Corretg=E9 wrote: > On Sep 20, 2011, at 12:59 AM, Roman Shpount wrote: > >> Randell, >> >> What I fail to understand is in what way would adding signaling to the w= eb browser would make things easy to build? How is what you are proposing = better then 2 or 3 well written samples? >> >> On the other hand, if you decide to build such simple signaling interfac= e, depending on what use case you are trying to address you will end up wit= h very different libraries. You have to decide how complex you want to make= this library on the server vs the client side. You will need to decide if = the purpose of this library is to simplify browser-to-browser or browser-to= -PSTN calls. There is going to be a large number of very complex decisions = none of which have obvious answers and will greatly affect the overall libr= ary design. >> >> Most importantly, I think this is a misconception that you can build som= ething that can be developed in 20 lines or less and be useful. Real-time c= ommunication is order of magnitude more complex then most of the web relate= d applications. You need to deal with multiple event sources, deal with eve= nt collisions, negotiation failures, call state machines. And this is what = required for the basic call setups. Once you start dealing with transfers, = conferences, call status monitoring, things become even more complex. It is= almost impossible to develop something that is simple to use that serves m= ore then one or two specific use cases. If we try to invent something like = this we might never finish. > +1. > > If we add some signaling protocol to the browser to ease web developers t= hen someone might say "why don't we also add X, Y and Z". The browser only = needs the media plane, the signaling can be elsewhere, and it's far better = to have it elsewhere. > > As Roman pointed out, RTC applications are not something that can nor sho= uld be done in 20 lines of JS. It's just complex. If people want to make si= mple apps they can build a simple JS library using an invented simple proto= col. But RTCWeb shouldn't encourage this IMHO. Let me just say that I totally disagree on this point. The developers of applications that need audio and video capabilities are n= ot RTC developers. Their main focus and main skill set will lie elsewhere. In a little more than 20 lines of code, it is possible to set up a call usi= ng a variant form of the existing W3C API. I know, I have seen the code. Ot= her examples (in a slightly different variant) are part of the Ericsson dem= o. What's perhaps more important is that none of those 20+ lines mention anyth= ing about codecs, bit rates, congestion control or any of the numerous othe= r issues we've been hashing out. With the API we support, simple things MUST be simple. Complex things must = be possible. From roman@telurix.com Thu Sep 22 18: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 823CD21F8B3E for ; Thu, 22 Sep 2011 18:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=-1.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, 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 VDOdOTGag2JT for ; Thu, 22 Sep 2011 18:16:34 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B35A21F8B3A for ; Thu, 22 Sep 2011 18:16:34 -0700 (PDT) Received: by gxk19 with SMTP id 19so2911666gxk.31 for ; Thu, 22 Sep 2011 18:19:07 -0700 (PDT) Received: by 10.236.116.194 with SMTP id g42mr18742652yhh.0.1316740746869; Thu, 22 Sep 2011 18:19:06 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by mx.google.com with ESMTPS id p46sm14107502yhh.15.2011.09.22.18.19.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 18:19:06 -0700 (PDT) Received: by yic13 with SMTP id 13so2571415yic.31 for ; Thu, 22 Sep 2011 18:19:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.4.170 with SMTP id l10mr6765998pbl.3.1316740744726; Thu, 22 Sep 2011 18:19:04 -0700 (PDT) Received: by 10.68.55.39 with HTTP; Thu, 22 Sep 2011 18:19:04 -0700 (PDT) In-Reply-To: <0FEA137C08A9DF4781EEF745038C969430A51F6401@nambx03.corp.adobe.com> References: <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <4E77C3EC.9060801@jesup.org> <4E79A964.2050007@alvestrand.no> <0FEA137C08A9DF4781EEF745038C969430A51F6401@nambx03.corp.adobe.com> Date: Thu, 22 Sep 2011 21:19:04 -0400 Message-ID: From: Roman Shpount To: Jozsef Vass Content-Type: multipart/alternative; boundary=bcaec5215f3559ca2304ad9198a7 Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Sep 2011 01:16:35 -0000 --bcaec5215f3559ca2304ad9198a7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable With the API we are discussing (ie have methods to generate an offer, process an answer or answer update to the last generated offer, process the last offer refusal, process an offer and generate an answer to it) it is very simple to build a simple point to point RTC call: First client uses the API to generate an offer. First client sends this offer (at this point it does not matter if offer is JSON or SDP encoded, as long as client can get this description and encode it into something that can be send over http), using http post to a web server. Web server stores this offer into some type of storage (local file, in memory db) Second client pulls the web server using some sort of timer for an offer using http GET. As soon as offer is created and stored, web server reads the offer from the storage and sends it to the second client. Second client uses API to process the offer and generate an answer. Second client sends the answer to the web server using http post. Web server stores answer in the storage. After sending the offer first client is pulling web server for the offer using some sort of timer http get. As soon as answer is created and stored, web server reads the answer from the storage and sends it to the first client. First client gets an answer from the web server, passes it to the API as an answer to the last offer. Connection is setup!. No SIP is used. Application like this can be develope= d by a fifth grader as a homework project and installed on any shared hosting provider. If you have websockets or some other javascript eventing library you can make this a lot more interactive. If you do SIP on the other hand, you will end up with a the same or more work as a developer, will have to install a lot more software on the web server, will have to learn a whole bunch about new signaling protocols unti= l you figure out why things do not work. _____________ Roman Shpount On Thu, Sep 22, 2011 at 8:58 PM, Jozsef Vass wrote: > I am in support of having some basic mechanism in the browser as part of > rtcweb to enable developers to quickly and easily setup media between > participants. Furthermore, if an API is too complex or too hard to use, > people will not use it or misuse it. I can only see a handful of companie= s > developing advanced calling feature on top of rtcweb, most people just wa= nt > to have something simple to work without caring too much about the detail= s. > > Maybe it would be advantages to specify such a very basic use case, e.g., > targeting gaming. It must work behind NATs using peer-to-peer media > transport (but fallback to media relay may not be required). Since it is > targeting closed community, there is no need for interoperability, there = is > no need for SIP, Jingle, etc. At the minimum, this would require a simple > service for ip address lookup and to aid NAT and firewall traversal. > > For example, when a user registers with this service, he/she is assigned = an > identifier or blob. In order to communicate with another party, all they > need to do is to exchange this information (this can be done using > websocket, etc.) and setup media channel. There should be no need for > parsing SDP, etc. > > Jozsef > > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: Wednesday, September 21, 2011 2:08 AM > To: rtcweb@ietf.org > Subject: [rtcweb] "20 lines" (Re: RTCWeb default signaling protocol [was > RE: About defining a signaling protocol for WebRTC (or not)]) > > On 09/20/2011 09:28 AM, Sa=FAl Ibarra Corretg=E9 wrote: > > On Sep 20, 2011, at 12:59 AM, Roman Shpount wrote: > > > >> Randell, > >> > >> What I fail to understand is in what way would adding signaling to the > web browser would make things easy to build? How is what you are proposi= ng > better then 2 or 3 well written samples? > >> > >> On the other hand, if you decide to build such simple signaling > interface, depending on what use case you are trying to address you will = end > up with very different libraries. You have to decide how complex you want= to > make this library on the server vs the client side. You will need to deci= de > if the purpose of this library is to simplify browser-to-browser or > browser-to-PSTN calls. There is going to be a large number of very comple= x > decisions none of which have obvious answers and will greatly affect the > overall library design. > >> > >> Most importantly, I think this is a misconception that you can build > something that can be developed in 20 lines or less and be useful. Real-t= ime > communication is order of magnitude more complex then most of the web > related applications. You need to deal with multiple event sources, deal > with event collisions, negotiation failures, call state machines. And thi= s > is what required for the basic call setups. Once you start dealing with > transfers, conferences, call status monitoring, things become even more > complex. It is almost impossible to develop something that is simple to u= se > that serves more then one or two specific use cases. If we try to invent > something like this we might never finish. > > +1. > > > > If we add some signaling protocol to the browser to ease web developers > then someone might say "why don't we also add X, Y and Z". The browser on= ly > needs the media plane, the signaling can be elsewhere, and it's far bette= r > to have it elsewhere. > > > > As Roman pointed out, RTC applications are not something that can nor > should be done in 20 lines of JS. It's just complex. If people want to ma= ke > simple apps they can build a simple JS library using an invented simple > protocol. But RTCWeb shouldn't encourage this IMHO. > Let me just say that I totally disagree on this point. > > The developers of applications that need audio and video capabilities are > not RTC developers. Their main focus and main skill set will lie elsewher= e. > > In a little more than 20 lines of code, it is possible to set up a call > using a variant form of the existing W3C API. I know, I have seen the cod= e. > Other examples (in a slightly different variant) are part of the Ericsson > demo. > What's perhaps more important is that none of those 20+ lines mention > anything about codecs, bit rates, congestion control or any of the numero= us > other issues we've been hashing out. > > With the API we support, simple things MUST be simple. Complex things mus= t > be possible. > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --bcaec5215f3559ca2304ad9198a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable With the API we are discussing (ie have methods to generate an offer, proce= ss an answer or answer update to the last generated offer, process the last= offer refusal, process an offer and generate an answer to it) it is very s= imple to build a simple point to point RTC call:

First client uses the API to generate an offer.

First client sen= ds this offer (at this point it does not matter if offer is JSON or SDP enc= oded, as long as client can get this description and encode it into somethi= ng that can be send over http), using http post to a web server.

Web server stores this offer into some type of storage (local file, in = memory db)

Second client pulls the web server using some sort of tim= er for an offer using http GET.

As soon as offer is created and sto= red, web server reads the offer from the storage and sends it to the second= client.

Second client uses API to process the offer and generate an answer.
=
Second client sends the answer to the web server using http post.
Web server stores answer in the storage.

After sending the offer f= irst client is pulling web server for the offer using some sort of timer ht= tp get.

As soon as answer is created and stored, web server reads the answer fr= om the storage and sends it to the first client.

First client gets a= n answer from the web server, passes it to the API as an answer to the last= offer.

Connection is setup!. No SIP is used. Application like this can be deve= loped by a fifth grader as a homework project and installed on any shared h= osting provider. If you have websockets or some other javascript eventing l= ibrary you can make this a lot more interactive.

If you do SIP on the other hand, you will end up with a the same or mor= e work as a developer, will have to install a lot more software on the web = server, will have to learn a whole bunch about new signaling protocols unti= l you figure out why things do not work.
_____________
Roman Shpount


On Thu, Sep 22, 2011 at 8:58 PM, Jozsef = Vass <jovass@adobe= .com> wrote:
I am in support of having some basic mechanism in the browser as part of rt= cweb to enable developers to quickly and easily setup media between partici= pants. Furthermore, if an API is too complex or too hard to use, people wil= l not use it or misuse it. I can only see a handful of companies developing= advanced calling feature on top of rtcweb, most people just want to have s= omething simple to work without caring too much about the details.

Maybe it would be advantages to specify such a very basic use case, e.g., t= argeting gaming. It must work behind NATs using peer-to-peer media transpor= t (but fallback to media relay may not be required). Since it is targeting = closed community, there is no need for interoperability, there is no need f= or SIP, Jingle, etc. At the minimum, this would require a simple service fo= r ip address lookup and to aid NAT and firewall traversal.

For example, when a user registers with this service, he/she is assigned an= identifier or blob. In order to communicate with another party, all they n= eed to do is to exchange this information (this can be done using websocket= , etc.) and setup media channel. There should be no need for parsing SDP, e= tc.

Jozsef

-----Original Message-----
From: Harald Alvestrand [mailto:har= ald@alvestrand.no]
Sent: Wednesday, September 21, 2011 2:08 AM
To: rtcweb@ietf.org
Subject: [rtcweb] "20 lines" (Re: RTCWeb default signaling protoc= ol [was RE: About defining a signaling protocol for WebRTC (or not)])

On 09/20/2011 09:28 AM, Sa=FAl Ibarra Corretg=E9 wrote:
> On Sep 20, 2011, at 12:59 AM, Roman Shpount wrote:
>
>> Randell,
>>
>> What I fail to understand is in what way would adding signaling to= the web browser would =A0make things easy to build? How is what you are pr= oposing better then 2 or 3 well written samples?
>>
>> On the other hand, if you decide to build such simple signaling in= terface, depending on what use case you are trying to address you will end = up with very different libraries. You have to decide how complex you want t= o make this library on the server vs the client side. You will need to deci= de if the purpose of this library is to simplify browser-to-browser or brow= ser-to-PSTN calls. There is going to be a large number of very complex deci= sions none of which have obvious answers and will greatly affect the overal= l library design.
>>
>> Most importantly, I think this is a misconception that you can bui= ld something that can be developed in 20 lines or less and be useful. Real-= time communication is order of magnitude more complex then most of the web = related applications. You need to deal with multiple event sources, deal wi= th event collisions, negotiation failures, call state machines. And this is= what required for the basic call setups. Once you start dealing with trans= fers, conferences, call status monitoring, things become even more complex.= It is almost impossible to develop something that is simple to use that se= rves more then one or two specific use cases. If we try to invent something= like this we might never finish.
> +1.
>
> If we add some signaling protocol to the browser to ease web developer= s then someone might say "why don't we also add X, Y and Z". = The browser only needs the media plane, the signaling can be elsewhere, and= it's far better to have it elsewhere.
>
> As Roman pointed out, RTC applications are not something that can nor = should be done in 20 lines of JS. It's just complex. If people want to = make simple apps they can build a simple JS library using an invented simpl= e protocol. But RTCWeb shouldn't encourage this IMHO.
Let me just say that I totally disagree on this point.

The developers of applications that need audio and video capabilities are n= ot RTC developers. Their main focus and main skill set will lie elsewhere.<= br>
In a little more than 20 lines of code, it is possible to set up a call usi= ng a variant form of the existing W3C API. I know, I have seen the code. Ot= her examples (in a slightly different variant) are part of the Ericsson dem= o.
What's perhaps more important is that none of those 20+ lines mention a= nything about codecs, bit rates, congestion control or any of the numerous = other issues we've been hashing out.

With the API we support, simple things MUST be simple. Complex things must = be possible.




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

--bcaec5215f3559ca2304ad9198a7-- From christer.holmberg@ericsson.com Thu Sep 22 22: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 D401F21F8B42 for ; Thu, 22 Sep 2011 22:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 4MYuhXkW5LXQ for ; Thu, 22 Sep 2011 22:04:25 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 109F921F8B2D for ; Thu, 22 Sep 2011 22:04:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-a6-4e7c13f069c6 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 20.7D.02839.0F31C7E4; Fri, 23 Sep 2011 07:06:56 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 23 Sep 2011 07:06:56 +0200 From: Christer Holmberg To: Hadriel Kaplan Date: Fri, 23 Sep 2011 07:06:55 +0200 Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism Thread-Index: AQHMeXq2MKhYCusi80eyAB0xuXvE55VaZ/sg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233FB6BA9@ESESSCMS0356.eemea.ericsson.se> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FB9@ESESSCMS0356.eemea.ericsson.se> <8A8889E9-2C33-40DE-90E5-E8F468072F62@acmepacket.com> In-Reply-To: <8A8889E9-2C33-40DE-90E5-E8F468072F62@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Sep 2011 05:04:25 -0000 Hi,=20 >>> The really hard part is knowing which stream to=20 >>> use/render/send-to, imho. And putting that decision in the=20 >>> gateway isn't good - the best decider of that is probably the=20 >>> JS in the browser. >>=20 >> I am not sure whether the JS app would be able to make=20 >> better decisions than the gateway - and I've never seen a SIP=20 >> client which would allow the user to choose which early media=20 >> to listen to.=20 >=20 >=20 > But these aren't phone-call SIP clients - they're browsers. =20 > They can show the multiple video streams in separate windows,=20 > for example. They can show multiple chat sessions per fork=20 > too. Or they may just pick the most recent one and only=20 > display it. That's the nice thing about JS: the JS developer=20 > decides what the user experience model is like, based on what=20 > type of application/service they're providing; as opposed to=20 > the IETF/W3C choosing for them. Sure, but it would be good if network applications, that provide the early = media, could make assumptions on how the end user is going to process it. I= t would make life easier both for the network application designer and the = client application designer - AND the SBC designer, btw, if the SBC will ha= ve to make decisions on which media to forward towards the user :) >> In my opinion the best thing would be if we could come up=20 >> with some common BCP, e.g. saying that media associated with=20 >> the early dialog on which the latest SDP answer was received=20 >> is considered "active", and will be presented to the user etc.=20 >=20 > That's not the whole problem though. Suppose it only forked=20 > to two agents: Robert and Bob. Robert sent a 18x with SDP=20 > first and then Bob. So the rtcweb browser starts off using=20 > Robert's, does ICE with Robert, etc., and then get's Bob's=20 > and starts using Bob's because it's fresher. Now Robert=20 > accepts the connection and/or Bob rejects it; how does the=20 > rtcweb browser revert to using Robert? =20 >=20 > If the answer is "well the rtcweb browser had to keep state=20 > information about Robert's SDP/media info as well as about=20 > Bob's", then we're back to the tricky part about=20 > PeerConnection having multiple media peers when it only=20 > expected one; if we can solve that, then we've solved the=20 > basic issue at hand. (I think... or I need more coffee) The browser doesn't need to keep state - it only does what the JS app tells= it to do.=20 But, the JS app needs to keep state, so that it can then provide the SDP an= swer associated with Bob to the browser when the 200 OK comes. Regards, Christer From christer.holmberg@ericsson.com Thu Sep 22 22:06: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 2D02B21F8573 for ; Thu, 22 Sep 2011 22:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 H0447wVxQJJi for ; Thu, 22 Sep 2011 22:06: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 691F721F8569 for ; Thu, 22 Sep 2011 22:06:56 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a2-4e7c148866fc Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2A.F5.20773.8841C7E4; Fri, 23 Sep 2011 07:09:29 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 23 Sep 2011 07:09:28 +0200 From: Christer Holmberg To: Roman Shpount , Hadriel Kaplan Date: Fri, 23 Sep 2011 07:09:27 +0200 Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism Thread-Index: Acx5fs23NM/h1Wl4R+WqaPUYYR5+DQAL+Ohg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233FB6BAA@ESESSCMS0356.eemea.ericsson.se> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FB9@ESESSCMS0356.eemea.ericsson.se> <8A8889E9-2C33-40DE-90E5-E8F468072F62@acmepacket.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 X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Sep 2011 05:06:57 -0000 =20 Hi,=09 >> That's not the whole problem though. Suppose it only forked to two agen= ts: Robert and Bob. Robert sent a 18x with SDP first and then Bob. So the= rtcweb browser starts off using=20 >>>Robert's, does ICE with Robert, etc., and then get's Bob's and starts us= ing Bob's because it's fresher. Now Robert accepts the connection and/or B= ob rejects it; how does the rtcweb=20 >>browser revert to using Robert? >=09 >The rtc browser will update the connection with the answer it got in SIP 2= 00 OK when Robert accepts the connection. There is nothing that prevents RT= C from doing update to the final accepted=20 >party. This is not ideal but works most of the time.=20 The 200 OK may not contain the answer, so the JS app would need to store it= somewhere. But, the browser doesn't need to do it (unless the application = is built into the browser, of course). Regards, Christer From HKaplan@acmepacket.com Thu Sep 22 23:21: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 C59AB21F8A71 for ; Thu, 22 Sep 2011 23:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 6e58dVtt6tJ1 for ; Thu, 22 Sep 2011 23:21:50 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1075C21F8B2B for ; Thu, 22 Sep 2011 23:21:49 -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, 23 Sep 2011 02:24:21 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 23 Sep 2011 02:24:21 -0400 From: Hadriel Kaplan To: Christer Holmberg Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism Thread-Index: AQHMebluA6nZhH7+dkWMXmflLs0yGA== Date: Fri, 23 Sep 2011 06:24:21 +0000 Message-ID: References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FB9@ESESSCMS0356.eemea.ericsson.se> <8A8889E9-2C33-40DE-90E5-E8F468072F62@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233FB6BA9@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233FB6BA9@ESESSCMS0356.eemea.ericsson.se> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Sep 2011 06:21:50 -0000 On Sep 23, 2011, at 1:06 AM, Christer Holmberg wrote: > Sure, but it would be good if network applications, that provide the earl= y media, could make assumptions on how the end user is going to process it.= It would make life easier both for the network application designer and th= e client application designer - AND the SBC designer, btw, if the SBC will = have to make decisions on which media to forward towards the user :) If the "network application" you're talking about is provided by the same d= omain that runs the rtcweb server, then obviously they can "control" it, si= nce they wrote the JS script. If you're talking about when rtcweb domain A calls SIP/rtcweb domain B, and= domain B wants to control it, then obviously they can because domain B can= use an SBC, or control the offer/answer and media on their side some simil= ar way, and we don't need to say anything about that. But that wasn't my point... the discussion was around whether the rtcweb sy= stem as a whole (browser or browser+JS) had to be able to support media for= king cases, or not. And my point was yes, they do, because if they talk SI= P to domain B then they cannot *mandate* B not media fork calls, because th= at's like mandating B not send re-INVITEs. It's part of basic SIP, part of= its base spec. Even from a practical standpoint it's not something imagin= ary like S/MIME; media forking happens in practice all the time. Obviously my employer would be better off if SBCs were mandated for all SIP= communications, but it's not right to require them in an IETF spec/archite= cture. People should use them if they have a need to, not just because bro= wsers are too lazy to handle real SIP scenarios.=20 Imagine if Google deployed rtcweb, and Columbia University deployed a SIP s= ervice for all their students, with multiple contacts, forking, etc. Colum= bia goes to Google and says "can we peer using SIP"? And Google says "sure= , but you'll have to deploy something to hide media forking, re-INVITEs, et= c." Columbia says "but I thought you guys peer with SIP?" and Google says = "oh we do, but it's a lighter SIP granted to us by the IETF, because we use= browsers". Do you see how crazy that would be? > The browser doesn't need to keep state - it only does what the JS app tel= ls it to do.=20 > But, the JS app needs to keep state, so that it can then provide the SDP = answer associated with Bob to the browser when the 200 OK comes. I'm with you there, but methinks we've lost that battle already. The brows= er's going to be the SDP offer/answer engine, so now I'm at least hoping it= 's a real/full one and not some hybrid. As a side note, I'm not actually sure what would happen to ICE processing w= ith peers if the browser only has one media state at a given time, and swit= ches from Robert's SDP to Bob's and back to Robert's. Someone should try i= t with the chromium prototype, in different timing scenarios. Like what ha= ppens if the browser's ICE to Robert gets to a completed state, then the br= owser switches to Bob, and later back to Robert and the browser thinks ICE = starts again with Robert but Robert thinks it's over. -hadriel From magnus.westerlund@ericsson.com Fri Sep 23 00:06: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 A075F21F8B95 for ; Fri, 23 Sep 2011 00:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.527 X-Spam-Level: X-Spam-Status: No, score=-106.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 BCUkzswn9pCL for ; Fri, 23 Sep 2011 00:06:09 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A47E421F8B8A for ; Fri, 23 Sep 2011 00:06:08 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-98-4e7c3078fa70 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1F.47.20773.8703C7E4; Fri, 23 Sep 2011 09:08:41 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 09:08:40 +0200 Message-ID: <4E7C306F.8050009@ericsson.com> Date: Fri, 23 Sep 2011 09:08:31 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <4E799ECC.8030306@ericsson.com> <4E7B7272.7020204@alvestrand.no> In-Reply-To: <4E7B7272.7020204@alvestrand.no> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Sep 2011 07:06:09 -0000 On 2011-09-22 19:37, Harald Alvestrand wrote: > > Magnus' analysis worries me a bit, because it seems to assume specific > functionality in the gateway (tracking of state and ability to generate > SIP messages depending on state). > It seems reasonably simple to build a gateway, but we quickly get to the > point where we have to write standards for the gateway function .... > which could lead us down rather deep ratholes. > My intention was to show that the general functionality do work when combing an RTCWEB end-point and a SIP end-point. Yes, you need some functionality on the signaling plane to adopt the two worlds. I don't think it is that complex. The SIP GW may in fact be the Webapp itself that has a JS SIP stack and a bit of logic around that. It can also be in the webserver, or third signalling GW node that are connected to the webserver for the RTCWEB service. I think all of these cases works. Thus no need for standardizing the gateway function. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Sep 23 00:18: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 A66B421F8ABD for ; Fri, 23 Sep 2011 00:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 ErAt9rhbf8NQ for ; Fri, 23 Sep 2011 00:18:55 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9056A21F8ABB for ; Fri, 23 Sep 2011 00:18:54 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ce-4e7c337700f0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8C.99.20773.7733C7E4; Fri, 23 Sep 2011 09:21:27 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 09:21:27 +0200 Message-ID: <4E7C3375.2070404@ericsson.com> Date: Fri, 23 Sep 2011 09:21:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Randell Jesup References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se><4E70D2E6.1000809@alvestrand.no><7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se><092401cc749b$8fd64940$af82dbc0$@com><4E765E4A.3050801@alvestrand.no><0ced01cc76de$28731630$79594290$@com> <4E77613B.4020805@ericsson.com> <1D062974A4845E4D8A343C6538049202066497EF@XMB-BGL-414.cisco.com> <4E784C38.2010909@ericsson.com> <1D062974A4845E4D8A343C65380492020672C04A@XMB-BGL-414.cisco.com> <4E7B2C04.401 0204@eri csson.com> <1D062974A4845E4D8A343C65380492020672C08F@XMB-BGL-414.cisco.com> <4E7B4F91.8090409@jesup.org> <4E7B5A2F.8020102@ericss on.com> <4E7B6774.7040601@jesup.org> In-Reply-To: <4E7B6774.7040601@jesup.org> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Sep 2011 07:18:55 -0000 On 2011-09-22 18:51, Randell Jesup wrote: > I wonder: could we create a default reliable data channel in all > PeerConnections that's used (solely?) for a heartbeat/"consent freshness"? > In that case, we get to define the heartbeat and can mandate enough entropy. > (Receiving data on reliable SCTP (or TCP) over DTLS might be enough right there.) > The short answer is Yes, you can. But the longer answer is that it might imply limitations on what deployments are possible. First of all, this is only in reality practical when you only have a single 5-tuple in use between the peers. If you don't multiplex all flows on a single 5-tuple then you will need both consent and keep-alive for each bi-directional flow the 5-tuple represents. Secondly, for any consent freshness / heartbeat you do need to transmit regularly. And considering common NAT timers for UDP we do need to have keep-alives no less often than every 15 seconds to try to ensure that the very aggressive timers of 30 seconds don't disconnect the session. Thirdly one are using resources both in establishing this reliable data channel, and then when using it for this function. Yes, you will spend some resources on heartbeat in all cases. But you might have to do it for multiple flow and then the reliable is an additional flow to keep-alive if it isn't used for anything else. So I am not thrilled of establishing an additional flow just for consent freshness. In fact I am not thrilled by the PeerConnections default UDP unreliable channel and believe the transports should be only enabled upon demand from the application for such a transport. I do see a simplicity in using ICE for keep-alive and consent freshness as this is likely applicable for all transport protocols that we need (as they will be over UDP) and aren't TCP to a relay or server. I do also notice that there are desire for alternative solutions. Lets keeps the discussion going. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From harald@alvestrand.no Fri Sep 23 02:30: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 CD85E21F8573 for ; Fri, 23 Sep 2011 02:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.805 X-Spam-Level: X-Spam-Status: No, score=-108.805 tagged_above=-999 required=5 tests=[AWL=1.794, 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 QI1Eec2KMQOW for ; Fri, 23 Sep 2011 02:30:57 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E3A9D21F84AC for ; Fri, 23 Sep 2011 02:30:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1C09F39E0C4; Fri, 23 Sep 2011 11:33:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgwCiXfSrUw0; Fri, 23 Sep 2011 11:33:29 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 71CDB39E0BC; Fri, 23 Sep 2011 11:33:29 +0200 (CEST) Message-ID: <4E7C5269.8050100@alvestrand.no> Date: Fri, 23 Sep 2011 11:33:29 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Magnus Westerlund References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se><7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se><4E70D2E6.1000809@alvestrand.no><7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se><092401cc749b$8fd64940$af82dbc0$@com><4E765E4A.3050801@alvestrand.no><0ced01cc76de$28731630$79594290$@com> <4E77613B.4020805@ericsson.com> <1D062974A4845E4D8A343C6538049202066497EF@XMB-BGL-414.cisco.com> <4E784C38.2010909@ericsson.com> <1D062974A4845E4D8A343C65380492020672C04A@XMB-BGL-414.cisco.com> <4E7B2C04.401 0204@eri csson.com> <1D062974A4845E4D8A343C65380492020672C08F@XMB-BGL-414.cisco.com> <4E7B4F91.8090409@jesup.org> <4E7B5A2F.8020102@ericss on.com> <4E7B6774.7040601@jesup.org> <4E7C3375.2070404@ericsson .com> In-Reply-To: <4E7C3375.2070404@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Randell Jesup , "rtcweb@ietf.org" Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Sep 2011 09:30:57 -0000 On 09/23/11 09:21, Magnus Westerlund wrote: > On 2011-09-22 18:51, Randell Jesup wrote: >> I wonder: could we create a default reliable data channel in all >> PeerConnections that's used (solely?) for a heartbeat/"consent freshness"? >> In that case, we get to define the heartbeat and can mandate enough entropy. >> (Receiving data on reliable SCTP (or TCP) over DTLS might be enough right there.) >> > The short answer is Yes, you can. But the longer answer is that it might > imply limitations on what deployments are possible. > > First of all, this is only in reality practical when you only have a > single 5-tuple in use between the peers. If you don't multiplex all > flows on a single 5-tuple then you will need both consent and keep-alive > for each bi-directional flow the 5-tuple represents. > > Secondly, for any consent freshness / heartbeat you do need to transmit > regularly. And considering common NAT timers for UDP we do need to have > keep-alives no less often than every 15 seconds to try to ensure that > the very aggressive timers of 30 seconds don't disconnect the session. > > Thirdly one are using resources both in establishing this reliable data > channel, and then when using it for this function. Yes, you will spend > some resources on heartbeat in all cases. But you might have to do it > for multiple flow and then the reliable is an additional flow to > keep-alive if it isn't used for anything else. And fourthly, any spec that requires a heartbeat channel on the media path mandates a media path gateway in order to interoperate with non-RTCWEB devices. > So I am not thrilled of establishing an additional flow just for consent > freshness. In fact I am not thrilled by the PeerConnections default UDP > unreliable channel and believe the transports should be only enabled > upon demand from the application for such a transport. We're removing it from the API spec. Whether or not it's mandated, that's not the right place to mandate it. > I do see a simplicity in using ICE for keep-alive and consent freshness > as this is likely applicable for all transport protocols that we need > (as they will be over UDP) and aren't TCP to a relay or server. > > I do also notice that there are desire for alternative solutions. > > Lets keeps the discussion going. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Frgatan 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 harald@alvestrand.no Fri Sep 23 02:44: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 0D6A121F8B37 for ; Fri, 23 Sep 2011 02:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.831 X-Spam-Level: X-Spam-Status: No, score=-108.831 tagged_above=-999 required=5 tests=[AWL=1.768, 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 6j49dyP8+XQT for ; Fri, 23 Sep 2011 02:44:56 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 67F5A21F8B20 for ; Fri, 23 Sep 2011 02:44:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E237739E0C4 for ; Fri, 23 Sep 2011 11:47:29 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfQIzbCa6RZo for ; Fri, 23 Sep 2011 11:47:29 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 3508139E0BC for ; Fri, 23 Sep 2011 11:47:29 +0200 (CEST) Message-ID: <4E7C55B1.4050704@alvestrand.no> Date: Fri, 23 Sep 2011 11:47:29 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FB9@ESESSCMS0356.eemea.ericsson.se> <8A8889E9-2C33-40DE-90E5-E8F468072F62@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233FB6BA9@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233FB6BA9@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Sep 2011 09:44:57 -0000 On 09/23/11 07:06, Christer Holmberg wrote: > Hi, > >>>> The really hard part is knowing which stream to >>>> use/render/send-to, imho. And putting that decision in the >>>> gateway isn't good - the best decider of that is probably the >>>> JS in the browser. >>> I am not sure whether the JS app would be able to make >>> better decisions than the gateway - and I've never seen a SIP >>> client which would allow the user to choose which early media >>> to listen to. >> >> But these aren't phone-call SIP clients - they're browsers. >> They can show the multiple video streams in separate windows, >> for example. They can show multiple chat sessions per fork >> too. Or they may just pick the most recent one and only >> display it. That's the nice thing about JS: the JS developer >> decides what the user experience model is like, based on what >> type of application/service they're providing; as opposed to >> the IETF/W3C choosing for them. > Sure, but it would be good if network applications, that provide the early media, could make assumptions on how the end user is going to process it. If the network application (whatever that is) delivered the JS to the end-user that does the presentation, the network application knows exactly how the end user is going to process it (modulo various forms of JS local override tricks that browsers and users play). If the network application didn't, then we're dealing with a proposal for an application that may be implemented on top of RTCWEB, but in my opinion, we shouldn't encode that into the browser specs. In other words - "all bets are off". From christer.holmberg@ericsson.com Fri Sep 23 03:47: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 69AA921F8A62 for ; Fri, 23 Sep 2011 03:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 xecI5Oc2dAao for ; Fri, 23 Sep 2011 03:47:43 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3E48B21F8531 for ; Fri, 23 Sep 2011 03:47:43 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-71-4e7c64688737 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B8.40.20773.8646C7E4; Fri, 23 Sep 2011 12:50:16 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 23 Sep 2011 12:50:15 +0200 From: Christer Holmberg To: Hadriel Kaplan Date: Fri, 23 Sep 2011 12:50:14 +0200 Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism Thread-Index: AQHMebluA6nZhH7+dkWMXmflLs0yGJVaxZmA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233FB6EA2@ESESSCMS0356.eemea.ericsson.se> References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FB9@ESESSCMS0356.eemea.ericsson.se> <8A8889E9-2C33-40DE-90E5-E8F468072F62@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233FB6BA9@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: "rtcweb@ietf.org" Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Sep 2011 10:47:44 -0000 Hi,=20 >> Sure, but it would be good if network applications, that=20 >> provide the early media, could make assumptions on how the end user is g= oing to=20 >> process it. It would make life easier both for the network=20 >> application designer and the client application designer - AND the SBC=20 >> designer, btw, if the SBC will have to make decisions on which media=20 >> to forward towards the user :) >=20 > If the "network application" you're talking about is provided=20 > by the same domain that runs the rtcweb server, then=20 > obviously they can "control" it, since they wrote the JS script. > > If you're talking about when rtcweb domain A calls SIP/rtcweb=20 > domain B, and domain B wants to control it, then obviously=20 > they can because domain B can use an SBC, or control the=20 > offer/answer and media on their side some similar way, and we=20 > don't need to say anything about that. Sure, you can control the offer/answer. My point was that it would be good = if everyone had a common understanding on how the offer/answers will be con= trolled. But, of course, as long as the JS app and the network application is provid= ed by the same provider, things would work. > But that wasn't my point... the discussion was around whether=20 > the rtcweb system as a whole (browser or browser+JS) had to=20 > be able to support media forking cases, or not. And my point=20 > was yes, they do, because if they talk SIP to domain B then=20 > they cannot *mandate* B not media fork calls, because that's=20 > like mandating B not send re-INVITEs. It's part of basic=20 > SIP, part of its base spec. Even from a practical standpoint=20 > it's not something imaginary like S/MIME; media forking=20 > happens in practice all the time. I agree that we somehow need to support forking, meaning that we on the sig= nalling level need to be able to handle multiple early dialogs. On the media plane, we also need to be able to switch from one remote media= source to another, but the question is still whether the browser, and the = PeerConnection API, needs to support *simultanous* media from multiple remo= te sources. > Obviously my employer would be better off if SBCs were=20 > mandated for all SIP communications, but it's not right to=20 > require them in an IETF spec/architecture. People should use=20 > them if they have a need to, not just because browsers are=20 > too lazy to handle real SIP scenarios.=20 >=20 > Imagine if Google deployed rtcweb, and Columbia University=20 > deployed a SIP service for all their students, with multiple=20 > contacts, forking, etc. Columbia goes to Google and says=20 > "can we peer using SIP"? And Google says "sure, but you'll=20 > have to deploy something to hide media forking, re-INVITEs,=20 > etc." Columbia says "but I thought you guys peer with SIP?"=20 > and Google says "oh we do, but it's a lighter SIP granted to=20 > us by the IETF, because we use browsers". Do you see how=20 > crazy that would be? Yes, and I am not suggesting anything like that :) >> The browser doesn't need to keep state - it only does what=20 >> the JS app tells it to do.=20 >> But, the JS app needs to keep state, so that it can then=20 >> provide the SDP answer associated with Bob to the browser=20 >> when the 200 OK comes. >=20 > I'm with you there, but methinks we've lost that battle=20 > already. The browser's going to be the SDP offer/answer=20 > engine, so now I'm at least hoping it's a real/full one and=20 > not some hybrid. I am not sure I understand what you mean by the browser being the SDP offer= /answer engine. Just because we would use offer/answer between the browser and the JS app, = it doesn't mean we have to support multiple dialogs on that interface. >As a side note, I'm not actually sure what would happen to=20 >ICE processing with peers if the browser only has one media=20 >state at a given time, and switches from Robert's SDP to=20 >Bob's and back to Robert's. Someone should try it with the=20 >chromium prototype, in different timing scenarios. Like what=20 >happens if the browser's ICE to Robert gets to a completed=20 >state, then the browser switches to Bob, and later back to=20 >Robert and the browser thinks ICE starts again with Robert=20 >but Robert thinks it's over. ICE is one of the impacts that we would need to consider, because what migh= t happen is that when you switch from one remote media source to another ev= erything (ICE, media security etc) is lost. ...unless, of course, the gateway relays all media, and handles the switchi= ng between remote media sources. Regards, Christer From stefan.lk.hakansson@ericsson.com Fri Sep 23 03: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 2833921F8BA7 for ; Fri, 23 Sep 2011 03:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=-0.036, 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 4sJN5wPnNkbm for ; Fri, 23 Sep 2011 03:48:11 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 332A021F8A95 for ; Fri, 23 Sep 2011 03:48:11 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-de-4e7c6484baad Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4B.50.20773.4846C7E4; Fri, 23 Sep 2011 12:50:44 +0200 (CEST) Received: from [150.132.141.36] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Fri, 23 Sep 2011 12:50:44 +0200 Message-ID: <4E7C6483.8060106@ericsson.com> Date: Fri, 23 Sep 2011 12:50:43 +0200 From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: rtcweb@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se><4E70D2E6.1000809@alvestrand.no><7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se><092401cc749b$8fd64940$af82dbc0$@com><4E765E4A.3050801@alvestrand.no><0ced01cc76de$28731630$79594290$@com> <4E77613B.4020805@ericsson.com> <1D062974A4845E4D8A343C6538049202066497EF@XMB-BGL-414.cisco.com> <4E784C38.2010909@ericsson.com> <1D062974A4845E4D8A343C65380492020672C04A@XMB-BGL-414.cisco.com> <4E7B2C04.401 0204@eri csson.com> <1D062974A4845E4D8A343C65380492020672C08F@XMB-BGL-414.cisco.com> <4E7B4F91.8090409@jesup.org> <4E7B5A2F.8020102@ericss on.com> <4E7B6774.7040601@jesup.org> <4E7C3375.2070404@ericsson .com> <4E7C5269.8050100@alvestrand.no> In-Reply-To: <4E7C5269.8050100@alvestrand.no> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [rtcweb] consent freshness [was RE: STUN for keep-alive] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Sep 2011 10:48:12 -0000 On 2011-09-23 11:33, Harald Alvestrand wrote: > On 09/23/11 09:21, Magnus Westerlund wrote: >> On 2011-09-22 18:51, Randell Jesup wrote: >>> I wonder: could we create a default reliable data channel in all >>> PeerConnections that's used (solely?) for a heartbeat/"consent freshness"? >>> In that case, we get to define the heartbeat and can mandate enough entropy. >>> (Receiving data on reliable SCTP (or TCP) over DTLS might be enough right there.) >>> >> The short answer is Yes, you can. But the longer answer is that it might >> imply limitations on what deployments are possible. >> >> First of all, this is only in reality practical when you only have a >> single 5-tuple in use between the peers. If you don't multiplex all >> flows on a single 5-tuple then you will need both consent and keep-alive >> for each bi-directional flow the 5-tuple represents. >> >> Secondly, for any consent freshness / heartbeat you do need to transmit >> regularly. And considering common NAT timers for UDP we do need to have >> keep-alives no less often than every 15 seconds to try to ensure that >> the very aggressive timers of 30 seconds don't disconnect the session. >> >> Thirdly one are using resources both in establishing this reliable data >> channel, and then when using it for this function. Yes, you will spend >> some resources on heartbeat in all cases. But you might have to do it >> for multiple flow and then the reliable is an additional flow to >> keep-alive if it isn't used for anything else. > And fourthly, any spec that requires a heartbeat channel on the media > path mandates a media path gateway in order to interoperate with > non-RTCWEB devices. >> So I am not thrilled of establishing an additional flow just for consent >> freshness. In fact I am not thrilled by the PeerConnections default UDP >> unreliable channel and believe the transports should be only enabled >> upon demand from the application for such a transport. > We're removing it from the API spec. Right. But just for clarity, we're not removing the "default connection". Creating a PeerConnection will result in a connection (naturally the app in the other browser must also create a PC, and the signaling messages must be passed between them and so on for it to happen) being set up. My assumption has been that it is set up and kept alive using ICE, but I guess other methods are discussed. > Whether or not it's mandated, that's not the right place to mandate it. >> I do see a simplicity in using ICE for keep-alive and consent freshness >> as this is likely applicable for all transport protocols that we need >> (as they will be over UDP) and aren't TCP to a relay or server. >> >> I do also notice that there are desire for alternative solutions. >> >> Lets keeps the discussion going. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Frgatan 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 Fri Sep 23 05:55: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 E5A3A21F8C2D for ; Fri, 23 Sep 2011 05:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.856 X-Spam-Level: X-Spam-Status: No, score=-108.856 tagged_above=-999 required=5 tests=[AWL=1.743, 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 KsqJoasl-JJC for ; Fri, 23 Sep 2011 05:55:59 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 5099921F8BEE for ; Fri, 23 Sep 2011 05:55:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2754E39E0C4 for ; Fri, 23 Sep 2011 14:58:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkThNibpC0tW for ; Fri, 23 Sep 2011 14:58:31 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id BE23E39E0BC for ; Fri, 23 Sep 2011 14:58:31 +0200 (CEST) Message-ID: <4E7C8277.9000902@alvestrand.no> Date: Fri, 23 Sep 2011 14:58:31 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: "rtcweb@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [rtcweb] Another approach to forking... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Sep 2011 12:56:00 -0000 Just to confuse the forking issue still further: If the APIs remain as they are today, a JS application that wants to support forking can do the following: - Create a PeerConnection - Cause it to generate an SDP blob ("SDP OFFER") - Send that SDP blob out to be forked - Throw away the PeerConnection - As the answers come back, for each answer: - Create a new PeerConnection - Take out the SDP blob, put "SDP OFFER" at the top, and give it to the PeerConnection - Throw away the generated "SDP ANSWER" Then connect all the media to output devices as appropriate, and shut them down one by one as the application decides that these were not the connections that would last. For extra safety, cause the PeerConnection to do a renegotiation at an appropriate time, so that both sides have seen an SDP OFFER/ANSWER exchange that actually came from the other side. It requires a little bit of insight into the SDP offer/answer model, and it's a pity to have to resort to string manipulation at any level, but .... it doesn't seem anywhere near impossible. Not even particularly architecture-breaking. Harald From HKaplan@acmepacket.com Fri Sep 23 06:23: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 CEC9321F8BA8 for ; Fri, 23 Sep 2011 06:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, J_CHICKENPOX_25=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 AM1yYwD7hZyY for ; Fri, 23 Sep 2011 06:23:15 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAB021F8B1E for ; Fri, 23 Sep 2011 06:23:15 -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, 23 Sep 2011 09:25:47 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 23 Sep 2011 09:25:46 -0400 From: Hadriel Kaplan To: Harald Alvestrand Thread-Topic: [rtcweb] Another approach to forking... Thread-Index: AQHMefRNEfPyrR9P3kauDT2dWYY7CA== Date: Fri, 23 Sep 2011 13:25:46 +0000 Message-ID: <2DB2EECF-82F3-4D36-AD17-6891CDAACBBF@acmepacket.com> References: <4E7C8277.9000902@alvestrand.no> In-Reply-To: <4E7C8277.9000902@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Another approach to forking... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Sep 2011 13:23:15 -0000 On Sep 23, 2011, at 8:58 AM, Harald Alvestrand wrote: > Just to confuse the forking issue still further: >=20 > If the APIs remain as they are today, a JS application that wants to supp= ort forking can do the following: >=20 > - Create a PeerConnection > - Cause it to generate an SDP blob ("SDP OFFER") > - Send that SDP blob out to be forked > - Throw away the PeerConnection > - As the answers come back, for each answer: > - Create a new PeerConnection > - Take out the SDP blob, put "SDP OFFER" at the top, and give it to the = PeerConnection By this you mean take the answer and make it appear as an offer to PeerConn= , right? > - Throw away the generated "SDP ANSWER" But wouldn't the new PeerConn's be creating new ICE ufrag/passwords that wo= n't match the one it created in the original PeerConn's offer, and thus not= be able to successfully negotiate ICE with the peer(s)? And doesn't PeerConn create/allocate the IP:ports used for MediaStreams? I= f so, each new PeerConn would also presumably be using a new UDP listen por= t and break this. -hadriel From harald@alvestrand.no Fri Sep 23 06: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 33BE721F8C3C for ; Fri, 23 Sep 2011 06:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.581 X-Spam-Level: X-Spam-Status: No, score=-108.581 tagged_above=-999 required=5 tests=[AWL=1.418, BAYES_00=-2.599, J_CHICKENPOX_25=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 ZXuX9ULXPbG0 for ; Fri, 23 Sep 2011 06:28:22 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9510E21F8B92 for ; Fri, 23 Sep 2011 06:28:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 743A139E112; Fri, 23 Sep 2011 15:30:55 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwHAyaybIAqE; Fri, 23 Sep 2011 15:30:54 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 3EEE439E0C4; Fri, 23 Sep 2011 15:30:54 +0200 (CEST) Message-ID: <4E7C8A0D.2010307@alvestrand.no> Date: Fri, 23 Sep 2011 15:30:53 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E7C8277.9000902@alvestrand.no> <2DB2EECF-82F3-4D36-AD17-6891CDAACBBF@acmepacket.com> In-Reply-To: <2DB2EECF-82F3-4D36-AD17-6891CDAACBBF@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Another approach to forking... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Sep 2011 13:28:23 -0000 On 09/23/11 15:25, Hadriel Kaplan wrote: > On Sep 23, 2011, at 8:58 AM, Harald Alvestrand wrote: > >> Just to confuse the forking issue still further: >> >> If the APIs remain as they are today, a JS application that wants to support forking can do the following: >> >> - Create a PeerConnection >> - Cause it to generate an SDP blob ("SDP OFFER") >> - Send that SDP blob out to be forked >> - Throw away the PeerConnection >> - As the answers come back, for each answer: >> - Create a new PeerConnection >> - Take out the SDP blob, put "SDP OFFER" at the top, and give it to the PeerConnection > By this you mean take the answer and make it appear as an offer to PeerConn, right? > > >> - Throw away the generated "SDP ANSWER" > But wouldn't the new PeerConn's be creating new ICE ufrag/passwords that won't match the one it created in the original PeerConn's offer, and thus not be able to successfully negotiate ICE with the peer(s)? > > And doesn't PeerConn create/allocate the IP:ports used for MediaStreams? If so, each new PeerConn would also presumably be using a new UDP listen port and break this. Oops. There was something I'd forgotten. You're right - it won't work unless we create PeerConnections from the initial PeerConnection so that they can clone the ICE data and share the port. Back to the drawing board. Thanks! (in a previous API discussion I suggested a PeerConnectionFactory class.... nobody liked it at the time...) From randell-ietf@jesup.org Fri Sep 23 08:30: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 62BF821F8CD3 for ; Fri, 23 Sep 2011 08:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 pkweubRLM45O for ; Fri, 23 Sep 2011 08:30:32 -0700 (PDT) Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 589BA21F8CD0 for ; Fri, 23 Sep 2011 08:30:32 -0700 (PDT) Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1R77kQ-0002tF-7R for rtcweb@ietf.org; Fri, 23 Sep 2011 10:33:06 -0500 Message-ID: <4E7CA5DD.4060302@jesup.org> Date: Fri, 23 Sep 2011 11:29:33 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: rtcweb@ietf.org References: <4E7C8277.9000902@alvestrand.no> In-Reply-To: <4E7C8277.9000902@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] Another approach to forking... X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 23 Sep 2011 15:30:33 -0000 On 9/23/2011 8:58 AM, Harald Alvestrand wrote: > Just to confuse the forking issue still further: > > If the APIs remain as they are today, a JS application that wants to > support forking can do the following: > > - Create a PeerConnection > - Cause it to generate an SDP blob ("SDP OFFER") > - Send that SDP blob out to be forked > - Throw away the PeerConnection > - As the answers come back, for each answer: > - Create a new PeerConnection > - Take out the SDP blob, put "SDP OFFER" at the top, and give it to > the PeerConnection > - Throw away the generated "SDP ANSWER" > > Then connect all the media to output devices as appropriate, and shut > them down one by one as the application decides that these were not > the connections that would last. > > For extra safety, cause the PeerConnection to do a renegotiation at an > appropriate time, so that both sides have seen an SDP OFFER/ANSWER > exchange that actually came from the other side. > > It requires a little bit of insight into the SDP offer/answer model, > and it's a pity to have to resort to string manipulation at any level, > but .... it doesn't seem anywhere near impossible. Not even > particularly architecture-breaking. Evil (kinda), but effective in practice. I'd prefer the ability to effectively 'clone' a PeerConnection object on receipt of (another) speculative answer (see my earlier proposal), removing the need to play games like above. This requires keeping in the PeerConnection any necessary state to reproduce the necessary object state on a new speculative (or final) answer. Seems fairly straightforward. Alternatively you could use a model where an offer was done via a PeerConnectionOffer object, and on a (speculative or final) answer a connected PeerConnection object is produced by it. When the app is done and has decided "no more forks accepted" (for example on an ACCEPT per my proposal), it would kill the PeerConnectionOffer and any PeerConnections it didn't want to keep. This is a bit 'cleaner' an API in my mind than just PeerConnections with some sort of fork/clone method, but that's minor and a personal preference. -- Randell Jesup randell-ietf@jesup.org From oej@edvina.net Sat Sep 24 04:49: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 E531221F8B3A for ; Sat, 24 Sep 2011 04:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 QJcq11iF543g for ; Sat, 24 Sep 2011 04:49:23 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 14A6221F8B39 for ; Sat, 24 Sep 2011 04:49:23 -0700 (PDT) Received: from [10.135.234.23] (213-205-77-102.static.net.novis.pt [213.205.77.102]) by smtp7.webway.se (Postfix) with ESMTPA id 35854754BCE4; Sat, 24 Sep 2011 11:51:53 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_ED103BF4-3318-43D9-833A-12F8EC55983C" From: "Olle E. Johansson" In-Reply-To: Date: Sat, 24 Sep 2011 13:51:52 +0200 Message-Id: <7DEACFFC-8AF3-4450-8844-FF6E187AE4D2@edvina.net> References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <092401cc749b$8fd64940$af82dbc0$@com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com> <4E7AE83E.9090508@ericsson.com> <0C42CC63-CA1A-4F64-B522-BC1DAB477471@acmepacket.com > To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1244.3) Cc: "" , Colin Perkins Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-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, 24 Sep 2011 11:49:24 -0000 --Apple-Mail=_ED103BF4-3318-43D9-833A-12F8EC55983C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 22 sep 2011 kl. 13:08 skrev I=F1aki Baz Castillo: > I can understand that some requirements can be imposed to RTCweb > environments in the media plane, but try at least to make it > compatible with VoIP networks out there. For example, requiring SRTP o > ZRTP could make sense (anyhow I don't see why that should be a > requirement in a local intranet in which plain-RTP is already used for > SIP communication). This is where you get it wrong. You are pushing the decision to the = user. They have to evaluate the network their browser is currently attached to and make a decision on what kind = of security they=20 need for this particular network. Even in the office, the iPad on your = desk might be connected to 3G because it lost contact with the wifi.=20 I think we can not require that users are able to perform a security = evaluation of each and every network the device their browser is running on connects to. Make = it secure by default. I mean, this is the year 2011 and we do have CPUs that can handle it. = People walk around with dual core in their pockets. /O= --Apple-Mail=_ED103BF4-3318-43D9-833A-12F8EC55983C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
I can = understand that some requirements can be imposed to = RTCweb
environments in the media plane, but try at least to make = it
compatible with VoIP networks out there. For example, requiring = SRTP o
ZRTP could make sense (anyhow I don't see why that should be = a
requirement in a local intranet in which plain-RTP is already used = for
SIP communication).